Re: fully convert arm to use dma-direct v3

2022-07-07 Thread Arnd Bergmann
On Thu, Jul 7, 2022 at 6:58 AM Christoph Hellwig  wrote:
> On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote:
> > > Any comments or additional testing?  It would be really great to get
> > > this off the table.
> >
> > For the USB bits:
> >
> > Acked-by: Greg Kroah-Hartman 
>
> So given that we're not making any progress on getting anyone interested
> on the series, I'm tempted to just pull it into the dma-mapping tree
> this weekend so that we'll finally have all architectures using the
> common code.

Yes, please do!

Getting it into linux-next now should give plenty of time to test it
with the automated kernelci and lkft systems, as well as Russell's
Assabet. I'm sure we can fix up any regressions before this actually
hits the 5.20 release.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-28 Thread Arnd Bergmann
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 by dma_map_single() when the device
> > is not cache-coherent.
>
> That's one of the 'liberties' I alluded to. The reason I left these in
> is that I'm none too certain what device feature the DMA API uses to
> decide a device isn't cache-coherent. If it's dev->coherent_dma_mask,
> the way I set up the device in the a3000 driver should leave the
> coherent mask unchanged. For the Zorro drivers, devices are set up to
> use the same storage to store normal and coherent masks - something we
> most likely want to change. I need to think about the ramifications of
> that.
>
> Note that zorro_esp.c uses dma_sync_single_for_device() and uses a 32
> bit coherent DMA mask which does work OK. I might  ask Adrian to test a
> change to only set dev->dma_mask, and drop the
> dma_sync_single_for_device() calls if there's any doubt on this aspect.

The "coherent_mask" is independent of the cache flushing. On some
architectures, a device can indicate whether it needs cache management
or not to guarantee coherency, but on m68k it appears that we always
assume it does, see arch/m68k/kernel/dma.c

> > b) The bounce buffer is never mapped here, instead you have the
> > virt_to_phys() here, which is not the same. I think you need to map
> > the pointer that actually gets passed down to the device after deciding
> > to use a bouce buffer or not.
>
> I hadn't realized that I can map the bounce buffer just as it's done for
> the SCp data buffer. Should have been obvious, but I'm still learning
> about the DMA API.
>
> I've updated the patch now, will re-send as part of a complete series
> once done.

I suppose you can just drop the bounce buffer if this just comes
from kmalloc().

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-28 Thread Arnd Bergmann
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_ONCE() in there so we know whether this
> code path is still being used.

kmalloc() guarantees alignment to the next power-of-two size or
KMALLOC_MIN_ALIGN, whichever is bigger. On m68k this means it
is cacheline aligned.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-28 Thread Arnd Bergmann
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 patches 1 and 2 in scsi-staging to see if anything breaks...

Ok, thanks!

I have just the third patch in the asm-generic tree now. As long as it all
make it into the merge window, this should work out fine without build
issues, though there is a small bisection window during which the buslogic
driver becomes hidden. I think that's ok here.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-28 Thread Arnd Bergmann
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 driver would be very
> similar to handle (after conversion to a platform device).
>
> The driver allocates bounce buffers using kmalloc if it hits an
> unaligned data buffer - can such buffers still even happen these days?
> If I understand dma_map_single() correctly, the resulting dma handle
> would be equally misaligned?
>
> To allocate a bounce buffer, would it be OK to use dma_alloc_coherent()
> even though AFAIU memory used for DMA buffers generally isn't consistent
> on m68k?

I think it makes sense to skip the bounce buffering as you do here:
the only standardized way we have for integrating that part is to
use the swiotlb infrastructure, but as you mentioned earlier that
part is probably too resource-heavy here for Amiga.

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 by dma_map_single() when the device
is not cache-coherent.

b) The bounce buffer is never mapped here, instead you have the
virt_to_phys() here, which is not the same. I think you need to map
the pointer that actually gets passed down to the device after deciding
to use a bouce buffer or not.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-26 Thread Arnd Bergmann
(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-trivial,
> > and if you want a shortcut here, I would suggest introducing
> > platform specific helpers similar to isa_virt_to_bus() and call
> > them amiga_virt_to_bus() and vme_virt_to_bus, respectively.
>
> I don't think Amiga and m68k VME differ at all in that respect, so might
> just call it m68k_virt_to_bus() for now.
>
> > Putting these into a platform specific header file at least helps
> > clarify that both the helper functions and the drivers using them
> > are non-portable.
>
> There are no platform specific header files other than asm/amigahw.h and
> asm/mvme147hw.h, currently only holding register address definitions.
> Would it be OK to add m68k_virt_to_bus() in there if it can't remain in
> asm/virtconvert.h, Geert?

In that case, I would just leave it under the current name and not change
m68k at all. I don't like the m68k_virt_to_bus() name because there is
not anything CPU specific in what it does, and keeping it in a common
header does nothing to prevent it from being used on other platforms
either.

> >> 32bit powerpc is a different matter though.
> >
> > It's similar, but unrelated. The two apple ethernet drivers
> > (bmac and mace) can again either get changed to use the
> > dma-mapping interfaces, or get a custom pmac_virt_to_bus()/
> > pmac_bus_to_virt() helper.
>
> Hmmm - I see Finn had done the DMA API conversion on macmace.c which
> might give some hints on what to do about mace.c ... no idea about
> bmac.c though. And again, haven't got hardware to test, so custom
> helpers is it, then.

Ok.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
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 did make it through to the linux-scsi
list at least:

https://lore.kernel.org/all/20220624155226.2889613-3-a...@kernel.org/

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v3 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
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 only exceptions to this are a few network and scsi drivers for m68k
Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
with the old interfaces and are probably not worth changing.

On alpha and parisc, virt_to_bus() were still used in asm/floppy.h.
alpha can use isa_virt_to_bus() like x86 does, and parisc can just
open-code the virt_to_phys() here, as this is architecture specific
code.

I tried updating the bus-virt-phys-mapping.rst documentation, which
started as an email from Linus to explain some details of the Linux-2.0
driver interfaces. The bits about virt_to_bus() were declared obsolete
backin 2000, and the rest is not all that relevant any more, so in the
end I just decided to remove the file completely.

Reviewed-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Acked-by: Michael Ellerman  (powerpc)
Signed-off-by: Arnd Bergmann 
---
 .../core-api/bus-virt-phys-mapping.rst| 220 --
 Documentation/core-api/dma-api-howto.rst  |  14 --
 Documentation/core-api/index.rst  |   1 -
 .../translations/zh_CN/core-api/index.rst |   1 -
 arch/alpha/Kconfig|   1 -
 arch/alpha/include/asm/floppy.h   |   2 +-
 arch/alpha/include/asm/io.h   |   8 +-
 arch/ia64/Kconfig |   1 -
 arch/ia64/include/asm/io.h|   8 -
 arch/m68k/Kconfig |   1 -
 arch/m68k/include/asm/virtconvert.h   |   4 +-
 arch/microblaze/Kconfig   |   1 -
 arch/microblaze/include/asm/io.h  |   2 -
 arch/mips/Kconfig |   1 -
 arch/mips/include/asm/io.h|   9 -
 arch/parisc/Kconfig   |   1 -
 arch/parisc/include/asm/floppy.h  |   4 +-
 arch/parisc/include/asm/io.h  |   2 -
 arch/powerpc/Kconfig  |   1 -
 arch/powerpc/include/asm/io.h |   2 -
 arch/riscv/include/asm/page.h |   1 -
 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/io.h |   9 -
 arch/xtensa/Kconfig   |   1 -
 arch/xtensa/include/asm/io.h  |   3 -
 include/asm-generic/io.h  |  14 --
 mm/Kconfig|   8 -
 27 files changed, 10 insertions(+), 311 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst

diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst 
b/Documentation/core-api/bus-virt-phys-mapping.rst
deleted file mode 100644
index c72b24a7d52c..
--- a/Documentation/core-api/bus-virt-phys-mapping.rst
+++ /dev/null
@@ -1,220 +0,0 @@
-==
-How to access I/O mapped memory from within device drivers
-==
-
-:Author: Linus
-
-.. warning::
-
-   The virt_to_bus() and bus_to_virt() functions have been
-   superseded by the functionality provided by the PCI DMA interface
-   (see Documentation/core-api/dma-api-howto.rst).  They continue
-   to be documented below for historical purposes, but new code
-   must not use them. --davidm 00/12/12
-
-::
-
-  [ This is a mail message in response to a query on IO mapping, thus the
-strange format for a "document" ]
-
-The AHA-1542 is a bus-master device, and your patch makes the driver give the
-controller the physical address of the buffers, which is correct on x86
-(because all bus master devices see the physical memory mappings directly). 
-
-However, on many setups, there are actually **three** different ways of looking
-at memory addresses, and in this case we actually want the third, the
-so-called "bus address". 
-
-Essentially, the three ways of addressing memory are (this is "real memory",
-that is, normal RAM--see later about other details): 
-
- - CPU untranslated.  This is the "physical" address.  Physical address 
-   0 is what the CPU sees when it drives zeroes on the memory bus.
-
- - CPU translated address. This is the "virtual" address, and is 
-   completely internal to the CPU itself with the CPU doing the appropriate
-   translations into "CPU untranslated". 
-
- - bus address. This is the address of memory as seen by OTHER devices, 
-   not the CPU. Now, in theory there could be many different bus 
-   addresses, with each device seeing memory in some device-specific way, but
-   happily most hardware designers aren't actually actively trying to make
-   things any more comp

[PATCH v3 1/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
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 to 64-bit."),
the driver had a dependency on x86-32, presumably because of this
problem. However, the change introduced another bug that made it still
impossible to use the driver on any 64-bit machine.

This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
64-bit system enumeration error for Buslogic"), 8 years later, which
shows that there are not a lot of users.

Maciej is still using the driver on 32-bit hardware, and Khalid mentioned
that the driver works with the device emulation used in VirtualBox
and VMware. Both of those only emulate it for Windows 2000 and older
operating systems that did not ship with the better LSI logic driver.

Do a minimum fix that searches through the list of descriptors to find
one that matches the bus address. This is clearly as inefficient as
was indicated in the code comment about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.

Cc: Maciej W. Rozycki 
Cc: Matt Wang 
Tested-by: Khalid Aziz 
Reviewed-by: Robin Murphy 
Reviewed-by: Hannes Reinecke 
Signed-off-by: Arnd Bergmann 
---
v3: Address issues pointed out by Khalid Aziz
v2: Attempt to fix the driver instead of removing it
---
 drivers/scsi/BusLogic.c | 35 +++
 drivers/scsi/Kconfig|  2 +-
 2 files changed, 24 insertions(+), 13 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index a897c8f914cf..f2abffce2659 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2515,12 +2515,26 @@ static int blogic_resultcode(struct blogic_adapter 
*adapter,
return (hoststatus << 16) | tgt_status;
 }
 
+/*
+ * turn the dma address from an inbox into a ccb pointer
+ * This is rather inefficient.
+ */
+static struct blogic_ccb *
+blogic_inbox_to_ccb(struct blogic_adapter *adapter, struct blogic_inbox *inbox)
+{
+   struct blogic_ccb *ccb;
+
+   for (ccb = adapter->all_ccbs; ccb; ccb = ccb->next_all)
+   if (inbox->ccb == ccb->dma_handle)
+   break;
+
+   return ccb;
+}
 
 /*
   blogic_scan_inbox scans the Incoming Mailboxes saving any
   Incoming Mailbox entries for completion processing.
 */
-
 static void blogic_scan_inbox(struct blogic_adapter *adapter)
 {
/*
@@ -2540,17 +2554,14 @@ static void blogic_scan_inbox(struct blogic_adapter 
*adapter)
enum blogic_cmplt_code comp_code;
 
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(
-  actually works.  There *needs* to be a dma_addr_to_virt()
-  in the new PCI DMA mapping interface to replace
-  bus_to_virt() or else this code is going to become very
-  innefficient.
-*/
-   struct blogic_ccb *ccb =
-   (struct blogic_ccb *) bus_to_virt(next_inbox->ccb);
-   if (comp_code != BLOGIC_CMD_NOTFOUND) {
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, 
next_inbox);
+   if (!ccb) {
+   /*
+* This should never happen, unless the CCB list is
+* corrupted in memory.
+*/
+   blogic_warn("Could not find CCB for dma address %x\n", 
adapter, next_inbox->ccb);
+   } else if (comp_code != BLOGIC_CMD_NOTFOUND) {
if (ccb->status == BLOGIC_CCB_ACTIVE ||
ccb->status == BLOGIC_CCB_RESET) {
/*
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 6e3a04107bb6..689186f3a908 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -514,7 +514,7 @@ config SCSI_HPTIOP
 
 config SCSI_BUSLOGIC
tristate "BusLogic SCSI support"
-   depends on PCI && SCSI && VIRT_TO_BUS
+   depends on PCI && SCSI
help
  This is support for BusLogic MultiMaster and FlashPoint SCSI Host
  Adapters. Consult the SCSI-HOWTO, available from
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v3 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
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 interface for good.

Any out of tree drivers using virt_to_bus() should be converted to
using the dma-mapping interfaces, typically dma_alloc_coherent()
or dma_map_single()).

There are a few m68k and ppc32 specific drivers that keep using the
interfaces, but these are all guarded with architecture-specific
Kconfig dependencies, and are not actually broken. It might be
helpful as a follow-up to replace them with platform specific
helpers for amiga, m68k-vme and powermac.

There are still a number of drivers that are using virt_to_phys()
and phys_to_virt() in place of dma-mapping operations, and these
are often broken, but they are out of scope for this series.

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.

  Arnd

---
Changes since v2:
 - Drop the dpt_i2o driver completely rather than fixing it
 - fix mistake in BusLogic patch

Changes since v1:
 - dropped VME patches that are already in staging-next
 - dropped media patch that gets merged independently
 - added a networking patch and dropped it again after it got merged
 - replace BusLogic removal with a workaround

Cc: Jakub Kicinski 
Cc: Christoph Hellwig  # dma-mapping
Cc: Marek Szyprowski  # dma-mapping
Cc: Robin Murphy  # dma-mapping
Cc: iommu@lists.linux-foundation.org
Cc: Khalid Aziz  # buslogic
Cc: Maciej W. Rozycki  # buslogic
Cc: Matt Wang  # buslogic
Cc: Miquel van Smoorenburg  # dpt_i2o
Cc: Mark Salyzyn  # dpt_i2o
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-par...@vger.kernel.org
Cc: Denis Efremov  # floppy

Arnd Bergmann (3):
  scsi: BusLogic remove bus_to_virt
  scsi: dpt_i2o: remove obsolete driver
  arch/*/: remove CONFIG_VIRT_TO_BUS

 .../core-api/bus-virt-phys-mapping.rst|  220 -
 Documentation/core-api/dma-api-howto.rst  |   14 -
 Documentation/core-api/index.rst  |1 -
 .../translations/zh_CN/core-api/index.rst |1 -
 .../userspace-api/ioctl/ioctl-number.rst  |2 +-
 MAINTAINERS   |8 -
 arch/alpha/Kconfig|1 -
 arch/alpha/include/asm/floppy.h   |2 +-
 arch/alpha/include/asm/io.h   |8 +-
 arch/ia64/Kconfig |1 -
 arch/ia64/include/asm/io.h|8 -
 arch/m68k/Kconfig |1 -
 arch/m68k/include/asm/virtconvert.h   |4 +-
 arch/microblaze/Kconfig   |1 -
 arch/microblaze/include/asm/io.h  |2 -
 arch/mips/Kconfig |1 -
 arch/mips/include/asm/io.h|9 -
 arch/parisc/Kconfig   |1 -
 arch/parisc/include/asm/floppy.h  |4 +-
 arch/parisc/include/asm/io.h  |2 -
 arch/powerpc/Kconfig  |1 -
 arch/powerpc/include/asm/io.h |2 -
 arch/riscv/include/asm/page.h |1 -
 arch/x86/Kconfig  |1 -
 arch/x86/include/asm/io.h |9 -
 arch/xtensa/Kconfig   |1 -
 arch/xtensa/include/asm/io.h  |3 -
 drivers/scsi/BusLogic.c   |   35 +-
 drivers/scsi/Kconfig  |   13 +-
 drivers/scsi/Makefile |1 -
 drivers/scsi/dpt/dpti_i2o.h   |  441 --
 drivers/scsi/dpt/dpti_ioctl.h |  136 -
 drivers/scsi/dpt/dptsig.h |  336 --
 drivers/scsi/dpt/osd_defs.h   |   79 -
 drivers/scsi/dpt/osd_util.h   |  358 --
 drivers/scsi/dpt/sys_info.h   |  417 --
 drivers/scsi/dpt_i2o.c| 3546 -
 drivers/scsi/dpti.h   |  331 --
 include/asm-generic/io.h  |   14 -
 mm/Kconfig|8 -
 40 files changed, 35 insertions(+), 5989 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst
 delete mode 100644 drivers/scsi/dpt/dpti_i2o.h
 delete mode 100644 drivers/scsi/dpt/dpti_ioctl.h
 delete mode 100644 drivers/scsi/dpt/dptsig.h
 delete mode 100644 drivers/scsi/dpt/osd_defs.h
 delete mode 100644 drivers/scsi/dpt/osd_util.h
 delete mode 100644 drivers/scsi/dpt/sys_info.h
 delete mode 100644 drivers/scsi/dpt_i2o.c
 delete mode 100644 drivers/scsi/dpti.h

-- 
2.29.2

Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-24 Thread Arnd Bergmann
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, will send out the fixed patch in a bit.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-24 Thread Arnd Bergmann
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.  This means the definitions on most architectures, and the
> > CONFIG_VIRT_TO_BUS symbol are now obsolete and can be removed.
> >
> > The only exceptions to this are a few network and scsi drivers for m68k
> > Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
> > with the old interfaces and are probably not worth changing.
>
> The Amiga SCSI drivers are all old WD33C93 ones, and replacing
> virt_to_bus by virt_to_phys in the dma_setup() function there would
> cause no functional change at all.

Ok, thanks for taking a look here.

> drivers/vme/bridges/vme_ca91cx42.c hasn't been used at all on m68k (it
> is a PCI-to-VME bridge chipset driver that would be needed on
> architectures that natively use a PCI bus). I haven't found anything
> that selects that driver, so not sure it is even still in use??

It's gone now, Greg has already taken my patches for this through
the staging tree.

> That would allow you to drop the remaining virt_to_bus define from
> arch/m68k/include/asm/virtconvert.h.
>
> I could submit a patch to convert the Amiga SCSI drivers to use
> virt_to_phys if Geert and the SCSI maintainers think it's worth the churn.

I don't think using virt_to_phys() is an improvement here, as
virt_to_bus() was originally meant as a better abstraction to
replace the use of virt_to_phys() to make drivers portable, before
it got replaced by the dma-mapping interface in turn.

It looks like the Amiga SCSI drivers have an open-coded version of
what dma_map_single() does, to do bounce buffering and cache
management. The ideal solution would be to convert the drivers
actually use the appropriate dma-mapping interfaces and remove
this custom code.

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-trivial,
and if you want a shortcut here, I would suggest introducing
platform specific helpers similar to isa_virt_to_bus() and call
them amiga_virt_to_bus() and vme_virt_to_bus, respectively.

Putting these into a platform specific header file at least helps
clarify that both the helper functions and the drivers using them
are non-portable.

> 32bit powerpc is a different matter though.

It's similar, but unrelated. The two apple ethernet drivers
(bmac and mace) can again either get changed to use the
dma-mapping interfaces, or get a custom pmac_virt_to_bus()/
pmac_bus_to_virt() helper.

There is also drivers/tty/serial/cpm_uart/cpm_uart_cpm2.c,
which I think just needs a trivial change, but I'm not sure
how to do it correctly.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-23 Thread Arnd Bergmann
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(
> > -actually works.  There *needs* to be a dma_addr_to_virt()
> > -in the new PCI DMA mapping interface to replace
> > -bus_to_virt() or else this code is going to become very
> > -innefficient.
> > -  */
> > - struct blogic_ccb *ccb =
> > - (struct blogic_ccb *) bus_to_virt(next_inbox->ccb);
> > + struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, 
> > adapter->next_inbox);
>
> This change looks good enough as workaround to not use bus_to_virt() for
> now. There are two problems I see though. One, I do worry about
> blogic_inbox_to_ccb() returning NULL for ccb which should not happen
> unless the mailbox pointer was corrupted which would indicate a bigger
> problem. Nevertheless a NULL pointer causing kernel panic concerns me.
> How about adding a check before we dereference ccb?

Right, makes sense

> Second, with this patch applied, I am seeing errors from the driver:
>
> =
> [ 1623.902685]  sdb: sdb1 sdb2
> [ 1623.903245] sd 2:0:0:0: [sdb] Attached SCSI disk
> [ 1623.911000] scsi2: Illegal CCB #76 status 2 in Incoming Mailbox
> [ 1623.911005] scsi2: Illegal CCB #76 status 2 in Incoming Mailbox
> [ 1623.911070] scsi2: Illegal CCB #79 status 2 in Incoming Mailbox
> [ 1651.458008] scsi2: Warning: Partition Table appears to have Geometry
> 256/63 which is
> [ 1651.458013] scsi2: not compatible with current BusLogic Host Adapter
> Geometry 255/63
> [ 1658.797609] scsi2: Resetting BusLogic BT-958D Failed
> [ 1659.533208] sd 2:0:0:0: Device offlined - not ready after error recovery
> [ 1659.51] sd 2:0:0:0: Device offlined - not ready after error recovery
> [ 1659.53] sd 2:0:0:0: Device offlined - not ready after error recovery
> [ 1659.533342] sd 2:0:0:0: [sdb] tag#101 FAILED Result:
> hostbyte=DID_TIME_OUT driverbyte=DRIVER_OK cmd_age=35s
> [ 1659.533345] sd 2:0:0:0: [sdb] tag#101 CDB: Read(10) 28 00 00 00 00 28
> 00 00 10 00
> [ 1659.533346] I/O error, dev sdb, sector 40 op 0x0:(READ) flags 0x80700
> phys_seg 1 prio class 0
>
> =
>
> This is on VirtualBox using emulated BusLogic adapter.
>
> This patch needs more refinement.

Thanks for testing the patch, too bad it didn't work. At least I quickly found
one stupid mistake on my end, hope it's the only one.

Can you test it again with this patch on top?

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index d057abfcdd5c..9e67f2ee25ee 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2554,8 +2554,14 @@ static void blogic_scan_inbox(struct
blogic_adapter *adapter)
enum blogic_cmplt_code comp_code;

while ((comp_code = next_inbox->comp_code) != BLOGIC_INBOX_FREE) {
-   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter,
adapter->next_inbox);
-   if (comp_code != BLOGIC_CMD_NOTFOUND) {
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter,
next_inbox);
+   if (!ccb) {
+   /*
+* This should never happen, unless the CCB list is
+* corrupted in memory.
+*/
+   blogic_warn("Could not find CCB for dma
address 0x%x\n", adapter, next_inbox->ccb);
+   } else if (comp_code != BLOGIC_CMD_NOTFOUND) {
if (ccb->status == BLOGIC_CCB_ACTIVE ||
ccb->status == BLOGIC_CCB_RESET) {
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2 3/3] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-17 Thread Arnd Bergmann
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 only exceptions to this are a few network and scsi drivers for m68k
Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
with the old interfaces and are probably not worth changing.

On alpha and parisc, virt_to_bus() were still used in asm/floppy.h.
alpha can use isa_virt_to_bus() like x86 does, and parisc can just
open-code the virt_to_phys() here, as this is architecture specific
code.

I tried updating the bus-virt-phys-mapping.rst documentation, which
started as an email from Linus to explain some details of the Linux-2.0
driver interfaces. The bits about virt_to_bus() were declared obsolete
backin 2000, and the rest is not all that relevant any more, so in the
end I just decided to remove the file completely.

Reviewed-by: Geert Uytterhoeven 
Acked-by: Geert Uytterhoeven 
Acked-by: Michael Ellerman  (powerpc)
Signed-off-by: Arnd Bergmann 
---
 .../core-api/bus-virt-phys-mapping.rst| 220 --
 Documentation/core-api/dma-api-howto.rst  |  14 --
 Documentation/core-api/index.rst  |   1 -
 .../translations/zh_CN/core-api/index.rst |   1 -
 arch/alpha/Kconfig|   1 -
 arch/alpha/include/asm/floppy.h   |   2 +-
 arch/alpha/include/asm/io.h   |   8 +-
 arch/ia64/Kconfig |   1 -
 arch/ia64/include/asm/io.h|   8 -
 arch/m68k/Kconfig |   1 -
 arch/m68k/include/asm/virtconvert.h   |   4 +-
 arch/microblaze/Kconfig   |   1 -
 arch/microblaze/include/asm/io.h  |   2 -
 arch/mips/Kconfig |   1 -
 arch/mips/include/asm/io.h|   9 -
 arch/parisc/Kconfig   |   1 -
 arch/parisc/include/asm/floppy.h  |   4 +-
 arch/parisc/include/asm/io.h  |   2 -
 arch/powerpc/Kconfig  |   1 -
 arch/powerpc/include/asm/io.h |   2 -
 arch/riscv/include/asm/page.h |   1 -
 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/io.h |   9 -
 arch/xtensa/Kconfig   |   1 -
 arch/xtensa/include/asm/io.h  |   3 -
 include/asm-generic/io.h  |  14 --
 mm/Kconfig|   8 -
 27 files changed, 10 insertions(+), 311 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst

diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst 
b/Documentation/core-api/bus-virt-phys-mapping.rst
deleted file mode 100644
index c72b24a7d52c..
--- a/Documentation/core-api/bus-virt-phys-mapping.rst
+++ /dev/null
@@ -1,220 +0,0 @@
-==
-How to access I/O mapped memory from within device drivers
-==
-
-:Author: Linus
-
-.. warning::
-
-   The virt_to_bus() and bus_to_virt() functions have been
-   superseded by the functionality provided by the PCI DMA interface
-   (see Documentation/core-api/dma-api-howto.rst).  They continue
-   to be documented below for historical purposes, but new code
-   must not use them. --davidm 00/12/12
-
-::
-
-  [ This is a mail message in response to a query on IO mapping, thus the
-strange format for a "document" ]
-
-The AHA-1542 is a bus-master device, and your patch makes the driver give the
-controller the physical address of the buffers, which is correct on x86
-(because all bus master devices see the physical memory mappings directly). 
-
-However, on many setups, there are actually **three** different ways of looking
-at memory addresses, and in this case we actually want the third, the
-so-called "bus address". 
-
-Essentially, the three ways of addressing memory are (this is "real memory",
-that is, normal RAM--see later about other details): 
-
- - CPU untranslated.  This is the "physical" address.  Physical address 
-   0 is what the CPU sees when it drives zeroes on the memory bus.
-
- - CPU translated address. This is the "virtual" address, and is 
-   completely internal to the CPU itself with the CPU doing the appropriate
-   translations into "CPU untranslated". 
-
- - bus address. This is the address of memory as seen by OTHER devices, 
-   not the CPU. Now, in theory there could be many different bus 
-   addresses, with each device seeing memory in some device-specific way, but
-   happily most hardware designers aren't actually actively trying to make
-   things any more comp

[PATCH v2 2/3] scsi: BusLogic remove bus_to_virt

2022-06-17 Thread Arnd Bergmann
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 to 64-bit."),
the driver had a dependency on x86-32, presumably because of this
problem. However, the change introduced another bug that made it still
impossible to use the driver on any 64-bit machine.

This was in turn fixed in commit 56f396146af2 ("scsi: BusLogic: Fix
64-bit system enumeration error for Buslogic"), 8 years later, which
shows that there are not a lot of users.

Maciej is still using the driver on 32-bit hardware, and Khalid mentioned
that the driver works with the device emulation used in VirtualBox
and VMware. Both of those only emulate it for Windows 2000 and older
operating systems that did not ship with the better LSI logic driver.

Do a minimum fix that searches through the list of descriptors to find
one that matches the bus address. This is clearly as inefficient as
was indicated in the code comment about the lack of a bus_to_virt()
replacement. A better fix would likely involve changing out the entire
descriptor allocation for a simpler one, but that would be much
more invasive.

Cc: Maciej W. Rozycki 
Cc: Matt Wang 
Cc: Khalid Aziz 
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/BusLogic.c | 27 ---
 drivers/scsi/Kconfig|  2 +-
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index a897c8f914cf..d057abfcdd5c 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -2515,12 +2515,26 @@ static int blogic_resultcode(struct blogic_adapter 
*adapter,
return (hoststatus << 16) | tgt_status;
 }
 
+/*
+ * turn the dma address from an inbox into a ccb pointer
+ * This is rather inefficient.
+ */
+static struct blogic_ccb *
+blogic_inbox_to_ccb(struct blogic_adapter *adapter, struct blogic_inbox *inbox)
+{
+   struct blogic_ccb *ccb;
+
+   for (ccb = adapter->all_ccbs; ccb; ccb = ccb->next_all)
+   if (inbox->ccb == ccb->dma_handle)
+   break;
+
+   return ccb;
+}
 
 /*
   blogic_scan_inbox scans the Incoming Mailboxes saving any
   Incoming Mailbox entries for completion processing.
 */
-
 static void blogic_scan_inbox(struct blogic_adapter *adapter)
 {
/*
@@ -2540,16 +2554,7 @@ static void blogic_scan_inbox(struct blogic_adapter 
*adapter)
enum blogic_cmplt_code comp_code;
 
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(
-  actually works.  There *needs* to be a dma_addr_to_virt()
-  in the new PCI DMA mapping interface to replace
-  bus_to_virt() or else this code is going to become very
-  innefficient.
-*/
-   struct blogic_ccb *ccb =
-   (struct blogic_ccb *) bus_to_virt(next_inbox->ccb);
+   struct blogic_ccb *ccb = blogic_inbox_to_ccb(adapter, 
adapter->next_inbox);
if (comp_code != BLOGIC_CMD_NOTFOUND) {
if (ccb->status == BLOGIC_CCB_ACTIVE ||
ccb->status == BLOGIC_CCB_RESET) {
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index cf75588a2587..56bdc08d0b77 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -513,7 +513,7 @@ config SCSI_HPTIOP
 
 config SCSI_BUSLOGIC
tristate "BusLogic SCSI support"
-   depends on PCI && SCSI && VIRT_TO_BUS
+   depends on PCI && SCSI
help
  This is support for BusLogic MultiMaster and FlashPoint SCSI Host
  Adapters. Consult the SCSI-HOWTO, available from
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2 0/3] phase out CONFIG_VIRT_TO_BUS

2022-06-17 Thread Arnd Bergmann
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 interface for good.

Any out of tree drivers using virt_to_bus() should be converted to
using the dma-mapping interfaces, typically dma_alloc_coherent()
or dma_map_single()).

There are a few m68k and ppc32 specific drivers that keep using the
interfaces, but these are all guarded with architecture-specific
Kconfig dependencies, and are not actually broken.

There are still a number of drivers that are using virt_to_phys()
and phys_to_virt() in place of dma-mapping operations, and these
are often broken, but they are out of scope for this series.

I would like the first two patches to either get merged through
the SCSI tree, or get an Ack from the SCSI maintainers so I can
merge them through the asm-generic tree

  Arnd

---
Changes since v1:
 - dropped VME patches that are already in staging-next
 - dropped media patch that gets merged independently
 - added a networking patch and dropped it again after it got merged
 - replace BusLogic removal with a workaround

Cc: Jakub Kicinski 
Cc: Christoph Hellwig  # dma-mapping
Cc: Marek Szyprowski  # dma-mapping
Cc: Robin Murphy  # dma-mapping
Cc: iommu@lists.linux-foundation.org
Cc: Khalid Aziz  # buslogic
Cc: Maciej W. Rozycki  # buslogic
Cc: Matt Wang  # buslogic
Cc: Miquel van Smoorenburg  # dpt_i2o
Cc: Mark Salyzyn  # dpt_i2o
Cc: linux-s...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-par...@vger.kernel.org
Cc: Denis Efremov  # floppy

Arnd Bergmann (3):
  scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency
  scsi: BusLogic remove bus_to_virt
  arch/*/: remove CONFIG_VIRT_TO_BUS

 .../core-api/bus-virt-phys-mapping.rst| 220 --
 Documentation/core-api/dma-api-howto.rst  |  14 --
 Documentation/core-api/index.rst  |   1 -
 .../translations/zh_CN/core-api/index.rst |   1 -
 arch/alpha/Kconfig|   1 -
 arch/alpha/include/asm/floppy.h   |   2 +-
 arch/alpha/include/asm/io.h   |   8 +-
 arch/ia64/Kconfig |   1 -
 arch/ia64/include/asm/io.h|   8 -
 arch/m68k/Kconfig |   1 -
 arch/m68k/include/asm/virtconvert.h   |   4 +-
 arch/microblaze/Kconfig   |   1 -
 arch/microblaze/include/asm/io.h  |   2 -
 arch/mips/Kconfig |   1 -
 arch/mips/include/asm/io.h|   9 -
 arch/parisc/Kconfig   |   1 -
 arch/parisc/include/asm/floppy.h  |   4 +-
 arch/parisc/include/asm/io.h  |   2 -
 arch/powerpc/Kconfig  |   1 -
 arch/powerpc/include/asm/io.h |   2 -
 arch/riscv/include/asm/page.h |   1 -
 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/io.h |   9 -
 arch/xtensa/Kconfig   |   1 -
 arch/xtensa/include/asm/io.h  |   3 -
 drivers/scsi/BusLogic.c   |  27 ++-
 drivers/scsi/Kconfig  |   4 +-
 drivers/scsi/dpt_i2o.c|   4 +-
 include/asm-generic/io.h  |  14 --
 mm/Kconfig|   8 -
 30 files changed, 30 insertions(+), 326 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst

-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2 1/3] scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency

2022-06-17 Thread Arnd Bergmann
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 remove the driver, as it is
clearly obsolete. The i2o driver layer was removed in 2015 with commit
4a72a7af462d ("staging: remove i2o subsystem"), but the even older
dpt_i2o scsi driver stayed around.

The last non-cleanup patches I could find were from Miquel van Smoorenburg
and Mark Salyzyn back in 2008, they might know if there is any chance
of the hardware still being used anywhere.

Fixes: 67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt to 
dma_alloc_coherent")
Cc: Miquel van Smoorenburg 
Cc: Mark Salyzyn 
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/Kconfig   | 2 +-
 drivers/scsi/dpt_i2o.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a9fe5152addd..cf75588a2587 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -460,7 +460,7 @@ config SCSI_MVUMI
 
 config SCSI_DPT_I2O
tristate "Adaptec I2O RAID support "
-   depends on SCSI && PCI && VIRT_TO_BUS
+   depends on SCSI && PCI
help
  This driver supports all of Adaptec's I2O based RAID controllers as 
  well as the DPT SmartRaid V cards.  This is an Adaptec maintained
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 2e9155ba7408..55dfe7011912 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -52,11 +52,11 @@ MODULE_DESCRIPTION("Adaptec I2O RAID Driver");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include  /* for boot_cpu_data */
-#include /* for virt_to_bus, etc. */
 
 #include 
 #include 
@@ -2112,7 +2112,7 @@ static irqreturn_t adpt_isr(int irq, void *dev_id)
} else {
/* Ick, we should *never* be here */
printk(KERN_ERR "dpti: reply frame not from pool\n");
-   reply = (u8 *)bus_to_virt(m);
+   goto out;
}
 
if (readl(reply) & MSG_FAIL) {
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 5/6] scsi: remove stale BusLogic driver

2022-06-08 Thread Arnd Bergmann
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 until we do not have any users.

Maciej already offered to help fix the driver, so I think it will be ok.

On the other hand, it sounds like VirtualBox users should not actually try to
use the BusLogic driver with modern Linux guests. From what I can tell
from the documentation [1], VirtualBox only provides this emulation because it
was shipped with early versions of VMware and is supported by Windows 2000
and earlier, but not actually on any modern Windows guest. The VMware
documentation in turn explicitly says that BusLogic does not work with 64-bit
guests [2], presumably this applies to both Windows and Linux guests.

Arnd

[1] https://www.virtualbox.org/manual/ch05.html#harddiskcontrollers
[2] https://kb.vmware.com/s/article/2010470
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/6] phase out CONFIG_VIRT_TO_BUS

2022-06-06 Thread Arnd Bergmann
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 here.

Thanks,

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 5/6] scsi: remove stale BusLogic driver

2022-06-06 Thread Arnd Bergmann
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.
> >
> > The fact that this was found at all is an indication that there are
> > users, and it seems that Maciej, Matt and Khalid all have access to
> > this hardware, but if it took eight years to find the problem,
> > it's likely that nobody actually relies on it.
>
>  Umm, I use it with a 32-bit system, so it would be quite an issue for me
> to discover a problem with 64-bit configurations.  And I quite rely on
> this system for various stuff too!

Ok, good to know.

> > Remove it as part of the global virt_to_bus()/bus_to_virt() removal.
> > If anyone is still interested in keeping this driver, the alternative
> > is to stop it from using bus_to_virt(), possibly along the lines of
> > how dpt_i2o gets around the same issue.
>
>  Thanks for the pointer and for cc-ing me.  Please refrain from removing
> the driver at least for this release cycle and let me fix it.

Sure, no problem. It looks like I forgot to actually Cc you on the series
as I had meant to, glad it reached you anyway.

> It should be easy to mimic what I did for the defza driver: all bus addresses 
> in
> the DMA API come associated with virtual addresses, so it is just a matter of
> recording those somewhere for later use rather than trying to mess up with
> bus addresses to figure out a reverse mapping.

I looked at the defza driver and that one appears simpler to me, as you
can look up the virtual address from an index, but it's possible I missed
what you do here. I meant specifically the calculation added by commit
67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt
to dma_alloc_coherent") in the dpt_i2o driver that can be used to
compute the virtual address. If something simpler works as well, that
is of course better.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 6/6] arch/*/: remove CONFIG_VIRT_TO_BUS

2022-06-06 Thread Arnd Bergmann
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 only exceptions to this are a few network and scsi drivers for m68k
Amiga and VME machines and ppc32 Macintosh. These drivers work correctly
with the old interfaces and are probably not worth changing.

On alpha and parisc, virt_to_bus() were still used in asm/floppy.h.
alpha can use isa_virt_to_bus() like x86 does, and parisc can just
open-code the virt_to_phys() here, as this is architecture specific
code.

I tried updating the bus-virt-phys-mapping.rst documentation, which
started as an email from Linus to explain some details of the Linux-2.0
driver interfaces. The bits about virt_to_bus() were declared obsolete
backin 2000, and the rest is not all that relevant any more, so in the
end I just decided to remove the file completely.

Signed-off-by: Arnd Bergmann 
---
 .../core-api/bus-virt-phys-mapping.rst| 220 --
 Documentation/core-api/dma-api-howto.rst  |  14 --
 Documentation/core-api/index.rst  |   1 -
 .../translations/zh_CN/core-api/index.rst |   1 -
 arch/alpha/Kconfig|   1 -
 arch/alpha/include/asm/floppy.h   |   2 +-
 arch/alpha/include/asm/io.h   |   8 +-
 arch/ia64/Kconfig |   1 -
 arch/ia64/include/asm/io.h|   8 -
 arch/m68k/Kconfig |   1 -
 arch/m68k/include/asm/virtconvert.h   |   4 +-
 arch/microblaze/Kconfig   |   1 -
 arch/microblaze/include/asm/io.h  |   2 -
 arch/mips/Kconfig |   1 -
 arch/mips/include/asm/io.h|   9 -
 arch/parisc/Kconfig   |   1 -
 arch/parisc/include/asm/floppy.h  |   4 +-
 arch/parisc/include/asm/io.h  |   2 -
 arch/powerpc/Kconfig  |   1 -
 arch/powerpc/include/asm/io.h |   2 -
 arch/riscv/include/asm/page.h |   1 -
 arch/x86/Kconfig  |   1 -
 arch/x86/include/asm/io.h |   9 -
 arch/xtensa/Kconfig   |   1 -
 arch/xtensa/include/asm/io.h  |   3 -
 include/asm-generic/io.h  |  14 --
 mm/Kconfig|   8 -
 27 files changed, 10 insertions(+), 311 deletions(-)
 delete mode 100644 Documentation/core-api/bus-virt-phys-mapping.rst

diff --git a/Documentation/core-api/bus-virt-phys-mapping.rst 
b/Documentation/core-api/bus-virt-phys-mapping.rst
deleted file mode 100644
index c72b24a7d52c..
--- a/Documentation/core-api/bus-virt-phys-mapping.rst
+++ /dev/null
@@ -1,220 +0,0 @@
-==
-How to access I/O mapped memory from within device drivers
-==
-
-:Author: Linus
-
-.. warning::
-
-   The virt_to_bus() and bus_to_virt() functions have been
-   superseded by the functionality provided by the PCI DMA interface
-   (see Documentation/core-api/dma-api-howto.rst).  They continue
-   to be documented below for historical purposes, but new code
-   must not use them. --davidm 00/12/12
-
-::
-
-  [ This is a mail message in response to a query on IO mapping, thus the
-strange format for a "document" ]
-
-The AHA-1542 is a bus-master device, and your patch makes the driver give the
-controller the physical address of the buffers, which is correct on x86
-(because all bus master devices see the physical memory mappings directly). 
-
-However, on many setups, there are actually **three** different ways of looking
-at memory addresses, and in this case we actually want the third, the
-so-called "bus address". 
-
-Essentially, the three ways of addressing memory are (this is "real memory",
-that is, normal RAM--see later about other details): 
-
- - CPU untranslated.  This is the "physical" address.  Physical address 
-   0 is what the CPU sees when it drives zeroes on the memory bus.
-
- - CPU translated address. This is the "virtual" address, and is 
-   completely internal to the CPU itself with the CPU doing the appropriate
-   translations into "CPU untranslated". 
-
- - bus address. This is the address of memory as seen by OTHER devices, 
-   not the CPU. Now, in theory there could be many different bus 
-   addresses, with each device seeing memory in some device-specific way, but
-   happily most hardware designers aren't actually actively trying to make
-   things any more complex than necessary, so you can assume that all 
-   external hardware sees the memory the same way

[PATCH 4/6] scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency

2022-06-06 Thread Arnd Bergmann
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 the driver, as it is
clearly obsolete. The i2o driver layer was removed in 2015 with commit
4a72a7af462d ("staging: remove i2o subsystem"), but the even older
dpt_i2o scsi driver stayed around.

The last non-cleanup patches I could find were from Miquel van
Smoorenburg and Mark Salyzyn back in 2008, they might know if
there is any chance of the hardware still being used anywhere.

Fixes: 67af2b060e02 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt to 
dma_alloc_coherent")
Cc: Miquel van Smoorenburg 
Cc: Mark Salyzyn 
Signed-off-by: Arnd Bergmann 
---
 drivers/scsi/Kconfig   | 2 +-
 drivers/scsi/dpt_i2o.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a9fe5152addd..cf75588a2587 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -460,7 +460,7 @@ config SCSI_MVUMI
 
 config SCSI_DPT_I2O
tristate "Adaptec I2O RAID support "
-   depends on SCSI && PCI && VIRT_TO_BUS
+   depends on SCSI && PCI
help
  This driver supports all of Adaptec's I2O based RAID controllers as 
  well as the DPT SmartRaid V cards.  This is an Adaptec maintained
diff --git a/drivers/scsi/dpt_i2o.c b/drivers/scsi/dpt_i2o.c
index 2e9155ba7408..55dfe7011912 100644
--- a/drivers/scsi/dpt_i2o.c
+++ b/drivers/scsi/dpt_i2o.c
@@ -52,11 +52,11 @@ MODULE_DESCRIPTION("Adaptec I2O RAID Driver");
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
 #include  /* for boot_cpu_data */
-#include /* for virt_to_bus, etc. */
 
 #include 
 #include 
@@ -2112,7 +2112,7 @@ static irqreturn_t adpt_isr(int irq, void *dev_id)
} else {
/* Ick, we should *never* be here */
printk(KERN_ERR "dpti: reply frame not from pool\n");
-   reply = (u8 *)bus_to_virt(m);
+   goto out;
}
 
if (readl(reply) & MSG_FAIL) {
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 3/6] media: sta2x11: remove VIRT_TO_BUS dependency

2022-06-06 Thread Arnd Bergmann
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 fails to build on some
architectures that are missing CONFIG_VIRT_TO_BUS, but it is
always set on x86 machines with the STA2X11 platform enabled.

More likely though is that it was never meant to depend on
CONFIG_VIRT_TO_BUS, and the Kconfig dependency was kept from
an out-of-tree version when the driver was originally merged.

Fixes: efeb98b4e2b2 ("[media] STA2X11 VIP: new V4L2 driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/pci/sta2x11/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/sta2x11/Kconfig 
b/drivers/media/pci/sta2x11/Kconfig
index a96e170ab04e..118b922c08c3 100644
--- a/drivers/media/pci/sta2x11/Kconfig
+++ b/drivers/media/pci/sta2x11/Kconfig
@@ -1,7 +1,7 @@
 # SPDX-License-Identifier: GPL-2.0-only
 config STA2X11_VIP
tristate "STA2X11 VIP Video For Linux"
-   depends on PCI && VIDEO_DEV && VIRT_TO_BUS && I2C
+   depends on PCI && VIDEO_DEV && I2C
depends on STA2X11 || COMPILE_TEST
select GPIOLIB if MEDIA_SUBDRV_AUTOSELECT
select VIDEO_ADV7180 if MEDIA_SUBDRV_AUTOSELECT
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 1/6] vme: remove ca91cx42 Universe-II support

2022-06-06 Thread Arnd Bergmann
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 introduced in 1997 and
only supports 32-bit legacy PCI. It was replaced by TSI148 in
2004, but that chip has since been discontinued, while a version
of the older Universe II remains in production after 25 years.

The vme_vmivme7805 board uses Universe-II, so this also gets
removed in the process, but PCI add-on cards based on TSI148
can still work in theory.

If there are users of the Universe-II driver after all, it is
of course possible to revert this patch and fix it to use the
dma-mapping interface like the tsi148 driver does.

Signed-off-by: Arnd Bergmann 
---
 drivers/vme/Kconfig |2 -
 drivers/vme/Makefile|1 -
 drivers/vme/boards/Kconfig  |   10 -
 drivers/vme/boards/Makefile |6 -
 drivers/vme/boards/vme_vmivme7805.c |  106 --
 drivers/vme/boards/vme_vmivme7805.h |   33 -
 drivers/vme/bridges/Kconfig |7 -
 drivers/vme/bridges/Makefile|1 -
 drivers/vme/bridges/vme_ca91cx42.c  | 1928 ---
 drivers/vme/bridges/vme_ca91cx42.h  |  579 
 10 files changed, 2673 deletions(-)
 delete mode 100644 drivers/vme/boards/Kconfig
 delete mode 100644 drivers/vme/boards/Makefile
 delete mode 100644 drivers/vme/boards/vme_vmivme7805.c
 delete mode 100644 drivers/vme/boards/vme_vmivme7805.h
 delete mode 100644 drivers/vme/bridges/vme_ca91cx42.c
 delete mode 100644 drivers/vme/bridges/vme_ca91cx42.h

diff --git a/drivers/vme/Kconfig b/drivers/vme/Kconfig
index c13dd9d2a604..26feabba19d2 100644
--- a/drivers/vme/Kconfig
+++ b/drivers/vme/Kconfig
@@ -13,6 +13,4 @@ if VME_BUS
 
 source "drivers/vme/bridges/Kconfig"
 
-source "drivers/vme/boards/Kconfig"
-
 endif # VME
diff --git a/drivers/vme/Makefile b/drivers/vme/Makefile
index 8bfe4b370c41..2dfb929a23de 100644
--- a/drivers/vme/Makefile
+++ b/drivers/vme/Makefile
@@ -5,4 +5,3 @@
 obj-$(CONFIG_VME_BUS)  += vme.o
 
 obj-y  += bridges/
-obj-y  += boards/
diff --git a/drivers/vme/boards/Kconfig b/drivers/vme/boards/Kconfig
deleted file mode 100644
index 7a255f72980b..
--- a/drivers/vme/boards/Kconfig
+++ /dev/null
@@ -1,10 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-comment "VME Board Drivers"
-
-config VMIVME_7805
-   tristate "VMIVME-7805"
-   help
- If you say Y here you get support for the VMIVME-7805 board.
- This board has an additional control interface to the Universe II
- chip. This driver has to be included if you want to access VME bus
- with VMIVME-7805 board.
diff --git a/drivers/vme/boards/Makefile b/drivers/vme/boards/Makefile
deleted file mode 100644
index 87122381452c..
--- a/drivers/vme/boards/Makefile
+++ /dev/null
@@ -1,6 +0,0 @@
-# SPDX-License-Identifier: GPL-2.0-only
-#
-# Makefile for the VME board drivers.
-#
-
-obj-$(CONFIG_VMIVME_7805)  += vme_vmivme7805.o
diff --git a/drivers/vme/boards/vme_vmivme7805.c 
b/drivers/vme/boards/vme_vmivme7805.c
deleted file mode 100644
index 51e056bae943..
--- a/drivers/vme/boards/vme_vmivme7805.c
+++ /dev/null
@@ -1,106 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * Support for the VMIVME-7805 board access to the Universe II bridge.
- *
- * Author: Arthur Benilov 
- * Copyright 2010 Ion Beam Application, Inc.
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "vme_vmivme7805.h"
-
-static int vmic_probe(struct pci_dev *, const struct pci_device_id *);
-static void vmic_remove(struct pci_dev *);
-
-/** Base address to access FPGA register */
-static void __iomem *vmic_base;
-
-static const char driver_name[] = "vmivme_7805";
-
-static const struct pci_device_id vmic_ids[] = {
-   { PCI_DEVICE(PCI_VENDOR_ID_VMIC, PCI_DEVICE_ID_VTIMR) },
-   { },
-};
-
-static struct pci_driver vmic_driver = {
-   .name = driver_name,
-   .id_table = vmic_ids,
-   .probe = vmic_probe,
-   .remove = vmic_remove,
-};
-
-static int vmic_probe(struct pci_dev *pdev, const struct pci_device_id *id)
-{
-   int retval;
-   u32 data;
-
-   /* Enable the device */
-   retval = pci_enable_device(pdev);
-   if (retval) {
-   dev_err(>dev, "Unable to enable device\n");
-   goto err;
-   }
-
-   /* Map Registers */
-   retval = pci_request_regions(pdev, driver_name);
-   if (retval) {
-   dev_err(>dev, "Unable to reserve resources\n");
-   goto err_resource;
-   }
-
-   /* Map registers in BAR 0 */
-   vmic_base = ioremap(pci_resource_start(pdev, 0), 16);

[PATCH 2/6] vme: move back to staging

2022-06-06 Thread Arnd Bergmann
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 working through, that should happen soon,
hopefully.

However, this never happened: maintenance of drivers/vme effectively
stopped in 2017, with all subsequent changes being treewide cleanups.
No hardware driver remains in staging, only the limited user-level
access, and I just removed one of the two bridge drivers and the only
remaining board.

drivers/staging/vme/devices/ was recently moved to
drivers/staging/vme_user/, but as the vme_user driver is the only one
remaining for this subsystem, it is easier to just move the remaining
three source files into this directory rather than keeping the original
hierarchy.

Signed-off-by: Arnd Bergmann 
---
 Documentation/driver-api/vme.rst  |  4 +--
 MAINTAINERS   |  4 +--
 drivers/Kconfig   |  2 --
 drivers/Makefile  |  1 -
 drivers/staging/vme_user/Kconfig  | 27 +++
 drivers/staging/vme_user/Makefile |  3 +++
 drivers/{vme => staging/vme_user}/vme.c   |  2 +-
 .../linux => drivers/staging/vme_user}/vme.h  |  0
 .../{vme => staging/vme_user}/vme_bridge.h|  2 +-
 .../bridges => staging/vme_user}/vme_fake.c   |  4 +--
 .../bridges => staging/vme_user}/vme_tsi148.c |  4 +--
 .../bridges => staging/vme_user}/vme_tsi148.h |  0
 drivers/staging/vme_user/vme_user.c   |  2 +-
 drivers/vme/Kconfig   | 16 ---
 drivers/vme/Makefile  |  7 -
 drivers/vme/bridges/Kconfig   | 17 
 drivers/vme/bridges/Makefile  |  3 ---
 17 files changed, 40 insertions(+), 58 deletions(-)
 rename drivers/{vme => staging/vme_user}/vme.c (99%)
 rename {include/linux => drivers/staging/vme_user}/vme.h (100%)
 rename drivers/{vme => staging/vme_user}/vme_bridge.h (99%)
 rename drivers/{vme/bridges => staging/vme_user}/vme_fake.c (99%)
 rename drivers/{vme/bridges => staging/vme_user}/vme_tsi148.c (99%)
 rename drivers/{vme/bridges => staging/vme_user}/vme_tsi148.h (100%)
 delete mode 100644 drivers/vme/Kconfig
 delete mode 100644 drivers/vme/Makefile
 delete mode 100644 drivers/vme/bridges/Kconfig
 delete mode 100644 drivers/vme/bridges/Makefile

diff --git a/Documentation/driver-api/vme.rst b/Documentation/driver-api/vme.rst
index def139c13410..c0b475369de0 100644
--- a/Documentation/driver-api/vme.rst
+++ b/Documentation/driver-api/vme.rst
@@ -290,8 +290,8 @@ The function :c:func:`vme_bus_num` returns the bus ID of 
the provided bridge.
 VME API
 ---
 
-.. kernel-doc:: include/linux/vme.h
+.. kernel-doc:: drivers/staging/vme_user/vme.h
:internal:
 
-.. kernel-doc:: drivers/vme/vme.c
+.. kernel-doc:: drivers/staging/vme_user/vme.c
:export:
diff --git a/MAINTAINERS b/MAINTAINERS
index a6d3bd9d2a8d..d8e2cdbb93e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21229,12 +21229,10 @@ M:Martyn Welch 
 M: Manohar Vanga 
 M: Greg Kroah-Hartman 
 L: linux-ker...@vger.kernel.org
-S: Maintained
+S: Odd fixes
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git
 F: Documentation/driver-api/vme.rst
 F: drivers/staging/vme_user/
-F: drivers/vme/
-F: include/linux/vme*
 
 VM SOCKETS (AF_VSOCK)
 M: Stefano Garzarella 
diff --git a/drivers/Kconfig b/drivers/Kconfig
index b6a172d32a7d..19ee995bd0ae 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -183,8 +183,6 @@ source "drivers/iio/Kconfig"
 
 source "drivers/ntb/Kconfig"
 
-source "drivers/vme/Kconfig"
-
 source "drivers/pwm/Kconfig"
 
 source "drivers/irqchip/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 9a30842b22c5..dadf2678277f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -165,7 +165,6 @@ obj-$(CONFIG_PM_DEVFREQ)+= devfreq/
 obj-$(CONFIG_EXTCON)   += extcon/
 obj-$(CONFIG_MEMORY)   += memory/
 obj-$(CONFIG_IIO)  += iio/
-obj-$(CONFIG_VME_BUS)  += vme/
 obj-$(CONFIG_IPACK_BUS)+= ipack/
 obj-$(CONFIG_NTB)  += ntb/
 obj-$(CONFIG_POWERCAP) += powercap/
diff --git a/drivers/staging/vme_user/Kconfig b/drivers/staging/vme_user/Kconfig
index e8b4461bf27f..c8eabf8f40f1 100644
--- a/drivers/staging/vme_user/Kconfig
+++ b/drivers/staging/vme_user/Kconfig
@@ -1,4 +1,29 @@
 # SPDX-License-Identifier: GPL-2.0
+menuconfig VME_BUS
+   bool "VME bridge support"
+   depends on STAGING && PCI
+   help
+ If you say Y here you get support for the VME bridge Framework.
+
+if VME_BUS
+
+comment "VME Bridge Drivers"
+
+c

[PATCH 0/6] phase out CONFIG_VIRT_TO_BUS

2022-06-06 Thread Arnd Bergmann
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 interface for good.

Any out of tree drivers using virt_to_bus() should be converted to
using the dma-mapping interfaces, typically dma_alloc_coherent()
or dma_map_single()).

There are a few m68k and ppc32 specific drivers that keep using the
interfaces, but these are all guarded with architecture-specific
Kconfig dependencies, and are not actually broken.

There are still a number of drivers that are using virt_to_phys()
and phys_to_virt() in place of dma-mapping operations, and these
are often broken, but they are out of scope for this series.

  Arnd

Cc: Jakub Kicinski 
Cc: Christoph Hellwig  # dma-mapping
Cc: Marek Szyprowski  # dma-mapping
Cc: Robin Murphy  # dma-mapping
Cc: iommu@lists.linux-foundation.org
Cc: Khalid Aziz  # buslogic
Cc: linux-s...@vger.kernel.org
Cc: Manohar Vanga  # vme
Cc: Martyn Welch  # vme
Cc: Greg Kroah-Hartman  # vme
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-a...@vger.kernel.org
Cc: linux-al...@vger.kernel.org
Cc: linux-m...@lists.linux-m68k.org
Cc: linux-par...@vger.kernel.org
Cc: Denis Efremov  # floppy

Arnd Bergmann (6):
  vme: remove ca91cx42 Universe-II support
  vme: move back to staging
  media: sta2x11: remove VIRT_TO_BUS dependency
  scsi: dpt_i2o: drop stale VIRT_TO_BUS dependency
  scsi: remove stale BusLogic driver
  arch/*/: remove CONFIG_VIRT_TO_BUS

 .../core-api/bus-virt-phys-mapping.rst|  220 -
 Documentation/core-api/dma-api-howto.rst  |   14 -
 Documentation/core-api/index.rst  |1 -
 Documentation/driver-api/vme.rst  |4 +-
 Documentation/scsi/BusLogic.rst   |  581 --
 Documentation/scsi/FlashPoint.rst |  176 -
 .../translations/zh_CN/core-api/index.rst |1 -
 MAINTAINERS   |   11 +-
 arch/alpha/Kconfig|1 -
 arch/alpha/include/asm/floppy.h   |2 +-
 arch/alpha/include/asm/io.h   |8 +-
 arch/ia64/Kconfig |1 -
 arch/ia64/include/asm/io.h|8 -
 arch/m68k/Kconfig |1 -
 arch/m68k/include/asm/virtconvert.h   |4 +-
 arch/microblaze/Kconfig   |1 -
 arch/microblaze/include/asm/io.h  |2 -
 arch/mips/Kconfig |1 -
 arch/mips/include/asm/io.h|9 -
 arch/parisc/Kconfig   |1 -
 arch/parisc/include/asm/floppy.h  |4 +-
 arch/parisc/include/asm/io.h  |2 -
 arch/powerpc/Kconfig  |1 -
 arch/powerpc/include/asm/io.h |2 -
 arch/riscv/include/asm/page.h |1 -
 arch/x86/Kconfig  |1 -
 arch/x86/include/asm/io.h |9 -
 arch/xtensa/Kconfig   |1 -
 arch/xtensa/include/asm/io.h  |3 -
 drivers/Kconfig   |2 -
 drivers/Makefile  |1 -
 drivers/media/pci/sta2x11/Kconfig |2 +-
 drivers/scsi/BusLogic.c   | 3727 
 drivers/scsi/BusLogic.h   | 1284 ---
 drivers/scsi/FlashPoint.c | 7560 -
 drivers/scsi/Kconfig  |   26 +-
 drivers/scsi/dpt_i2o.c|4 +-
 drivers/staging/vme_user/Kconfig  |   27 +
 drivers/staging/vme_user/Makefile |3 +
 drivers/{vme => staging/vme_user}/vme.c   |2 +-
 .../linux => drivers/staging/vme_user}/vme.h  |0
 .../{vme => staging/vme_user}/vme_bridge.h|2 +-
 .../bridges => staging/vme_user}/vme_fake.c   |4 +-
 .../bridges => staging/vme_user}/vme_tsi148.c |4 +-
 .../bridges => staging/vme_user}/vme_tsi148.h |0
 drivers/staging/vme_user/vme_user.c   |2 +-
 drivers/vme/Kconfig   |   18 -
 drivers/vme/Makefile  |8 -
 drivers/vme/boards/Kconfig|   10 -
 drivers/vme/boards/Makefile   |6 -
 drivers/vme/boards/vme_vmivme7805.c   |  106 -
 drivers/vme/boards/vme_vmivme7805.h   |   33 -
 drivers/vme/bridges/Kconfig   |   24 -
 drivers/vme/bridges/Makefile  |4 -
 drivers/vme/bridges/vme_ca91cx42.c| 1928 -
 drivers/vme/bridges/vme_ca91cx42.h|  579 --
 include/asm-generic/io.h  |   14 -
 mm/Kconfig|8 -
 58 files changed, 54 insertions(+), 16405 deletions(-)
 

Re: [PATCH 04/10] ARM/dma-mapping: remove the unused virt_to_dma helper

2022-05-02 Thread Arnd Bergmann
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-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: fully convert arm to use dma-direct

2022-04-21 Thread Arnd Bergmann
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'd love to merge this series through the dma-mapping tree
> as it gives us the opportunity for additional core dma-mapping
> improvements.

Thanks a lot for completing this, it looks all good to me, and I hope that
Russell can test my assabet patch to make sure this doesn't break
anything.

I saw one opportunity for an additional cleanup patch that I commented
on, but that does not stop the rest from getting merged.

I also made sure that this passes the basic kernelci tests across all
arm machines.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 7/7] ARM: use dma-direct unconditionally

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig  wrote:
>
> Use dma-direct unconditionally on arm.  It has already been used for
> some time for LPAE and nommu configurations.
>
> This mostly changes the streaming mapping implementation and the (simple)
> coherent allocator for device that are DMA coherent.  The existing
> complex allocator for uncached mappings for non-coherent devices is still
> used as is using the arch_dma_alloc/arch_dma_free hooks.
>
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/Kconfig   |   4 +-
>  arch/arm/include/asm/dma-mapping.h |  24 --
>  arch/arm/mach-highbank/highbank.c  |   2 +-
>  arch/arm/mach-mvebu/coherency.c|   2 +-
>  arch/arm/mm/dma-mapping.c  | 365 ++---
>  5 files changed, 19 insertions(+), 378 deletions(-)
>  delete mode 100644 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 of machines, which is a good
sign.

Tested-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 6/7] ARM: use the common dma_to_phys/phys_to_dma implementation where possible

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig  wrote:
>
> Only the footbridge platforms provide their own DMA address translation
> helpers, so switch to the generic version for all other platforms, and
> consolidate the footbridge implementation to remove two levels of
> 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 pfn)
> +#else
> +static inline unsigned long fb_bus_sdram_offset(void)
>  {
> -   return __pfn_to_phys(pfn) + (fb_bus_sdram_offset() - PHYS_OFFSET);
> +   return BUS_OFFSET;
>  }
> -EXPORT_SYMBOL(__pfn_to_bus);
> +#endif /* CONFIG_FOOTBRIDGE_ADDIN */

I have an older patch to remove CONFIG_FOOTBRIDGE_ADDIN
completely, as it does a couple of other nasty things and there are
apparently no users. Would that help here?

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 5/7] ARM: use dma_to_phys/phys_to_dma in the dma-mapping code

2022-04-21 Thread Arnd Bergmann
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: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 4/7] ARM: remove the unused virt_to_dma helper

2022-04-21 Thread Arnd Bergmann
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)
> -{
> -   if (dev)
> -   return pfn_to_dma(dev, virt_to_pfn(addr));
> -
> -   return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
> -}

I think __virt_to_bus() is now unused as well and could be removed
in the same step.

It looks like __bus_to_virt() is still used in the ISA DMA API, but
as that is only used on footbridge and rpc, the generic version of
that could be moved into rpc (footbridge already has a custom
version).

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 3/7] ARM: mark various dma-mapping routines static in dma-mapping.c

2022-04-21 Thread Arnd Bergmann
On Thu, Apr 21, 2022 at 9:42 AM Christoph Hellwig  wrote:
>
> With the dmabounce removal these aren't used outside of dma-mapping.c,
> so mark them static.  Move the dma_map_ops declarations down a bit
> to avoid lots of forward declarations.
>
> Signed-off-by: Christoph Hellwig 

Reviewed-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 2/7] ARM: remove dmabounce

2022-04-21 Thread Arnd Bergmann
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-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch V3 12/35] soc: ti: ti_sci_inta_msi: Allocate MSI device data on first use

2021-12-11 Thread Arnd Bergmann
On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Allocate the MSI device data on first invocation of the allocation function.
>
> Signed-off-by: Thomas Gleixner 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Jason Gunthorpe 
> Cc: Nishanth Menon 
> Cc: Tero Kristo 
> Cc: Santosh Shilimkar 
> Cc: linux-arm-ker...@lists.infradead.org

Acked-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch V3 34/35] soc: ti: ti_sci_inta_msi: Get rid of ti_sci_inta_msi_get_virq()

2021-12-11 Thread Arnd Bergmann
On Fri, Dec 10, 2021 at 11:19 PM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> Just use the core function msi_get_virq().
>
> Signed-off-by: Thomas Gleixner 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Jason Gunthorpe 
> Cc: Peter Ujfalusi 
> Cc: Vinod Koul 
> Cc: dmaeng...@vger.kernel.org

Acked-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch V3 07/35] device: Move MSI related data into a struct

2021-12-11 Thread Arnd Bergmann
On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> The only unconditional part of MSI data in struct device is the irqdomain
> pointer. Everything else can be allocated on demand. Create a data
> structure and move the irqdomain pointer into it. The other MSI specific
> parts are going to be removed from struct device in later steps.
>
> Signed-off-by: Thomas Gleixner 
> Reviewed-by: Greg Kroah-Hartman 
> Reviewed-by: Jason Gunthorpe 

Acked-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [patch V3 05/35] powerpc/cell/axon_msi: Use PCI device property

2021-12-11 Thread Arnd Bergmann
On Fri, Dec 10, 2021 at 11:18 PM Thomas Gleixner  wrote:
>
> From: Thomas Gleixner 
>
> instead of fiddling with MSI descriptors.
>
> Signed-off-by: Thomas Gleixner 
> Cc: Arnd Bergmann 
> Cc: Michael Ellerman 
> Cc: Benjamin Herrenschmidt 
> Cc: linuxppc-...@lists.ozlabs.org
> ---

Acked-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC 2/2] drm/msm/gem: Make use of the system cache

2021-11-16 Thread Arnd Bergmann
On Wed, Nov 17, 2021 at 12:16 AM Georgi Djakov
 wrote:
>
> Instead of writing to WC cmdstream buffers that go all the way to the main
> memory, let's use the system cache to improve the performance.
>
> Signed-off-by: Georgi Djakov 
> ---
>  drivers/gpu/drm/msm/msm_gem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
> index 104fdfc14027..921a1c24721e 100644
> --- a/drivers/gpu/drm/msm/msm_gem.c
> +++ b/drivers/gpu/drm/msm/msm_gem.c
> @@ -214,7 +214,7 @@ void msm_gem_put_pages(struct drm_gem_object *obj)
>  static pgprot_t msm_gem_pgprot(struct msm_gem_object *msm_obj, pgprot_t prot)
>  {
> if (msm_obj->flags & (MSM_BO_WC|MSM_BO_UNCACHED))
> -   return pgprot_writecombine(prot);
> +   return pgprot_syscached(prot);
> return prot;
>  }

Based on the definition in patch 1, doesn't this mean that 32-bit
kernels degrade
from writecombined to uncached, making them a lot slower?

My feeling about this series is that there should be a clearer
definition of what
exactly happens on systems with and without system cache.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-13 Thread Arnd Bergmann
On Wed, Oct 13, 2021 at 6:20 PM Will Deacon  wrote:
> On Wed, Oct 13, 2021 at 10:33:55AM +0200, Arnd Bergmann wrote:
> > On Wed, Oct 13, 2021 at 9:58 AM Will Deacon  wrote:
> > > On Tue, Oct 12, 2021 at 05:18:00PM +0200, Arnd Bergmann wrote:

> > I was hoping you and Joerg could just pick your preferred patch
> > into the iommu fixes tree for v5.15.
> >
> > I currently have nothing else pending for my asm-generic tree that
> > introduced the regression, but I can take it through there if that helps
> > you.
>
> I also don't have any fixes pending, and I don't see any in Joerg's tree so
> it's probably quickest if you send it on yourself. Is that ok?

Sure, no problem. I ended up adding it to the arm/fixes branch of the
soc tree, as I just merged some other fixes there, and it seems as good
as any of the other trees.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-13 Thread Arnd Bergmann
On Wed, Oct 13, 2021 at 9:58 AM Will Deacon  wrote:
> On Tue, Oct 12, 2021 at 05:18:00PM +0200, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> >
> > My previous bugfix ended up making things worse for the QCOM IOMMU
> > driver when it forgot to add the Kconfig symbol that is getting used to
> > control the compilation of the SMMU implementation specific code
> > for Qualcomm.
> >
> > Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol")
> > Reported-by: Daniel Lezcano 
> > Reported-by: Dmitry Baryshkov 
> > Reported-by: John Stultz 
> > Link: 
> > https://lore.kernel.org/lkml/20211010023350.978638-1-dmitry.barysh...@linaro.org/
> > Signed-off-by: Arnd Bergmann 
> > ---
> > In case we want fix it this way after all, here is the patch
> > I made. Either this one or Dmitry patch from the link above
> > is required for v5.15
> > ---
> >  drivers/iommu/Kconfig | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index c5c71b7ab7e8..3eb68fa1b8cc 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -355,6 +355,14 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
> > 'arm-smmu.disable_bypass' will continue to override this
> > config.
> >
> > +config ARM_SMMU_QCOM
> > + def_tristate y
> > + depends on ARM_SMMU && ARCH_QCOM
> > + select QCOM_SCM
> > + help
> > +   When running on a Qualcomm platform that has the custom variant
> > +   of the ARM SMMU, this needs to be built into the SMMU driver.
> > +
>
> FWIW, I prefer this solution over changing the driver code, so:
>
> Acked-by: Will Deacon 
>
> I assume you'll be getting this fixed for 5.15?

I was hoping you and Joerg could just pick your preferred patch
into the iommu fixes tree for v5.15.

I currently have nothing else pending for my asm-generic tree that
introduced the regression, but I can take it through there if that helps
you.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu/arm: fix ARM_SMMU_QCOM compilation

2021-10-12 Thread Arnd Bergmann
From: Arnd Bergmann 

My previous bugfix ended up making things worse for the QCOM IOMMU
driver when it forgot to add the Kconfig symbol that is getting used to
control the compilation of the SMMU implementation specific code
for Qualcomm.

Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol")
Reported-by: Daniel Lezcano 
Reported-by: Dmitry Baryshkov 
Reported-by: John Stultz 
Link: 
https://lore.kernel.org/lkml/20211010023350.978638-1-dmitry.barysh...@linaro.org/
Signed-off-by: Arnd Bergmann 
---
In case we want fix it this way after all, here is the patch
I made. Either this one or Dmitry patch from the link above
is required for v5.15
---
 drivers/iommu/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c5c71b7ab7e8..3eb68fa1b8cc 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -355,6 +355,14 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
  'arm-smmu.disable_bypass' will continue to override this
  config.
 
+config ARM_SMMU_QCOM
+   def_tristate y
+   depends on ARM_SMMU && ARCH_QCOM
+   select QCOM_SCM
+   help
+ When running on a Qualcomm platform that has the custom variant
+ of the ARM SMMU, this needs to be built into the SMMU driver.
+
 config ARM_SMMU_V3
tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
depends on ARM64
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-11 Thread Arnd Bergmann
On Mon, Oct 11, 2021 at 11:10 AM Dmitry Baryshkov
 wrote:
>
> On Mon, 11 Oct 2021 at 09:09, Arnd Bergmann  wrote:
> >
> > On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov
> >  wrote:
> > > On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann  wrote:
> > >
> > > The patch seems correct, but it becomes overcomplicated. What about:
> > > - restoring QCOM_SCM stubs
> >
> > The stubs are what has led to the previous bugs in this area to often
> > go unnoticed for too long, as illustrated by your suggestion
> >
> > > - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM
> >
> > I assume you meant "select QCOM_SCM if ARCH_QCOM",
> > after we stop using ARM_SMMU_QCOM?
> >
> > > This would have almost the same result as with your patch, but without
> > > extra ARM_SMMU_QCOM Kconfig symbol.
> >
> > The "almost" is the problem: consider the case of
> >
> > CONFIG_ARM=y
> > CONFIG_COMPILE_TEST=y
> > CONFIG_ARCH_QCOM=n
> > CONFIG_ARM_SMMU=y
> > CONFIG_DRM_MSM=m
> > CONFIG_QCOM_SCM=m (selected by DRM_MSM)
> >
> > The stubs here lead to ARM_SMMU linking against the QCOM_SCM
> > driver from built-in code, which fails because QCOM_SCM itself
> > is a loadable module.
>
> I see. The idealist in me wishes to change my suggestion to
> 'select QCOM_SCM if ARCH_QCOM || COMPILE_TEST'
> but I have the subtle feeling that this also might fail somehow.

I think that would actually work, but it has the nasty side-effect
that simply flipping 'CONFIG_COMPILE_TEST' changes what
the kernel does, rather than just hiding or unhiding additional
options.

> > We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM
> > symbol if we make that a tristate though, if you want to separate it
> > a little more.
>
> This would complicate things a bit, as we would no longer be able to
> use 'arm-smmu-$(CONFIG_ARM_SMMU_QCOM) +=' construct.

I'm fairly sure we could still use that, Kbuild is smart enough
to include both 'file-m +=' and 'file-y += ' in 'file.ko', see
scripts/Makefile.lib:

# If $(foo-objs), $(foo-y), $(foo-m), or $(foo-) exists, foo.o is a
composite object
multi-obj-y := $(call multi-search, $(obj-y), .o, -objs -y)
multi-obj-m := $(call multi-search, $(obj-m), .o, -objs -y -m)
multi-obj-ym := $(multi-obj-y) $(multi-obj-m)

# Replace multi-part objects by their individual parts,
# including built-in.a from subdirectories
real-obj-y := $(call real-search, $(obj-y), .o, -objs -y)
real-obj-m := $(call real-search, $(obj-m), .o, -objs -y -m)

What doesn't work is having a built-in driver in a directory that is
guarded with a =m symbol, or including a =m object into a =y
module.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-11 Thread Arnd Bergmann
On Mon, Oct 11, 2021 at 6:11 AM Dmitry Baryshkov
 wrote:
> On Sun, 10 Oct 2021 at 20:42, Arnd Bergmann  wrote:
>
> The patch seems correct, but it becomes overcomplicated. What about:
> - restoring QCOM_SCM stubs

The stubs are what has led to the previous bugs in this area to often
go unnoticed for too long, as illustrated by your suggestion

> - making ARM_SMMU select QCOM_SCM if ARM_SMMU_QCOM

I assume you meant "select QCOM_SCM if ARCH_QCOM",
after we stop using ARM_SMMU_QCOM?

> This would have almost the same result as with your patch, but without
> extra ARM_SMMU_QCOM Kconfig symbol.

The "almost" is the problem: consider the case of

CONFIG_ARM=y
CONFIG_COMPILE_TEST=y
CONFIG_ARCH_QCOM=n
CONFIG_ARM_SMMU=y
CONFIG_DRM_MSM=m
CONFIG_QCOM_SCM=m (selected by DRM_MSM)

The stubs here lead to ARM_SMMU linking against the QCOM_SCM
driver from built-in code, which fails because QCOM_SCM itself
is a loadable module.

We can move the "select QCOM_SCM" in the ARM_SMMU_QCOM
symbol if we make that a tristate though, if you want to separate it
a little more.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] iommu: fix ARM_SMMU vs QCOM_SCM compilation

2021-10-10 Thread Arnd Bergmann
On Sun, Oct 10, 2021 at 6:17 AM Bjorn Andersson
 wrote:
>
> On Sat 09 Oct 21:33 CDT 2021, Dmitry Baryshkov wrote:
>
> > After commit 424953cf3c66 ("qcom_scm: hide Kconfig symbol") arm-smmu got
> > qcom_smmu_impl_init() call guarded by IS_ENABLED(CONFIG_ARM_SMMU_QCOM).
> > However the CONFIG_ARM_SMMU_QCOM Kconfig entry does not exist, so the
> > qcom_smmu_impl_init() is never called.
> >
> > So, let's fix this by always calling qcom_smmu_impl_init(). It does not
> > touch the smmu passed unless the device is a non-Qualcomm one. Make
> > ARM_SMMU select QCOM_SCM for ARCH_QCOM.

Sorry about this bug. I was sure I had it working, but I lost part of the commit
during a rebase, and my randconfig builds still succeeded without it, so I
sent a wrong version.

> Arnd's intention was to not force QCOM_SCM to be built on non-Qualcomm
> devices. But as Daniel experienced, attempting to boot most Qualcomm
> boards without this results in a instant reboot.
>
> I think it's okay if we tinker with CONFIG_ARM_SMMU_QCOM for v5.16, but
> we're getting late in v5.15 so I would prefer if we make sure this works
> out of the box.

Yes, makes sense. For reference, see below for how I would fix this properly,
this is what I had intended to have in the patch. Feel free to pick
either version
as the immediate bugfix. I'll give the below a little more randconfig testing
overnight though. The pasted version of the patch is probably
whitespace-damaged,
let me know if you would like me to send it as a proper patch.

   Arnd

8<-
Subject: iommu: fix ARM_SMMU_QCOM compilation

My previous bugfix ended up making things worse for the QCOM IOMMU
driver when it forgot to add the Kconfig symbol that is getting used to
control the compilation of the SMMU implementation specific code
for Qualcomm.

Fixes: 424953cf3c66 ("qcom_scm: hide Kconfig symbol")
Reported-by: Daniel Lezcano 
Reported-by: Dmitry Baryshkov 
Signed-off-by: Arnd Bergmann 

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index c5c71b7ab7e8..2dfe744ddd97 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -311,6 +311,7 @@ config ARM_SMMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
+   select QCOM_SCM if ARM_SMMU_QCOM
help
  Support for implementations of the ARM System MMU architecture
  versions 1 and 2.
@@ -355,6 +356,13 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
  'arm-smmu.disable_bypass' will continue to override this
  config.

+config ARM_SMMU_QCOM
+   def_bool y
+   depends on ARM_SMMU && ARCH_QCOM
+   help
+ When running on a Qualcomm platform that has the custom variant
+ of the ARM SMMU, this needs to be built into the SMMU driver.
+
 config ARM_SMMU_V3
tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
depends on ARM64
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH v2 2/2] qcom_scm: hide Kconfig symbol

2021-10-07 Thread Arnd Bergmann
From: Arnd Bergmann 

Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:

aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'

ld.lld: error: undefined symbol: qcom_scm_is_available
>>> referenced by adreno_gpu.c
>>>   gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in 
>>> archive drivers/built-in.a

This can happen when CONFIG_ARCH_QCOM is disabled and we don't select
QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd
use a similar dependency here to what we have for QCOM_RPROC_COMMON,
but that causes dependency loops from other things selecting QCOM_SCM.

This appears to be an endless problem, so try something different this
time:

 - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on'
   but that is simply selected by all of its users

 - All the stubs in include/linux/qcom_scm.h can go away

 - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to
   allow compile-testing QCOM_SCM on all architectures.

 - To avoid a circular dependency chain involving RESET_CONTROLLER
   and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement.
   According to my testing this still builds fine, and the QCOM
   platform selects this symbol already.

Acked-by: Kalle Valo 
Acked-by: Alex Elder 
Signed-off-by: Arnd Bergmann 
---
Changes in v2:
- fix the iommu dependencies

I've queued this version as a bugfix along with patch 1/2
in my asm-generic tree.

 drivers/firmware/Kconfig   |  5 +-
 drivers/gpu/drm/msm/Kconfig|  4 +-
 drivers/iommu/Kconfig  |  3 +-
 drivers/iommu/arm/arm-smmu/Makefile|  3 +-
 drivers/iommu/arm/arm-smmu/arm-smmu-impl.c |  3 +-
 drivers/media/platform/Kconfig |  2 +-
 drivers/mmc/host/Kconfig   |  2 +-
 drivers/net/ipa/Kconfig|  1 +
 drivers/net/wireless/ath/ath10k/Kconfig|  2 +-
 drivers/pinctrl/qcom/Kconfig   |  3 +-
 include/linux/arm-smccc.h  | 10 +++
 include/linux/qcom_scm.h   | 71 --
 12 files changed, 24 insertions(+), 85 deletions(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 220a58cf0a44..cda7d7162cbb 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -203,10 +203,7 @@ config INTEL_STRATIX10_RSU
  Say Y here if you want Intel RSU support.
 
 config QCOM_SCM
-   tristate "Qcom SCM driver"
-   depends on ARM || ARM64
-   depends on HAVE_ARM_SMCCC
-   select RESET_CONTROLLER
+   tristate
 
 config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
bool "Qualcomm download mode enabled by default"
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index e9c6af78b1d7..3ddf739a6f9b 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -17,7 +17,7 @@ config DRM_MSM
select DRM_SCHED
select SHMEM
select TMPFS
-   select QCOM_SCM if ARCH_QCOM
+   select QCOM_SCM
select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
@@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO
 
 config DRM_MSM_HDMI_HDCP
bool "Enable HDMI HDCP support in MSM DRM driver"
-   depends on DRM_MSM && QCOM_SCM
+   depends on DRM_MSM
default y
help
  Choose this option to enable HDCP state machine
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 124c41adeca1..c5c71b7ab7e8 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -308,7 +308,6 @@ config APPLE_DART
 config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -438,7 +437,7 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on QCOM_SCM=y
+   select QCOM_SCM
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU
diff --git a/drivers/iommu/arm/arm-smmu/Makefile 
b/drivers/iommu/arm/arm-smmu/Makefile
index e240a7bcf310..b0cc01aa20c9 100644
--- a/drivers/iommu/arm/arm-smmu/Makefile
+++ b/drivers/iommu/arm/arm-smmu/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
 obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o 

[PATCH v2 1/2] firmware: include drivers/firmware/Kconfig unconditionally

2021-10-07 Thread Arnd Bergmann
From: Arnd Bergmann 

Compile-testing drivers that require access to a firmware layer
fails when that firmware symbol is unavailable. This happened
twice this week:

 - My proposed to change to rework the QCOM_SCM firmware symbol
   broke on ppc64 and others.

 - The cs_dsp firmware patch added device specific firmware loader
   into drivers/firmware, which broke on the same set of
   architectures.

We should probably do the same thing for other subsystems as well,
but fix this one first as this is a dependency for other patches
getting merged.

Reviewed-by: Bjorn Andersson 
Reviewed-by: Charles Keepax 
Acked-by: Will Deacon 
Acked-by: Bjorn Andersson 
Cc: Mark Brown 
Cc: Liam Girdwood 
Cc: Charles Keepax 
Cc: Simon Trimmer 
Cc: Michael Ellerman 
Reviewed-by: Mark Brown 
Signed-off-by: Arnd Bergmann 
---
No changes in v2, but it's now queued in my asm-generic
tree for v5.15

 arch/arm/Kconfig| 2 --
 arch/arm64/Kconfig  | 2 --
 arch/ia64/Kconfig   | 2 --
 arch/mips/Kconfig   | 2 --
 arch/parisc/Kconfig | 2 --
 arch/riscv/Kconfig  | 2 --
 arch/x86/Kconfig| 2 --
 drivers/Kconfig | 2 ++
 8 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index fc196421b2ce..59baf6c132a7 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1989,8 +1989,6 @@ config ARCH_HIBERNATION_POSSIBLE
 
 endmenu
 
-source "drivers/firmware/Kconfig"
-
 if CRYPTO
 source "arch/arm/crypto/Kconfig"
 endif
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 077f2ec4eeb2..407b4addea36 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1931,8 +1931,6 @@ source "drivers/cpufreq/Kconfig"
 
 endmenu
 
-source "drivers/firmware/Kconfig"
-
 source "drivers/acpi/Kconfig"
 
 source "arch/arm64/kvm/Kconfig"
diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 045792cde481..1e33666fa679 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -388,8 +388,6 @@ config CRASH_DUMP
  help
Generate crash dump after being started by kexec.
 
-source "drivers/firmware/Kconfig"
-
 endmenu
 
 menu "Power management and ACPI options"
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 771ca53af06d..6b8f591c5054 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -3316,8 +3316,6 @@ source "drivers/cpuidle/Kconfig"
 
 endmenu
 
-source "drivers/firmware/Kconfig"
-
 source "arch/mips/kvm/Kconfig"
 
 source "arch/mips/vdso/Kconfig"
diff --git a/arch/parisc/Kconfig b/arch/parisc/Kconfig
index 4742b6f169b7..27a8b49af11f 100644
--- a/arch/parisc/Kconfig
+++ b/arch/parisc/Kconfig
@@ -384,6 +384,4 @@ config KEXEC_FILE
 
 endmenu
 
-source "drivers/firmware/Kconfig"
-
 source "drivers/parisc/Kconfig"
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c3f3fd583e04..8bc71ab143e3 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -561,5 +561,3 @@ menu "Power management options"
 source "kernel/power/Kconfig"
 
 endmenu
-
-source "drivers/firmware/Kconfig"
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4e001425..4dca39744ee9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2828,8 +2828,6 @@ config HAVE_ATOMIC_IOMAP
def_bool y
depends on X86_32
 
-source "drivers/firmware/Kconfig"
-
 source "arch/x86/kvm/Kconfig"
 
 source "arch/x86/Kconfig.assembler"
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 30d2db37cc87..0d399ddaa185 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -17,6 +17,8 @@ source "drivers/bus/Kconfig"
 
 source "drivers/connector/Kconfig"
 
+source "drivers/firmware/Kconfig"
+
 source "drivers/gnss/Kconfig"
 
 source "drivers/mtd/Kconfig"
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 4:46 PM Bjorn Andersson
 wrote:
>
> On Wed 29 Sep 05:04 CDT 2021, Arnd Bergmann wrote:
>
> > On Wed, Sep 29, 2021 at 11:51 AM Will Deacon  wrote:
> > > On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote:
> > > >
> > > > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > > > index 124c41adeca1..989c83acbfee 100644
> > > > --- a/drivers/iommu/Kconfig
> > > > +++ b/drivers/iommu/Kconfig
> > > > @@ -308,7 +308,7 @@ config APPLE_DART
> > > >  config ARM_SMMU
> > > >   tristate "ARM Ltd. System MMU (SMMU) Support"
> > > >   depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
> > > > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
> > > > + select QCOM_SCM
> > > >   select IOMMU_API
> > > >   select IOMMU_IO_PGTABLE_LPAE
> > > >   select ARM_DMA_USE_IOMMU if ARM
> > >
> > > I don't want to get in the way of this patch because I'm also tired of the
> > > randconfig failures caused by QCOM_SCM. However, ARM_SMMU is applicable to
> > > a wide variety of (non-qcom) SoCs and so it seems a shame to require the
> > > QCOM_SCM code to be included for all of those when it's not strictly 
> > > needed
> > > at all.
> >
> > Good point, I agree that needs to be fixed. I think this additional
> > change should do the trick:
> >
>
> ARM_SMMU and QCOM_IOMMU are two separate implementations and both uses
> QCOM_SCM. So both of them should select QCOM_SCM.

Right, I figured that out later as well.

> "Unfortunately" the Qualcomm portion of ARM_SMMU is builtin
> unconditionally, so going with something like select QCOM_SCM if
> ARCH_QCOM would still require the stubs in qcom_scm.h.

Yes, sounds good. I also noticed that I still need one hack in there
if I do this:

diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 55690af1b25d..36c304a8fc9b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -427,6 +427,9 @@ struct arm_smmu_device *qcom_smmu_impl_init(struct
arm_smmu_device *smmu)
 {
const struct device_node *np = smmu->dev->of_node;

+   if (!IS_ENABLED(CONFIG_QCOM_SCM))
+   return ERR_PTR(-ENXIO);
+
 #ifdef CONFIG_ACPI
if (np == NULL) {
/* Match platform for ACPI boot */


Otherwise it still breaks with ARM_SMMU=y and QCOM_SCM=m.

Splitting out the qualcomm portion of the arm_smmu driver using
a separate 'bool' symbol should also work, if  you prefer that
and can suggest a name and help text for that symbol. It would
look like

diff --git a/drivers/iommu/arm/arm-smmu/Makefile
b/drivers/iommu/arm/arm-smmu/Makefile
index e240a7bcf310..b0cc01aa20c9 100644
--- a/drivers/iommu/arm/arm-smmu/Makefile
+++ b/drivers/iommu/arm/arm-smmu/Makefile
@@ -1,4 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_QCOM_IOMMU) += qcom_iommu.o
 obj-$(CONFIG_ARM_SMMU) += arm_smmu.o
-arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o arm-smmu-qcom.o
+arm_smmu-objs += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o
+arm_smmu-$(CONFIG_ARM_SMMU_QCOM) += arm-smmu-qcom.o
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
index 9f465e146799..2c25cce38060 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-impl.c
@@ -215,7 +215,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct
arm_smmu_device *smmu)
of_device_is_compatible(np, "nvidia,tegra186-smmu"))
return nvidia_smmu_impl_init(smmu);

-   smmu = qcom_smmu_impl_init(smmu);
+   if (IS_ENABLED(CONFIG_ARM_SMMU_QCOM))
+   smmu = qcom_smmu_impl_init(smmu);

if (of_device_is_compatible(np, "marvell,ap806-smmu-500"))
smmu->impl = _mmu500_impl;



   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-29 Thread Arnd Bergmann
On Wed, Sep 29, 2021 at 11:51 AM Will Deacon  wrote:
> On Mon, Sep 27, 2021 at 05:22:13PM +0200, Arnd Bergmann wrote:
> >
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 124c41adeca1..989c83acbfee 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -308,7 +308,7 @@ config APPLE_DART
> >  config ARM_SMMU
> >   tristate "ARM Ltd. System MMU (SMMU) Support"
> >   depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
> > - depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
> > + select QCOM_SCM
> >   select IOMMU_API
> >   select IOMMU_IO_PGTABLE_LPAE
> >   select ARM_DMA_USE_IOMMU if ARM
>
> I don't want to get in the way of this patch because I'm also tired of the
> randconfig failures caused by QCOM_SCM. However, ARM_SMMU is applicable to
> a wide variety of (non-qcom) SoCs and so it seems a shame to require the
> QCOM_SCM code to be included for all of those when it's not strictly needed
> at all.

Good point, I agree that needs to be fixed. I think this additional
change should do the trick:

--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -308,7 +308,6 @@ config APPLE_DART
 config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   select QCOM_SCM
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
@@ -438,7 +437,7 @@ config QCOM_IOMMU
# Note: iommu drivers cannot (yet?) be built as modules
bool "Qualcomm IOMMU Support"
depends on ARCH_QCOM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on QCOM_SCM=y
+   select QCOM_SCM
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU

I'll see if that causes any problems for the randconfig builds.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH 2/2] [v2] qcom_scm: hide Kconfig symbol

2021-09-28 Thread Arnd Bergmann
From: Arnd Bergmann 

Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:

aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'

ld.lld: error: undefined symbol: qcom_scm_is_available
>>> referenced by adreno_gpu.c
>>>   gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in 
>>> archive drivers/built-in.a

This can happen when CONFIG_ARCH_QCOM is disabled and we don't select
QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd
use a similar dependency here to what we have for QCOM_RPROC_COMMON,
but that causes dependency loops from other things selecting QCOM_SCM.

This appears to be an endless problem, so try something different this
time:

 - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on'
   but that is simply selected by all of its users

 - All the stubs in include/linux/qcom_scm.h can go away

 - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to
   allow compile-testing QCOM_SCM on all architectures.

 - To avoid a circular dependency chain involving RESET_CONTROLLER
   and PINCTRL_SUNXI, drop the 'select RESET_CONTROLLER' statement.
   According to my testing this still builds fine, and the QCOM
   platform selects this symbol already.

Acked-by: Kalle Valo 
Signed-off-by: Arnd Bergmann 
---
Changes in v2:
  - drop the 'select RESET_CONTROLLER' line, rather than adding
more of the same
---
 drivers/firmware/Kconfig|  5 +-
 drivers/gpu/drm/msm/Kconfig |  4 +-
 drivers/iommu/Kconfig   |  2 +-
 drivers/media/platform/Kconfig  |  2 +-
 drivers/mmc/host/Kconfig|  2 +-
 drivers/net/ipa/Kconfig |  1 +
 drivers/net/wireless/ath/ath10k/Kconfig |  2 +-
 drivers/pinctrl/qcom/Kconfig|  3 +-
 include/linux/arm-smccc.h   | 10 
 include/linux/qcom_scm.h| 71 -
 10 files changed, 20 insertions(+), 82 deletions(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 220a58cf0a44..cda7d7162cbb 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -203,10 +203,7 @@ config INTEL_STRATIX10_RSU
  Say Y here if you want Intel RSU support.
 
 config QCOM_SCM
-   tristate "Qcom SCM driver"
-   depends on ARM || ARM64
-   depends on HAVE_ARM_SMCCC
-   select RESET_CONTROLLER
+   tristate
 
 config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
bool "Qualcomm download mode enabled by default"
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index e9c6af78b1d7..3ddf739a6f9b 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -17,7 +17,7 @@ config DRM_MSM
select DRM_SCHED
select SHMEM
select TMPFS
-   select QCOM_SCM if ARCH_QCOM
+   select QCOM_SCM
select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
@@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO
 
 config DRM_MSM_HDMI_HDCP
bool "Enable HDMI HDCP support in MSM DRM driver"
-   depends on DRM_MSM && QCOM_SCM
+   depends on DRM_MSM
default y
help
  Choose this option to enable HDCP state machine
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 124c41adeca1..989c83acbfee 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -308,7 +308,7 @@ config APPLE_DART
 config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
+   select QCOM_SCM
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 157c924686e4..80321e03809a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -565,7 +565,7 @@ config VIDEO_QCOM_VENUS
depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
select QCOM_MDT_LOADER if ARCH_QCOM
-   select QCOM_SCM if ARCH_QCOM
+   select QCOM_SCM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 71313961cc54..95b3511b0560 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -547,7 +547,7 @@ config MMC_SDHCI_MSM
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
select MMC_CQHCI
-   select QCOM_SCM if MMC_CRYPTO && ARCH_QCOM
+   select QCOM_SCM if MMC_CRYPTO
help
   

Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-28 Thread Arnd Bergmann
On Tue, Sep 28, 2021 at 9:05 AM Kalle Valo  wrote:
> Arnd Bergmann  writes:
> > From: Arnd Bergmann 
> I assume I can continue to build test ATH10K_SNOC with x86 as before?
> That's important for me. If yes, then:
>
> Acked-by: Kalle Valo 
>
> --
> https://patchwork.kernel.org/project/linux-wireless/list/
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Yes, the difference is that this will then also build the qcom_scm module, but
that should not cause any problems after the other changes in this patch.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
On Mon, Sep 27, 2021 at 10:42 PM Bjorn Andersson
 wrote:
> On Mon 27 Sep 13:15 PDT 2021, Arnd Bergmann wrote:
> > On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson 
> >  wrote:
> >
> > An easier option might be to find a way to build QCOM_SCM without
> > RESET_CONTROLLER for compile testing purposes. I don't know
> > what would break from that.
> >
>
> Afaict the reset API is properly stubbed and RESET_CONTROLLER is a bool,
> so I think we can simply drop the "select" and the kernel will still
> compile fine in all combinations.
>
> When it comes to runtime, we currently select RESET_CONTROLLER from the
> Qualcomm common clocks. If that is dropped (why would it...) it seems
> possible to build a custom kernel for msm8916 that we can boot and miss
> the stubbed out "mss restart" reset line from the SCM.
>
>
> So, let's just drop the select RESET_CONTROLLER from SCM for now.

Ok, I've made that change locally, giving it more time on the randconfig
build box now.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
On Mon, Sep 27, 2021 at 9:52 PM Bjorn Andersson
 wrote:
> On Mon 27 Sep 08:22 PDT 2021, Arnd Bergmann wrote:
> > From: Arnd Bergmann 
> >
> >  - To avoid a circular dependency chain involving RESET_CONTROLLER
> >and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in
> >the latter one to 'select'.
>
> Can you please help me understand why this is part of the same patch?

This can be done as a preparatory patch if we decide to do it this way,
for the review it seemed better to spell out that this is required.

I still hope that we can avoid adding another 'select RESET_CONTROLLER'
if someone can figure out what to do instead.

The problem here is that QCOM_SCM selects RESET_CONTROLLER,
and turning that into 'depends on' would in turn mean that any driver that
wants to select QCOM_SCM would have to have the same RESET_CONTROLLER
dependency.

An easier option might be to find a way to build QCOM_SCM without
RESET_CONTROLLER for compile testing purposes. I don't know
what would break from that.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] [RFC] qcom_scm: hide Kconfig symbol

2021-09-27 Thread Arnd Bergmann
From: Arnd Bergmann 

Now that SCM can be a loadable module, we have to add another
dependency to avoid link failures when ipa or adreno-gpu are
built-in:

aarch64-linux-ld: drivers/net/ipa/ipa_main.o: in function `ipa_probe':
ipa_main.c:(.text+0xfc4): undefined reference to `qcom_scm_is_available'

ld.lld: error: undefined symbol: qcom_scm_is_available
>>> referenced by adreno_gpu.c
>>>   gpu/drm/msm/adreno/adreno_gpu.o:(adreno_zap_shader_load) in 
>>> archive drivers/built-in.a

This can happen when CONFIG_ARCH_QCOM is disabled and we don't select
QCOM_MDT_LOADER, but some other module selects QCOM_SCM. Ideally we'd
use a similar dependency here to what we have for QCOM_RPROC_COMMON,
but that causes dependency loops from other things selecting QCOM_SCM.

This appears to be an endless problem, so try something different this
time:

 - CONFIG_QCOM_SCM becomes a hidden symbol that nothing 'depends on'
   but that is simply selected by all of its users

 - All the stubs in include/linux/qcom_scm.h can go away

 - arm-smccc.h needs to provide a stub for __arm_smccc_smc() to
   allow compile-testing QCOM_SCM on all architectures.

 - To avoid a circular dependency chain involving RESET_CONTROLLER
   and PINCTRL_SUNXI, change the 'depends on RESET_CONTROLLER' in
   the latter one to 'select'.

The last bit is rather annoying, as drivers should generally never
'select' another subsystem, and about half the users of the reset
controller interface do this anyway.

Nevertheless, this version seems to pass all my randconfig tests
and is more robust than any of the prior versions.

Comments?

Signed-off-by: Arnd Bergmann 
---
 drivers/firmware/Kconfig|  4 +-
 drivers/gpu/drm/msm/Kconfig |  4 +-
 drivers/iommu/Kconfig   |  2 +-
 drivers/media/platform/Kconfig  |  2 +-
 drivers/mmc/host/Kconfig|  2 +-
 drivers/net/ipa/Kconfig |  1 +
 drivers/net/wireless/ath/ath10k/Kconfig |  2 +-
 drivers/pinctrl/qcom/Kconfig|  3 +-
 drivers/pinctrl/sunxi/Kconfig   |  6 +--
 include/linux/arm-smccc.h   | 10 
 include/linux/qcom_scm.h| 71 -
 11 files changed, 23 insertions(+), 84 deletions(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 220a58cf0a44..f7dd82ef0b9c 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -203,9 +203,7 @@ config INTEL_STRATIX10_RSU
  Say Y here if you want Intel RSU support.
 
 config QCOM_SCM
-   tristate "Qcom SCM driver"
-   depends on ARM || ARM64
-   depends on HAVE_ARM_SMCCC
+   tristate
select RESET_CONTROLLER
 
 config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
diff --git a/drivers/gpu/drm/msm/Kconfig b/drivers/gpu/drm/msm/Kconfig
index e9c6af78b1d7..3ddf739a6f9b 100644
--- a/drivers/gpu/drm/msm/Kconfig
+++ b/drivers/gpu/drm/msm/Kconfig
@@ -17,7 +17,7 @@ config DRM_MSM
select DRM_SCHED
select SHMEM
select TMPFS
-   select QCOM_SCM if ARCH_QCOM
+   select QCOM_SCM
select WANT_DEV_COREDUMP
select SND_SOC_HDMI_CODEC if SND_SOC
select SYNC_FILE
@@ -55,7 +55,7 @@ config DRM_MSM_GPU_SUDO
 
 config DRM_MSM_HDMI_HDCP
bool "Enable HDMI HDCP support in MSM DRM driver"
-   depends on DRM_MSM && QCOM_SCM
+   depends on DRM_MSM
default y
help
  Choose this option to enable HDCP state machine
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 124c41adeca1..989c83acbfee 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -308,7 +308,7 @@ config APPLE_DART
 config ARM_SMMU
tristate "ARM Ltd. System MMU (SMMU) Support"
depends on ARM64 || ARM || (COMPILE_TEST && !GENERIC_ATOMIC64)
-   depends on QCOM_SCM || !QCOM_SCM #if QCOM_SCM=m this can't be =y
+   select QCOM_SCM
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select ARM_DMA_USE_IOMMU if ARM
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index 157c924686e4..80321e03809a 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -565,7 +565,7 @@ config VIDEO_QCOM_VENUS
depends on VIDEO_DEV && VIDEO_V4L2 && QCOM_SMEM
depends on (ARCH_QCOM && IOMMU_DMA) || COMPILE_TEST
select QCOM_MDT_LOADER if ARCH_QCOM
-   select QCOM_SCM if ARCH_QCOM
+   select QCOM_SCM
select VIDEOBUF2_DMA_CONTIG
select V4L2_MEM2MEM_DEV
help
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 71313961cc54..95b3511b0560 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -547,7 +547,7 @@ config MMC_SDHCI_MSM
depends on MMC_SDHCI_PLTFM
select MMC_SDHCI_IO_ACCESSORS
select MMC_CQHCI
-   select QCOM_SCM if MMC_CRYPTO &&am

[PATCH] iommu/mediatek: fix out-of-range warning with clang

2021-09-27 Thread Arnd Bergmann
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 always 
false [-Werror,-Wtautological-constant-out-of-range-compare]
if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
 ~~ ^  ~

Add an explicit check for the type of the variable to skip the check
and the warning in that case.

Fixes: b4dad40e4f35 ("iommu/mediatek: Adjust the PA for the 4GB Mode")
Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/mtk_iommu.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index d837adfd1da5..25b834104790 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -550,7 +550,9 @@ static phys_addr_t mtk_iommu_iova_to_phys(struct 
iommu_domain *domain,
phys_addr_t pa;
 
pa = dom->iop->iova_to_phys(dom->iop, iova);
-   if (dom->data->enable_4GB && pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
+   if (IS_ENABLED(CONFIG_PHYS_ADDR_T_64BIT) &&
+   dom->data->enable_4GB &&
+   pa >= MTK_IOMMU_4GB_MODE_REMAP_BASE)
pa &= ~BIT_ULL(32);
 
return pa;
-- 
2.29.2

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v4 0/3] Apple M1 DART IOMMU driver

2021-07-14 Thread Arnd Bergmann
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.
>
> BTW this isn't something we can fully support in general. IOMMU API
> users may expect this to work:
>
> iommu_map(domain, iova, page_to_phys(p1), PAGE_SIZE, prot);
> iommu_map(domain, iova + PAGE_SIZE, page_to_phys(p2), PAGE_SIZE, prot);
>
> Although they do in principle have visibility of pgsize_bitmap, I still
> doubt anyone is really prepared for CPU-page-aligned mappings to fail.
> Even at the DMA API level you could hide *some* of it (at the cost of
> effectively only having 1/4 of the usable address space), but there are
> still cases like where v4l2 has a hard requirement that a page-aligned
> scatterlist can be mapped into a contiguous region of DMA addresses.

I think that was the same conclusion we had earlier: the dma-mapping
interfaces should be possible for large iotlb pages, but any driver directly
using the IOMMU API, such as VFIO, would not work.

The question is how we can best allow one but not the other.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-20 Thread Arnd Bergmann
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).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-20 Thread Arnd Bergmann
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).
> >
> > For loadable modules, this is up to user space in the end.
> >
> > Which of the drivers in this scenario are loadable modules?
>
> All the drivers involved in my case are built-in (nvmem, soc and final
> soc_device_match consumer e.g. caam_jr that crashes the kernel if soc is
> not identified properly).

Ok, in that case you may have a chance to just adapt the initcall
levels. This is somewhat fragile if someone else already relies
on a particular order, but it's an easy one-line change to change
a driver e.g. from module_init() or device_initcall() to arch_initcall().

> I frankly don't like the idea of moving nvmem/ above soc/ in
> drivers/Makefile as a "solution" to this (especially as there is one
> that seems to care about what soc they run on...), so I'll have a look
> at links first, hopefully that will work out.

Right, that would be way more fragile.

I think the main problem in this case is the caam driver that really
should not look into the particular SoC type or even machine
compatible string. This is something we can do as a last resort
for compatibility with busted devicetree files, but it appears that
this driver does it as the primary method for identifying different
hardware revisions. I would suggest fixing the binding so that
each SoC that includes one of these devices has a soc specific
compatible string associated with the device that the driver can
use as the primary way of identifying the device.

We probably need to keep the old logic around for old dtb files,
but there can at least be a comment next to that table that
discourages people from adding more entries there.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v1 PATCH 3/3] driver: update all the code that use soc_device_match

2021-04-19 Thread Arnd Bergmann
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 should only be enabled on a very specific subset of
> > systems.  IMHO such systems should make sure soc_device_match()
> > is available early, by registering their SoC device early.
>
> I definitely agree there, my suggestion to defer was only because I know
> of no other way to influence the ordering of drivers loading reliably
> and gave up on soc being init'd early.

In some cases, you can use the device_link infrastructure to deal
with dependencies between devices. Not sure if this would help
in your case, but have a look at device_link_add() etc in drivers/base/core.c

> In this particular case the problem is that since 7d981405d0fd ("soc:
> imx8m: change to use platform driver") the soc probe tries to use the
> nvmem driver for ocotp fuses for imx8m devices, which isn't ready yet.
> So soc loading gets pushed back to the end of the list because it gets
> defered and other drivers relying on soc_device_match get confused
> because they wrongly think a device doesn't match a quirk when it
> actually does.
>
> If there is a way to ensure the nvmem driver gets loaded before the soc,
> that would also solve the problem nicely, and avoid the need to mess
> with all the ~50 drivers which use it.
>
> Is there a way to control in what order drivers get loaded? Something in
> the dtb perhaps?

For built-in drivers, load order depends on the initcall level and
link order (how things are lined listed in the Makefile hierarchy).

For loadable modules, this is up to user space in the end.

Which of the drivers in this scenario are loadable modules?

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 1/3] iommu: io-pgtable: add DART pagetable format

2021-04-09 Thread Arnd Bergmann
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 worrying (and again, I don't think this belongs here). How is this
> > thing supposed to work if the CPU is using 4k pages?
>
> This SoC is just full of fun surprises!
> I didn't even think about that case since I've always been using 16k pages so 
> far.
>
> I've checked again and wasn't able to find any way to configure the pagesize
> of the IOMMU. There seem to be variants of this IP in older iPhones which
> support a 4k pagesize but to the best of my knowledge this is hard wired
> and not configurable in software.
>
> When booting with 4k pages I hit the BUG_ON in iova.c that ensures that the
> iommu pagesize has to be <= the cpu page size.
>
> I see two options here and I'm not sure I like either of them:
>
> 1) Just don't support 4k CPU pages together with IOMMU translations and only
>allow full bypass mode there.
>This would however mean that PCIe (i.e. ethernet, usb ports on the Mac
>mini) and possibly Thunderbolt support would not be possible since these
>devices don't seem to like iommu bypass mode at all.

It should be possible to do a fake bypass mode by just programming a
static page table for as much address space as you can, and then
use swiotlb to address any memory beyond that. This won't perform
well because it requires bounce buffers for any high memory, but it
can be a last resort if a dart instance cannot do normal bypass mode.

> 2) I've had a brief discussion on IRC with Arnd about this [1] and he pointed
>out that the dma_map_sg API doesn't make any guarantees about the returned
>iovas and that it might be possible to make this work at least for devices
>that go through the normal DMA API.
>
>I've then replaced the page size check with a WARN_ON in iova.c just to see
>what happens. At least normal devices that go through the DMA API seem to
>work with my configuration. iommu_dma_alloc took the iommu_dma_alloc_remap
>path which was called with the cpu page size but then used
>domain->pgsize_bitmap to increase that to 16k. So this kinda works out, but
>there are other functions in dma-iommu.c that I believe rely on the fact 
> that
>the iommu can map single cpu pages. This feels very fragile right now and
>would probably require some rather invasive changes.

The other second-to-last resort here would be to duplicate the code from
the dma-iommu code and implement the dma-mapping API directly on
top of the dart hardware instead of the iommu layer. This would probably
be much faster than the swiotlb on top of a bypass or a linear map,
but it's a really awful abstraction that would require adding special cases
into a lot of generic code.

>Any driver that tries to use the iommu API directly could be trouble
>as well if they make similar assumptions.

I think pretty much all drivers using the iommu API directly already
depends on having a matching page size.  I don't see any way to use
e.g. PCI device assignment using vfio, or a GPU driver with per-process
contexts when the iotlb page size is larger than the CPU's.

>Is this something you would even want to support in the iommu subsytem
>and is it even possible to do this in a sane way?

I don't know how hard it is to do adjust the dma-iommu implementation
to allow this, but as long as we can work out the DT binding to support
both normal dma-iommu mode with 16KB pages and some kind of
passthrough mode (emulated or not) with 4KB pages, it can be left
as a possible optimization for later.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v3] drivers: introduce and use WANT_DMA_CMA for soft dependencies on DMA_CMA

2021-04-09 Thread Arnd Bergmann
On Fri, Apr 9, 2021 at 1:21 PM David Hildenbrand  wrote:
>
> Random drivers should not override a user configuration of core knobs
> (e.g., CONFIG_DMA_CMA=n). Applicable drivers would like to use DMA_CMA,
> which depends on CMA, if possible; however, these drivers also have to
> tolerate if DMA_CMA is not available/functioning, for example, if no CMA
> area for DMA_CMA use has been setup via "cma=X". In the worst case, the
> driver cannot do it's job properly in some configurations.
>
> For example, commit 63f5677544b3 ("drm/etnaviv: select CMA and DMA_CMA if
> available") documents
> While this is no build dependency, etnaviv will only work correctly
> on most systems if CMA and DMA_CMA are enabled. Select both options
> if available to avoid users ending up with a non-working GPU due to
> a lacking kernel config.
> So etnaviv really wants to have DMA_CMA, however, can deal with some cases
> where it is not available.
>
> Let's introduce WANT_DMA_CMA and use it in most cases where drivers
> select CMA/DMA_CMA, or depend on DMA_CMA (in a wrong way via CMA because
> of recursive dependency issues).
>
> We'll assume that any driver that selects DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER would like to use DMA_CMA if possible.
>
> With this change, distributions can disable CONFIG_CMA or
> CONFIG_DMA_CMA, without it silently getting enabled again by random
> drivers. Also, we'll now automatically try to enabled both, CONFIG_CMA
> and CONFIG_DMA_CMA if they are unspecified and any driver is around that
> selects WANT_DMA_CMA -- also implicitly via DRM_GEM_CMA_HELPER or
> DRM_KMS_CMA_HELPER.
>
> For example, if any driver selects WANT_DMA_CMA and we do a
> "make olddefconfig":
>
> 1. With "# CONFIG_CMA is not set" and no specification of
>"CONFIG_DMA_CMA"
>
> -> CONFIG_DMA_CMA won't be part of .config
>
> 2. With no specification of CONFIG_CMA or CONFIG_DMA_CMA
>
> Contiguous Memory Allocator (CMA) [Y/n/?] (NEW)
> DMA Contiguous Memory Allocator (DMA_CMA) [Y/n/?] (NEW)
>
> 3. With "# CONFIG_CMA is not set" and "# CONFIG_DMA_CMA is not set"
>
> -> CONFIG_DMA_CMA will be removed from .config
>
> 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 it to a soft dependency.

I don't think this dependency is fundamentally different from the others,
though davinci machines tend to have less memory than a lot of the
other machines, so it's more likely to fail without CMA.

Regardless of this,

Reviewed-by: Arnd Bergmann 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 2/3] dt-bindings: iommu: add DART iommu bindings

2021-03-28 Thread Arnd Bergmann
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 iommu should be iommu@82f0, not dart2a@82f0.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
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" property.  But it is unclear to
> me how the different puzzle pieces fit together for Thunderbolt.

As a general observation, bypass mode for Thunderbolt is what enabled
the http://thunderclap.io/ attack. This is extremely useful for debugging
a running kernel from another machine, but it's also something that
should never be done in a production kernel.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
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 information
> > > is needed by the DART driver, and there is no direct cnnection from
> > > the DART to the individual devices in the devicetree.  The "iommus"
> > > property makes a connection in the opposite direction.
> >
> > What still seems unclear is whether these addressing limitations are a
> > property of the DART input interface, the device output interface, or
> > the interconnect between them. Although the observable end result
> > appears more or less the same either way, they are conceptually
> > different things which we have different abstractions to deal with.
>
> I'm not really sure if there is any way for us to figure out where these
> limitation comes from though.

My first guess was that this is done to partition the available address
address space in a way that allows one physical IOTLB to handle
multiple devices that each have their own page table for a subset
of the address space, as was done on old PowerPC IOMMUs.
However, the ranges you list don't really support that model.

> I've done some more experiments and looked at all DART nodes in Apple's Device
> Tree though. It seems that most (if not all) masters only connect 32 address
> lines even though the iommu can handle a much larger address space. I'll 
> therefore
> remove the code to handle the full space for v2 since it's essentially dead
> code that can't be tested anyway.
>
>
> There are some exceptions though:
>
> There are the PCIe DARTs which have a different limitation which could be
> encoded as 'dma-ranges' in the pci bus node:
>
>name base  size
>  dart-apcie1: 0010  3fe0
>  dart-apcie2: 0010  3fe0
>  dart-apcie0: 0010  3fe0
> dart-apciec0: 4000  7fffc000
> dart-apciec1: 8000  7fffc000

This looks like they are reserving some address space in the beginning
and/or the end, and for apciec0, the address space is partitioned into
two equal-sized regions.

> Then there are also these display controller DARTs. If we wanted to use 
> dma-ranges
> we could just put them in a single sub bus:
>
>   name base  size
>   dart-disp0:  fc00
> dart-dcp:  fc00
>dart-dispext0:  fc00
>  dart-dcpext:  fc00
>
>
> And finally we have these strange ones which might eventually each require
> another awkward sub-bus if we want to stick to the dma-ranges property.
>
> name base  size
>   dart-aop: 0003  ("always-on processor")
>   dart-pmp:  bff0 (no idea yet)

Here I also see a "pio-vm-size" property:

dart-pmp {
  pio-vm-base = <0xc000>;
  pio-vm-size = <0x4000>;
  vm-size = <0xbff0>;
  ...
   };

Which seems to give 3GB of address space to the normal iotlb,
plus the last 1GB to something else. The vm-base property is also
missing rather than zero, but that could just be part of their syntax
instead of a real difference.

Could it be that there are

>   dart-sio: 0021c000 fbde4000 (at least their Secure Enclave/TPM co-processor)

Same here:
dart-sio {
   vm-base = <0x0>;
   vm-size = <0xfc00>;
   pio-vm-base = <0xfd00>;
  pio-vm-size = <0x200>;
  pio-granularity = <0x100>;
   }

There are clearly two distinct ranges that split up the 4GB space again,
with a small hole of 16MB (==pio-granularity) at the end of each range.

The "pio" name might indicate that this is a range of addresses that
can be programmed to point at I/O registers in another device, rather
than pointing to RAM.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
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 that would mean that if the
> > DART driver needs to look at that property to figure out the address
> > range that supports translation it will need to be able to distinguish
> > between the translatable address range and the bypass address range.
>
> Do we understand if and why we even need to bypass certain streams?

My guess is that this is a performance optimization.

There are generally three reasons to want an iommu in the first place:
 - Pass a device down to a guest or user process without giving
   access to all of memory
 - Avoid problems with limitations in the device, typically when it
only supports
   32-bit bus addressing, but the installed memory is larger than 4GB
 - Protect kernel memory from broken drivers

If you care about none of the above, but you do care about data transfer
speed, you are better off just leaving the IOMMU in bypass mode.
I don't think we have to support it if the IOMMU works reliably, but it's
something that users might want.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-26 Thread Arnd Bergmann
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:
> > >
> > > 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 these via the iommu to any physical
> > > address" using 'dma-ranges'.
> >
> > It sounds like this is a holdover from the original powerpc iommu,
> > which also had a limited set of virtual addresses in the iommu.
> >
> > I would think it's sufficient to describe it in the iommu itself,
> > since the limitation is more "addresses coming into the iommu must
> > be this range" than "this device must use that address range for
> > talking to the iommu".
> >
> > If the addresses are allocated by the iommu driver, and each iommu
> > only has one DMA master attached to it, having a simple range
> > property in the iommu node should do the trick here. If there might
> > be multiple devices on the same iommu but with different address
> > ranges (which I don't think is the case), then it could be part of
> > the reference to the iommu.
>
> The ADT has properties on the iommu node that describe the adresses it
> accepts for translation ("vm-base" and "vm-size").  So I think we can
> safely assume that the same limits apply to all DMA masters that are
> attached to it.  We don't know if the range limit is baked into the
> silicon or whether it is related to how the firmware sets things up.
> Having the properties on the iommu node makes it easy for m1n1 to
> update the properties with the right values if necessary.

Ok.

> 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 that would mean that if the
> DART driver needs to look at that property to figure out the address
> range that supports translation it will need to be able to distinguish
> between the translatable address range and the bypass address range.

I'm not following here. Do you mean the bus address used for bypass is
different from the upstream address that gets programmed into the iommu
when it is active?

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 0/3] Apple M1 DART IOMMU driver

2021-03-25 Thread Arnd Bergmann
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 these via the iommu to any physical
> address" using 'dma-ranges'.

It sounds like this is a holdover from the original powerpc iommu, which also
had a limited set of virtual addresses in the iommu.

I would think it's sufficient to describe it in the iommu itself,
since the limitation
is more "addresses coming into the iommu must be this range" than "this device
must use that address range for talking to the iommu".

If the addresses are allocated by the iommu driver, and each iommu only has
one DMA master attached to it, having a simple range property in the iommu
node should do the trick here. If there might be multiple devices on the same
iommu but with different address ranges (which I don't think is the case), then
it could be part of the reference to the iommu.

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

2021-03-11 Thread Arnd Bergmann
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 || !IOMMUv2
> dependency on the core amdgpu driver for x86.
>
> That should solve the build problem at hand quite nicely.

Right, that sounds better than the IS_REACHABLE() hack, and would fix
the immediate build regression until the driver is changed to use the proper
IOMMU interfaces.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 1/1] drm/amdkfd: fix build error with AMD_IOMMU_V2=m

2021-03-09 Thread Arnd Bergmann
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:
>
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
> `kfd_iommu_bind_process_to_device':
> kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
> `kfd_iommu_unbind_process':
> kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
> `kfd_iommu_suspend':
> kfd_iommu.c:(.text+0x966): undefined reference to 
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to 
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to 
> `amd_iommu_free_device'
> x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
> `kfd_iommu_resume':
> kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to 
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to 
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to 
> `amd_iommu_bind_pasid'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to 
> `amd_iommu_set_invalidate_ctx_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to 
> `amd_iommu_set_invalid_ppr_cb'
> x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to 
> `amd_iommu_free_device'
>
> Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols
> are reachable by the amdkfd driver. Output a warning if they are not,
> because that may not be what the user was expecting.

This would fix the compile-time failure, but it still fails my CI
because you introduce
a compile-time warning. Can you change it into a runtime warning instead?

Neither type of warning is likely to actually reach the person trying
to debug the
problem, so you still end up with machines that don't do what they should,
but I can live with the runtime warning as long as the build doesn't break.

I think the proper fix would be to not rely on custom hooks into a particular
IOMMU driver, but to instead ensure that the amdgpu driver can do everything
it needs through the regular linux/iommu.h interfaces. I realize this
is more work,
but I wonder if you've tried that, and why it didn't work out.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC PATCH v3 1/2] mempinfd: Add new syscall to provide memory pin

2021-02-07 Thread Arnd Bergmann
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_faccessat2, sys_faccessat2)
>  __SYSCALL(__NR_process_madvise, sys_process_madvise)
>  #define __NR_epoll_pwait2 441
>  __SYSCALL(__NR_epoll_pwait2, compat_sys_epoll_pwait2)
> +#define __NR_mempinfd 442
> +__SYSCALL(__NR_mempinfd, sys_mempinfd)

This adds a compat syscall for 32-bit tasks running on arm64 without adding
the same for the native arch/arm syscall table. Those two need to always
stay synchronized. In fact, new system call should ideally get assigned
on all architectures at the same time, with the same number (or +110
on arch/alpha).

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] [v3] x86: apic: avoid -Wshadow warning in header

2020-10-30 Thread Arnd Bergmann
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 'apic' variable to the more descriptive
'x86_local_apic'. It was originally called 'genapic', but both that
and the current 'apic' seem to be a little overly generic for a global
variable.

Fixes: c48f14966cc4 ("KVM: inline kvm_apic_present() and kvm_lapic_enabled()")
Fixes: c8d46cf06dc2 ("x86: rename 'genapic' to 'apic'")
Signed-off-by: Arnd Bergmann 
---
v3: rename the global from x86_system_apic to x86_local_apic

v2: rename the global instead of the local variable in the header

This is only tested in an allmodconfig build, after fixing up a
few mistakes in the original search It's likely that I
missed a few others, but this version should be sufficient to
decide whether this is a good idea in the first place, as well
as if there are better ideas for the new name.
---
 arch/x86/hyperv/hv_apic.c |  2 ++
 arch/x86/hyperv/hv_spinlock.c |  4 ++--
 arch/x86/include/asm/apic.h   | 18 +-
 arch/x86/kernel/acpi/boot.c   |  2 +-
 arch/x86/kernel/apic/apic.c   | 18 +-
 arch/x86/kernel/apic/apic_flat_64.c   |  8 
 arch/x86/kernel/apic/apic_numachip.c  |  4 ++--
 arch/x86/kernel/apic/bigsmp_32.c  |  2 +-
 arch/x86/kernel/apic/hw_nmi.c |  2 +-
 arch/x86/kernel/apic/io_apic.c| 19 ++-
 arch/x86/kernel/apic/ipi.c| 22 +++---
 arch/x86/kernel/apic/msi.c|  2 +-
 arch/x86/kernel/apic/probe_32.c   | 20 ++--
 arch/x86/kernel/apic/probe_64.c   | 12 ++--
 arch/x86/kernel/apic/vector.c |  8 
 arch/x86/kernel/apic/x2apic_cluster.c |  3 ++-
 arch/x86/kernel/apic/x2apic_phys.c|  2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c|  2 +-
 arch/x86/kernel/cpu/common.c  | 14 --
 arch/x86/kernel/cpu/mce/inject.c  |  4 ++--
 arch/x86/kernel/cpu/topology.c|  8 
 arch/x86/kernel/irq_work.c|  2 +-
 arch/x86/kernel/kvm.c |  6 +++---
 arch/x86/kernel/nmi_selftest.c|  2 +-
 arch/x86/kernel/smpboot.c | 20 +++-
 arch/x86/kernel/vsmp_64.c |  2 +-
 arch/x86/kvm/vmx/vmx.c|  2 +-
 arch/x86/mm/srat.c|  2 +-
 arch/x86/platform/uv/uv_irq.c |  4 ++--
 arch/x86/platform/uv/uv_nmi.c |  2 +-
 arch/x86/xen/apic.c   |  8 
 drivers/iommu/amd/iommu.c | 10 ++
 drivers/iommu/intel/irq_remapping.c   |  4 ++--
 33 files changed, 125 insertions(+), 115 deletions(-)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 284e73661a18..9df6ed521048 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -254,6 +254,8 @@ static void hv_send_ipi_self(int vector)
 
 void __init hv_apic_init(void)
 {
+   struct apic *apic = x86_local_apic;
+
if (ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) {
pr_info("Hyper-V: Using IPI hypercalls\n");
/*
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index f3270c1fc48c..01576e14460e 100644
--- a/arch/x86/hyperv/hv_spinlock.c
+++ b/arch/x86/hyperv/hv_spinlock.c
@@ -20,7 +20,7 @@ static bool __initdata hv_pvspin = true;
 
 static void hv_qlock_kick(int cpu)
 {
-   apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
+   x86_local_apic->send_IPI(cpu, X86_PLATFORM_IPI_VECTOR);
 }
 
 static void hv_qlock_wait(u8 *byte, u8 val)
@@ -64,7 +64,7 @@ PV_CALLEE_SAVE_REGS_THUNK(hv_vcpu_is_preempted);
 
 void __init hv_init_spinlocks(void)
 {
-   if (!hv_pvspin || !apic ||
+   if (!hv_pvspin || !x86_local_apic ||
!(ms_hyperv.hints & HV_X64_CLUSTER_IPI_RECOMMENDED) ||
!(ms_hyperv.features & HV_MSR_GUEST_IDLE_AVAILABLE)) {
pr_info("PV spinlocks disabled\n");
diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 4e3099d9ae62..34294fc8f2da 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -361,7 +361,7 @@ struct apic {
  * always just one such driver in use - the kernel decides via an
  * early probing process which one it picks - and then sticks to it):
  */
-extern struct apic *apic;
+extern struct apic *x86_local_apic;
 
 /*
  * APIC drivers are probed based on how they are listed in the .apicdrivers
@@ -395,37 +395,37 @@ extern int lapic_can_unplug_cpu(void);
 
 static inline u32 apic_read(u32 reg)
 {
-   return apic->read(reg);
+   return x86_local_apic->read(reg);
 }
 
 static inline void apic_write(u32 reg, u32 val)
 {
-   apic->write(reg, val);
+   x86_local_apic->write(reg, va

Re: [PATCH] [v2] x86: apic: avoid -Wshadow warning in header

2020-10-29 Thread Arnd Bergmann
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 that
> > and the current 'apic' seem to be a little overly generic for a global
> > variable.
>
> The 'apic' affects only the current CPU, so one of 'x86_local_apic',
> 'x86_lapic' or 'x86_apic' is probably preferrable.

Ok, I'll change it to x86_local_apic then, unless someone else has
a preference between them.

> I don't have huge objections to renaming 'apic' variables and arguments
> in KVM to 'lapic'.  I do agree with Sean however that it's going to
> break again very soon.

I think ideally there would be no global variable, withall accesses
encapsulated in function calls, possibly using static_call() optimizations
if any of them are performance critical.

It doesn't seem hard to do, but I'd rather leave that change to
an x86 person ;-)

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] [v2] x86: apic: avoid -Wshadow warning in header

2020-10-28 Thread Arnd Bergmann
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 'apic' variable to the more descriptive
'x86_system_apic'. It was originally called 'genapic', but both that
and the current 'apic' seem to be a little overly generic for a global
variable.

Fixes: c48f14966cc4 ("KVM: inline kvm_apic_present() and kvm_lapic_enabled()")
Fixes: c8d46cf06dc2 ("x86: rename 'genapic' to 'apic'")
Signed-off-by: Arnd Bergmann 
---
v2: rename the global instead of the local variable in the header

This is only tested in an allmodconfig build, after fixing up a
few mistakes in the original search It's likely that I
missed a few others, but this version should be sufficient to
decide whether this is a good idea in the first place, as well
as if there are better ideas for the new name.
---
 arch/x86/hyperv/hv_apic.c | 24 
 arch/x86/hyperv/hv_spinlock.c |  4 ++--
 arch/x86/include/asm/apic.h   | 18 +-
 arch/x86/kernel/acpi/boot.c   |  2 +-
 arch/x86/kernel/apic/apic.c   | 18 +-
 arch/x86/kernel/apic/apic_flat_64.c   |  8 
 arch/x86/kernel/apic/apic_numachip.c  |  4 ++--
 arch/x86/kernel/apic/bigsmp_32.c  |  2 +-
 arch/x86/kernel/apic/hw_nmi.c |  2 +-
 arch/x86/kernel/apic/io_apic.c| 19 ++-
 arch/x86/kernel/apic/ipi.c| 22 +++---
 arch/x86/kernel/apic/msi.c|  2 +-
 arch/x86/kernel/apic/probe_32.c   | 20 ++--
 arch/x86/kernel/apic/probe_64.c   | 12 ++--
 arch/x86/kernel/apic/vector.c |  8 
 arch/x86/kernel/apic/x2apic_cluster.c |  3 ++-
 arch/x86/kernel/apic/x2apic_phys.c|  2 +-
 arch/x86/kernel/apic/x2apic_uv_x.c|  2 +-
 arch/x86/kernel/cpu/common.c  | 14 --
 arch/x86/kernel/cpu/mce/inject.c  |  4 ++--
 arch/x86/kernel/cpu/topology.c|  8 
 arch/x86/kernel/irq_work.c|  2 +-
 arch/x86/kernel/kvm.c |  6 +++---
 arch/x86/kernel/nmi_selftest.c|  2 +-
 arch/x86/kernel/smpboot.c | 20 +++-
 arch/x86/kernel/vsmp_64.c |  2 +-
 arch/x86/kvm/vmx/vmx.c|  2 +-
 arch/x86/mm/srat.c|  2 +-
 arch/x86/platform/uv/uv_irq.c |  4 ++--
 arch/x86/platform/uv/uv_nmi.c |  2 +-
 arch/x86/xen/apic.c   |  8 
 drivers/iommu/amd/iommu.c | 10 ++
 drivers/iommu/intel/irq_remapping.c   |  4 ++--
 33 files changed, 135 insertions(+), 127 deletions(-)

diff --git a/arch/x86/hyperv/hv_apic.c b/arch/x86/hyperv/hv_apic.c
index 284e73661a18..33e2dc78ca11 100644
--- a/arch/x86/hyperv/hv_apic.c
+++ b/arch/x86/hyperv/hv_apic.c
@@ -259,14 +259,14 @@ void __init hv_apic_init(void)
/*
 * Set the IPI entry points.
 */
-   orig_apic = *apic;
-
-   apic->send_IPI = hv_send_ipi;
-   apic->send_IPI_mask = hv_send_ipi_mask;
-   apic->send_IPI_mask_allbutself = hv_send_ipi_mask_allbutself;
-   apic->send_IPI_allbutself = hv_send_ipi_allbutself;
-   apic->send_IPI_all = hv_send_ipi_all;
-   apic->send_IPI_self = hv_send_ipi_self;
+   orig_apic = *x86_system_apic;
+
+   x86_system_apic->send_IPI = hv_send_ipi;
+   x86_system_apic->send_IPI_mask = hv_send_ipi_mask;
+   x86_system_apic->send_IPI_mask_allbutself = 
hv_send_ipi_mask_allbutself;
+   x86_system_apic->send_IPI_allbutself = hv_send_ipi_allbutself;
+   x86_system_apic->send_IPI_all = hv_send_ipi_all;
+   x86_system_apic->send_IPI_self = hv_send_ipi_self;
}
 
if (ms_hyperv.hints & HV_X64_APIC_ACCESS_RECOMMENDED) {
@@ -285,10 +285,10 @@ void __init hv_apic_init(void)
 */
apic_set_eoi_write(hv_apic_eoi_write);
if (!x2apic_enabled()) {
-   apic->read  = hv_apic_read;
-   apic->write = hv_apic_write;
-   apic->icr_write = hv_apic_icr_write;
-   apic->icr_read  = hv_apic_icr_read;
+   x86_system_apic->read  = hv_apic_read;
+   x86_system_apic->write = hv_apic_write;
+   x86_system_apic->icr_write = hv_apic_icr_write;
+   x86_system_apic->icr_read  = hv_apic_icr_read;
}
}
 }
diff --git a/arch/x86/hyperv/hv_spinlock.c b/arch/x86/hyperv/hv_spinlock.c
index f3270c1fc48c..03c8ac56b430 100644
--- a/arch/x86/hyperv/hv_spinlock.c
++

Re: arm64: Internal error: Oops: qcom_iommu_tlb_inv_context free_io_pgtable_ops on db410c

2020-07-20 Thread Arnd Bergmann
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: f8456690ba8eb18ea4714e68554e242a04f65cff
>   git describe: v5.8-rc5-48-gf8456690ba8e
>   make_kernelversion: 5.8.0-rc5
>   kernel-config:
> https://builds.tuxbuild.com/2aLnwV7BLStU0t1R1QPwHQ/kernel.config

Thanks for the report. Adding freedreno folks to Cc, as this may have something
to do with that driver.

>
> [5.444121] Unable to handle kernel NULL pointer dereference at
> virtual address 0018
> [5.456615]   ESR = 0x9604
> [5.464471]   SET = 0, FnV = 0
> [5.464487]   EA = 0, S1PTW = 0
> [5.466521] Data abort info:
> [5.469971]   ISV = 0, ISS = 0x0004
> [5.472768]   CM = 0, WnR = 0
> [5.476172] user pgtable: 4k pages, 48-bit VAs, pgdp=bacba000
> [5.479349] [0018] pgd=, p4d=
> [5.485820] Internal error: Oops: 9604 [#1] PREEMPT SMP
> [5.492448] Modules linked in: crct10dif_ce adv7511(+)
> qcom_spmi_temp_alarm cec msm(+) mdt_loader qcom_camss videobuf2_dma_sg
> drm_kms_helper v4l2_fwnode videobuf2_memops videobuf2_v4l2 qcom_rng
> videobuf2_common i2c_qcom_cci display_connector socinfo drm qrtr ns
> rmtfs_mem fuse
> [5.500256] CPU: 0 PID: 286 Comm: systemd-udevd Not tainted 5.8.0-rc5 #1
> [5.522484] Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
> [5.529170] pstate: 2005 (nzCv daif -PAN -UAO BTYPE=--)
> [5.535856] pc : qcom_iommu_tlb_inv_context+0x18/0xa8
> [5.541148] lr : free_io_pgtable_ops+0x28/0x58
> [5.546350] sp : 80001219b5f0
> [5.550689] x29: 80001219b5f0 x28: 0013
> [5.554078] x27: 0100 x26: 36add3b8
> [5.559459] x25: 8915e910 x24: 3a5458c0
> [5.564753] x23: 0003 x22: 36a37058
> [5.570049] x21: 36a3a100 x20: 36a3a480
> [5.575344] x19: 36a37158 x18: 
> [5.580639] x17:  x16: 
> [5.585935] x15: 0004 x14: 0368
> [5.591229] x13:  x12: 39c61798
> [5.596525] x11: 39c616d0 x10: 4000
> [5.601820] x9 :  x8 : 39c616f8
> [5.607114] x7 :  x6 : 09f699a0
> [5.612410] x5 : 80001219b520 x4 : 36a3a000
> [5.617705] x3 : 09f69904 x2 : 
> [5.623001] x1 : 8000107e27e8 x0 : 3a545810
> [5.628297] Call trace:
> [5.633592]  qcom_iommu_tlb_inv_context+0x18/0xa8

This means that dev_iommu_fwspec_get() has returned NULL
in qcom_iommu_tlb_inv_context(), either because dev->iommu
is NULL, or because dev->iommu->fwspec is NULL.

qcom_iommu_tlb_inv_context() does not check for a NULL
pointer before using the returned object.

The bug is either in the lack of error handling, or the fact
that it's possible to get into this function for a device
that has not been fully set up.

> [5.635764]  free_io_pgtable_ops+0x28/0x58
> [5.640624]  qcom_iommu_domain_free+0x38/0x60
> [5.644617]  iommu_group_release+0x4c/0x70
> [5.649045]  kobject_put+0x6c/0x120
> [5.653035]  kobject_del+0x64/0x90
> [5.656421]  kobject_put+0xfc/0x120
> [5.659893]  iommu_group_remove_device+0xdc/0xf0
> [5.663281]  iommu_release_device+0x44/0x70
> [5.668142]  iommu_bus_notifier+0xbc/0xd0
> [5.672048]  notifier_call_chain+0x54/0x98
> [5.676214]  blocking_notifier_call_chain+0x48/0x70
> [5.680209]  device_del+0x26c/0x3a0
> [5.684981]  platform_device_del.part.0+0x1c/0x88
> [5.688453]  platform_device_unregister+0x24/0x40
> [5.693316]  of_platform_device_destroy+0xe4/0xf8
> [5.698002]  device_for_each_child+0x5c/0xa8
> [5.702689]  of_platform_depopulate+0x3c/0x80
> [5.707144]  msm_pdev_probe+0x1c4/0x308 [msm]

It was triggered by a failure in msm_pdev_probe(), which was
calls of_platform_depopulate() in its error handling code.
This is a combination of two problems:

a) Whatever caused msm_pdev_probe() to fail means that
the gpu won't be usable, though it should not have caused the
kernel to crash.

b) the error handling itself causing additional problems due
to failed unwinding.

> [5.711286]  platform_drv_probe+0x54/0xa8
> [5.715624]  really_probe+0xd8/0x320
> [5.719617]  driver_probe_device+0x58/0xb8
> [5.723263]  device_driver_attach+0x74/0x80
> [5.727168]  __driver_attach+0x58/0xe0
> [5.731248]  bus_for_each_dev+0x70/0xc0
> [5.735067]  driver_attach+0x24/0x30
> [5.738801]  bus_add_driver+0x14c/0x1f0
> [5.742619]  driver_register+0x64/0x120
> [5.746178]  __platform_driver_register+0x48/0x58
> [5.750099]  msm_drm_register+0x58/0x70 [msm]
> [5.754861]  

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-06-09 Thread Arnd Bergmann
On Tue, Jun 9, 2020 at 6:02 AM Zhangfei Gao  wrote:
> On 2020/6/9 上午12:41, Bjorn Helgaas wrote:
> > On Mon, Jun 08, 2020 at 10:54:15AM +0800, Zhangfei Gao wrote:
> >> On 2020/6/6 上午7:19, Bjorn Helgaas wrote:
>  +++ b/drivers/iommu/iommu.c
>  @@ -2418,6 +2418,10 @@ int iommu_fwspec_init(struct device *dev, struct
>  fwnode_handle *iommu_fwnode,
>    fwspec->iommu_fwnode = iommu_fwnode;
>    fwspec->ops = ops;
>    dev_iommu_fwspec_set(dev, fwspec);
>  +
>  +   if (dev_is_pci(dev))
>  +   pci_fixup_device(pci_fixup_final, to_pci_dev(dev));
>  +
> 
>  Then pci_fixup_final will be called twice, the first in 
>  pci_bus_add_device.
>  Here in iommu_fwspec_init is the second time, specifically for 
>  iommu_fwspec.
>  Will send this when 5.8-rc1 is open.
> >>> Wait, this whole fixup approach seems wrong to me.  No matter how you
> >>> do the fixup, it's still a fixup, which means it requires ongoing
> >>> maintenance.  Surely we don't want to have to add the Vendor/Device ID
> >>> for every new AMBA device that comes along, do we?
> >>>
> >> Here the fake pci device has standard PCI cfg space, but physical
> >> implementation is base on AMBA
> >> They can provide pasid feature.
> >> However,
> >> 1, does not support tlp since they are not real pci devices.
> >> 2. does not support pri, instead support stall (provided by smmu)
> >> And stall is not a pci feature, so it is not described in struct pci_dev,
> >> but in struct iommu_fwspec.
> >> So we use this fixup to tell pci system that the devices can support stall,
> >> and hereby support pasid.
> > This did not answer my question.  Are you proposing that we update a
> > quirk every time a new AMBA device is released?  I don't think that
> > would be a good model.
>
> Yes, you are right, but we do not have any better idea yet.
> Currently we have three fake pci devices, which support stall and pasid.
> We have to let pci system know the device can support pasid, because of
> stall feature, though not support pri.
> Do you have any other ideas?

It sounds like the best way would be to allocate a PCI capability for it, so
detection can be done through config space, at least in future devices,
or possibly after a firmware update if the config space in your system
is controlled by firmware somewhere.  Once there is a proper mechanism
to do this, using fixups to detect the early devices that don't use that
should be uncontroversial. I have no idea what the process or timeline
is to add new capabilities into the PCIe specification, or if this one
would be acceptable to the PCI SIG at all.

If detection cannot be done through PCI config space, the next best
alternative is to pass auxiliary data through firmware. On DT based
machines, you can list non-hotpluggable PCIe devices and add custom
properties that could be read during device enumeration. I assume
ACPI has something similar, but I have not done that.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/2] Introduce PCI_FIXUP_IOMMU

2020-05-27 Thread Arnd Bergmann
On Wed, May 27, 2020 at 11:00 AM Greg Kroah-Hartman
 wrote:
>
> On Tue, May 26, 2020 at 07:49:07PM +0800, Zhangfei Gao wrote:
> > Some platform devices appear as PCI but are actually on the AMBA bus,
>
> Why would these devices not just show up on the AMBA bus and use all of
> that logic instead of being a PCI device and having to go through odd
> fixes like this?

There is a general move to having hardware be discoverable even with
ARM processors. Having on-chip devices be discoverable using PCI config
space is how x86 SoCs usually do it, and that is generally a good thing
as it means we don't need to describe them in DT

I guess as the hardware designers are still learning about it, this is not
always done correctly. In general, we can also describe PCI devices on
DT and do fixups during the probing there, but I suspect that won't work
as easily using ACPI probing, so the fixup is keyed off the hardware ID,
again as is common for x86 on-chip devices.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu/renesas: fix unused-function warning

2020-05-08 Thread Arnd Bergmann
gcc warns because the only reference to ipmmu_find_group
is inside of an #ifdef:

drivers/iommu/ipmmu-vmsa.c:878:28: error: 'ipmmu_find_group' defined but not 
used [-Werror=unused-function]

Change the #ifdef to an equivalent IS_ENABLED().

Fixes: 6580c8a78424 ("iommu/renesas: Convert to probe/release_device() 
call-backs")
Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/ipmmu-vmsa.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/ipmmu-vmsa.c b/drivers/iommu/ipmmu-vmsa.c
index fb7e702dee23..4c2972f3153b 100644
--- a/drivers/iommu/ipmmu-vmsa.c
+++ b/drivers/iommu/ipmmu-vmsa.c
@@ -903,11 +903,8 @@ static const struct iommu_ops ipmmu_ops = {
.probe_device = ipmmu_probe_device,
.release_device = ipmmu_release_device,
.probe_finalize = ipmmu_probe_finalize,
-#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
-   .device_group = generic_device_group,
-#else
-   .device_group = ipmmu_find_group,
-#endif
+   .device_group = IS_ENABLED(CONFIG_ARM) && !IS_ENABLED(CONFIG_IOMMU_DMA)
+   ? generic_device_group : ipmmu_find_group,
.pgsize_bitmap = SZ_1G | SZ_2M | SZ_4K,
.of_xlate = ipmmu_of_xlate,
 };
-- 
2.26.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: fix min_not_zero() type mismatch warning

2019-12-10 Thread Arnd Bergmann
min()/max() require the arguments to be of the same type.

When dma_addr_t is not compatible with __u64, this causes
a warning:

In file included from include/linux/list.h:9,
 from include/linux/kobject.h:19,
 from include/linux/of.h:17,
 from include/linux/irqdomain.h:35,
 from include/linux/acpi.h:13,
 from include/linux/acpi_iort.h:10,
 from drivers/iommu/dma-iommu.c:11:
drivers/iommu/dma-iommu.c: In function 'iommu_dma_alloc_iova':
include/linux/kernel.h:844:29: error: comparison of distinct pointer types 
lacks a cast [-Werror]
   (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
 ^~
include/linux/kernel.h:858:4: note: in expansion of macro '__typecheck'
   (__typecheck(x, y) && __no_side_effects(x, y))
^~~
include/linux/kernel.h:868:24: note: in expansion of macro '__safe_cmp'
  __builtin_choose_expr(__safe_cmp(x, y), \
^~
include/linux/kernel.h:877:19: note: in expansion of macro '__careful_cmp'
 #define min(x, y) __careful_cmp(x, y, <)
   ^
include/linux/kernel.h:910:39: note: in expansion of macro 'min'
  __x == 0 ? __y : ((__y == 0) ? __x : min(__x, __y)); })
   ^~~
drivers/iommu/dma-iommu.c:424:14: note: in expansion of macro 'min_not_zero'
  dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
  ^~~~

Add an explicit cast to work around it, as there is no min_not_zero_t()
equivalent of min_t().

Fixes: a7ba70f1787f ("dma-mapping: treat dev->bus_dma_mask as a DMA limit")
Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/dma-iommu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 0cc702a70a96..6fa32231dc9f 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -421,7 +421,7 @@ static dma_addr_t iommu_dma_alloc_iova(struct iommu_domain 
*domain,
if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
iova_len = roundup_pow_of_two(iova_len);
 
-   dma_limit = min_not_zero(dma_limit, dev->bus_dma_limit);
+   dma_limit = min_not_zero((u64)dma_limit, dev->bus_dma_limit);
 
if (domain->geometry.force_aperture)
dma_limit = min(dma_limit, domain->geometry.aperture_end);
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] media: staging: tegra-vde: Fix build error

2019-09-20 Thread Arnd Bergmann
On Thu, Jul 25, 2019 at 2:24 PM Dmitry Osipenko  wrote:
>
> 25.07.2019 5:41, YueHaibing пишет:
> > If IOMMU_SUPPORT is not set, and COMPILE_TEST is y,
> > IOMMU_IOVA may be set to m. So building will fails:
> >
> > drivers/staging/media/tegra-vde/iommu.o: In function `tegra_vde_iommu_map':
> > iommu.c:(.text+0x41): undefined reference to `alloc_iova'
> > iommu.c:(.text+0x56): undefined reference to `__free_iova'
> >
> > Select IOMMU_IOVA while COMPILE_TEST is set to fix this.

> > @@ -3,7 +3,7 @@ config TEGRA_VDE
> >   tristate "NVIDIA Tegra Video Decoder Engine driver"
> >   depends on ARCH_TEGRA || COMPILE_TEST
> >   select DMA_SHARED_BUFFER
> > - select IOMMU_IOVA if IOMMU_SUPPORT
> > + select IOMMU_IOVA if (IOMMU_SUPPORT || COMPILE_TEST)
> >   select SRAM
> >   help
> >   Say Y here to enable support for the NVIDIA Tegra video decoder
> >
>
> This results in missing the case of compile-testing !IOMMU_IOVA for the
> driver, but probably that's not a big deal.
>
> Acked-by: Dmitry Osipenko 

I don't know what happened here, but the patch from YueHaibing caused this
error for me, which is very much like the problem it was meant to fix:

drivers/gpu/host1x/dev.o: In function `host1x_probe':
dev.c:(.text+0x1734): undefined reference to `put_iova_domain'
dev.c:(.text+0x1744): undefined reference to `iova_cache_put'
drivers/gpu/host1x/dev.o: In function `host1x_remove':
dev.c:(.text+0x1894): undefined reference to `put_iova_domain'
dev.c:(.text+0x1898): undefined reference to `iova_cache_put'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
cdma.c:(.text+0x5d0): undefined reference to `alloc_iova'
cdma.c:(.text+0x61c): undefined reference to `__free_iova'
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_deinit':
cdma.c:(.text+0x6c8): undefined reference to `free_iova'
drivers/gpu/host1x/job.o: In function `host1x_job_pin':
job.c:(.text+0x514): undefined reference to `alloc_iova'
job.c:(.text+0x528): undefined reference to `__free_iova'
drivers/gpu/host1x/job.o: In function `host1x_job_unpin':
job.c:(.text+0x5bc): undefined reference to `free_iova'

After reverthing commit 6b2265975239 ("media: staging:
tegra-vde: Fix build error"), I can no longer reproduce the
issue.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] iommu: omap: mark pm functions __maybe_unused

2019-09-06 Thread Arnd Bergmann
On Fri, Sep 6, 2019 at 5:24 PM Suman Anna  wrote:
>
> Hi Arnd,
>
> On 9/6/19 10:15 AM, Arnd Bergmann wrote:
> > The runtime_pm functions are unused when CONFIG_PM is disabled:
> >
> > drivers/iommu/omap-iommu.c:1022:12: error: unused function 
> > 'omap_iommu_runtime_suspend' [-Werror,-Wunused-function]
> > static int omap_iommu_runtime_suspend(struct device *dev)
> > drivers/iommu/omap-iommu.c:1064:12: error: unused function 
> > 'omap_iommu_runtime_resume' [-Werror,-Wunused-function]
> > static int omap_iommu_runtime_resume(struct device *dev)
> >
> > Mark them as __maybe_unused to let gcc silently drop them
> > instead of warning.
>
> Curious, what defconfig is this? OMAP drivers won't be functional in
> general without pm_runtime, so CONFIG_PM is mandatory. But from just a
> CONFIG_PM option point of view, agree with the patch.

I did some randconfig builds for testing the stuff I merged for 5.4.
I don't think there are any defconfigs without CONFIG_PM.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] iommu: omap: mark pm functions __maybe_unused

2019-09-06 Thread Arnd Bergmann
The runtime_pm functions are unused when CONFIG_PM is disabled:

drivers/iommu/omap-iommu.c:1022:12: error: unused function 
'omap_iommu_runtime_suspend' [-Werror,-Wunused-function]
static int omap_iommu_runtime_suspend(struct device *dev)
drivers/iommu/omap-iommu.c:1064:12: error: unused function 
'omap_iommu_runtime_resume' [-Werror,-Wunused-function]
static int omap_iommu_runtime_resume(struct device *dev)

Mark them as __maybe_unused to let gcc silently drop them
instead of warning.

Fixes: db8918f61d51 ("iommu/omap: streamline enable/disable through runtime pm 
callbacks")
Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/omap-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 451e3c98ab2d..09c6e1c680db 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -1019,7 +1019,7 @@ EXPORT_SYMBOL_GPL(omap_iommu_domain_activate);
  * reset line. This function also saves the context of any
  * locked TLBs if suspending.
  **/
-static int omap_iommu_runtime_suspend(struct device *dev)
+static __maybe_unused int omap_iommu_runtime_suspend(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct iommu_platform_data *pdata = dev_get_platdata(dev);
@@ -1061,7 +1061,7 @@ static int omap_iommu_runtime_suspend(struct device *dev)
  * reset line. The function also restores any locked TLBs if
  * resuming after a suspend.
  **/
-static int omap_iommu_runtime_resume(struct device *dev)
+static __maybe_unused int omap_iommu_runtime_resume(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct iommu_platform_data *pdata = dev_get_platdata(dev);
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] powerpc/dma: Fix invalid DMA mmap behavior

2019-07-19 Thread Arnd Bergmann
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_COHERENT_DMA_MMAP set uses this default implementation, so
> > > > I assume this behavior is acceptable on those architectures.
> > >
> > > It might be acceptable, but there's no reason to use pgport_noncached
> > > if the platform supports cache-coherent DMA.
> > >
> > > Christoph (+cc) made the change so maybe he saw something we're missing.
> >
> > I always found the forcing of noncached access even for coherent
> > devices a little odd, but this was inherited from the previous
> > implementation, which surprised me a bit as the different attributes
> > are usually problematic even on x86.  Let me dig into the history a
> > bit more, but I suspect the righ fix is to default to cached mappings
> > for coherent devices.
>
> Ok, some history:
>
> The generic dma mmap implementation, which we are effectively still
> using today was added by:
>
> commit 64ccc9c033c6089b2d426dad3c56477ab066c999
> Author: Marek Szyprowski 
> Date:   Thu Jun 14 13:03:04 2012 +0200
>
> common: dma-mapping: add support for generic dma_mmap_* calls
>
> and unconditionally uses pgprot_noncached in dma_common_mmap, which is
> then used as the fallback by dma_mmap_attrs if no ->mmap method is
> present.  At that point we already had the powerpc implementation
> that only uses pgprot_noncached for non-coherent mappings, and
> the arm one, which uses pgprot_writecombine if DMA_ATTR_WRITE_COMBINE
> is set and otherwise pgprot_dmacoherent, which seems to be uncached.
> Arm did support coherent platforms at that time, but they might have
> been an afterthought and not handled properly.

Cache-coherent devices are still very rare on 32-bit ARM.

Among the callers of dma_mmap_coherent(), almost all are in platform
specific device drivers that only ever run on noncoherent ARM SoCs,
which explains why nobody would have noticed problems.

There is also a difference in behavior between ARM and PowerPC
when dealing with mismatched cacheability attributes: If the same
page is mapped as both cached and uncached to, this may
cause silent undefined behavior on ARM, while PowerPC should
enter a checkstop as soon as it notices.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH 5/7 v2] MIPS: use the generic uncached segment support in dma-direct

2019-07-03 Thread Arnd Bergmann
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
> > > offset instead.
> > >
> > > Signed-off-by: Christoph Hellwig 
> > > ---
> > >  arch/mips/Kconfig  |  1 +
> > >  arch/mips/include/asm/page.h   |  3 ---
> > >  arch/mips/jazz/jazzdma.c   |  6 --
> > >  arch/mips/mm/dma-noncoherent.c | 26 +-
> > >  4 files changed, 10 insertions(+), 26 deletions(-)
> >
> > This one looks good to me now, for patches 1 & 5:
> >
> >   Acked-by: Paul Burton 
>
> Thanks, I've merged thos into the dma-mapping tree.

I think this is the cause of some kernelci failures in current
linux-next builds:

https://kernelci.org/build/next/branch/master/kernel/next-20190702/

bigsur_defconfig ‐ mips3 warnings — 1 error
cavium_octeon_defconfig ‐ mips3 warnings — 1 error
ip27_defconfig ‐ mips3 warnings — 1 error
loongson3_defconfig ‐ mips3 warnings — 1 error
mips_paravirt_defconfig ‐ mips3 warnings — 1 error
nlm_xlp_defconfig ‐ mips3 warnings — 1 error
nlm_xlr_defconfig ‐ mips1 warning — 1 error

/home/buildslave/workspace/workspace/kernel-build@8/linux/build/../kernel/dma/direct.c:144:
undefined reference to `arch_dma_prep_coherent'
2/home/buildslave/workspace/kernel-build/linux/build/../kernel/dma/direct.c:144:
undefined reference to `arch_dma_prep_coherent'
2(.text+0xafc): undefined reference to `arch_dma_prep_coherent'
1direct.c:(.text+0x934): undefined reference to `arch_dma_prep_coherent'
1(.text+0xb84): undefined reference to `arch_dma_prep_coherent'

I haven't looked into the details, but I suspect all machines
with cache-coherent DMA are broken.

   Arnd


[PATCH] iommu: fix integer truncation

2019-06-17 Thread Arnd Bergmann
On 32-bit architectures, phys_addr_t may be different from dma_add_t,
both smaller and bigger. This can lead to an overflow during an assignment
that clang warns about:

drivers/iommu/dma-iommu.c:230:10: error: implicit conversion from 'dma_addr_t' 
(aka 'unsigned long long') to
  '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 inaccessible DMA 
address")
Signed-off-by: Arnd Bergmann 
---
 drivers/iommu/dma-iommu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index cc0613c83d71..a9f13313a22f 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -226,8 +226,8 @@ static int iova_reserve_pci_windows(struct pci_dev *dev,
start = window->res->end - window->offset + 1;
/* If window is last entry */
if (window->node.next == >dma_ranges &&
-   end != ~(dma_addr_t)0) {
-   end = ~(dma_addr_t)0;
+   end != ~(phys_addr_t)0) {
+   end = ~(phys_addr_t)0;
goto resv_iova;
}
}
-- 
2.20.0



[PATCH] swiotlb: fix phys_addr_t overflow warning

2019-06-17 Thread Arnd Bergmann
On architectures that have a larger dma_addr_t than phys_addr_t,
the swiotlb_tbl_map_single() function truncates its return code
in the failure path, making it impossible to identify the error
later, as we compare to the original value:

kernel/dma/swiotlb.c:551:9: error: implicit conversion from 'dma_addr_t' (aka 
'unsigned long long') to 'phys_addr_t' (aka 'unsigned int') changes value from 
18446744073709551615 to 4294967295 [-Werror,-Wconstant-conversion]
return DMA_MAPPING_ERROR;

Use an explicit typecast here to convert it to the narrower 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 patch restores the correct behavior.
---
 drivers/xen/swiotlb-xen.c | 2 +-
 kernel/dma/swiotlb.c  | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index d53f3493a6b9..cfbe46785a3b 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -402,7 +402,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 
map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir,
 attrs);
-   if (map == DMA_MAPPING_ERROR)
+   if (map == (phys_addr_t)DMA_MAPPING_ERROR)
return DMA_MAPPING_ERROR;
 
dev_addr = xen_phys_to_bus(map);
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index e906ef2e6315..a3be651973ad 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -548,7 +548,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit())
dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes), total 
%lu (slots), used %lu (slots)\n",
 size, io_tlb_nslabs, tmp_io_tlb_used);
-   return DMA_MAPPING_ERROR;
+   return (phys_addr_t)DMA_MAPPING_ERROR;
 found:
io_tlb_used += nslots;
spin_unlock_irqrestore(_tlb_lock, flags);
@@ -666,7 +666,7 @@ bool swiotlb_map(struct device *dev, phys_addr_t *phys, 
dma_addr_t *dma_addr,
/* Oh well, have to allocate and map a bounce buffer. */
*phys = swiotlb_tbl_map_single(dev, __phys_to_dma(dev, io_tlb_start),
*phys, size, dir, attrs);
-   if (*phys == DMA_MAPPING_ERROR)
+   if (*phys == (phys_addr_t)DMA_MAPPING_ERROR)
return false;
 
/* Ensure that the address returned is DMA'ble */
-- 
2.20.0



Re: [Xen-devel] [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-13 Thread Arnd Bergmann
On Wed, Mar 13, 2019 at 7:33 PM Christoph Hellwig  wrote:
> On Fri, Mar 08, 2019 at 05:25:57PM +, Julien Grall wrote:
> > In the common case, Dom0 also contains the PV backend drivers. Those
> > drivers may directly use the guest buffer in the DMA request (so a copy is
> > avoided). To avoid using a bounce buffer too much, xen-swiotlb will find
> > the host physical address associated to the guest buffer and will use it to
> > compute the DMA address.
> >
> > While Dom0 kernel may only deal with 32-bit physical address, the
> > hypervisor can still deal with up to 40-bit physical address. This means
> > the guest memory can be allocated above the 4GB threshold. Hence why the
> > dma_addr_t is always 64-bit with CONFIG_XEN=y.
>
> This at least makes some sense.  But is it really so much better to
> avoid having a 64-bit phys_addr_t?

I like the way we tie phys_addr_t to the page table format, as it seems
consistent to have phys_addr_t be whichever data type can be addressed
through virtual memory.

The main practical advantage I see in allowing phys_addr_t and dma_addr_t
to be independent rather than having both of them be the same and grow
to as much as is needed is that most randconfig issues I found that
result from a type mismatch are for real bugs, typically in driver code that
is written under the assumption that both have not only the same size
but also the same binary representation for a given memory address.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] [v3] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
Clang has a rather annoying behavior of checking for integer
arithmetic problems in code paths that are discarded by gcc
before that perfoms the same checks.

For DMA_BIT_MASK(64), this leads to a warning despite the
result of the macro being completely sensible:

arch/arm/plat-iop/adma.c:146:24: error: shift count >= width of type 
[-Werror,-Wshift-count-overflow]
.coherent_dma_mask = DMA_BIT_MASK(64),

The best workaround I could come up with is to shift the
value twice, which makes the macro way less readable but
always has the same result.

Link: https://bugs.llvm.org/show_bug.cgi?id=38789
Reviewed-by: Geert Uytterhoeven 
Reviewed-by: Robin Murphy 
Signed-off-by: Arnd Bergmann 
---
v3: use (2ull << n-1) instead of ((1ull << n-1) << 1)
special-case 0 instead of 64
v2: fix off-by-one error
---
 include/linux/dma-mapping.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75e60be91e5f..5788d60c2223 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -138,7 +138,11 @@ struct dma_map_ops {
 extern const struct dma_map_ops dma_virt_ops;
 extern const struct dma_map_ops dma_dummy_ops;
 
-#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+/*
+ * Shifting '2' instead of '1' because of
+ * https://bugs.llvm.org/show_bug.cgi?id=38789
+ */
+#define DMA_BIT_MASK(n)(((n) == 0) ? 0ULL : (2ULL<<((n)-1))-1)
 
 #define DMA_MASK_NONE  0x0ULL
 
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] [v2] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
On Thu, Mar 7, 2019 at 10:17 AM Robin Murphy  wrote:
> On 2019-03-07 8:52 am, Arnd Bergmann wrote:
> >
> > -#define DMA_BIT_MASK(n)  (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> > +/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789 
> > */
> > +#define DMA_BIT_MASK(n)  (((n) == 64) ? ~0ULL : ((1ULL<<((n)-1))<<1)-1)
>
> I think that now makes DMA_BIT_MASK(0) undefined - that shouldn't matter
> in most cases, but it could potentially happen at runtime where callers
> use a non-constant argument. However, it also means we don't need to
> special-case 64 any more (since that's there to avoid the same thing
> anyway), so we could simply flip that to handle 0 instead.

Yes, good idea.

> FWIW I'd be very tempted to fold in the second shift as "2ULL<<((n)-1)",
> but that may not be to everyone's taste.

I like that. So shall we do this?

/*
 * Shifting '2' instead of '1' because of
 * https://bugs.llvm.org/show_bug.cgi?id=38789
 */
#define DMA_BIT_MASK(n)(((n) == 0) ? 0ULL : ((2ULL<<((n)-1)))-1)

 Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] [v2] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
Clang has a rather annoying behavior of checking for integer
arithmetic problems in code paths that are discarded by gcc
before that perfoms the same checks.

For DMA_BIT_MASK(64), this leads to a warning despite the
result of the macro being completely sensible:

arch/arm/plat-iop/adma.c:146:24: error: shift count >= width of type 
[-Werror,-Wshift-count-overflow]
.coherent_dma_mask = DMA_BIT_MASK(64),

The best workaround I could come up with is to shift the
value twice, which makes the macro way less readable but
always has the same result.

Link: https://bugs.llvm.org/show_bug.cgi?id=38789
Signed-off-by: Arnd Bergmann 
---
v2: fix off-by-one error
---
 include/linux/dma-mapping.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75e60be91e5f..9e438fe6b130 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -138,7 +138,8 @@ struct dma_map_ops {
 extern const struct dma_map_ops dma_virt_ops;
 extern const struct dma_map_ops dma_dummy_ops;
 
-#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789 */
+#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<((n)-1))<<1)-1)
 
 #define DMA_MASK_NONE  0x0ULL
 
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
On Thu, Mar 7, 2019 at 9:28 AM Geert Uytterhoeven  wrote:
> On Thu, Mar 7, 2019 at 9:01 AM Arnd Bergmann  wrote:
> > Clang has a rather annoying behavior of checking for integer
> > arithmetic problems in code paths that are discarded by gcc
> > before that perfoms the same checks.
> >
> > For DMA_BIT_MASK(64), this leads to a warning despite the
> > result of the macro being completely sensible:
> >
> > arch/arm/plat-iop/adma.c:146:24: error: shift count >= width of type 
> > [-Werror,-Wshift-count-overflow]
> > .coherent_dma_mask = DMA_BIT_MASK(64),
> >
> > The best workaround I could come up with is to shift the
> > value twice, which makes the macro way less readable but
> > always has the same result.
> >
> > Link: https://bugs.llvm.org/show_bug.cgi?id=38789
> > Signed-off-by: Arnd Bergmann 
> > ---
> >  include/linux/dma-mapping.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index 75e60be91e5f..380d3a95d02e 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -138,7 +138,8 @@ struct dma_map_ops {
> >  extern const struct dma_map_ops dma_virt_ops;
> >  extern const struct dma_map_ops dma_dummy_ops;
> >
> > -#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
> > +/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789 
> > */
> > +#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : (((1ULL<<((n)-1))-1) 
> > << 1))
>
> The second "-1" should be done on the final result, not on the
> intermediate value.

Ah, of course. I'll send an update patch in a bit, sorry about this.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] dma-mapping: work around clang bug

2019-03-07 Thread Arnd Bergmann
Clang has a rather annoying behavior of checking for integer
arithmetic problems in code paths that are discarded by gcc
before that perfoms the same checks.

For DMA_BIT_MASK(64), this leads to a warning despite the
result of the macro being completely sensible:

arch/arm/plat-iop/adma.c:146:24: error: shift count >= width of type 
[-Werror,-Wshift-count-overflow]
.coherent_dma_mask = DMA_BIT_MASK(64),

The best workaround I could come up with is to shift the
value twice, which makes the macro way less readable but
always has the same result.

Link: https://bugs.llvm.org/show_bug.cgi?id=38789
Signed-off-by: Arnd Bergmann 
---
 include/linux/dma-mapping.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 75e60be91e5f..380d3a95d02e 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -138,7 +138,8 @@ struct dma_map_ops {
 extern const struct dma_map_ops dma_virt_ops;
 extern const struct dma_map_ops dma_dummy_ops;
 
-#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
+/* double shift to work around https://bugs.llvm.org/show_bug.cgi?id=38789 */
+#define DMA_BIT_MASK(n)(((n) == 64) ? ~0ULL : (((1ULL<<((n)-1))-1) << 
1))
 
 #define DMA_MASK_NONE  0x0ULL
 
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-05 Thread Arnd Bergmann
On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy  wrote:
> On 2019-03-04 7:59 pm, Arnd Bergmann wrote:
> > This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), 
> > which
> > introduced an overflow warning in configurations that have a larger
> > dma_addr_t than phys_addr_t:
> >
> > In file included from include/linux/dma-direct.h:5,
> >   from kernel/dma/swiotlb.c:23:
> > kernel/dma/swiotlb.c: In function 'swiotlb_tbl_map_single':
> > include/linux/dma-mapping.h:136:28: error: conversion from 'long long 
> > unsigned int' to 'phys_addr_t' {aka 'unsigned int'} changes value from 
> > '18446744073709551615' to '4294967295' [-Werror=overflow]
> >   #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
> >  ^
> > kernel/dma/swiotlb.c:544:9: note: in expansion of macro 'DMA_MAPPING_ERROR'
> >return DMA_MAPPING_ERROR;
> >
> > The configuration that caused this is on 32-bit ARM, where the DMA address
> > space depends on the enabled hardware platforms, while the physical
> > address space depends on the type of MMU chosen (classic vs LPAE).
>
> Are these real platforms, or random configs? Realistically I don't see a
> great deal of need to support DMA_ADDR_T_64BIT for non-LPAE.
> Particularly in this case since AFAIK the only selector of SWIOTLB on
> Arm is Xen, and that by definition is never going to be useful on
> non-LPAE hardware.
...
On Mon, Mar 4, 2019 at 11:00 PM Konrad Rzeszutek Wilk
 wrote:
> What about making the phys_addr_t and dma_addr_t have the same
> width with some magic #ifdef hackery?

As far as I can tell, only randconfig builds see this problem, in
real systems phys_addr_t is normally the same as dma_addr_t,
and you could reasonably have a machine with a larger phys_addr_t
than dma_addr_t but wouldn't need to bother.

The reason I'd like to keep them independent on ARM is that
the difference does occasionally find real driver bugs where some
drivers happily mix phys_addr_t and dma_addr_t in ways that
are broken even when they are the same size.

On Tue, Mar 5, 2019 at 12:56 AM Robin Murphy  wrote:
> Fair enough that we don't still don't want even randconfigs generating
> warnings, though. As long as this change doesn't let SWIOTLB_MAP_ERROR
> leak out to logic expecting DMA_MAP_ERROR - which does appear to be the
> case - and is also still OK for the opposite weirdness of
> PHYS_ADDR_T_64BIT && !DMA_ADDR_T_64BIT, then I think it's reasonable.

Another option would be to change the return type of swiotlb_tbl_map_single()
to 'u64', which would always be large enough to contain both a phys_addr_t
and DMA_MAP_ERROR. I first tried changing the return type to dma_addr_t,
which solves the build issue, but I couldn't convince myself that this is
correct in all cases, or that this is a sensible type to use here.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


[PATCH] Revert "swiotlb: remove SWIOTLB_MAP_ERROR"

2019-03-04 Thread Arnd Bergmann
This reverts commit b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR"), which
introduced an overflow warning in configurations that have a larger
dma_addr_t than phys_addr_t:

In file included from include/linux/dma-direct.h:5,
 from kernel/dma/swiotlb.c:23:
kernel/dma/swiotlb.c: In function 'swiotlb_tbl_map_single':
include/linux/dma-mapping.h:136:28: error: conversion from 'long long unsigned 
int' to 'phys_addr_t' {aka 'unsigned int'} changes value from 
'18446744073709551615' to '4294967295' [-Werror=overflow]
 #define DMA_MAPPING_ERROR  (~(dma_addr_t)0)
^
kernel/dma/swiotlb.c:544:9: note: in expansion of macro 'DMA_MAPPING_ERROR'
  return DMA_MAPPING_ERROR;

The configuration that caused this is on 32-bit ARM, where the DMA address
space depends on the enabled hardware platforms, while the physical
address space depends on the type of MMU chosen (classic vs LPAE).

I tried a couple of alternative approaches, but the previous version
seems as good as any other, so I went back to that.

Fixes: b907e20508d0 ("swiotlb: remove SWIOTLB_MAP_ERROR")
Signed-off-by: Arnd Bergmann 
---
 drivers/xen/swiotlb-xen.c | 4 ++--
 include/linux/swiotlb.h   | 3 +++
 kernel/dma/swiotlb.c  | 4 ++--
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 877baf2a94f4..57a98279bf4f 100644
--- a/drivers/xen/swiotlb-xen.c
+++ b/drivers/xen/swiotlb-xen.c
@@ -406,7 +406,7 @@ static dma_addr_t xen_swiotlb_map_page(struct device *dev, 
struct page *page,
 
map = swiotlb_tbl_map_single(dev, start_dma_addr, phys, size, dir,
 attrs);
-   if (map == DMA_MAPPING_ERROR)
+   if (map == SWIOTLB_MAP_ERROR)
return DMA_MAPPING_ERROR;
 
dev_addr = xen_phys_to_bus(map);
@@ -557,7 +557,7 @@ xen_swiotlb_map_sg_attrs(struct device *hwdev, struct 
scatterlist *sgl,
 sg_phys(sg),
 sg->length,
 dir, attrs);
-   if (map == DMA_MAPPING_ERROR) {
+   if (map == SWIOTLB_MAP_ERROR) {
dev_warn(hwdev, "swiotlb buffer is full\n");
/* Don't panic here, we expect map_sg users
   to do proper error handling. */
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 361f62bb4a8e..a65a36551f58 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -44,6 +44,9 @@ enum dma_sync_target {
SYNC_FOR_DEVICE = 1,
 };
 
+/* define the last possible byte of physical address space as a mapping error 
*/
+#define SWIOTLB_MAP_ERROR (~(phys_addr_t)0x0)
+
 extern phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
  dma_addr_t tbl_dma_addr,
  phys_addr_t phys, size_t size,
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 12059b78b631..922880b84387 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -541,7 +541,7 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
spin_unlock_irqrestore(_tlb_lock, flags);
if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit())
dev_warn(hwdev, "swiotlb buffer is full (sz: %zd bytes)\n", 
size);
-   return DMA_MAPPING_ERROR;
+   return SWIOTLB_MAP_ERROR;
 found:
io_tlb_used += nslots;
spin_unlock_irqrestore(_tlb_lock, flags);
@@ -659,7 +659,7 @@ bool swiotlb_map(struct device *dev, phys_addr_t *phys, 
dma_addr_t *dma_addr,
/* Oh well, have to allocate and map a bounce buffer. */
*phys = swiotlb_tbl_map_single(dev, __phys_to_dma(dev, io_tlb_start),
*phys, size, dir, attrs);
-   if (*phys == DMA_MAPPING_ERROR)
+   if (*phys == SWIOTLB_MAP_ERROR)
return false;
 
/* Ensure that the address returned is DMA'ble */
-- 
2.20.0

___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: remove block layer bounce buffering for MMC

2019-01-16 Thread Arnd Bergmann
On Wed, Jan 16, 2019 at 2:51 PM Linus Walleij  wrote:
>
> On Wed, Jan 16, 2019 at 11:25 AM Arnd Bergmann  wrote:
> > On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson  wrote:
> > >
> > > +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
> Nah it's not THAT bounce buffer.
>
> > Linus probably knows more here, but I have a vague recollection of
> > the MMC bounce buffer code being needed mostly for performance
> > reasons: when the scatterlist is discontiguous, that can result in
> > a request being split up into separate MMC commands, which due
> > to the lack of queued commands combined with the need for
> > garbage collection on sub-page writes results in a huge slowdown
> > compared to having larger bounce buffers all the time.
> >
> > We had discussed finding a different way to do this (separate
> > from the bounce buffering), but I don't know if that ever happened,
> > or if this is even the code that you are changing here.
>
> Nope not the same code.
>
> The term "bounce buffer" is sadly used as ambigously as
> __underscores in front of function names.
>
> That other "bounce buffer" was first deleted and then
> reimplemented as a local hack in the SDHCI driver core
> after it caused performance regressions on the i.MX and
> some laptops, see commit:
>
> commit bd9b902798ab14d19ca116b10bde581ddff8f905
> mmc: sdhci: Implement an SDHCI-specific bounce buffer
>
> That should be orthogonal to Christoph's changes in this
> patch series.

Ok, thanks for the clarification. Please ignore my comments then.

Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: remove block layer bounce buffering for MMC

2019-01-16 Thread Arnd Bergmann
On Mon, Jan 14, 2019 at 11:27 AM Ulf Hansson  wrote:
>
> +Linus Walleij (recently made a cleanup of the mmc bounce buffering code).
>
> On Mon, 14 Jan 2019 at 10:58, Christoph Hellwig  wrote:
> >
> > Hi everyone,
> >
> > this series converts the remaining MMC host drivers to properly kmap the
> > scatterlist entries it does PIO operations on, and then goes on to
> > remove the usage of block layer bounce buffering (which I plan to remove
> > eventually) from the MMC layer.
> >
> > As a bonus I've converted various drivers to the proper scatterlist
> > helpers so that at least in theory they are ready for chained
> > scatterlists.
> >
> > All the changes are compile tested only as I don't have any of the
> > hardware, so a careful review would be appreciated.
>
> Thanks for posting this. I will have a look as soon as I can, but
> first needs to catch up with things since the holidays.

Linus probably knows more here, but I have a vague recollection of
the MMC bounce buffer code being needed mostly for performance
reasons: when the scatterlist is discontiguous, that can result in
a request being split up into separate MMC commands, which due
to the lack of queued commands combined with the need for
garbage collection on sub-page writes results in a huge slowdown
compared to having larger bounce buffers all the time.

We had discussed finding a different way to do this (separate
from the bounce buffering), but I don't know if that ever happened,
or if this is even the code that you are changing here.

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: dmaengine for sh7760 (was Re: use the generic dma-noncoherent code for sh V2)

2018-08-20 Thread Arnd Bergmann
On Sun, Aug 19, 2018 at 7:38 AM Rob Landley  wrote:
>
> On 08/17/2018 03:23 PM, Arnd Bergmann wrote:
> > On Fri, Aug 17, 2018 at 7:04 PM Rob Landley  wrote:
> >> On 07/31/2018 07:56 AM, Arnd Bergmann wrote:
> >>> On Fri, Jul 27, 2018 at 6:20 PM, Rob Landley  wrote:
> >>>> On 07/24/2018 03:21 PM, Christoph Hellwig wrote:
> >>>>> On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christoph Hellwig wrote:
> >>>>>> Hi all,
> >>> If you hack on it, please convert the dmaengine platform data to use
> >>> a dma_slave_map array to pass the data into the dmaengine driver,
> >>
> >> The dmatest module didn't need it? I don't see why the ethernet driver 
> >> would?
> >> (Isn't the point of an allocator to allocate from a request?)
> >
> > I guess you have hit two of the special cases here:
> >
> > - dmatest uses the memory-to-memory DMA engine interface, not the slave
> >   API, so you don't have to configure a slave at all
>
> I've read through
> https://www.kernel.org/doc/Documentation/driver-api/dmaengine/client.rst twice
> and am still very unclear on the slave API.
>
> > - smc91x (and its smc911x.c relative) are apparently special in that they
> >   use they use the DMA slave API
>
> Only sort of. In 4.14 at least it's under #ifdef ARCH_PXA and full of PXA
> constants (PXAD_PRIO_LOWEST and such).
>
> > but (AFAICT) require programming
> >   the dmaengine hardware into a memory-to-memory transfer with no
> >   DMA slave request signal and completely synchronous operation
> >   (the IRQ handler polls for the DMA descriptor to be complete),
> >   see also https://lkml.org/lkml/2018/4/3/464 for the discussion about
> >   the recent rework of that driver's implementation.
>
> Bookmarked, thanks.
>
> (Being able to just upgrade to a 4.19 kernel or something and have DMA work in
> this driver if I've got dmaengine set up for the platform would be lovely.)

I wouldn't expect too much even with the newer kernel, I think it
still relies on a special case in the pxa DMA engine driver, possibly
even in their hardware implementation.

> >>> mapping the settings from a (pdev-name, channel-id) tuple to a pointer
> >>> that describes the channel configuration rather than having the
> >>> mapping from an numerical slave_id to a struct sh_dmae_slave_config
> >>> in the setup files. It should be a fairly mechanical conversion.
> >>
> >> I think all 8 channels are generic. Drivers should be able to grab them and
> >> release them at will, why does it need a table?
> >>
> >> (I say this not having made the smc91x.c driver use this yet, its 
> >> "conversion"
> >> to device tree left it full of PXA #ifdefs and constants, and I've tried 
> >> the
> >
> > Another point about smc91x is that it only uses DMA on the PXA platform,
> > which is not part of the "multiplatform" ARM setup. It's likely that no
> > other platform actually has a DMA engine that can talk to this device in
> > the absence of a request signal, or that on more modern CPU cores,
> > a readsl() is actually just as fast, but it avoids the setup cost of talking
> > to the dma engine. Possibly both of the above.
>
> The sh7760 has the CPU pegged at 100% trying to keep up with ethernet traffic.
> Being able to use DMA on this would be very nice.

This is probably for the most part due to the rather slow bus interface
of the smc91x, especially if you can't use the 32-bit mode or an optimized
readsl() implementation.

Using DMA won't let you do the transfer in the background either, as it
would on any other ethernet hardware, it just means the CPU is blocked
for a little less time if the DMA engine can access the bus faster
than the readsl() implementation can on your CPU.

> >> last half-dozen kernel releases and qemu releases and have yet to find an 
> >> arm
> >> mainstone board under qemu that _doesn't_ time out trying to use DMA with 
> >> this
> >> card. But that's another post...)
> >
> > Is smc91x the only driver that you want to make use of the DMA engine?
>
> This driver's the low-hanging fruit, yeah. Copying NOR flash jffs2 data into
> page cache would be nice but there's a decompression step so I'm not sure 
> that's
> a win.

Right, that would be even harder. The devices that are actually designed
for interacting with the DMA engine are likely MMC, USB and audio on
that chip. Those should be easier to do than the smc91x.

> > I suspect that every other one currently relies on passing a slave ID
> > shdma_chan_filter into dma_request_s

Re: dmaengine for sh7760 (was Re: use the generic dma-noncoherent code for sh V2)

2018-08-17 Thread Arnd Bergmann
On Fri, Aug 17, 2018 at 7:04 PM Rob Landley  wrote:
> On 07/31/2018 07:56 AM, Arnd Bergmann wrote:
> > On Fri, Jul 27, 2018 at 6:20 PM, Rob Landley  wrote:
> >> On 07/24/2018 03:21 PM, Christoph Hellwig wrote:
> >>> On Tue, Jul 24, 2018 at 02:01:42PM +0200, Christoph Hellwig wrote:
> >>>> Hi all,
> > If you hack on it, please convert the dmaengine platform data to use
> > a dma_slave_map array to pass the data into the dmaengine driver,
>
> The dmatest module didn't need it? I don't see why the ethernet driver would?
> (Isn't the point of an allocator to allocate from a request?)

I guess you have hit two of the special cases here:

- dmatest uses the memory-to-memory DMA engine interface, not the slave
  API, so you don't have to configure a slave at all

- smc91x (and its smc911x.c relative) are apparently special in that they
  use they use the DMA slave API but (AFAICT) require programming
  the dmaengine hardware into a memory-to-memory transfer with no
  DMA slave request signal and completely synchronous operation
  (the IRQ handler polls for the DMA descriptor to be complete),
  see also https://lkml.org/lkml/2018/4/3/464 for the discussion about
  the recent rework of that driver's implementation.

> > mapping the settings from a (pdev-name, channel-id) tuple to a pointer
> > that describes the channel configuration rather than having the
> > mapping from an numerical slave_id to a struct sh_dmae_slave_config
> > in the setup files. It should be a fairly mechanical conversion.
>
> I think all 8 channels are generic. Drivers should be able to grab them and
> release them at will, why does it need a table?
>
> (I say this not having made the smc91x.c driver use this yet, its "conversion"
> to device tree left it full of PXA #ifdefs and constants, and I've tried the

Another point about smc91x is that it only uses DMA on the PXA platform,
which is not part of the "multiplatform" ARM setup. It's likely that no
other platform actually has a DMA engine that can talk to this device in
the absence of a request signal, or that on more modern CPU cores,
a readsl() is actually just as fast, but it avoids the setup cost of talking
to the dma engine. Possibly both of the above.

> last half-dozen kernel releases and qemu releases and have yet to find an arm
> mainstone board under qemu that _doesn't_ time out trying to use DMA with this
> card. But that's another post...)

Is smc91x the only driver that you want to make use of the DMA engine?
I suspect that every other one currently relies on passing a slave ID
shdma_chan_filter into dma_request_slave_channel_compat() or
dma_request_channel() , which are some of the interfaces we want to
remove in the future, to make everything work the same across
all platforms.

shdma_chan_filter() is one of those that expect its pointer argument to
be a number that is in turn associated with an sh_dmae_slave_config
structure in the platform data of the dma engine. What the newer
dma_request_chan() interface does is to pass a pointer to the
slave device and a string as identifier for the same data, which then
gets associated through the dma_slave_map. On smc91x, both
the device and name argument are NULL, which triggers the special
case in the pxa dmaengine driver.

> > The other part I noticed is arch/sh/drivers/dma/*, which appears to
> > be entirely unused, and should probably removed.
>
> I had to switch that off to get this to work, yes. I believe it predates
> dmaengine and was obsoleted by it.

Ok. Have you found any reason to keep it around though?

   Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 0/7] Stop losing firmware-set DMA masks

2018-08-06 Thread Arnd Bergmann
On Mon, Aug 6, 2018 at 2:08 PM Christoph Hellwig  wrote:
>
> On Mon, Aug 06, 2018 at 12:01:34PM +0200, Arnd Bergmann wrote:
> > There are a few subtle corner cases here, in particular in which cases
> > the new dma_set_mask() behavior on arm64 reports success or
> > failure when truncating the mask to the bus_dma_mask.
>
> Going forward my plan was to make dma_set_mask() never fail.  The idea
> is that it sets the mask that the device is capable of, and the core
> dma code is responsible for also looking at bus_dma_mask and otherwise
> make things just work.
>
> Robin brought up the case where a platform can't handle a given limitation
> ever, e.g. a PCI(e) device with a 24-bit dma mask on a device with a dma
> offset that means we'll never have any physical memory reachable in that
> range.  So we'll either still need to allow it to fail for such corner
> cases or delay such error until later, e.g. when dma_alloc_* (or in the
> corner case of the corner case dma_map_*) is called.  I'm still undecided
> which way to go, but not allowing error returns from dma_set_mask and
> its variants sounds very tempting.

Another case that I think can happen in practice are devices that need a
DMA mask smaller than 32-bit wide (either asked for by the driver
or according to bus limitations) on a platform that has no ZONE_DMA.

However, IIRC there was no reason to ever fail a dma_set_mask()
to something wider than 32 bit even if the resulting mask still stays
at the default 32-bit mask or something inbetween.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [PATCH v2 0/7] Stop losing firmware-set DMA masks

2018-08-06 Thread Arnd Bergmann
On Tue, Jul 31, 2018 at 1:30 PM Robin Murphy  wrote:
> On 29/07/18 13:32, Arnd Bergmann wrote:
> > On Tue, Jul 24, 2018 at 12:16 AM, Robin Murphy  wrote:

> > Thanks a lot for working on this, this has bugged me for many years,
> > and I've discussed possible solutions with lots of people over time.
> >
> > I /think/ all your patches are good, but I'm currently travelling and don't
> > have a chance to review the resulting overall implementation.
> > Could you summarize what happens in the following corner cases of
> > DT dma-ranges after your changes (with a driver not setting a mask,
> > setting a 64-bit mask and setting a 24-bit mask, respectively)?
> >
> > a) a device with no dma-ranges property anywhere in its parents
> > b) a device with with a 64-bit dma-ranges translation in its parent
> > but none in its grandparent
> > c) a device with no dma-ranges in its parent but a 64-bit mask
> > in its grandparent
> > d) a device with a 24-bit mask in its parent.
>
> In terms of the actual dma-ranges parsing, nothing should be changed by
> these patches, so the weirdness and inconsistency that I'm pretty sure
> exists for some of those cases will still be there for the moment - I'm
> starting on actually fixing of_dma_get_range() now.

Right, but I'm interested in the combination of of_dma_get_range()
with dma_set_mask(), which is the part that was traditionally broken
on arm64 and should be fixed now.

There are a few subtle corner cases here, in particular in which cases
the new dma_set_mask() behavior on arm64 reports success or
failure when truncating the mask to the bus_dma_mask.

> The effect after these patches is that a device with a "valid" (per the
> current of_dma_get_range() implementation) dma-ranges translation gets
> it bus_dma_mask set to cover the given range, whereas a device with no
> valid dma-ranges effectively gets a 32-bit bus_dma_mask. That's slightly
> different from the ACPI default behaviour, due to subtle spec
> differences, but I think it's in line with what you've proposed before
> for DT, and it's certainly still flexible if anyone has a different
> view. The bus_dma_mask in itself should also be low-impact, since it
> will only currently be enforced in the generic dma-direct and iommu-dma
> paths, so the likes of powerpc shouldn't see any change at all just yet.

Ok.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: use the generic dma-noncoherent code for sh V2

2018-07-31 Thread Arnd Bergmann
On Mon, Jul 30, 2018 at 11:06 AM, Christoph Hellwig  wrote:
> On Fri, Jul 27, 2018 at 11:20:21AM -0500, Rob Landley wrote:
>> Speaking of DMA:
>
> Which really has nothing to do with the dma mapping code, which
> also means I can't help you much unfortunately.
>
> That being said sh is the last pending of the initial dma-noncoherent
> conversion, I'd greatly appreciate if we could get this reviewed and
> merge for the 4.19 merge window..

I've spent 30 minutes looking through your submission to find something
wrong with it now, but it all looks fine, the only criticism would be that
some of the changelogs could provide a little more background.

The original implementation seems odd in some places, but your
new version resolves the few concerns I had (like mixing up
phys and dma addresses), and I didn't see anything that should
change behavior.

I hope that helps.

  Arnd
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


  1   2   3   >