On Monday 16 May 2016 12:19:00 Sricharan R wrote:
> diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
> index f7b4c11..1240a5a 100644
> --- a/drivers/iommu/msm_iommu.c
> +++ b/drivers/iommu/msm_iommu.c
> @@ -124,6 +124,7 @@ static void msm_iommu_reset(void __iomem *base, int ncb)
>
On Wednesday 18 May 2016 17:37:40 Sricharan wrote:
> >
> >These comments are completely useless. What is the specific race
> >that you are protecting against, and why are the implicit barriers
> >not sufficient here? Please find a better way to document what
> >is going on.
> >
>
> The reason for
On Friday 20 May 2016 16:24:53 Sricharan R wrote:
> While using the generic pagetable ops the tlb maintenance
> operation gets completed in the sync callback. So use writel_relaxed
> for all register access and add a mb() at appropriate places.
>
> Signed-off-by: Sricharan R
> ---
> drivers/iomm
On Friday 20 May 2016 13:44:10 Arnd Bergmann wrote:
> > #define GET_CTX_REG(reg, base, ctx) \
> > (readl((base) + (reg) + ((ctx) << CTX_SHIFT)))
> >
> > -#define SET_GLOBAL_REG(reg, base, val) writel((val), ((base) +
> > (
On Monday, May 23, 2016 11:35:04 AM CEST Sricharan wrote:
> Hi Arnd,
>
> >> @@ -124,6 +124,9 @@ static void msm_iommu_reset(void __iomem *base, int
> >> ncb)
> >>SET_TLBLKCR(base, ctx, 0);
> >>SET_CONTEXTIDR(base, ctx, 0);
> >>}
> >> +
> >> + /* Ensure completion of r
On Wednesday, May 25, 2016 4:15:31 PM CEST Sricharan wrote:
> >
> >Any operation that could trigger a DMA from a device is required
> >to have a barrier preceding it (usually wmb() one implied by writel()),
> >so this is clearly not about a driver that installs a DMA mapping
> >before starting a DM
On Wednesday, May 25, 2016 6:49:18 PM CEST Sricharan wrote:
> Hi Arnd,
>
> >> Ok, so i was doing this from the idea that, other iommu drivers
> >> where polling on a status bit in their sync call to ensure completion
> >> of pending TLB invalidations. But in this case, there is no status bit.
> >
in the discussion
(fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
asked me to send the whole thing again.
Signed-off-by: Arnd Bergmann
Cc: Andrzej Hajda
Cc: Andrew Morton
Link: https://lkml.org/lkml/2016/1/7/363
Link: https://lkml.org/lkml/2016/5/27/486
---
drivers/acpi/acpi_dbg.c
On Thursday, May 26, 2016 9:44:10 AM CEST Ulf Hansson wrote:
> On 26 May 2016 at 06:05, Yangbo Lu wrote:
> > Hi Uffe,
> >
> > Could we merge this patchset? ...
> > It has been a long time to wait for Arnd's response...
> >
> > Thanks a lot.
> >
> >
>
> As we are still in the merge window I won't
strings.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index 246acdafedb6..fc7613cc7fd5 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -225,6 +225,7 @@ config GENERIC_CPU_AUTOPROBE
config SOC_BUS
bool
+ select GLOB
this into a platform_driver registering a soc_device
rather than providing an ad-hoc interface for soc-id]
Signed-off-by: Yangbo Lu
Signed-off-by: Arnd Bergmann
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index cb58ef0d9b2c..7106463f118e 100644
--- a/drivers/soc/Kconfig
+++ b/drivers
esdhc" identifier but that have other host versions that
are correctly detected.
Signed-off-by: Arnd Bergmann
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index 3f34d354f1fc..1d4814fe4cb2 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/hos
All users of this driver are PowerPC specific and the header file
has no business in the global include/linux/ hierarchy, so move
it back before anyone starts using it on ARM.
This reverts commit 948486544713492f00ac8a9572909101ea892cb0.
Signed-off-by: Arnd Bergmann
---
This part of the series
On Monday, May 30, 2016 3:14:38 PM CEST Arnd Bergmann wrote:
> We keep running into cases where device drivers want to know the exact
> version of the SoC a they are currently running on. In the past, this
> has usually been done through a vendor specific API that can be called
> by
On Wednesday, June 1, 2016 8:47:22 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:15 +0200, Arnd Bergmann wrote:
> > diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> > new file mode 100644
> > index ..2f30698f5bcf
> > --- /dev/null
>
On Wednesday, June 1, 2016 8:11:14 PM CEST Scott Wood wrote:
> > +#define T4240_HOST_VER ((VENDOR_V_23 << SDHCI_VENDOR_VER_SHIFT) |
> > SDHCI_SPEC_200)
> > +static const struct soc_device_attribute esdhc_t4240_quirk = {
> > + /* T4240 revision < 0x20 uses vendor version 23, SDHCI version 200
>
On Wednesday, June 1, 2016 8:24:20 PM CEST Scott Wood wrote:
> On Mon, 2016-05-30 at 15:18 +0200, Arnd Bergmann wrote:
> > All users of this driver are PowerPC specific and the header file
> > has no business in the global include/linux/ hierarchy, so move
> > it back before a
On Thursday, July 7, 2016 2:35:33 AM CEST Yangbo Lu wrote:
> Hi Arnd,
>
> Could you reply when you see the email?
> If your method doesn’t resolve the problem, we still want to use our old
> patchset.
>
> This guts driver had been discussed about one year and blocked many
> workaround upstream.
lly been done through a vendor specific API that can be called by a
> > driver, or by directly accessing some kind of version register that is
> > not part of the device itself but that belongs to a global register area
> > of the chip.
Please add "From: Arnd Bergmann "
e dmaengine parts look fine to me. But to go thru
> > dmaengine tree I would need ACK on non dmaengine patches.
>
> I havent heard back from this one and I am inclined to merge this one now.
> If anyone has any objects, please speak up now...
>
> Also ACKs welcome...
>
On Friday, September 16, 2016 12:48:23 PM CEST Laurent Pinchart wrote:
> On Friday 16 Sep 2016 11:07:48 Arnd Bergmann wrote:
> > On Thursday, September 15, 2016 9:56:51 PM CEST Vinod Koul wrote:
> > > On Wed, Aug 10, 2016 at 11:07:10PM +0530, Vinod Koul wrote:
> > >>
On Friday, September 16, 2016 3:09:29 PM CEST Laurent Pinchart wrote:
> > I wasn't thinking quite that far, though that is also a theoretical
> > problem. However, the simple solution would be to have a bit in the DMA
> > specifier let the driver know whether translation is needed or not.
> >
> >
On Friday, October 28, 2016 2:50:17 PM CEST Yangbo Lu wrote:
> +
> +static int soc_device_match_one(struct device *dev, void *arg)
> +{
> + struct soc_device *soc_dev = container_of(dev, struct soc_device,
> dev);
> + const struct soc_device_attribute *match = arg;
> +
> + if (ma
On Friday, October 28, 2016 2:50:14 PM CEST Yangbo Lu wrote:
> Move mpc85xx.h to include/linux/fsl and rename it to svr.h as a common
> header file. This SVR numberspace is used on some ARM chips as well as
> PPC, and even to check for a PPC SVR multi-arch drivers would otherwise
> need to ifdef t
method in soc driver
> and apply it on esdhc driver to fix this bug.
>
Looks good overall. With patch 3 dropped (or an explanation why it's still
needed), everything
Acked-by: Arnd Bergmann
Arnd
___
iommu mailing list
iommu@lis
On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote:
> >
> > I don't see any of the contents of this header referenced by the soc
> > driver any more. I think you can just drop this patch.
> >
>
> [Lu Yangbo-B47093] This header file was included by guts.c.
> The guts driver used macro SVR_M
On Tuesday, November 8, 2016 6:49:51 AM CET Y.B. Lu wrote:
> Hi Arnd,
>
>
> > -Original Message-
> > From: Arnd Bergmann [mailto:a...@arndb.de]
> > Sent: Tuesday, November 08, 2016 5:20 AM
> > To: Y.B. Lu
> > Cc: linuxppc-...@lists.ozlabs.org;
the warning.
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8ee54d71c7eb..bb537d06d319 100644
---
dependency, moving warning text into
a comment.
Fixes: 1f59adb1766d ("iommu/exynos: Replace non-existing big-endian Kconfig
option")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/Kconfig| 1 +
drivers/iommu/exynos-iommu.c | 4
2 files changed, 1 insertion(+), 4 deletions(-)
ns lets the compiler
drop the functions silently instead.
Fixes: 0ae349a0f33f ("iommu/qcom: Add qcom_iommu")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/qcom_iommu.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/q
to fix up the warning
and make the code look reasonable at the same time.
Fixes: 2436bdcda53f ("dma-coherent: remove the DMA_MEMORY_MAP and DMA_MEMORY_IO
flags")
Signed-off-by: Arnd Bergmann
---
drivers/base/dma-coherent.c | 38 +-
1 file changed,
. On compilers
that don't show the warning today, this should have no impact since the
function gets inlined anyway.
Signed-off-by: Arnd Bergmann
---
drivers/iommu/dmar.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
>> @@ -338,14 +346,18 @@ static struct reserved_mem
>> *dma_reserved_default_memory __initdata;
>> static int rmem_dma_device_init(struct reserved_mem *rmem, struct device
>> *dev)
>> {
>> struct dma_coherent_mem *mem = rmem->priv;
>> + int ret;
>> +
>> + if (!mem)
>> +
rent_memory() logic
error")
Reported-by: Roy Pledge
Signed-off-by: Arnd Bergmann
---
Roy, can you test this new fix?
---
drivers/base/dma-coherent.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-
LB sync")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/ipmmu-vmsa.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index af8140054273..bdd0d0d20925 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/d
On Wed, Oct 11, 2017 at 4:16 PM, Robin Murphy wrote:
> On 11/10/17 14:59, Arnd Bergmann wrote:
>
> That said, I think the third option is now viable as well, namely to
> shuffle some lines and get rid of the almost-duplicated ops entirely.
> I'll have a quick go at that
On Fri, Oct 13, 2017 at 8:23 PM, Robin Murphy wrote:
> Arnd reports a build warning[1] thanks to me missing ipmmu-vmsa's second
> set of ops when converting io-pgtable-arm users to the new iommu_iotlb_*
> callbacks. Rather than just treat the symptom with a point fix, this
> seemed like a good exc
init.h used to rely on it being
included indirectly, so I have to put an explicit include in there
now.
Signed-off-by: Arnd Bergmann
---
arch/x86/include/asm/setup.h| 1 -
arch/x86/kernel/platform-quirks.c | 1 +
arch/x86/platform/ce4100/ce4100.c | 1 +
arch/x86/platform/
;t include asm/x86_init.h in asm/setup.h")
Signed-off-by: Arnd Bergmann
---
The broken commit is in x86/timers, please add this one on top
---
drivers/iommu/dmar.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index e9304d6247e1..ed1dd13e03
On Tue, Feb 6, 2018 at 11:14 AM, Geert Uytterhoeven
wrote:
> Hi all,
>
> If NO_DMA=y, get_dma_ops() returns a reference to the non-existing
> symbol bad_dma_ops, thus causing a link failure if it is ever used.
>
> The intention of this is twofold:
> 1. To catch users of the DMA API on sy
On Tue, Feb 6, 2018 at 2:05 PM, Robin Murphy wrote:
>
> It looks like we have only one real arch (score) without IOMEM, and two
> (s390 and tile) where it is possible to configure out, so it does seem like
> a reasonable feature to assume. Maybe we could have something like
> asm-generic/no-io.h t
_by_node() might
theoretically return a NULL pointer.
Fixes: 5fd577c3eac3 ("iommu/rockchip: Use OF_IOMMU to attach devices
automatically")
Signed-off-by: Arnd Bergmann
---
This warning appears to only have been introduced in linux-next after
the merge window opened.
---
drivers/i
protected
section of the file.
Fixes: ea6166f4b83e ("iommu/amd: Split irq_lookup_table out of the
amd_iommu_devtable_lock")
Signed-off-by: Arnd Bergmann
---
drivers/iommu/amd_iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/amd_iommu.c b/drive
wer type,
and use the same expression in the error handling later.
Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR")
Signed-off-by: Arnd Bergmann
---
I still think that reverting the original commit would have
provided clearer semantics for this corner case, but at least
this pat
o
'phys_addr_t' (aka 'unsigned int') changes value from
18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion]
Use phys_addr_t here because that is the type that the variable was
declared as.
Fixes: aadad097cd46 ("iommu/dma: Reserve IOVA for PCIe in
On Mon, Jun 3, 2019 at 8:50 AM Christoph Hellwig wrote:
>
> On Wed, May 01, 2019 at 05:13:57PM +, Paul Burton wrote:
> > Hi Christoph,
> >
> > On Wed, May 01, 2019 at 03:13:39PM +0200, Christoph Hellwig wrote:
> > > Stop providing our arch alloc/free hooks and just expose the segment
> > > off
On Thu, Jul 18, 2019 at 11:52 AM Christoph Hellwig wrote:
>
> On Thu, Jul 18, 2019 at 10:49:34AM +0200, Christoph Hellwig wrote:
> > On Thu, Jul 18, 2019 at 01:45:16PM +1000, Oliver O'Halloran wrote:
> > > > Other than m68k, mips, and arm64, everybody else that doesn't have
> > > > ARCH_NO_COHEREN
On Mon, Jul 20, 2020 at 8:36 AM Naresh Kamboju
wrote:
>
> This kernel oops while boot linux mainline kernel on arm64 db410c device.
>
> metadata:
> git branch: master
> git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git commit: f8456690ba8eb18ea4714e68554e242
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote:
>
> Remove the now unused dmabounce code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundati
h Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Signed-off-by: Christoph Hellwig
I generally prefer to have at least something useful in the description, e.g.
why it's now unused and what it was used for before.
> -static inline dma_addr_t virt_to_dma(struct device *dev, void *addr
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig wrote:
>
> Use the helpers as expected by the dma-direct code in the old arm
> dma-mapping code to ease a gradual switch to the common DMA code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by
gt; indirection.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
> ---
> @@ -335,17 +336,19 @@ unsigned long __bus_to_virt(unsigned long res)
> return res;
> }
> EXPORT_SYMBOL(__bus_to_virt);
> -
> -unsigned long __pfn_to_bus(unsigned long pf
arch/arm/include/asm/dma-mapping.h
The diffstat looks really nice!
I can't really tell from looking at the code if this is an equivalent
conversion,
so I have to trust you on that. I did make sure this passes the basic tests
on kernelci.org, which tests a large number o
On Thu, Apr 21, 2022 at 9:41 AM Christoph Hellwig wrote:
>
> Hi all,
>
> arm is the last platform not using the dma-direct code for directly
> mapped DMA. With the dmaboune removal from Arnd we can easily switch
> arm to always use dma-direct now (it already does for LPAE configs
> and nommu). I
On Mon, May 2, 2022 at 6:43 PM Christoph Hellwig wrote:
>
> virt_to_dma was only used by the now removed dmabounce code.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Arnd Bergmann
___
iommu mailing list
iommu@lists.linux-foundati
From: Arnd Bergmann
The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old
From: Arnd Bergmann
This is one of four remaining drivers using the ancient
virt_to_bus() interface instead of the dma-mapping interface,
making it incompatible with most modern machines.
As nobody has cleaned this up, there is a high chance that this
driver has no actual users. The chip was
From: Arnd Bergmann
The VME subsystem graduated from staging into a top-level subsystem in
2012, with commit db3b9e990e75 ("Staging: VME: move VME drivers out of
staging") stating:
The VME device drivers have not moved out yet due to some API
questions they are still worki
From: Arnd Bergmann
This driver does not use the virt_to_bus() function, though it
depends on x86 specific fixups in the swiotlb code, which was
last rewritten in commit e380a0394c36 ("x86/PCI: sta2x11: use
default DMA address translation").
It is possible that the driver still fail
From: Arnd Bergmann
The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008 but
it a stale reference in a broken error handling code path that could
never work.
Fix it up to build without VIRT_TO_BUS and remove the Kconfig dependency.
The alternative to this would be to just remove
From: Arnd Bergmann
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The
On Mon, Jun 6, 2022 at 12:40 PM Maciej W. Rozycki wrote:
>
> On Mon, 6 Jun 2022, Arnd Bergmann wrote:
>
> > This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
> > 64-bit system enumeration error for Buslogic"), 8 years later.
> >
> >
On Mon, Jun 6, 2022 at 11:25 AM Greg Kroah-Hartman
wrote:
>
> I'll take patches 1 and 2 right now through my staging tree if that's
> ok.
Yes, that's perfect, as there are no actual interdependencies with the
other drivers -- applying the last patch first would just hide the driver
I'm removing h
On Mon, Jun 6, 2022 at 6:35 PM Khalid Aziz wrote:
> On 6/6/22 02:41, Arnd Bergmann wrote: From: Arnd Bergmann
>
> I would say no to removing BusLogic driver. Virtualbox is another
> consumer of this driver. This driver is very old but I would rather fix
> the issues than remove it
From: Arnd Bergmann
The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old
From: Arnd Bergmann
The dpt_i2o driver was fixed to stop using virt_to_bus() in 2008, but
it still has a stale reference in an error handling code path that could
never work.
Fix it up to build without VIRT_TO_BUS and remove the Kconfig dependency.
The alternative to this would be to just
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver
From: Arnd Bergmann
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The
On Tue, Jun 21, 2022 at 11:56 PM Khalid Aziz wrote:
> > while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {
> > - /*
> > -We are only allowed to do this because we limit our
> > -architectures we run on to machines where bus_to_virt(
On Sat, Jun 18, 2022 at 3:06 AM Michael Schmitz wrote:
> Am 18.06.2022 um 00:57 schrieb Arnd Bergmann:
> >
> > All architecture-independent users of virt_to_bus() and bus_to_virt()
> > have been fixed to use the dma mapping interfaces or have been
> > removed now. Th
On Fri, Jun 24, 2022 at 5:38 PM Khalid Aziz wrote:
> On 6/23/22 08:47, Arnd Bergmann wrote:
>
> Driver works with this change. next_inbox is the correct pointer to pass.
Ok, great! I'll add a 'Tested-by' line then. I was already in the process of
preparing a v3 patch set,
From: Arnd Bergmann
The virt_to_bus/bus_to_virt interface has been deprecated for
decades. After Jakub Kicinski put a lot of work into cleaning out the
network drivers using them, there are only a couple of other drivers
left, which can all be removed or otherwise cleaned up, to remove the
old
From: Arnd Bergmann
The BusLogic driver is the last remaining driver that relies on the
deprecated bus_to_virt() function, which in turn only works on a few
architectures, and is incompatible with both swiotlb and iommu support.
Before commit 391e2f25601e ("[SCSI] BusLogic: Port driver
From: Arnd Bergmann
All architecture-independent users of virt_to_bus() and bus_to_virt()
have been fixed to use the dma mapping interfaces or have been
removed now. This means the definitions on most architectures, and the
CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
The
On Fri, Jun 24, 2022 at 5:52 PM Arnd Bergmann wrote:
> Arnd Bergmann (3):
> scsi: BusLogic remove bus_to_virt
> scsi: dpt_i2o: remove obsolete driver
The dpt_i2o removal is overly large and got dropped by some of the
mailing lists,
if anyone wants to see the full patch, it di
(On Sun, Jun 26, 2022 at 7:21 AM Michael Schmitz wrote:
> > The same could be done for the two vme drivers (scsi/mvme147.c
> > and ethernet/82596.c), which do the cache management but
> > apparently don't need swiotlb bounce buffering.
> >
> > Rewriting the drivers to modern APIs is of course non
On Tue, Jun 28, 2022 at 5:25 AM Michael Schmitz wrote:
> Am 28.06.2022 um 09:12 schrieb Michael Schmitz:
>
> Leaving the bounce buffer handling in place, and taking a few other
> liberties - this is what converting the easiest case (a3000 SCSI) might
> look like. Any obvious mistakes? The mvme147
On Tue, Jun 28, 2022 at 4:59 AM Martin K. Petersen
wrote:
> Hi Arnd!
>
> > If there are no more issues identified with this series, I'll merge it
> > through the asm-generic tree. The SCSI patches can also get merged
> > separately through the SCSI maintainers' tree if they prefer.
>
> I put patch
On Tue, Jun 28, 2022 at 11:03 PM Michael Schmitz wrote:
> On 28/06/22 19:03, Geert Uytterhoeven wrote:
> >> The driver allocates bounce buffers using kmalloc if it hits an
> >> unaligned data buffer - can such buffers still even happen these days?
> > No idea.
> Hmmm - I think I'll stick a WARN_ON
On Tue, Jun 28, 2022 at 11:38 PM Michael Schmitz wrote:
> On 28/06/22 19:08, Arnd Bergmann wrote:
> > I see two other problems with your patch though:
> >
> > a) you still duplicate the cache handling: the cache_clear()/cache_push()
> > is supposed to already be done b
On Sun, Feb 7, 2021 at 9:18 AM Zhou Wang wrote:
> diff --git a/arch/arm64/include/asm/unistd32.h
> b/arch/arm64/include/asm/unistd32.h
> index cccfbbe..3f49529 100644
> --- a/arch/arm64/include/asm/unistd32.h
> +++ b/arch/arm64/include/asm/unistd32.h
> @@ -891,6 +891,8 @@ __SYSCALL(__NR_faccessa
On Tue, Mar 9, 2021 at 4:23 AM Felix Kuehling wrote:
>
> Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link
> against the exported functions. If the GPU driver is built-in but the
> IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
> built but does not work:
>
>
On Tue, Mar 9, 2021 at 7:34 PM Christian König wrote:
> Am 09.03.21 um 18:59 schrieb Alex Deucher:
>
> There has been quite some effort for this already for generic PASID
> interface etc.. But it looks like that effort is stalled by now.
>
> Anyway at least I'm perfectly fine to have the IOMMUv2 |
On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote:
> On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
>
> I'm probably just confused or maybe the documentation is outdated but I don't
> see how I could specify "this device can only use DMA addresses from
> 0x0010...0x3ff0 but can map thes
On Fri, Mar 26, 2021 at 4:59 PM Mark Kettenis wrote:
>
> > From: Arnd Bergmann
> > Date: Thu, 25 Mar 2021 22:41:09 +0100
> >
> > On Thu, Mar 25, 2021 at 8:53 AM Sven Peter wrote:
> > > On Tue, Mar 23, 2021, at 21:53, Rob Herring wrote:
> > >
On Fri, Mar 26, 2021 at 5:10 PM Sven Peter wrote:
> On Fri, Mar 26, 2021, at 16:59, Mark Kettenis wrote:
> > Some of the DARTs provide a bypass facility. That code make using the
> > standard "dma-ranges" property tricky. That property would need to
> > contain the bypass address range. But tha
On Fri, Mar 26, 2021 at 6:51 PM Sven Peter wrote:
> On Fri, Mar 26, 2021, at 18:34, Robin Murphy wrote:
> > On 2021-03-26 17:26, Mark Kettenis wrote:
> > >
> > > Anyway, from my viewpoint having the information about the IOVA
> > > address space sit on the devices makes little sense. This informa
On Fri, Mar 26, 2021 at 6:28 PM Mark Kettenis wrote:
> I haven't figured out how the bypass stuff really works. Corellium
> added support for it in their codebase when they added support for
> Thunderbolt, and some of the DARTs that seem to be related to
> Thunderbolt do indeed have a "bypass" p
On Sun, Mar 28, 2021 at 9:40 AM Sven Peter wrote:
I noticed only one detail here:
> + - |+
> +dart2a: dart2a@82f0 {
> + compatible = "apple,t8103-dart";
> + reg = <0x82f0 0x4000>;
> + interrupts = <1 781 4>;
> + #iommu-cells = <1>;
> +};
The name of the iomm
fig
>
> Note: drivers/remoteproc seems to be special; commit c51e882cd711
> ("remoteproc/davinci: Update Kconfig to depend on DMA_CMA") explains that
> there is a real dependency to DMA_CMA for it to work; leave that dependency
> in place and don't convert
On Fri, Apr 9, 2021 at 6:56 PM Sven Peter wrote:
> On Wed, Apr 7, 2021, at 12:44, Will Deacon wrote:
> > On Sun, Mar 28, 2021 at 09:40:07AM +0200, Sven Peter wrote:
> >
> > > + cfg->pgsize_bitmap &= SZ_16K;
> > > + if (!cfg->pgsize_bitmap)
> > > + return NULL;
> >
> > This is worryin
On Mon, Apr 19, 2021 at 11:33 AM Dominique MARTINET
wrote:
> Geert Uytterhoeven wrote on Mon, Apr 19, 2021 at 11:03:24AM +0200:
>
> > soc_device_match() should only be used as a last resort, to identify
> > systems that cannot be identified otherwise. Typically this is used for
> > quirks, which
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Tue, Apr 20, 2021 at 1:44 AM Dominique MARTINET
wrote:
> Arnd Bergmann wrote on Mon, Apr 19, 2021 at 02:16:36PM +0200:
> > For built-in drivers, load order depends on the initcall level and
> > link order (how things are lined listed in the Makefile hierarchy).
> >
>
On Wed, Jul 14, 2021 at 8:21 PM Robin Murphy wrote:
>
> On 2021-06-27 15:34, Sven Peter wrote:
> [...]
> > In the long term, I'd like to extend the dma-iommu framework itself to
> > support iommu pagesizes with a larger granule than the CPU pagesize if that
> > is
> > something you agree with.
>
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'a
On Thu, Oct 29, 2020 at 8:04 AM Paolo Bonzini wrote:
>
> On 28/10/20 22:20, Arnd Bergmann wrote:
> > Avoid this by renaming the global 'apic' variable to the more descriptive
> > 'x86_system_apic'. It was originally called 'genapic', but both tha
From: Arnd Bergmann
There are hundreds of warnings in a W=2 build about a local
variable shadowing the global 'apic' definition:
arch/x86/kvm/lapic.h:149:65: warning: declaration of 'apic' shadows a global
declaration [-Wshadow]
Avoid this by renaming the global 'a
From: Arnd Bergmann
clang-14 notices that a comparison is never true when
CONFIG_PHYS_ADDR_T_64BIT is disabled:
drivers/iommu/mtk_iommu.c:553:34: error: result of comparison of constant
5368709120 with expression of type 'phys_addr_t' (aka 'unsigned int') is al
201 - 300 of 345 matches
Mail list logo
