[EXT] Re: [PATCH v2 00/12] ACPI/OF: Upgrade MSI/IOMMU ID mapping APIs

Tue Jul 21 00:28:29 EDT 2020


> -----Original Message-----
> From: Lorenzo Pieralisi <lorenzo.pieralisi at arm.com>
> Sent: Monday, July 20, 2020 10:25 PM
> To: linux-arm-kernel at lists.infradead.org; Rob Herring <robh+dt at kernel.org>;
> Rafael J. Wysocki <rjw at rjwysocki.net>; Bjorn Helgaas <bhelgaas at google.com>;
> Catalin Marinas <catalin.marinas at arm.com>; Will Deacon <will at kernel.org>;
> joro at 8bytes.org
> Cc: Hanjun Guo <guohanjun at huawei.com>; Sudeep Holla
> <sudeep.holla at arm.com>; Robin Murphy <robin.murphy at arm.com>; Marc
> Zyngier <maz at kernel.org>; iommu at lists.linux-foundation.org; linux-
> acpi at vger.kernel.org; devicetree at vger.kernel.org; linux-pci at vger.kernel.org;
> Makarand Pawagi <makarand.pawagi at nxp.com>; Diana Madalina Craciun (OSS)
> <diana.craciun at oss.nxp.com>; Laurentiu Tudor <laurentiu.tudor at nxp.com>
> Subject: [EXT] Re: [PATCH v2 00/12] ACPI/OF: Upgrade MSI/IOMMU ID mapping
> APIs
> 
> Caution: EXT Email
> 
> On Fri, Jun 19, 2020 at 09:20:01AM +0100, Lorenzo Pieralisi wrote:
> > This series is a v2 of a previous posting:
> >
> > v1 -> v2
> >
> > - Removed _rid() wrappers
> > - Fixed !CONFIG_ACPI compilation issue
> > - Converted of_pci_iommu_init() to use of_iommu_configure_dev_id()
> >
> > v1:
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore
> > .kernel.org%2Flinux-arm-kernel%2F20200521130008.8266-1-lorenzo.pierali
> >
> si%40arm.com%2F&data=02%7C01%7Cmakarand.pawagi%40nxp.com%7C
> da7bade
> >
> c592846a1478808d82ccd9eb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C1%7
> >
> C637308608924853281&sdata=ZoP3e2Q5Ijkz%2FtsGfgu9MYkmKXSHQExs5
> J64Sb
> > h51YA%3D&reserved=0
> >
> > Original cover letter
> > ---------------------
> >
> > Firmware bindings provided in the ACPI IORT table[1] and device tree
> > bindings define rules to carry out input/output ID mappings - ie
> > retrieving an IOMMU/MSI controller input ID for a device with a given
> > ID.
> >
> > At the moment these firmware bindings are used exclusively for PCI
> > devices and their requester ID to IOMMU/MSI id mapping but there is
> > nothing PCI specific in the ACPI and devicetree bindings that prevent
> > the firmware and kernel from using the firmware bindings to traslate
> > device IDs for any bus that requires its devices to carry out
> > input/output id translations.
> >
> > The Freescale FSL bus is an example whereby the input/output ID
> > translation kernel code put in place for PCI can be reused for devices
> > attached to the bus that are not PCI devices.
> >
> > This series updates the kernel code to make the MSI/IOMMU input/output
> > ID translation PCI agnostic and apply the resulting changes to the
> > device ID space provided by the Freescale FSL bus.
> >
> > [1]
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Finfoc
> >
> enter.arm.com%2Fhelp%2Ftopic%2Fcom.arm.doc.den0049d%2FDEN0049D_IO_
> Rema
> >
> pping_Table.pdf&data=02%7C01%7Cmakarand.pawagi%40nxp.com%7Cda
> 7bade
> >
> c592846a1478808d82ccd9eb1%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%
> 7C1%7
> >
> C637308608924853281&sdata=RzpIo4AfAFsi2pdEuY%2FbnPAyase5cSmFIr5
> 2SX
> > aOrTg%3D&reserved=0
> >
> > Cc: Rob Herring <robh+dt at kernel.org>
> > Cc: "Rafael J. Wysocki" <rjw at rjwysocki.net>
> > Cc: "Joerg Roedel <joro at 8bytes.org>
> > Cc: Hanjun Guo <guohanjun at huawei.com>
> > Cc: Bjorn Helgaas <bhelgaas at google.com>
> > Cc: Sudeep Holla <sudeep.holla at arm.com>
> > Cc: Robin Murphy <robin.murphy at arm.com>
> > Cc: Catalin Marinas <catalin.marinas at arm.com>
> > Cc: Will Deacon <will at kernel.org>
> > Cc: Marc Zyngier <maz at kernel.org>
> >
> > Diana Craciun (2):
> >   of/irq: make of_msi_map_get_device_domain() bus agnostic
> >   bus/fsl-mc: Refactor the MSI domain creation in the DPRC driver
> >
> > Laurentiu Tudor (1):
> >   dt-bindings: arm: fsl: Add msi-map device-tree binding for fsl-mc
> > bus
> >
> > Lorenzo Pieralisi (8):
> >   ACPI/IORT: Make iort_match_node_callback walk the ACPI namespace for
> >     NC
> >   ACPI/IORT: Make iort_get_device_domain IRQ domain agnostic
> >   ACPI/IORT: Make iort_msi_map_rid() PCI agnostic
> >   ACPI/IORT: Remove useless PCI bus walk
> >   ACPI/IORT: Add an input ID to acpi_dma_configure()
> >   of/iommu: Make of_map_rid() PCI agnostic
> >   of/device: Add input id to of_dma_configure()
> >   of/irq: Make of_msi_map_rid() PCI bus agnostic
> >
> > Makarand Pawagi (1):
> >   bus: fsl-mc: Add ACPI support for fsl-mc
> >
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt |  50 +++++++-
> >  drivers/acpi/arm64/iort.c                     | 108 ++++++++++++------
> >  drivers/acpi/scan.c                           |   8 +-
> >  drivers/bus/fsl-mc/dprc-driver.c              |  31 ++---
> >  drivers/bus/fsl-mc/fsl-mc-bus.c               |  79 +++++++++----
> >  drivers/bus/fsl-mc/fsl-mc-msi.c               |  36 ++++--
> >  drivers/bus/fsl-mc/fsl-mc-private.h           |   6 +-
> >  drivers/iommu/of_iommu.c                      |  81 +++++++------
> >  drivers/irqchip/irq-gic-v3-its-fsl-mc-msi.c   | 105 ++++++++++++++---
> >  drivers/of/base.c                             |  42 +++----
> >  drivers/of/device.c                           |   8 +-
> >  drivers/of/irq.c                              |  34 +++---
> >  drivers/pci/msi.c                             |   9 +-
> >  include/acpi/acpi_bus.h                       |   9 +-
> >  include/linux/acpi.h                          |   7 ++
> >  include/linux/acpi_iort.h                     |  20 ++--
> >  include/linux/of.h                            |   4 +-
> >  include/linux/of_device.h                     |  16 ++-
> >  include/linux/of_iommu.h                      |   6 +-
> >  include/linux/of_irq.h                        |  13 ++-
> >  20 files changed, 451 insertions(+), 221 deletions(-)
> 
> Hi guys,
> 
> I think this series is ready for upstream (there are two ACKs missing from Rafael
> on patch (5) and Bjorn on patch (3) - I asked for them), it touches lots of
> subsystems so I am not really sure what's the best way to pull it, more so given
> that it is also late in the cycle (I do think it is best to merge it via a single tree, it
> does not make sense to split it up in my opinion).
> 
> Please let me know.
> 
Hi Lorenzo, I too find it suitable to merge it as a whole.
Hi Rafael, Bjorn, Can you finalize your review for patch-5 and patch-3? 


> Thanks,
> Lorenzo