[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3)
  - Adds the dma-mapping support for fsl-mc bus (patch 4,5)
  - Updates the fsl-mc device node with iommu/dma related changes

This patchset is based on staging-testing tree where fsl-mc bus is out
from staging

This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-parent device-tree binding
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: remove dma ops setup from driver
  dma-mapping: support fsl-mc bus
  dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |  6 ++++-
 drivers/base/dma-mapping.c                         |  7 +++++
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  5 +---
 drivers/iommu/arm-smmu.c                           |  7 +++++
 drivers/iommu/iommu.c                              | 21 +++++++++++++++
 drivers/iommu/of_iommu.c                           | 23 ++++++++++++++++
 include/linux/fsl/mc.h                             |  8 ++++++
 include/linux/iommu.h                              |  2 ++
 9 files changed, 105 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3)
  - Adds the dma-mapping support for fsl-mc bus (patch 4,5)
  - Updates the fsl-mc device node with iommu/dma related changes

This patchset is based on staging-testing tree where fsl-mc bus is out
from staging

This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-parent device-tree binding
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: remove dma ops setup from driver
  dma-mapping: support fsl-mc bus
  dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |  6 ++++-
 drivers/base/dma-mapping.c                         |  7 +++++
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  5 +---
 drivers/iommu/arm-smmu.c                           |  7 +++++
 drivers/iommu/iommu.c                              | 21 +++++++++++++++
 drivers/iommu/of_iommu.c                           | 23 ++++++++++++++++
 include/linux/fsl/mc.h                             |  8 ++++++
 include/linux/iommu.h                              |  2 ++
 9 files changed, 105 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 0/6] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

These patches
  - Define the new property 'iommu-parent' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3)
  - Adds the dma-mapping support for fsl-mc bus (patch 4,5)
  - Updates the fsl-mc device node with iommu/dma related changes

This patchset is based on staging-testing tree where fsl-mc bus is out
from staging

This patchset is dependent on patch https://patchwork.kernel.org/patch/10207507/;
otherwise DPAA2 Ethernet driver functionality will break.

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-parent device-tree binding
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: remove dma ops setup from driver
  dma-mapping: support fsl-mc bus
  dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |  6 ++++-
 drivers/base/dma-mapping.c                         |  7 +++++
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  5 +---
 drivers/iommu/arm-smmu.c                           |  7 +++++
 drivers/iommu/iommu.c                              | 21 +++++++++++++++
 drivers/iommu/of_iommu.c                           | 23 ++++++++++++++++
 include/linux/fsl/mc.h                             |  8 ++++++
 include/linux/iommu.h                              |  2 ++
 9 files changed, 105 insertions(+), 5 deletions(-)

-- 
1.9.1

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +106,27 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
 
 Example:
 
+        smmu: iommu@5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <1>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc@80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                iommu-parent = <&smmu>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +106,27 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
 
 Example:
 
+        smmu: iommu at 5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <1>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc at 80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                iommu-parent = <&smmu>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a binding for
mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..011c7d6 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is cannot be used to describe the relationship
+between fsl-mc and IOMMUs, so an iommu-parent property is used to define
+the same.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +106,27 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
+  The property specifies the IOMMU behind which the devices on
+  fsl-mc bus are residing.
 
 Example:
 
+        smmu: iommu@5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <1>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc@80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                iommu-parent = <&smmu>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 14:29, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Given that allowing "msi-parent" for #msi-cells > 1 is merely a 
backward-compatibility bodge full of hard-coded assumptions, why would 
we want to knowingly introduce a similarly unpleasant equivalent for 
IOMMUs? What's wrong with "iommu-map"?

> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>   .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
>   1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
>   such as network interfaces, crypto accelerator instances, L2 switches,
>   etc.
>   
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.

IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know 
they're currently documented under bindings/pci, but they're not really 
intended to be absolutely PCI-specific.

Robin.

> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.
> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>   Required properties:
>   
>       - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>                 Value type: <phandle>
>                 Definition: Specifies the phandle to the PHY device node associated
>                             with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.
>   
>   Example:
>   
> +        smmu: iommu@5000000 {
> +               compatible = "arm,mmu-500";
> +               #iommu-cells = <1>;
> +               stream-match-mask = <0x7C00>;
> +               ...
> +        };
> +
>           fsl_mc: fsl-mc@80c000000 {
>                   compatible = "fsl,qoriq-mc";
>                   reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
>                         <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
>                   msi-parent = <&its>;
> +                iommu-parent = <&smmu>;
>                   #address-cells = <3>;
>                   #size-cells = <1>;
>   
> 

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 14:29, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.

Given that allowing "msi-parent" for #msi-cells > 1 is merely a 
backward-compatibility bodge full of hard-coded assumptions, why would 
we want to knowingly introduce a similarly unpleasant equivalent for 
IOMMUs? What's wrong with "iommu-map"?

> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>   .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
>   1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
>   such as network interfaces, crypto accelerator instances, L2 switches,
>   etc.
>   
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.

IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know 
they're currently documented under bindings/pci, but they're not really 
intended to be absolutely PCI-specific.

Robin.

> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.
> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>   Required properties:
>   
>       - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>                 Value type: <phandle>
>                 Definition: Specifies the phandle to the PHY device node associated
>                             with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.
>   
>   Example:
>   
> +        smmu: iommu at 5000000 {
> +               compatible = "arm,mmu-500";
> +               #iommu-cells = <1>;
> +               stream-match-mask = <0x7C00>;
> +               ...
> +        };
> +
>           fsl_mc: fsl-mc at 80c000000 {
>                   compatible = "fsl,qoriq-mc";
>                   reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
>                         <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
>                   msi-parent = <&its>;
> +                iommu-parent = <&smmu>;
>                   #address-cells = <3>;
>                   #size-cells = <1>;
>   
> 

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Monday, March 05, 2018 20:23
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com;
> mark.rutland@arm.com; catalin.marinas@arm.com
> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de;
> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org;
> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 14:29, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> backward-compatibility bodge full of hard-coded assumptions, why would
> we want to knowingly introduce a similarly unpleasant equivalent for
> IOMMUs? What's wrong with "iommu-map"?

Hi Robin,

With 'msi-parent' the property is fixed up to have msi-map. In this case there is
no fixup required and simple 'iommu-parent' property can be used, with MC bus
itself providing the stream-id's (in the code execution via FW).

We can also use the iommu-map property similar to PCI, which will require u-boot
fixup. But then it leads to little bit complications of u-boot - kernel compatibility.

If you suggest we can re-use the iommu-map property. What is your opinion?

Thanks,
Nipun

> 
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >   such as network interfaces, crypto accelerator instances, L2 switches,
> >   etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> 
> IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
> they're currently documented under bindings/pci, but they're not really
> intended to be absolutely PCI-specific.
> 
> Robin.
> 
> > +The generic 'iommus' property is cannot be used to describe the relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >   Required properties:
> >
> >       - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                 Value type: <phandle>
> >                 Definition: Specifies the phandle to the PHY device node associated
> >                             with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> >
> >   Example:
> >
> > +        smmu: iommu@5000000 {
> > +               compatible = "arm,mmu-500";
> > +               #iommu-cells = <1>;
> > +               stream-match-mask = <0x7C00>;
> > +               ...
> > +        };
> > +
> >           fsl_mc: fsl-mc@80c000000 {
> >                   compatible = "fsl,qoriq-mc";
> >                   reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
> >                         <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> >                   msi-parent = <&its>;
> > +                iommu-parent = <&smmu>;
> >                   #address-cells = <3>;
> >                   #size-cells = <1>;
> >
> >

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Monday, March 05, 2018 20:23
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com;
> mark.rutland at arm.com; catalin.marinas at arm.com
> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de;
> m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org;
> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 14:29, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> backward-compatibility bodge full of hard-coded assumptions, why would
> we want to knowingly introduce a similarly unpleasant equivalent for
> IOMMUs? What's wrong with "iommu-map"?

Hi Robin,

With 'msi-parent' the property is fixed up to have msi-map. In this case there is
no fixup required and simple 'iommu-parent' property can be used, with MC bus
itself providing the stream-id's (in the code execution via FW).

We can also use the iommu-map property similar to PCI, which will require u-boot
fixup. But then it leads to little bit complications of u-boot - kernel compatibility.

If you suggest we can re-use the iommu-map property. What is your opinion?

Thanks,
Nipun

> 
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >   1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >   such as network interfaces, crypto accelerator instances, L2 switches,
> >   etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> 
> IOW, precisely the case for which "{msi,iommu}-map" exist. Yes, I know
> they're currently documented under bindings/pci, but they're not really
> intended to be absolutely PCI-specific.
> 
> Robin.
> 
> > +The generic 'iommus' property is cannot be used to describe the relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >   Required properties:
> >
> >       - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                 Value type: <phandle>
> >                 Definition: Specifies the phandle to the PHY device node associated
> >                             with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> >
> >   Example:
> >
> > +        smmu: iommu at 5000000 {
> > +               compatible = "arm,mmu-500";
> > +               #iommu-cells = <1>;
> > +               stream-match-mask = <0x7C00>;
> > +               ...
> > +        };
> > +
> >           fsl_mc: fsl-mc at 80c000000 {
> >                   compatible = "fsl,qoriq-mc";
> >                   reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
> >                         <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> >                   msi-parent = <&its>;
> > +                iommu-parent = <&smmu>;
> >                   #address-cells = <3>;
> >                   #size-cells = <1>;
> >
> >

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw
MTggMjA6MjMNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k
ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh
cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr
aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu
Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl
cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp
bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTQ6MjksIE5pcHVuIEd1cHRh
IHdyb3RlOg0KPiA+IFRoZSBleGlzdGluZyBJT01NVSBiaW5kaW5ncyBjYW5ub3QgYmUgdXNlZCB0
byBzcGVjaWZ5IHRoZSByZWxhdGlvbnNoaXANCj4gPiBiZXR3ZWVuIGZzbC1tYyBkZXZpY2VzIGFu
ZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4gbWFwcGluZyBmc2wt
bWMgZGV2aWNlcyB0byBJT01NVXMsIHVzaW5nIGEgbmV3IGlvbW11LXBhcmVudCBwcm9wZXJ0eS4N
Cj4gDQo+IEdpdmVuIHRoYXQgYWxsb3dpbmcgIm1zaS1wYXJlbnQiIGZvciAjbXNpLWNlbGxzID4g
MSBpcyBtZXJlbHkgYQ0KPiBiYWNrd2FyZC1jb21wYXRpYmlsaXR5IGJvZGdlIGZ1bGwgb2YgaGFy
ZC1jb2RlZCBhc3N1bXB0aW9ucywgd2h5IHdvdWxkDQo+IHdlIHdhbnQgdG8ga25vd2luZ2x5IGlu
dHJvZHVjZSBhIHNpbWlsYXJseSB1bnBsZWFzYW50IGVxdWl2YWxlbnQgZm9yDQo+IElPTU1Vcz8g
V2hhdCdzIHdyb25nIHdpdGggImlvbW11LW1hcCI/DQoNCkhpIFJvYmluLA0KDQpXaXRoICdtc2kt
cGFyZW50JyB0aGUgcHJvcGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlz
IGNhc2UgdGhlcmUgaXMNCm5vIGZpeHVwIHJlcXVpcmVkIGFuZCBzaW1wbGUgJ2lvbW11LXBhcmVu
dCcgcHJvcGVydHkgY2FuIGJlIHVzZWQsIHdpdGggTUMgYnVzDQppdHNlbGYgcHJvdmlkaW5nIHRo
ZSBzdHJlYW0taWQncyAoaW4gdGhlIGNvZGUgZXhlY3V0aW9uIHZpYSBGVykuDQoNCldlIGNhbiBh
bHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3aWxs
IHJlcXVpcmUgdS1ib290DQpmaXh1cC4gQnV0IHRoZW4gaXQgbGVhZHMgdG8gbGl0dGxlIGJpdCBj
b21wbGljYXRpb25zIG9mIHUtYm9vdCAtIGtlcm5lbCBjb21wYXRpYmlsaXR5Lg0KDQpJZiB5b3Ug
c3VnZ2VzdCB3ZSBjYW4gcmUtdXNlIHRoZSBpb21tdS1tYXAgcHJvcGVydHkuIFdoYXQgaXMgeW91
ciBvcGluaW9uPw0KDQpUaGFua3MsDQpOaXB1bg0KDQo+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IE5p
cHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgLi4uL2Rldmlj
ZXRyZWUvYmluZGluZ3MvbWlzYy9mc2wscW9yaXEtbWMudHh0ICAgICAgfCAzMQ0KPiArKysrKysr
KysrKysrKysrKysrKysrDQo+ID4gICAxIGZpbGUgY2hhbmdlZCwgMzEgaW5zZXJ0aW9ucygrKQ0K
PiA+DQo+ID4gZGlmZiAtLWdpdCBhL0RvY3VtZW50YXRpb24vZGV2aWNldHJlZS9iaW5kaW5ncy9t
aXNjL2ZzbCxxb3JpcS1tYy50eHQNCj4gYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGlu
Z3MvbWlzYy9mc2wscW9yaXEtbWMudHh0DQo+ID4gaW5kZXggNjYxMWE3Yy4uMDExYzdkNiAxMDA2
NDQNCj4gPiAtLS0gYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbWlzYy9mc2ws
cW9yaXEtbWMudHh0DQo+ID4gKysrIGIvRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2JpbmRpbmdz
L21pc2MvZnNsLHFvcmlxLW1jLnR4dA0KPiA+IEBAIC05LDYgKzksMjQgQEAgYmxvY2tzIHRoYXQg
Y2FuIGJlIHVzZWQgdG8gY3JlYXRlIGZ1bmN0aW9uYWwgaGFyZHdhcmUNCj4gb2JqZWN0cy9kZXZp
Y2VzDQo+ID4gICBzdWNoIGFzIG5ldHdvcmsgaW50ZXJmYWNlcywgY3J5cHRvIGFjY2VsZXJhdG9y
IGluc3RhbmNlcywgTDIgc3dpdGNoZXMsDQo+ID4gICBldGMuDQo+ID4NCj4gPiArRm9yIGFuIG92
ZXJ2aWV3IG9mIHRoZSBEUEFBMiBhcmNoaXRlY3R1cmUgYW5kIGZzbC1tYyBidXMgc2VlOg0KPiA+
ICtkcml2ZXJzL3N0YWdpbmcvZnNsLW1jL1JFQURNRS50eHQNCj4gPiArDQo+ID4gK0FzIGRlc2Ny
aWJlZCBpbiB0aGUgYWJvdmUgb3ZlcnZpZXcsIGFsbCBEUEFBMiBvYmplY3RzIGluIGEgRFBSQyBz
aGFyZSB0aGUNCj4gPiArc2FtZSBoYXJkd2FyZSAiaXNvbGF0aW9uIGNvbnRleHQiIGFuZCBhIDEw
LWJpdCB2YWx1ZSBjYWxsZWQgYW4gSUNJRA0KPiA+ICsoaXNvbGF0aW9uIGNvbnRleHQgaWQpIGlz
IGV4cHJlc3NlZCBieSB0aGUgaGFyZHdhcmUgdG8gaWRlbnRpZnkNCj4gPiArdGhlIHJlcXVlc3Rl
ci4NCj4gDQo+IElPVywgcHJlY2lzZWx5IHRoZSBjYXNlIGZvciB3aGljaCAie21zaSxpb21tdX0t
bWFwIiBleGlzdC4gWWVzLCBJIGtub3cNCj4gdGhleSdyZSBjdXJyZW50bHkgZG9jdW1lbnRlZCB1
bmRlciBiaW5kaW5ncy9wY2ksIGJ1dCB0aGV5J3JlIG5vdCByZWFsbHkNCj4gaW50ZW5kZWQgdG8g
YmUgYWJzb2x1dGVseSBQQ0ktc3BlY2lmaWMuDQo+IA0KPiBSb2Jpbi4NCj4gDQo+ID4gK1RoZSBn
ZW5lcmljICdpb21tdXMnIHByb3BlcnR5IGlzIGNhbm5vdCBiZSB1c2VkIHRvIGRlc2NyaWJlIHRo
ZSByZWxhdGlvbnNoaXANCj4gPiArYmV0d2VlbiBmc2wtbWMgYW5kIElPTU1Vcywgc28gYW4gaW9t
bXUtcGFyZW50IHByb3BlcnR5IGlzIHVzZWQgdG8gZGVmaW5lDQo+ID4gK3RoZSBzYW1lLg0KPiA+
ICsNCj4gPiArRm9yIGdlbmVyaWMgSU9NTVUgYmluZGluZ3MsIHNlZQ0KPiA+ICtEb2N1bWVudGF0
aW9uL2RldmljZXRyZWUvYmluZGluZ3MvaW9tbXUvaW9tbXUudHh0Lg0KPiA+ICsNCj4gPiArRm9y
IGFybS1zbW11IGJpbmRpbmcsIHNlZToNCj4gPiArRG9jdW1lbnRhdGlvbi9kZXZpY2V0cmVlL2Jp
bmRpbmdzL2lvbW11L2FybSxzbW11LnR4dC4NCj4gPiArDQo+ID4gICBSZXF1aXJlZCBwcm9wZXJ0
aWVzOg0KPiA+DQo+ID4gICAgICAgLSBjb21wYXRpYmxlDQo+ID4gQEAgLTg4LDE0ICsxMDYsMjcg
QEAgU3ViLW5vZGVzOg0KPiA+ICAgICAgICAgICAgICAgICBWYWx1ZSB0eXBlOiA8cGhhbmRsZT4N
Cj4gPiAgICAgICAgICAgICAgICAgRGVmaW5pdGlvbjogU3BlY2lmaWVzIHRoZSBwaGFuZGxlIHRv
IHRoZSBQSFkgZGV2aWNlIG5vZGUgYXNzb2NpYXRlZA0KPiA+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB3aXRoIHRoZSB0aGlzIGRwbWFjLg0KPiA+ICtPcHRpb25hbCBwcm9wZXJ0aWVzOg0K
PiA+ICsNCj4gPiArLSBpb21tdS1wYXJlbnQ6IE1hcHMgdGhlIGRldmljZXMgb24gZnNsLW1jIGJ1
cyB0byBhbiBJT01NVS4NCj4gPiArICBUaGUgcHJvcGVydHkgc3BlY2lmaWVzIHRoZSBJT01NVSBi
ZWhpbmQgd2hpY2ggdGhlIGRldmljZXMgb24NCj4gPiArICBmc2wtbWMgYnVzIGFyZSByZXNpZGlu
Zy4NCj4gPg0KPiA+ICAgRXhhbXBsZToNCj4gPg0KPiA+ICsgICAgICAgIHNtbXU6IGlvbW11QDUw
MDAwMDAgew0KPiA+ICsgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImFybSxtbXUtNTAwIjsN
Cj4gPiArICAgICAgICAgICAgICAgI2lvbW11LWNlbGxzID0gPDE+Ow0KPiA+ICsgICAgICAgICAg
ICAgICBzdHJlYW0tbWF0Y2gtbWFzayA9IDwweDdDMDA+Ow0KPiA+ICsgICAgICAgICAgICAgICAu
Li4NCj4gPiArICAgICAgICB9Ow0KPiA+ICsNCj4gPiAgICAgICAgICAgZnNsX21jOiBmc2wtbWNA
ODBjMDAwMDAwIHsNCj4gPiAgICAgICAgICAgICAgICAgICBjb21wYXRpYmxlID0gImZzbCxxb3Jp
cS1tYyI7DQo+ID4gICAgICAgICAgICAgICAgICAgcmVnID0gPDB4MDAwMDAwMDggMHgwYzAwMDAw
MCAwIDB4NDA+LCAgICAvKiBNQyBwb3J0YWwgYmFzZSAqLw0KPiA+ICAgICAgICAgICAgICAgICAg
ICAgICAgIDwweDAwMDAwMDAwIDB4MDgzNDAwMDAgMCAweDQwMDAwPjsgLyogTUMgY29udHJvbCBy
ZWcgKi8NCj4gPiAgICAgICAgICAgICAgICAgICBtc2ktcGFyZW50ID0gPCZpdHM+Ow0KPiA+ICsg
ICAgICAgICAgICAgICAgaW9tbXUtcGFyZW50ID0gPCZzbW11PjsNCj4gPiAgICAgICAgICAgICAg
ICAgICAjYWRkcmVzcy1jZWxscyA9IDwzPjsNCj4gPiAgICAgICAgICAgICAgICAgICAjc2l6ZS1j
ZWxscyA9IDwxPjsNCj4gPg0KPiA+DQo=

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 15:00, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy@arm.com]
>> Sent: Monday, March 05, 2018 20:23
>> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com;
>> mark.rutland@arm.com; catalin.marinas@arm.com
>> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de;
>> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org;
>> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-
>> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
>> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan
>> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
>> <laurentiu.tudor@nxp.com>
>> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
>>
>> On 05/03/18 14:29, Nipun Gupta wrote:
>>> The existing IOMMU bindings cannot be used to specify the relationship
>>> between fsl-mc devices and IOMMUs. This patch adds a binding for
>>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
>>
>> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
>> backward-compatibility bodge full of hard-coded assumptions, why would
>> we want to knowingly introduce a similarly unpleasant equivalent for
>> IOMMUs? What's wrong with "iommu-map"?
> 
> Hi Robin,
> 
> With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> no fixup required and simple 'iommu-parent' property can be used, with MC bus
> itself providing the stream-id's (in the code execution via FW).
> 
> We can also use the iommu-map property similar to PCI, which will require u-boot
> fixup. But then it leads to little bit complications of u-boot - kernel compatibility.

What needs fixing up? With a stream-map-mask in place to ignore the 
upper Stream ID bits, you just need:

	iommu-map = <0 &smmu 0 0x80>;

to say that the lower bits of the ICID value map directly to the lower 
bits of the Stream ID value - that's the same fixed property of the 
hardware that you're wanting to assume in iommu-parent.

> If you suggest we can re-use the iommu-map property. What is your opinion?

I think it makes a lot more sense to directly use the property which 
already exists, than to introduce a new one to merely assume one 
hard-coded value of the existing one. Extending msi-parent to msi-map 
was a case of "oops, it turns out we need more flexibility here"; for 
the case of iommu-map I can't imagine any justification for saying 
"oops, we need less flexibility here" (saving 9 whole bytes in the DT 
really is irrelevant).

Robin.

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 15:00, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Monday, March 05, 2018 20:23
>> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com;
>> mark.rutland at arm.com; catalin.marinas at arm.com
>> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de;
>> m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org;
>> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux-
>> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
>> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan
>> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
>> <laurentiu.tudor@nxp.com>
>> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
>>
>> On 05/03/18 14:29, Nipun Gupta wrote:
>>> The existing IOMMU bindings cannot be used to specify the relationship
>>> between fsl-mc devices and IOMMUs. This patch adds a binding for
>>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
>>
>> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
>> backward-compatibility bodge full of hard-coded assumptions, why would
>> we want to knowingly introduce a similarly unpleasant equivalent for
>> IOMMUs? What's wrong with "iommu-map"?
> 
> Hi Robin,
> 
> With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> no fixup required and simple 'iommu-parent' property can be used, with MC bus
> itself providing the stream-id's (in the code execution via FW).
> 
> We can also use the iommu-map property similar to PCI, which will require u-boot
> fixup. But then it leads to little bit complications of u-boot - kernel compatibility.

What needs fixing up? With a stream-map-mask in place to ignore the 
upper Stream ID bits, you just need:

	iommu-map = <0 &smmu 0 0x80>;

to say that the lower bits of the ICID value map directly to the lower 
bits of the Stream ID value - that's the same fixed property of the 
hardware that you're wanting to assume in iommu-parent.

> If you suggest we can re-use the iommu-map property. What is your opinion?

I think it makes a lot more sense to directly use the property which 
already exists, than to introduce a new one to merely assume one 
hard-coded value of the existing one. Extending msi-parent to msi-map 
was a case of "oops, it turns out we need more flexibility here"; for 
the case of iommu-map I can't imagine any justification for saying 
"oops, we need less flexibility here" (saving 9 whole bytes in the DT 
really is irrelevant).

Robin.

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Robin Murphy]

On 05/03/18 15:00, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org]
>> Sent: Monday, March 05, 2018 20:23
>> To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; will.deacon-5wv7dgnIgG8@public.gmane.org;
>> mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org
>> Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; hch-jcswGhMUV9g@public.gmane.org;
>> m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
>> Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; linux-
>> kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
>> kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; Bharat Bhushan
>> <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor
>> <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>
>> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
>>
>> On 05/03/18 14:29, Nipun Gupta wrote:
>>> The existing IOMMU bindings cannot be used to specify the relationship
>>> between fsl-mc devices and IOMMUs. This patch adds a binding for
>>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
>>
>> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
>> backward-compatibility bodge full of hard-coded assumptions, why would
>> we want to knowingly introduce a similarly unpleasant equivalent for
>> IOMMUs? What's wrong with "iommu-map"?
> 
> Hi Robin,
> 
> With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> no fixup required and simple 'iommu-parent' property can be used, with MC bus
> itself providing the stream-id's (in the code execution via FW).
> 
> We can also use the iommu-map property similar to PCI, which will require u-boot
> fixup. But then it leads to little bit complications of u-boot - kernel compatibility.

What needs fixing up? With a stream-map-mask in place to ignore the 
upper Stream ID bits, you just need:

	iommu-map = <0 &smmu 0 0x80>;

to say that the lower bits of the ICID value map directly to the lower 
bits of the Stream ID value - that's the same fixed property of the 
hardware that you're wanting to assume in iommu-parent.

> If you suggest we can re-use the iommu-map property. What is your opinion?

I think it makes a lot more sense to directly use the property which 
already exists, than to introduce a new one to merely assume one 
hard-coded value of the existing one. Extending msi-parent to msi-map 
was a case of "oops, it turns out we need more flexibility here"; for 
the case of iommu-map I can't imagine any justification for saying 
"oops, we need less flexibility here" (saving 9 whole bytes in the DT 
really is irrelevant).

Robin.

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Monday, March 05, 2018 21:07
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com;
> mark.rutland@arm.com; catalin.marinas@arm.com
> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de;
> m.szyprowski@samsung.com; gregkh@linuxfoundation.org; joro@8bytes.org;
> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-
> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 15:00, Nipun Gupta wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy@arm.com]
> >> Sent: Monday, March 05, 2018 20:23
> >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon@arm.com;
> >> mark.rutland@arm.com; catalin.marinas@arm.com
> >> Cc: iommu@lists.linux-foundation.org; robh+dt@kernel.org; hch@lst.de;
> >> m.szyprowski@samsung.com; gregkh@linuxfoundation.org;
> joro@8bytes.org;
> >> Leo Li <leoyang.li@nxp.com>; shawnguo@kernel.org; linux-
> >> kernel@vger.kernel.org; devicetree@vger.kernel.org; linux-arm-
> >> kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org; Bharat Bhushan
> >> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> >> <laurentiu.tudor@nxp.com>
> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree
> binding
> >>
> >> On 05/03/18 14:29, Nipun Gupta wrote:
> >>> The existing IOMMU bindings cannot be used to specify the relationship
> >>> between fsl-mc devices and IOMMUs. This patch adds a binding for
> >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >>
> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> >> backward-compatibility bodge full of hard-coded assumptions, why would
> >> we want to knowingly introduce a similarly unpleasant equivalent for
> >> IOMMUs? What's wrong with "iommu-map"?
> >
> > Hi Robin,
> >
> > With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> > no fixup required and simple 'iommu-parent' property can be used, with MC
> bus
> > itself providing the stream-id's (in the code execution via FW).
> >
> > We can also use the iommu-map property similar to PCI, which will require u-
> boot
> > fixup. But then it leads to little bit complications of u-boot - kernel
> compatibility.
> 
> What needs fixing up? With a stream-map-mask in place to ignore the
> upper Stream ID bits, you just need:
> 
> 	iommu-map = <0 &smmu 0 0x80>;
> 
> to say that the lower bits of the ICID value map directly to the lower
> bits of the Stream ID value - that's the same fixed property of the
> hardware that you're wanting to assume in iommu-parent.

Makes sense. I was going in a little bit wrong direction. Thanks for correcting.
I will send v2 patchset with iommu-map property.

Regards,
Nipun

> 
> > If you suggest we can re-use the iommu-map property. What is your opinion?
> 
> I think it makes a lot more sense to directly use the property which
> already exists, than to introduce a new one to merely assume one
> hard-coded value of the existing one. Extending msi-parent to msi-map
> was a case of "oops, it turns out we need more flexibility here"; for
> the case of iommu-map I can't imagine any justification for saying
> "oops, we need less flexibility here" (saving 9 whole bytes in the DT
> really is irrelevant).
> 
> Robin.

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Monday, March 05, 2018 21:07
> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com;
> mark.rutland at arm.com; catalin.marinas at arm.com
> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de;
> m.szyprowski at samsung.com; gregkh at linuxfoundation.org; joro at 8bytes.org;
> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux-
> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On 05/03/18 15:00, Nipun Gupta wrote:
> >
> >
> >> -----Original Message-----
> >> From: Robin Murphy [mailto:robin.murphy at arm.com]
> >> Sent: Monday, March 05, 2018 20:23
> >> To: Nipun Gupta <nipun.gupta@nxp.com>; will.deacon at arm.com;
> >> mark.rutland at arm.com; catalin.marinas at arm.com
> >> Cc: iommu at lists.linux-foundation.org; robh+dt at kernel.org; hch at lst.de;
> >> m.szyprowski at samsung.com; gregkh at linuxfoundation.org;
> joro at 8bytes.org;
> >> Leo Li <leoyang.li@nxp.com>; shawnguo at kernel.org; linux-
> >> kernel at vger.kernel.org; devicetree at vger.kernel.org; linux-arm-
> >> kernel at lists.infradead.org; linuxppc-dev at lists.ozlabs.org; Bharat Bhushan
> >> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
> >> <laurentiu.tudor@nxp.com>
> >> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree
> binding
> >>
> >> On 05/03/18 14:29, Nipun Gupta wrote:
> >>> The existing IOMMU bindings cannot be used to specify the relationship
> >>> between fsl-mc devices and IOMMUs. This patch adds a binding for
> >>> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >>
> >> Given that allowing "msi-parent" for #msi-cells > 1 is merely a
> >> backward-compatibility bodge full of hard-coded assumptions, why would
> >> we want to knowingly introduce a similarly unpleasant equivalent for
> >> IOMMUs? What's wrong with "iommu-map"?
> >
> > Hi Robin,
> >
> > With 'msi-parent' the property is fixed up to have msi-map. In this case there is
> > no fixup required and simple 'iommu-parent' property can be used, with MC
> bus
> > itself providing the stream-id's (in the code execution via FW).
> >
> > We can also use the iommu-map property similar to PCI, which will require u-
> boot
> > fixup. But then it leads to little bit complications of u-boot - kernel
> compatibility.
> 
> What needs fixing up? With a stream-map-mask in place to ignore the
> upper Stream ID bits, you just need:
> 
> 	iommu-map = <0 &smmu 0 0x80>;
> 
> to say that the lower bits of the ICID value map directly to the lower
> bits of the Stream ID value - that's the same fixed property of the
> hardware that you're wanting to assume in iommu-parent.

Makes sense. I was going in a little bit wrong direction. Thanks for correcting.
I will send v2 patchset with iommu-map property.

Regards,
Nipun

> 
> > If you suggest we can re-use the iommu-map property. What is your opinion?
> 
> I think it makes a lot more sense to directly use the property which
> already exists, than to introduce a new one to merely assume one
> hard-coded value of the existing one. Extending msi-parent to msi-map
> was a case of "oops, it turns out we need more flexibility here"; for
> the case of iommu-map I can't imagine any justification for saying
> "oops, we need less flexibility here" (saving 9 whole bytes in the DT
> really is irrelevant).
> 
> Robin.

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIw
MTggMjE6MDcNCj4gVG86IE5pcHVuIEd1cHRhIDxuaXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5k
ZWFjb25AYXJtLmNvbTsNCj4gbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bh
cm0uY29tDQo+IENjOiBpb21tdUBsaXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBr
ZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdr
aEBsaW51eGZvdW5kYXRpb24ub3JnOyBqb3JvQDhieXRlcy5vcmc7DQo+IExlbyBMaSA8bGVveWFu
Zy5saUBueHAuY29tPjsgc2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+IGtlcm5lbEB2Z2Vy
Lmtlcm5lbC5vcmc7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+IGtl
cm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsg
QmhhcmF0IEJodXNoYW4NCj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFp
bC5jb207IExhdXJlbnRpdSBUdWRvcg0KPiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUgYmluZGluZw0KPiANCj4gT24gMDUvMDMvMTggMTU6MDAsIE5pcHVuIEd1cHRh
IHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4g
RnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+ID4+IFNl
bnQ6IE1vbmRheSwgTWFyY2ggMDUsIDIwMTggMjA6MjMNCj4gPj4gVG86IE5pcHVuIEd1cHRhIDxu
aXB1bi5ndXB0YUBueHAuY29tPjsgd2lsbC5kZWFjb25AYXJtLmNvbTsNCj4gPj4gbWFyay5ydXRs
YW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0uY29tDQo+ID4+IENjOiBpb21tdUBsaXN0
cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgcm9iaCtkdEBrZXJuZWwub3JnOyBoY2hAbHN0LmRlOw0K
PiA+PiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IGdyZWdraEBsaW51eGZvdW5kYXRpb24ub3Jn
Ow0KPiBqb3JvQDhieXRlcy5vcmc7DQo+ID4+IExlbyBMaSA8bGVveWFuZy5saUBueHAuY29tPjsg
c2hhd25ndW9Aa2VybmVsLm9yZzsgbGludXgtDQo+ID4+IGtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1hcm0tDQo+ID4+IGtlcm5lbEBsaXN0
cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy1kZXZAbGlzdHMub3psYWJzLm9yZzsgQmhhcmF0IEJo
dXNoYW4NCj4gPj4gPGJoYXJhdC5iaHVzaGFuQG54cC5jb20+OyBzdHV5b2RlckBnbWFpbC5jb207
IExhdXJlbnRpdSBUdWRvcg0KPiA+PiA8bGF1cmVudGl1LnR1ZG9yQG54cC5jb20+DQo+ID4+IFN1
YmplY3Q6IFJlOiBbUEFUQ0ggMS82XSBEb2NzOiBkdDogYWRkIGZzbC1tYyBpb21tdS1wYXJlbnQg
ZGV2aWNlLXRyZWUNCj4gYmluZGluZw0KPiA+Pg0KPiA+PiBPbiAwNS8wMy8xOCAxNDoyOSwgTmlw
dW4gR3VwdGEgd3JvdGU6DQo+ID4+PiBUaGUgZXhpc3RpbmcgSU9NTVUgYmluZGluZ3MgY2Fubm90
IGJlIHVzZWQgdG8gc3BlY2lmeSB0aGUgcmVsYXRpb25zaGlwDQo+ID4+PiBiZXR3ZWVuIGZzbC1t
YyBkZXZpY2VzIGFuZCBJT01NVXMuIFRoaXMgcGF0Y2ggYWRkcyBhIGJpbmRpbmcgZm9yDQo+ID4+
PiBtYXBwaW5nIGZzbC1tYyBkZXZpY2VzIHRvIElPTU1VcywgdXNpbmcgYSBuZXcgaW9tbXUtcGFy
ZW50IHByb3BlcnR5Lg0KPiA+Pg0KPiA+PiBHaXZlbiB0aGF0IGFsbG93aW5nICJtc2ktcGFyZW50
IiBmb3IgI21zaS1jZWxscyA+IDEgaXMgbWVyZWx5IGENCj4gPj4gYmFja3dhcmQtY29tcGF0aWJp
bGl0eSBib2RnZSBmdWxsIG9mIGhhcmQtY29kZWQgYXNzdW1wdGlvbnMsIHdoeSB3b3VsZA0KPiA+
PiB3ZSB3YW50IHRvIGtub3dpbmdseSBpbnRyb2R1Y2UgYSBzaW1pbGFybHkgdW5wbGVhc2FudCBl
cXVpdmFsZW50IGZvcg0KPiA+PiBJT01NVXM/IFdoYXQncyB3cm9uZyB3aXRoICJpb21tdS1tYXAi
Pw0KPiA+DQo+ID4gSGkgUm9iaW4sDQo+ID4NCj4gPiBXaXRoICdtc2ktcGFyZW50JyB0aGUgcHJv
cGVydHkgaXMgZml4ZWQgdXAgdG8gaGF2ZSBtc2ktbWFwLiBJbiB0aGlzIGNhc2UgdGhlcmUgaXMN
Cj4gPiBubyBmaXh1cCByZXF1aXJlZCBhbmQgc2ltcGxlICdpb21tdS1wYXJlbnQnIHByb3BlcnR5
IGNhbiBiZSB1c2VkLCB3aXRoIE1DDQo+IGJ1cw0KPiA+IGl0c2VsZiBwcm92aWRpbmcgdGhlIHN0
cmVhbS1pZCdzIChpbiB0aGUgY29kZSBleGVjdXRpb24gdmlhIEZXKS4NCj4gPg0KPiA+IFdlIGNh
biBhbHNvIHVzZSB0aGUgaW9tbXUtbWFwIHByb3BlcnR5IHNpbWlsYXIgdG8gUENJLCB3aGljaCB3
aWxsIHJlcXVpcmUgdS0NCj4gYm9vdA0KPiA+IGZpeHVwLiBCdXQgdGhlbiBpdCBsZWFkcyB0byBs
aXR0bGUgYml0IGNvbXBsaWNhdGlvbnMgb2YgdS1ib290IC0ga2VybmVsDQo+IGNvbXBhdGliaWxp
dHkuDQo+IA0KPiBXaGF0IG5lZWRzIGZpeGluZyB1cD8gV2l0aCBhIHN0cmVhbS1tYXAtbWFzayBp
biBwbGFjZSB0byBpZ25vcmUgdGhlDQo+IHVwcGVyIFN0cmVhbSBJRCBiaXRzLCB5b3UganVzdCBu
ZWVkOg0KPiANCj4gCWlvbW11LW1hcCA9IDwwICZzbW11IDAgMHg4MD47DQo+IA0KPiB0byBzYXkg
dGhhdCB0aGUgbG93ZXIgYml0cyBvZiB0aGUgSUNJRCB2YWx1ZSBtYXAgZGlyZWN0bHkgdG8gdGhl
IGxvd2VyDQo+IGJpdHMgb2YgdGhlIFN0cmVhbSBJRCB2YWx1ZSAtIHRoYXQncyB0aGUgc2FtZSBm
aXhlZCBwcm9wZXJ0eSBvZiB0aGUNCj4gaGFyZHdhcmUgdGhhdCB5b3UncmUgd2FudGluZyB0byBh
c3N1bWUgaW4gaW9tbXUtcGFyZW50Lg0KDQpNYWtlcyBzZW5zZS4gSSB3YXMgZ29pbmcgaW4gYSBs
aXR0bGUgYml0IHdyb25nIGRpcmVjdGlvbi4gVGhhbmtzIGZvciBjb3JyZWN0aW5nLg0KSSB3aWxs
IHNlbmQgdjIgcGF0Y2hzZXQgd2l0aCBpb21tdS1tYXAgcHJvcGVydHkuDQoNClJlZ2FyZHMsDQpO
aXB1bg0KDQo+IA0KPiA+IElmIHlvdSBzdWdnZXN0IHdlIGNhbiByZS11c2UgdGhlIGlvbW11LW1h
cCBwcm9wZXJ0eS4gV2hhdCBpcyB5b3VyIG9waW5pb24/DQo+IA0KPiBJIHRoaW5rIGl0IG1ha2Vz
IGEgbG90IG1vcmUgc2Vuc2UgdG8gZGlyZWN0bHkgdXNlIHRoZSBwcm9wZXJ0eSB3aGljaA0KPiBh
bHJlYWR5IGV4aXN0cywgdGhhbiB0byBpbnRyb2R1Y2UgYSBuZXcgb25lIHRvIG1lcmVseSBhc3N1
bWUgb25lDQo+IGhhcmQtY29kZWQgdmFsdWUgb2YgdGhlIGV4aXN0aW5nIG9uZS4gRXh0ZW5kaW5n
IG1zaS1wYXJlbnQgdG8gbXNpLW1hcA0KPiB3YXMgYSBjYXNlIG9mICJvb3BzLCBpdCB0dXJucyBv
dXQgd2UgbmVlZCBtb3JlIGZsZXhpYmlsaXR5IGhlcmUiOyBmb3INCj4gdGhlIGNhc2Ugb2YgaW9t
bXUtbWFwIEkgY2FuJ3QgaW1hZ2luZSBhbnkganVzdGlmaWNhdGlvbiBmb3Igc2F5aW5nDQo+ICJv
b3BzLCB3ZSBuZWVkIGxlc3MgZmxleGliaWxpdHkgaGVyZSIgKHNhdmluZyA5IHdob2xlIGJ5dGVz
IGluIHRoZSBEVA0KPiByZWFsbHkgaXMgaXJyZWxldmFudCkuDQo+IA0KPiBSb2Jpbi4NCg==

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Rob Herring]

On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
>  such as network interfaces, crypto accelerator instances, L2 switches,
>  etc.
>  
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
> +
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.

Why not? It is just a link between 2 nodes.

> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>  Required properties:
>  
>      - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>                Value type: <phandle>
>                Definition: Specifies the phandle to the PHY device node associated
>                            with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.

If you want a generic property, this should be documented in the common 
binding.

Couldn't you have more than 1 IOMMU upstream of a MC?

>  
>  Example:
>  
> +        smmu: iommu@5000000 {
> +               compatible = "arm,mmu-500";
> +               #iommu-cells = <1>;
> +               stream-match-mask = <0x7C00>;
> +               ...
> +        };
> +
>          fsl_mc: fsl-mc@80c000000 {
>                  compatible = "fsl,qoriq-mc";
>                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
>                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
>                  msi-parent = <&its>;
> +                iommu-parent = <&smmu>;
>                  #address-cells = <3>;
>                  #size-cells = <1>;
>  
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Rob Herring]

On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
>  such as network interfaces, crypto accelerator instances, L2 switches,
>  etc.
>  
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
> +
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.

Why not? It is just a link between 2 nodes.

> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>  Required properties:
>  
>      - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>                Value type: <phandle>
>                Definition: Specifies the phandle to the PHY device node associated
>                            with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.

If you want a generic property, this should be documented in the common 
binding.

Couldn't you have more than 1 IOMMU upstream of a MC?

>  
>  Example:
>  
> +        smmu: iommu at 5000000 {
> +               compatible = "arm,mmu-500";
> +               #iommu-cells = <1>;
> +               stream-match-mask = <0x7C00>;
> +               ...
> +        };
> +
>          fsl_mc: fsl-mc at 80c000000 {
>                  compatible = "fsl,qoriq-mc";
>                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
>                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
>                  msi-parent = <&its>;
> +                iommu-parent = <&smmu>;
>                  #address-cells = <3>;
>                  #size-cells = <1>;
>  
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Rob Herring]

On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> The existing IOMMU bindings cannot be used to specify the relationship
> between fsl-mc devices and IOMMUs. This patch adds a binding for
> mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> ---
>  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31 ++++++++++++++++++++++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> index 6611a7c..011c7d6 100644
> --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware objects/devices
>  such as network interfaces, crypto accelerator instances, L2 switches,
>  etc.
>  
> +For an overview of the DPAA2 architecture and fsl-mc bus see:
> +drivers/staging/fsl-mc/README.txt
> +
> +As described in the above overview, all DPAA2 objects in a DPRC share the
> +same hardware "isolation context" and a 10-bit value called an ICID
> +(isolation context id) is expressed by the hardware to identify
> +the requester.
> +
> +The generic 'iommus' property is cannot be used to describe the relationship
> +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> +the same.

Why not? It is just a link between 2 nodes.

> +
> +For generic IOMMU bindings, see
> +Documentation/devicetree/bindings/iommu/iommu.txt.
> +
> +For arm-smmu binding, see:
> +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> +
>  Required properties:
>  
>      - compatible
> @@ -88,14 +106,27 @@ Sub-nodes:
>                Value type: <phandle>
>                Definition: Specifies the phandle to the PHY device node associated
>                            with the this dpmac.
> +Optional properties:
> +
> +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> +  The property specifies the IOMMU behind which the devices on
> +  fsl-mc bus are residing.

If you want a generic property, this should be documented in the common 
binding.

Couldn't you have more than 1 IOMMU upstream of a MC?

>  
>  Example:
>  
> +        smmu: iommu@5000000 {
> +               compatible = "arm,mmu-500";
> +               #iommu-cells = <1>;
> +               stream-match-mask = <0x7C00>;
> +               ...
> +        };
> +
>          fsl_mc: fsl-mc@80c000000 {
>                  compatible = "fsl,qoriq-mc";
>                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
>                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
>                  msi-parent = <&its>;
> +                iommu-parent = <&smmu>;
>                  #address-cells = <3>;
>                  #size-cells = <1>;
>  
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

Hi Rob,

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Thursday, March 08, 2018 4:10
> To: Nipun Gupta <nipun.gupta@nxp.com>
> Cc: will.deacon@arm.com; robin.murphy@arm.com; mark.rutland@arm.com;
> catalin.marinas@arm.com; devicetree@vger.kernel.org; stuyoder@gmail.com;
> Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh@linuxfoundation.org;
> joro@8bytes.org; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
> Leo Li <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org; Laurentiu
> Tudor <laurentiu.tudor@nxp.com>; shawnguo@kernel.org; hch@lst.de; linux-
> arm-kernel@lists.infradead.org; m.szyprowski@samsung.com
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >  such as network interfaces, crypto accelerator instances, L2 switches,
> >  etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is cannot be used to describe the relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> 
> Why not? It is just a link between 2 nodes.

We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device.
Once USB and other devices start to use IOMMU we will also need this iommu-cells.

When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation
reports warning about the mismatch.
In fsl-mc bus case we do not have any stream id associated with the bus.

As suggested by Robin, we can simply use the iommu-map property.

> 
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >  Required properties:
> >
> >      - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                Value type: <phandle>
> >                Definition: Specifies the phandle to the PHY device node associated
> >                            with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> 
> If you want a generic property, this should be documented in the common
> binding.

We can use the iommu-map property which is already documented.

> 
> Couldn't you have more than 1 IOMMU upstream of a MC?

There is no such device currently with which fsl-mc bus uses more than one iommu.
Infact, our current systems have only single IOMMU :).

Even in future if such devices are there then we can use iommu-map to specify
more than one iommu with separate requester ID's (RID's).

Thank you for review...

Regards,
Nipun

> 
> >
> >  Example:
> >
> > +        smmu: iommu@5000000 {
> > +               compatible = "arm,mmu-500";
> > +               #iommu-cells = <1>;
> > +               stream-match-mask = <0x7C00>;
> > +               ...
> > +        };
> > +
> >          fsl_mc: fsl-mc@80c000000 {
> >                  compatible = "fsl,qoriq-mc";
> >                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
> >                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> >                  msi-parent = <&its>;
> > +                iommu-parent = <&smmu>;
> >                  #address-cells = <3>;
> >                  #size-cells = <1>;
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a
> 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560
> 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI
> %3D&reserved=0

[PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

Hi Rob,

> -----Original Message-----
> From: Rob Herring [mailto:robh at kernel.org]
> Sent: Thursday, March 08, 2018 4:10
> To: Nipun Gupta <nipun.gupta@nxp.com>
> Cc: will.deacon at arm.com; robin.murphy at arm.com; mark.rutland at arm.com;
> catalin.marinas at arm.com; devicetree at vger.kernel.org; stuyoder at gmail.com;
> Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh at linuxfoundation.org;
> joro at 8bytes.org; linuxppc-dev at lists.ozlabs.org; linux-kernel at vger.kernel.org;
> Leo Li <leoyang.li@nxp.com>; iommu at lists.linux-foundation.org; Laurentiu
> Tudor <laurentiu.tudor@nxp.com>; shawnguo at kernel.org; hch at lst.de; linux-
> arm-kernel at lists.infradead.org; m.szyprowski at samsung.com
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >  such as network interfaces, crypto accelerator instances, L2 switches,
> >  etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is cannot be used to describe the relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> 
> Why not? It is just a link between 2 nodes.

We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device.
Once USB and other devices start to use IOMMU we will also need this iommu-cells.

When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation
reports warning about the mismatch.
In fsl-mc bus case we do not have any stream id associated with the bus.

As suggested by Robin, we can simply use the iommu-map property.

> 
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >  Required properties:
> >
> >      - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                Value type: <phandle>
> >                Definition: Specifies the phandle to the PHY device node associated
> >                            with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> 
> If you want a generic property, this should be documented in the common
> binding.

We can use the iommu-map property which is already documented.

> 
> Couldn't you have more than 1 IOMMU upstream of a MC?

There is no such device currently with which fsl-mc bus uses more than one iommu.
Infact, our current systems have only single IOMMU :).

Even in future if such devices are there then we can use iommu-map to specify
more than one iommu with separate requester ID's (RID's).

Thank you for review...

Regards,
Nipun

> 
> >
> >  Example:
> >
> > +        smmu: iommu at 5000000 {
> > +               compatible = "arm,mmu-500";
> > +               #iommu-cells = <1>;
> > +               stream-match-mask = <0x7C00>;
> > +               ...
> > +        };
> > +
> >          fsl_mc: fsl-mc at 80c000000 {
> >                  compatible = "fsl,qoriq-mc";
> >                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
> >                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> >                  msi-parent = <&its>;
> > +                iommu-parent = <&smmu>;
> >                  #address-cells = <3>;
> >                  #size-cells = <1>;
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a
> 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560
> 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI
> %3D&reserved=0

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

Hi Rob,

> -----Original Message-----
> From: Rob Herring [mailto:robh@kernel.org]
> Sent: Thursday, March 08, 2018 4:10
> To: Nipun Gupta <nipun.gupta@nxp.com>
> Cc: will.deacon@arm.com; robin.murphy@arm.com; mark.rutland@arm.com;
> catalin.marinas@arm.com; devicetree@vger.kernel.org; stuyoder@gmail.com;
> Bharat Bhushan <bharat.bhushan@nxp.com>; gregkh@linuxfoundation.org;
> joro@8bytes.org; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.=
org;
> Leo Li <leoyang.li@nxp.com>; iommu@lists.linux-foundation.org; Laurentiu
> Tudor <laurentiu.tudor@nxp.com>; shawnguo@kernel.org; hch@lst.de; linux-
> arm-kernel@lists.infradead.org; m.szyprowski@samsung.com
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree bi=
nding
>=20
> On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >  such as network interfaces, crypto accelerator instances, L2 switches,
> >  etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share =
the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is cannot be used to describe the relati=
onship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to defi=
ne
> > +the same.
>=20
> Why not? It is just a link between 2 nodes.

We have #iommu-cells as '1' i.e. iommu will have one stream ID configured f=
or a device.
Once USB and other devices start to use IOMMU we will also need this iommu-=
cells.

When #iommu-cells is defined as '1' and we have 'iommus=3D<&smmu>' compilat=
ion
reports warning about the mismatch.
In fsl-mc bus case we do not have any stream id associated with the bus.

As suggested by Robin, we can simply use the iommu-map property.

>=20
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >  Required properties:
> >
> >      - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                Value type: <phandle>
> >                Definition: Specifies the phandle to the PHY device node=
 associated
> >                            with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
>=20
> If you want a generic property, this should be documented in the common
> binding.

We can use the iommu-map property which is already documented.

>=20
> Couldn't you have more than 1 IOMMU upstream of a MC?

There is no such device currently with which fsl-mc bus uses more than one =
iommu.
Infact, our current systems have only single IOMMU :).

Even in future if such devices are there then we can use iommu-map to speci=
fy
more than one iommu with separate requester ID's (RID's).

Thank you for review...

Regards,
Nipun

>=20
> >
> >  Example:
> >
> > +        smmu: iommu@5000000 {
> > +               compatible =3D "arm,mmu-500";
> > +               #iommu-cells =3D <1>;
> > +               stream-match-mask =3D <0x7C00>;
> > +               ...
> > +        };
> > +
> >          fsl_mc: fsl-mc@80c000000 {
> >                  compatible =3D "fsl,qoriq-mc";
> >                  reg =3D <0x00000008 0x0c000000 0 0x40>,    /* MC porta=
l base */
> >                        <0x00000000 0x08340000 0 0x40000>; /* MC control=
 reg */
> >                  msi-parent =3D <&its>;
> > +                iommu-parent =3D <&smmu>;
> >                  #address-cells =3D <3>;
> >                  #size-cells =3D <1>;
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Flists=
.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=3D02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a
> 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560
> 592302736942&sdata=3DiOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI
> %3D&reserved=3D0

RE: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding

[Nipun Gupta]

Hi Rob,

> -----Original Message-----
> From: Rob Herring [mailto:robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Thursday, March 08, 2018 4:10
> To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org;
> catalin.marinas-5wv7dgnIgG8@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org;
> Bharat Bhushan <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org;
> joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Laurentiu
> Tudor <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; hch-jcswGhMUV9g@public.gmane.org; linux-
> arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org
> Subject: Re: [PATCH 1/6] Docs: dt: add fsl-mc iommu-parent device-tree binding
> 
> On Mon, Mar 05, 2018 at 07:59:21PM +0530, Nipun Gupta wrote:
> > The existing IOMMU bindings cannot be used to specify the relationship
> > between fsl-mc devices and IOMMUs. This patch adds a binding for
> > mapping fsl-mc devices to IOMMUs, using a new iommu-parent property.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> > ---
> >  .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 31
> ++++++++++++++++++++++
> >  1 file changed, 31 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > index 6611a7c..011c7d6 100644
> > --- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > +++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
> > @@ -9,6 +9,24 @@ blocks that can be used to create functional hardware
> objects/devices
> >  such as network interfaces, crypto accelerator instances, L2 switches,
> >  etc.
> >
> > +For an overview of the DPAA2 architecture and fsl-mc bus see:
> > +drivers/staging/fsl-mc/README.txt
> > +
> > +As described in the above overview, all DPAA2 objects in a DPRC share the
> > +same hardware "isolation context" and a 10-bit value called an ICID
> > +(isolation context id) is expressed by the hardware to identify
> > +the requester.
> > +
> > +The generic 'iommus' property is cannot be used to describe the relationship
> > +between fsl-mc and IOMMUs, so an iommu-parent property is used to define
> > +the same.
> 
> Why not? It is just a link between 2 nodes.

We have #iommu-cells as '1' i.e. iommu will have one stream ID configured for a device.
Once USB and other devices start to use IOMMU we will also need this iommu-cells.

When #iommu-cells is defined as '1' and we have 'iommus=<&smmu>' compilation
reports warning about the mismatch.
In fsl-mc bus case we do not have any stream id associated with the bus.

As suggested by Robin, we can simply use the iommu-map property.

> 
> > +
> > +For generic IOMMU bindings, see
> > +Documentation/devicetree/bindings/iommu/iommu.txt.
> > +
> > +For arm-smmu binding, see:
> > +Documentation/devicetree/bindings/iommu/arm,smmu.txt.
> > +
> >  Required properties:
> >
> >      - compatible
> > @@ -88,14 +106,27 @@ Sub-nodes:
> >                Value type: <phandle>
> >                Definition: Specifies the phandle to the PHY device node associated
> >                            with the this dpmac.
> > +Optional properties:
> > +
> > +- iommu-parent: Maps the devices on fsl-mc bus to an IOMMU.
> > +  The property specifies the IOMMU behind which the devices on
> > +  fsl-mc bus are residing.
> 
> If you want a generic property, this should be documented in the common
> binding.

We can use the iommu-map property which is already documented.

> 
> Couldn't you have more than 1 IOMMU upstream of a MC?

There is no such device currently with which fsl-mc bus uses more than one iommu.
Infact, our current systems have only single IOMMU :).

Even in future if such devices are there then we can use iommu-map to specify
more than one iommu with separate requester ID's (RID's).

Thank you for review...

Regards,
Nipun

> 
> >
> >  Example:
> >
> > +        smmu: iommu@5000000 {
> > +               compatible = "arm,mmu-500";
> > +               #iommu-cells = <1>;
> > +               stream-match-mask = <0x7C00>;
> > +               ...
> > +        };
> > +
> >          fsl_mc: fsl-mc@80c000000 {
> >                  compatible = "fsl,qoriq-mc";
> >                  reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
> >                        <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
> >                  msi-parent = <&its>;
> > +                iommu-parent = <&smmu>;
> >                  #address-cells = <3>;
> >                  #size-cells = <1>;
> >
> > --
> > 1.9.1
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infr
> adead.org%2Fmailman%2Flistinfo%2Flinux-arm-
> kernel&data=02%7C01%7Cnipun.gupta%40nxp.com%7Cf64b4fe9c5cf45ce8a9a
> 08d5847c6919%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636560
> 592302736942&sdata=iOwv%2Fzd8UTLm7YCapDOWzrtd48VQeYY2vlufck7eYZI
> %3D&reserved=0

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+		      struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec;
+	int err;
+
+	iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+	if (!iommu_spec.np)
+		return NO_IOMMU;
+
+	iommu_spec.args[0] = mc_dev->icid;
+	iommu_spec.args_count = 1;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+		      struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec;
+	int err;
+
+	iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+	if (!iommu_spec.np)
+		return NO_IOMMU;
+
+	iommu_spec.args[0] = mc_dev->icid;
+	iommu_spec.args_count = 1;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 2/6] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/iommu/of_iommu.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..cc2fb9c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -160,6 +161,26 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int
+of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+		      struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec;
+	int err;
+
+	iommu_spec.np = of_parse_phandle(master_np, "iommu-parent", 0);
+	if (!iommu_spec.np)
+		return NO_IOMMU;
+
+	iommu_spec.args[0] = mc_dev->icid;
+	iommu_spec.args_count = 1;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -191,6 +212,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 3/6] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index 765ba41..ae9382b 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

[Nipun Gupta]

The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

[Nipun Gupta]

The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

[PATCH 4/6] bus: fsl-mc: remove dma ops setup from driver

[Nipun Gupta]

The dma setup for fsl-mc devices is being done from device_add()
function. So, no need to call in mc bus driver.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 1b333c4..c9a239a 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -616,6 +616,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +634,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/base/dma-mapping.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
  * Common configuration to enable DMA API use for a device
  */
 #include <linux/pci.h>
+#include <linux/fsl/mc.h>
 
 int dma_configure(struct device *dev)
 {
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
 			dma_dev = dma_dev->parent;
 	}
 
+	if (dev_is_fsl_mc(dev)) {
+		dma_dev = dev;
+		while (dev_is_fsl_mc(dma_dev))
+			dma_dev = dma_dev->parent;
+	}
+
 	if (dma_dev->of_node) {
 		ret = of_dma_configure(dev, dma_dev->of_node);
 	} else if (has_acpi_companion(dma_dev)) {
-- 
1.9.1

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/base/dma-mapping.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
  * Common configuration to enable DMA API use for a device
  */
 #include <linux/pci.h>
+#include <linux/fsl/mc.h>
 
 int dma_configure(struct device *dev)
 {
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
 			dma_dev = dma_dev->parent;
 	}
 
+	if (dev_is_fsl_mc(dev)) {
+		dma_dev = dev;
+		while (dev_is_fsl_mc(dma_dev))
+			dma_dev = dma_dev->parent;
+	}
+
 	if (dma_dev->of_node) {
 		ret = of_dma_configure(dev, dma_dev->of_node);
 	} else if (has_acpi_companion(dma_dev)) {
-- 
1.9.1

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/base/dma-mapping.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 3b11835..2279c4d 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -334,6 +334,7 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
  * Common configuration to enable DMA API use for a device
  */
 #include <linux/pci.h>
+#include <linux/fsl/mc.h>
 
 int dma_configure(struct device *dev)
 {
@@ -349,6 +350,12 @@ int dma_configure(struct device *dev)
 			dma_dev = dma_dev->parent;
 	}
 
+	if (dev_is_fsl_mc(dev)) {
+		dma_dev = dev;
+		while (dev_is_fsl_mc(dma_dev))
+			dma_dev = dma_dev->parent;
+	}
+
 	if (dma_dev->of_node) {
 		ret = of_dma_configure(dev, dma_dev->of_node);
 	} else if (has_acpi_companion(dma_dev)) {
-- 
1.9.1

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

We should not add any new hardocded busses here.  Please mark them in
OF/ACPI.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

We should not add any new hardocded busses here.  Please mark them in
OF/ACPI.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 15:08, Christoph Hellwig wrote:
> We should not add any new hardocded busses here.  Please mark them in
> OF/ACPI.

Unfortunately for us, fsl-mc is conceptually rather like PCI in that 
it's software-discoverable and the only thing described in DT is the bus 
"host", thus we need the same sort of thing as for PCI to map from the 
child devices back to the bus root in order to find the appropriate 
firmware node. Worse than PCI, though, we wouldn't even have the option 
of describing child devices statically in firmware at all, since it's 
actually one of these runtime-configurable "build your own network 
accelerator" hardware pools where userspace gets to create and destroy 
"devices" as it likes.

Robin.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 15:08, Christoph Hellwig wrote:
> We should not add any new hardocded busses here.  Please mark them in
> OF/ACPI.

Unfortunately for us, fsl-mc is conceptually rather like PCI in that 
it's software-discoverable and the only thing described in DT is the bus 
"host", thus we need the same sort of thing as for PCI to map from the 
child devices back to the bus root in order to find the appropriate 
firmware node. Worse than PCI, though, we wouldn't even have the option 
of describing child devices statically in firmware at all, since it's 
actually one of these runtime-configurable "build your own network 
accelerator" hardware pools where userspace gets to create and destroy 
"devices" as it likes.

Robin.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 15:08, Christoph Hellwig wrote:
> We should not add any new hardocded busses here.  Please mark them in
> OF/ACPI.

Unfortunately for us, fsl-mc is conceptually rather like PCI in that 
it's software-discoverable and the only thing described in DT is the bus 
"host", thus we need the same sort of thing as for PCI to map from the 
child devices back to the bus root in order to find the appropriate 
firmware node. Worse than PCI, though, we wouldn't even have the option 
of describing child devices statically in firmware at all, since it's 
actually one of these runtime-configurable "build your own network 
accelerator" hardware pools where userspace gets to create and destroy 
"devices" as it likes.

Robin.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's 
> software-discoverable and the only thing described in DT is the bus "host", 
> thus we need the same sort of thing as for PCI to map from the child 
> devices back to the bus root in order to find the appropriate firmware 
> node. Worse than PCI, though, we wouldn't even have the option of 
> describing child devices statically in firmware at all, since it's actually 
> one of these runtime-configurable "build your own network accelerator" 
> hardware pools where userspace gets to create and destroy "devices" as it 
> likes.

I really hate the PCI special case just as much.  Maybe we just
need a dma_configure method on the bus, and move PCI as well as fsl-mc
to it.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's 
> software-discoverable and the only thing described in DT is the bus "host", 
> thus we need the same sort of thing as for PCI to map from the child 
> devices back to the bus root in order to find the appropriate firmware 
> node. Worse than PCI, though, we wouldn't even have the option of 
> describing child devices statically in firmware at all, since it's actually 
> one of these runtime-configurable "build your own network accelerator" 
> hardware pools where userspace gets to create and destroy "devices" as it 
> likes.

I really hate the PCI special case just as much.  Maybe we just
need a dma_configure method on the bus, and move PCI as well as fsl-mc
to it.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's 
> software-discoverable and the only thing described in DT is the bus "host", 
> thus we need the same sort of thing as for PCI to map from the child 
> devices back to the bus root in order to find the appropriate firmware 
> node. Worse than PCI, though, we wouldn't even have the option of 
> describing child devices statically in firmware at all, since it's actually 
> one of these runtime-configurable "build your own network accelerator" 
> hardware pools where userspace gets to create and destroy "devices" as it 
> likes.

I really hate the PCI special case just as much.  Maybe we just
need a dma_configure method on the bus, and move PCI as well as fsl-mc
to it.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 18:39, Christoph Hellwig wrote:
> On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
>> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
>> software-discoverable and the only thing described in DT is the bus "host",
>> thus we need the same sort of thing as for PCI to map from the child
>> devices back to the bus root in order to find the appropriate firmware
>> node. Worse than PCI, though, we wouldn't even have the option of
>> describing child devices statically in firmware at all, since it's actually
>> one of these runtime-configurable "build your own network accelerator"
>> hardware pools where userspace gets to create and destroy "devices" as it
>> likes.
> 
> I really hate the PCI special case just as much.  Maybe we just
> need a dma_configure method on the bus, and move PCI as well as fsl-mc
> to it.

Hmm, on reflection, 100% ack to that idea. It would neatly supersede 
bus->force_dma *and* mean that we don't have to effectively pull pci.h 
into everything, which I've never liked. In hindsight dma_configure() 
does feel like it's grown into this odd choke point where we munge 
everything in just for it to awkwardly unpick things again.

Robin.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 18:39, Christoph Hellwig wrote:
> On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
>> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
>> software-discoverable and the only thing described in DT is the bus "host",
>> thus we need the same sort of thing as for PCI to map from the child
>> devices back to the bus root in order to find the appropriate firmware
>> node. Worse than PCI, though, we wouldn't even have the option of
>> describing child devices statically in firmware at all, since it's actually
>> one of these runtime-configurable "build your own network accelerator"
>> hardware pools where userspace gets to create and destroy "devices" as it
>> likes.
> 
> I really hate the PCI special case just as much.  Maybe we just
> need a dma_configure method on the bus, and move PCI as well as fsl-mc
> to it.

Hmm, on reflection, 100% ack to that idea. It would neatly supersede 
bus->force_dma *and* mean that we don't have to effectively pull pci.h 
into everything, which I've never liked. In hindsight dma_configure() 
does feel like it's grown into this odd choke point where we munge 
everything in just for it to awkwardly unpick things again.

Robin.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 05/03/18 18:39, Christoph Hellwig wrote:
> On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
>> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
>> software-discoverable and the only thing described in DT is the bus "host",
>> thus we need the same sort of thing as for PCI to map from the child
>> devices back to the bus root in order to find the appropriate firmware
>> node. Worse than PCI, though, we wouldn't even have the option of
>> describing child devices statically in firmware at all, since it's actually
>> one of these runtime-configurable "build your own network accelerator"
>> hardware pools where userspace gets to create and destroy "devices" as it
>> likes.
> 
> I really hate the PCI special case just as much.  Maybe we just
> need a dma_configure method on the bus, and move PCI as well as fsl-mc
> to it.

Hmm, on reflection, 100% ack to that idea. It would neatly supersede 
bus->force_dma *and* mean that we don't have to effectively pull pci.h 
into everything, which I've never liked. In hindsight dma_configure() 
does feel like it's grown into this odd choke point where we munge 
everything in just for it to awkwardly unpick things again.

Robin.

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, March 06, 2018 0:22
> 
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> >> software-discoverable and the only thing described in DT is the bus "host",
> >> thus we need the same sort of thing as for PCI to map from the child
> >> devices back to the bus root in order to find the appropriate firmware
> >> node. Worse than PCI, though, we wouldn't even have the option of
> >> describing child devices statically in firmware at all, since it's actually
> >> one of these runtime-configurable "build your own network accelerator"
> >> hardware pools where userspace gets to create and destroy "devices" as it
> >> likes.
> >
> > I really hate the PCI special case just as much.  Maybe we just
> > need a dma_configure method on the bus, and move PCI as well as fsl-mc
> > to it.
> 
> Hmm, on reflection, 100% ack to that idea. It would neatly supersede
> bus->force_dma *and* mean that we don't have to effectively pull pci.h
> into everything, which I've never liked. In hindsight dma_configure()
> does feel like it's grown into this odd choke point where we munge
> everything in just for it to awkwardly unpick things again.
> 
> Robin.

+1 to the idea.

Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
will be required where the former one will return "dma_dev"?

Regards,
Nipun

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Tuesday, March 06, 2018 0:22
> 
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> >> software-discoverable and the only thing described in DT is the bus "host",
> >> thus we need the same sort of thing as for PCI to map from the child
> >> devices back to the bus root in order to find the appropriate firmware
> >> node. Worse than PCI, though, we wouldn't even have the option of
> >> describing child devices statically in firmware at all, since it's actually
> >> one of these runtime-configurable "build your own network accelerator"
> >> hardware pools where userspace gets to create and destroy "devices" as it
> >> likes.
> >
> > I really hate the PCI special case just as much.  Maybe we just
> > need a dma_configure method on the bus, and move PCI as well as fsl-mc
> > to it.
> 
> Hmm, on reflection, 100% ack to that idea. It would neatly supersede
> bus->force_dma *and* mean that we don't have to effectively pull pci.h
> into everything, which I've never liked. In hindsight dma_configure()
> does feel like it's grown into this odd choke point where we munge
> everything in just for it to awkwardly unpick things again.
> 
> Robin.

+1 to the idea.

Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
will be required where the former one will return "dma_dev"?

Regards,
Nipun

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

DQoNCj4gRnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+
IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDE4IDA6MjINCj4gDQo+IE9uIDA1LzAzLzE4IDE4
OjM5LCBDaHJpc3RvcGggSGVsbHdpZyB3cm90ZToNCj4gPiBPbiBNb24sIE1hciAwNSwgMjAxOCBh
dCAwMzo0ODozMlBNICswMDAwLCBSb2JpbiBNdXJwaHkgd3JvdGU6DQo+ID4+IFVuZm9ydHVuYXRl
bHkgZm9yIHVzLCBmc2wtbWMgaXMgY29uY2VwdHVhbGx5IHJhdGhlciBsaWtlIFBDSSBpbiB0aGF0
IGl0J3MNCj4gPj4gc29mdHdhcmUtZGlzY292ZXJhYmxlIGFuZCB0aGUgb25seSB0aGluZyBkZXNj
cmliZWQgaW4gRFQgaXMgdGhlIGJ1cyAiaG9zdCIsDQo+ID4+IHRodXMgd2UgbmVlZCB0aGUgc2Ft
ZSBzb3J0IG9mIHRoaW5nIGFzIGZvciBQQ0kgdG8gbWFwIGZyb20gdGhlIGNoaWxkDQo+ID4+IGRl
dmljZXMgYmFjayB0byB0aGUgYnVzIHJvb3QgaW4gb3JkZXIgdG8gZmluZCB0aGUgYXBwcm9wcmlh
dGUgZmlybXdhcmUNCj4gPj4gbm9kZS4gV29yc2UgdGhhbiBQQ0ksIHRob3VnaCwgd2Ugd291bGRu
J3QgZXZlbiBoYXZlIHRoZSBvcHRpb24gb2YNCj4gPj4gZGVzY3JpYmluZyBjaGlsZCBkZXZpY2Vz
IHN0YXRpY2FsbHkgaW4gZmlybXdhcmUgYXQgYWxsLCBzaW5jZSBpdCdzIGFjdHVhbGx5DQo+ID4+
IG9uZSBvZiB0aGVzZSBydW50aW1lLWNvbmZpZ3VyYWJsZSAiYnVpbGQgeW91ciBvd24gbmV0d29y
ayBhY2NlbGVyYXRvciINCj4gPj4gaGFyZHdhcmUgcG9vbHMgd2hlcmUgdXNlcnNwYWNlIGdldHMg
dG8gY3JlYXRlIGFuZCBkZXN0cm95ICJkZXZpY2VzIiBhcyBpdA0KPiA+PiBsaWtlcy4NCj4gPg0K
PiA+IEkgcmVhbGx5IGhhdGUgdGhlIFBDSSBzcGVjaWFsIGNhc2UganVzdCBhcyBtdWNoLiAgTWF5
YmUgd2UganVzdA0KPiA+IG5lZWQgYSBkbWFfY29uZmlndXJlIG1ldGhvZCBvbiB0aGUgYnVzLCBh
bmQgbW92ZSBQQ0kgYXMgd2VsbCBhcyBmc2wtbWMNCj4gPiB0byBpdC4NCj4gDQo+IEhtbSwgb24g
cmVmbGVjdGlvbiwgMTAwJSBhY2sgdG8gdGhhdCBpZGVhLiBJdCB3b3VsZCBuZWF0bHkgc3VwZXJz
ZWRlDQo+IGJ1cy0+Zm9yY2VfZG1hICphbmQqIG1lYW4gdGhhdCB3ZSBkb24ndCBoYXZlIHRvIGVm
ZmVjdGl2ZWx5IHB1bGwgcGNpLmgNCj4gaW50byBldmVyeXRoaW5nLCB3aGljaCBJJ3ZlIG5ldmVy
IGxpa2VkLiBJbiBoaW5kc2lnaHQgZG1hX2NvbmZpZ3VyZSgpDQo+IGRvZXMgZmVlbCBsaWtlIGl0
J3MgZ3Jvd24gaW50byB0aGlzIG9kZCBjaG9rZSBwb2ludCB3aGVyZSB3ZSBtdW5nZQ0KPiBldmVy
eXRoaW5nIGluIGp1c3QgZm9yIGl0IHRvIGF3a3dhcmRseSB1bnBpY2sgdGhpbmdzIGFnYWluLg0K
PiANCj4gUm9iaW4uDQoNCisxIHRvIHRoZSBpZGVhLg0KDQpTb3JyeSBmb3IgYXNraW5nIGEgdHJp
dmlhbCBxdWVzdGlvbiAtIGxvb2tpbmcgaW50byBkbWFfY29uZmlndXJlKCkgSSBzZWUgdGhhdA0K
UENJIGlzIHVzZWQgaW4gdGhlIHN0YXJ0IGFuZCB0aGUgZW5kIG9mIHRoZSBBUEkuDQpJbiB0aGUg
ZW5kIHBhcnQgcGNpX3B1dF9ob3N0X2JyaWRnZV9kZXZpY2UoKSBpcyBjYWxsZWQuDQpTbyBhcmUg
dHdvIGJ1cyBjYWxsYmFja3Mgc29tZXRoaW5nIGxpa2UgJ2RtYV9jb25maWdfc3RhcnQnICYgJ2Rt
YV9jb25maWdfZW5kJw0Kd2lsbCBiZSByZXF1aXJlZCB3aGVyZSB0aGUgZm9ybWVyIG9uZSB3aWxs
IHJldHVybiAiZG1hX2RldiI/DQoNClJlZ2FyZHMsDQpOaXB1bg0K

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, March 06, 2018 0:22
> 
> On 05/03/18 18:39, Christoph Hellwig wrote:
> > On Mon, Mar 05, 2018 at 03:48:32PM +0000, Robin Murphy wrote:
> >> Unfortunately for us, fsl-mc is conceptually rather like PCI in that it's
> >> software-discoverable and the only thing described in DT is the bus "host",
> >> thus we need the same sort of thing as for PCI to map from the child
> >> devices back to the bus root in order to find the appropriate firmware
> >> node. Worse than PCI, though, we wouldn't even have the option of
> >> describing child devices statically in firmware at all, since it's actually
> >> one of these runtime-configurable "build your own network accelerator"
> >> hardware pools where userspace gets to create and destroy "devices" as it
> >> likes.
> >
> > I really hate the PCI special case just as much.  Maybe we just
> > need a dma_configure method on the bus, and move PCI as well as fsl-mc
> > to it.
> 
> Hmm, on reflection, 100% ack to that idea. It would neatly supersede
> bus->force_dma *and* mean that we don't have to effectively pull pci.h
> into everything, which I've never liked. In hindsight dma_configure()
> does feel like it's grown into this odd choke point where we munge
> everything in just for it to awkwardly unpick things again.
> 
> Robin.

+1 to the idea.

Sorry for asking a trivial question - looking into dma_configure() I see that
PCI is used in the start and the end of the API.
In the end part pci_put_host_bridge_device() is called.
So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
will be required where the former one will return "dma_dev"?

Regards,
Nipun

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> Sorry for asking a trivial question - looking into dma_configure() I see that
> PCI is used in the start and the end of the API.
> In the end part pci_put_host_bridge_device() is called.
> So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
> will be required where the former one will return "dma_dev"?

I'd just use dma_configure as the callback.

Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.   For fsl-mc
I suspect only of_dma_configure is relevanet, so just call that directly.
If at some point we get enough busses with either OF or ACPI we could
create a helper called from ->dma_configure for that.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> Sorry for asking a trivial question - looking into dma_configure() I see that
> PCI is used in the start and the end of the API.
> In the end part pci_put_host_bridge_device() is called.
> So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
> will be required where the former one will return "dma_dev"?

I'd just use dma_configure as the callback.

Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.   For fsl-mc
I suspect only of_dma_configure is relevanet, so just call that directly.
If at some point we get enough busses with either OF or ACPI we could
create a helper called from ->dma_configure for that.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Christoph Hellwig]

On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> Sorry for asking a trivial question - looking into dma_configure() I see that
> PCI is used in the start and the end of the API.
> In the end part pci_put_host_bridge_device() is called.
> So are two bus callbacks something like 'dma_config_start' & 'dma_config_end'
> will be required where the former one will return "dma_dev"?

I'd just use dma_configure as the callback.

Currently the of_dma_configure and acpi_dma_configure are only used
for PCI anyway, as no one else sets a non-NULL dma dev.   For fsl-mc
I suspect only of_dma_configure is relevanet, so just call that directly.
If at some point we get enough busses with either OF or ACPI we could
create a helper called from ->dma_configure for that.

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@lst.de]
> Sent: Thursday, March 08, 2018 13:11
> 
> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> > Sorry for asking a trivial question - looking into dma_configure() I see that
> > PCI is used in the start and the end of the API.
> > In the end part pci_put_host_bridge_device() is called.
> > So are two bus callbacks something like 'dma_config_start' &
> 'dma_config_end'
> > will be required where the former one will return "dma_dev"?
> 
> I'd just use dma_configure as the callback.

This would be a decent stuff.

> 
> Currently the of_dma_configure and acpi_dma_configure are only used
> for PCI anyway, as no one else sets a non-NULL dma dev.

My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.

I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.

> For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly.
> If at some point we get enough busses with either OF or ACPI we could
> create a helper called from ->dma_configure for that.

Totally agree with this.

Thanks,
Nipun

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch at lst.de]
> Sent: Thursday, March 08, 2018 13:11
> 
> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> > Sorry for asking a trivial question - looking into dma_configure() I see that
> > PCI is used in the start and the end of the API.
> > In the end part pci_put_host_bridge_device() is called.
> > So are two bus callbacks something like 'dma_config_start' &
> 'dma_config_end'
> > will be required where the former one will return "dma_dev"?
> 
> I'd just use dma_configure as the callback.

This would be a decent stuff.

> 
> Currently the of_dma_configure and acpi_dma_configure are only used
> for PCI anyway, as no one else sets a non-NULL dma dev.

My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.

I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.

> For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly.
> If at some point we get enough busses with either OF or ACPI we could
> create a helper called from ->dma_configure for that.

Totally agree with this.

Thanks,
Nipun

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch@lst.de]
> Sent: Thursday, March 08, 2018 13:11
>=20
> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> > Sorry for asking a trivial question - looking into dma_configure() I se=
e that
> > PCI is used in the start and the end of the API.
> > In the end part pci_put_host_bridge_device() is called.
> > So are two bus callbacks something like 'dma_config_start' &
> 'dma_config_end'
> > will be required where the former one will return "dma_dev"?
>=20
> I'd just use dma_configure as the callback.

This would be a decent stuff.

>=20
> Currently the of_dma_configure and acpi_dma_configure are only used
> for PCI anyway, as no one else sets a non-NULL dma dev.

My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.

I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.

> For fsl-mc I suspect only of_dma_configure is relevanet, so just call tha=
t directly.
> If at some point we get enough busses with either OF or ACPI we could
> create a helper called from ->dma_configure for that.

Totally agree with this.

Thanks,
Nipun

RE: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Nipun Gupta]

> -----Original Message-----
> From: Christoph Hellwig [mailto:hch-jcswGhMUV9g@public.gmane.org]
> Sent: Thursday, March 08, 2018 13:11
> 
> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
> > Sorry for asking a trivial question - looking into dma_configure() I see that
> > PCI is used in the start and the end of the API.
> > In the end part pci_put_host_bridge_device() is called.
> > So are two bus callbacks something like 'dma_config_start' &
> 'dma_config_end'
> > will be required where the former one will return "dma_dev"?
> 
> I'd just use dma_configure as the callback.

This would be a decent stuff.

> 
> Currently the of_dma_configure and acpi_dma_configure are only used
> for PCI anyway, as no one else sets a non-NULL dma dev.

My understanding is that even the platform bus uses the of_dma_configure
and probably acpi_dma_configure too. So platform bus may also need the
callback implemented. Please correct me if my understanding is wrong.

I will submit the patch with 'dma_configure' callback implemented for
the busses shortly.

> For fsl-mc I suspect only of_dma_configure is relevanet, so just call that directly.
> If at some point we get enough busses with either OF or ACPI we could
> create a helper called from ->dma_configure for that.

Totally agree with this.

Thanks,
Nipun

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 09/03/18 18:29, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Christoph Hellwig [mailto:hch@lst.de]
>> Sent: Thursday, March 08, 2018 13:11
>>
>> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
>>> Sorry for asking a trivial question - looking into dma_configure() I see that
>>> PCI is used in the start and the end of the API.
>>> In the end part pci_put_host_bridge_device() is called.
>>> So are two bus callbacks something like 'dma_config_start' &
>> 'dma_config_end'
>>> will be required where the former one will return "dma_dev"?
>>
>> I'd just use dma_configure as the callback.
> 
> This would be a decent stuff.

Yes, the PCI version should end up looking a lot like the old 
pci_dma_configure() used to, before everything got pulled together.

>> Currently the of_dma_configure and acpi_dma_configure are only used
>> for PCI anyway, as no one else sets a non-NULL dma dev.
> 
> My understanding is that even the platform bus uses the of_dma_configure
> and probably acpi_dma_configure too. So platform bus may also need the
> callback implemented. Please correct me if my understanding is wrong.

Indeed, platform and AMBA will want an implementation to dispatch 
between {of,acpi}_dma_configre() per the current logic. Host1x doesn't 
seem to care about ACPI so probably wants its own just calling 
of_dma_configure().

> I will submit the patch with 'dma_configure' callback implemented for
> the busses shortly.

Cheers - I've been trying to find some time to take a look myself, but 
having something to review instead would certainly be easier :)

Robin.

[PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 09/03/18 18:29, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Christoph Hellwig [mailto:hch at lst.de]
>> Sent: Thursday, March 08, 2018 13:11
>>
>> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
>>> Sorry for asking a trivial question - looking into dma_configure() I see that
>>> PCI is used in the start and the end of the API.
>>> In the end part pci_put_host_bridge_device() is called.
>>> So are two bus callbacks something like 'dma_config_start' &
>> 'dma_config_end'
>>> will be required where the former one will return "dma_dev"?
>>
>> I'd just use dma_configure as the callback.
> 
> This would be a decent stuff.

Yes, the PCI version should end up looking a lot like the old 
pci_dma_configure() used to, before everything got pulled together.

>> Currently the of_dma_configure and acpi_dma_configure are only used
>> for PCI anyway, as no one else sets a non-NULL dma dev.
> 
> My understanding is that even the platform bus uses the of_dma_configure
> and probably acpi_dma_configure too. So platform bus may also need the
> callback implemented. Please correct me if my understanding is wrong.

Indeed, platform and AMBA will want an implementation to dispatch 
between {of,acpi}_dma_configre() per the current logic. Host1x doesn't 
seem to care about ACPI so probably wants its own just calling 
of_dma_configure().

> I will submit the patch with 'dma_configure' callback implemented for
> the busses shortly.

Cheers - I've been trying to find some time to take a look myself, but 
having something to review instead would certainly be easier :)

Robin.

Re: [PATCH 5/6] dma-mapping: support fsl-mc bus

[Robin Murphy]

On 09/03/18 18:29, Nipun Gupta wrote:
> 
> 
>> -----Original Message-----
>> From: Christoph Hellwig [mailto:hch-jcswGhMUV9g@public.gmane.org]
>> Sent: Thursday, March 08, 2018 13:11
>>
>> On Tue, Mar 06, 2018 at 04:41:56AM +0000, Nipun Gupta wrote:
>>> Sorry for asking a trivial question - looking into dma_configure() I see that
>>> PCI is used in the start and the end of the API.
>>> In the end part pci_put_host_bridge_device() is called.
>>> So are two bus callbacks something like 'dma_config_start' &
>> 'dma_config_end'
>>> will be required where the former one will return "dma_dev"?
>>
>> I'd just use dma_configure as the callback.
> 
> This would be a decent stuff.

Yes, the PCI version should end up looking a lot like the old 
pci_dma_configure() used to, before everything got pulled together.

>> Currently the of_dma_configure and acpi_dma_configure are only used
>> for PCI anyway, as no one else sets a non-NULL dma dev.
> 
> My understanding is that even the platform bus uses the of_dma_configure
> and probably acpi_dma_configure too. So platform bus may also need the
> callback implemented. Please correct me if my understanding is wrong.

Indeed, platform and AMBA will want an implementation to dispatch 
between {of,acpi}_dma_configre() per the current logic. Host1x doesn't 
seem to care about ACPI so probably wants its own just calling 
of_dma_configure().

> I will submit the patch with 'dma_configure' callback implemented for
> the busses shortly.

Cheers - I've been trying to find some time to take a look myself, but 
having something to review instead would certainly be easier :)

Robin.

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking@1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-parent = <&smmu>;
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			stream-match-mask = <0x7C00>;
+			dma-coherent;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi@2100000 {
-- 
1.9.1

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking at 1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-parent = <&smmu>;
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			stream-match-mask = <0x7C00>;
+			dma-coherent;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi at 2100000 {
-- 
1.9.1

[PATCH 6/6] dts: fsl-ls208x: updated DT with SMMU support for fsl-mc

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1f15492 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking@1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-parent = <&smmu>;
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			stream-match-mask = <0x7C00>;
+			dma-coherent;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi@2100000 {
-- 
1.9.1

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
    and make corresponding changes for dma configuration of devices on
    fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |  39 +++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  16 ++-
 drivers/iommu/arm-smmu.c                           |   7 ++
 drivers/iommu/iommu.c                              |  21 ++++
 drivers/iommu/of_iommu.c                           | 126 ++++++++++++++++++++-
 drivers/of/irq.c                                   |   6 +-
 drivers/pci/of.c                                   | 101 -----------------
 include/linux/fsl/mc.h                             |   8 ++
 include/linux/iommu.h                              |   2 +
 include/linux/of_iommu.h                           |  11 ++
 include/linux/of_pci.h                             |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
    and make corresponding changes for dma configuration of devices on
    fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |  39 +++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  16 ++-
 drivers/iommu/arm-smmu.c                           |   7 ++
 drivers/iommu/iommu.c                              |  21 ++++
 drivers/iommu/of_iommu.c                           | 126 ++++++++++++++++++++-
 drivers/of/irq.c                                   |   6 +-
 drivers/pci/of.c                                   | 101 -----------------
 include/linux/fsl/mc.h                             |   8 ++
 include/linux/iommu.h                              |   2 +
 include/linux/of_iommu.h                           |  11 ++
 include/linux/of_pci.h                             |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
    and make corresponding changes for dma configuration of devices on
    fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |  39 +++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  16 ++-
 drivers/iommu/arm-smmu.c                           |   7 ++
 drivers/iommu/iommu.c                              |  21 ++++
 drivers/iommu/of_iommu.c                           | 126 ++++++++++++++++++++-
 drivers/of/irq.c                                   |   6 +-
 drivers/pci/of.c                                   | 101 -----------------
 include/linux/fsl/mc.h                             |   8 ++
 include/linux/iommu.h                              |   2 +
 include/linux/of_iommu.h                           |  11 ++
 include/linux/of_pci.h                             |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 0/6 v2] Support for fsl-mc bus and its devices in SMMU

[Nipun Gupta]

This patchset defines IOMMU DT binding for fsl-mc bus and adds
support in SMMU for fsl-mc bus.

This patch series is dependent on patset:
https://patchwork.kernel.org/patch/10317337/

These patches
  - Define property 'iommu-map' for fsl-mc bus (patch 1)
  - Integrates the fsl-mc bus with the SMMU using this
    IOMMU binding (patch 2,3,4)
  - Adds the dma configuration support for fsl-mc bus (patch 5)
  - Updates the fsl-mc device node with iommu/dma related changes (patch6)

Nipun Gupta (6):
  Docs: dt: add fsl-mc iommu-map device-tree binding
  iommu: of: make of_pci_map_rid() available for other devices too
  iommu: support iommu configuration for fsl-mc devices
  iommu: arm-smmu: Add support for the fsl-mc bus
  bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus
  arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

Changes in v2:
  - use iommu-map property for fsl-mc bus
  - rebase over patchset https://patchwork.kernel.org/patch/10317337/
    and make corresponding changes for dma configuration of devices on
    fsl-mc bus

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      |  39 +++++++
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi     |   6 +-
 drivers/bus/fsl-mc/fsl-mc-bus.c                    |  16 ++-
 drivers/iommu/arm-smmu.c                           |   7 ++
 drivers/iommu/iommu.c                              |  21 ++++
 drivers/iommu/of_iommu.c                           | 126 ++++++++++++++++++++-
 drivers/of/irq.c                                   |   6 +-
 drivers/pci/of.c                                   | 101 -----------------
 include/linux/fsl/mc.h                             |   8 ++
 include/linux/iommu.h                              |   2 +
 include/linux/of_iommu.h                           |  11 ++
 include/linux/of_pci.h                             |  10 --
 12 files changed, 231 insertions(+), 122 deletions(-)

-- 
1.9.1

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+        smmu: iommu@5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <2>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc@80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                /* define map for ICIDs 23-64 */
+                iommu-map = <23 &smmu 23 41>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+        smmu: iommu at 5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <2>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc at 80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                /* define map for ICIDs 23-64 */
+                iommu-map = <23 &smmu 23 41>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+        smmu: iommu@5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <2>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc@80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                /* define map for ICIDs 23-64 */
+                iommu-map = <23 &smmu 23 41>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/6 v2] Docs: dt: add fsl-mc iommu-map device-tree binding

[Nipun Gupta]

The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt      | 39 ++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6611a7c..8cbed4f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -9,6 +9,25 @@ blocks that can be used to create functional hardware objects/devices
 such as network interfaces, crypto accelerator instances, L2 switches,
 etc.
 
+For an overview of the DPAA2 architecture and fsl-mc bus see:
+drivers/staging/fsl-mc/README.txt
+
+As described in the above overview, all DPAA2 objects in a DPRC share the
+same hardware "isolation context" and a 10-bit value called an ICID
+(isolation context id) is expressed by the hardware to identify
+the requester.
+
+The generic 'iommus' property is insufficient to describe the relationship
+between ICIDs and IOMMUs, so an iommu-map property is used to define
+the set of possible ICIDs under a root DPRC and how they map to
+an IOMMU.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+For arm-smmu binding, see:
+Documentation/devicetree/bindings/iommu/arm,smmu.txt.
+
 Required properties:
 
     - compatible
@@ -88,14 +107,34 @@ Sub-nodes:
               Value type: <phandle>
               Definition: Specifies the phandle to the PHY device node associated
                           with the this dpmac.
+Optional properties:
+
+- iommu-map: Maps an ICID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (icid-base,iommu,iommu-base,length).
+
+  Any ICID i in the interval [icid-base, icid-base + length) is
+  associated with the listed IOMMU, with the iommu-specifier
+  (i - icid-base + iommu-base).
 
 Example:
 
+        smmu: iommu@5000000 {
+               compatible = "arm,mmu-500";
+               #iommu-cells = <2>;
+               stream-match-mask = <0x7C00>;
+               ...
+        };
+
         fsl_mc: fsl-mc@80c000000 {
                 compatible = "fsl,qoriq-mc";
                 reg = <0x00000008 0x0c000000 0 0x40>,    /* MC portal base */
                       <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
                 msi-parent = <&its>;
+                /* define map for ICIDs 23-64 */
+                iommu-map = <23 &smmu 23 41>;
                 #address-cells = <3>;
                 #size-cells = <1>;
 
-- 
1.9.1

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--
 drivers/of/irq.c         |   6 +--
 drivers/pci/of.c         | 101 --------------------------------------------
 include/linux/of_iommu.h |  11 +++++
 include/linux/of_pci.h   |  10 -----
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
 	return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+		   const char *map_name, const char *map_mask_name,
+		   struct device_node **target, u32 *id_out)
+{
+	u32 map_mask, masked_rid;
+	int map_len;
+	const __be32 *map = NULL;
+
+	if (!np || !map_name || (!target && !id_out))
+		return -EINVAL;
+
+	map = of_get_property(np, map_name, &map_len);
+	if (!map) {
+		if (target)
+			return -ENODEV;
+		/* Otherwise, no map implies no translation */
+		*id_out = rid;
+		return 0;
+	}
+
+	if (!map_len || map_len % (4 * sizeof(*map))) {
+		pr_err("%pOF: Error: Bad %s length: %d\n", np,
+			map_name, map_len);
+		return -EINVAL;
+	}
+
+	/* The default is to select all bits. */
+	map_mask = 0xffffffff;
+
+	/*
+	 * Can be overridden by "{iommu,msi}-map-mask" property.
+	 */
+	if (map_mask_name)
+		of_property_read_u32(np, map_mask_name, &map_mask);
+
+	masked_rid = map_mask & rid;
+	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+		struct device_node *phandle_node;
+		u32 rid_base = be32_to_cpup(map + 0);
+		u32 phandle = be32_to_cpup(map + 1);
+		u32 out_base = be32_to_cpup(map + 2);
+		u32 rid_len = be32_to_cpup(map + 3);
+
+		if (rid_base & ~map_mask) {
+			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+				np, map_name, map_name,
+				map_mask, rid_base);
+			return -EFAULT;
+		}
+
+		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+			continue;
+
+		phandle_node = of_find_node_by_phandle(phandle);
+		if (!phandle_node)
+			return -ENODEV;
+
+		if (target) {
+			if (*target)
+				of_node_put(phandle_node);
+			else
+				*target = phandle_node;
+
+			if (*target != phandle_node)
+				continue;
+		}
+
+		if (id_out)
+			*id_out = masked_rid - rid_base + out_base;
+
+		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
+			np, map_name, map_mask, rid_base, out_base,
+			rid_len, rid, masked_rid - rid_base + out_base);
+		return 0;
+	}
+
+	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+		np, map_name, rid, target && *target ? *target : NULL);
+	return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
 	struct device *dev;
 	struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	struct of_phandle_args iommu_spec = { .args_count = 1 };
 	int err;
 
-	err = of_pci_map_rid(info->np, alias, "iommu-map",
-			     "iommu-map-mask", &iommu_spec.np,
-			     iommu_spec.args);
+	err = of_map_rid(info->np, alias, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
 	if (err)
 		return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 02ad93a..b72eeec 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -22,7 +22,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
-#include <linux/of_pci.h>
+#include <linux/of_iommu.h>
 #include <linux/string.h>
 #include <linux/slab.h>
 
@@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 	 * "msi-map" property.
 	 */
 	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
-		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
-				    "msi-map-mask", np, &rid_out))
+		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
+				"msi-map-mask", np, &rid_out))
 			break;
 	return rid_out;
 }
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c..d2cebbe 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 #endif /* CONFIG_OF_ADDRESS */
 
-/**
- * of_pci_map_rid - Translate a requester ID through a downstream mapping.
- * @np: root complex device node.
- * @rid: PCI requester ID to map.
- * @map_name: property name of the map to use.
- * @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
- *
- * Given a PCI requester ID, look up the appropriate implementation-defined
- * platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
- *
- * Return: 0 on success or a standard error code on failure.
- */
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out)
-{
-	u32 map_mask, masked_rid;
-	int map_len;
-	const __be32 *map = NULL;
-
-	if (!np || !map_name || (!target && !id_out))
-		return -EINVAL;
-
-	map = of_get_property(np, map_name, &map_len);
-	if (!map) {
-		if (target)
-			return -ENODEV;
-		/* Otherwise, no map implies no translation */
-		*id_out = rid;
-		return 0;
-	}
-
-	if (!map_len || map_len % (4 * sizeof(*map))) {
-		pr_err("%pOF: Error: Bad %s length: %d\n", np,
-			map_name, map_len);
-		return -EINVAL;
-	}
-
-	/* The default is to select all bits. */
-	map_mask = 0xffffffff;
-
-	/*
-	 * Can be overridden by "{iommu,msi}-map-mask" property.
-	 * If of_property_read_u32() fails, the default is used.
-	 */
-	if (map_mask_name)
-		of_property_read_u32(np, map_mask_name, &map_mask);
-
-	masked_rid = map_mask & rid;
-	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
-		struct device_node *phandle_node;
-		u32 rid_base = be32_to_cpup(map + 0);
-		u32 phandle = be32_to_cpup(map + 1);
-		u32 out_base = be32_to_cpup(map + 2);
-		u32 rid_len = be32_to_cpup(map + 3);
-
-		if (rid_base & ~map_mask) {
-			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
-				np, map_name, map_name,
-				map_mask, rid_base);
-			return -EFAULT;
-		}
-
-		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
-			continue;
-
-		phandle_node = of_find_node_by_phandle(phandle);
-		if (!phandle_node)
-			return -ENODEV;
-
-		if (target) {
-			if (*target)
-				of_node_put(phandle_node);
-			else
-				*target = phandle_node;
-
-			if (*target != phandle_node)
-				continue;
-		}
-
-		if (id_out)
-			*id_out = masked_rid - rid_base + out_base;
-
-		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
-			np, map_name, map_mask, rid_base, out_base,
-			rid_len, rid, masked_rid - rid_base + out_base);
-		return 0;
-	}
-
-	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
-		np, map_name, rid, target && *target ? *target : NULL);
-	return -EFAULT;
-}
-
 #if IS_ENABLED(CONFIG_OF_IRQ)
 /**
  * of_irq_parse_pci - Resolve the interrupt for a PCI device
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 4fa654e..432b53c 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
 extern const struct iommu_ops *of_iommu_configure(struct device *dev,
 					struct device_node *master_np);
 
+int of_map_rid(struct device_node *np, u32 rid,
+	       const char *map_name, const char *map_mask_name,
+	       struct device_node **target, u32 *id_out);
+
 #else
 
 static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
@@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
 	return NULL;
 }
 
+static inline int of_map_rid(struct device_node *np, u32 rid,
+			     const char *map_name, const char *map_mask_name,
+			     struct device_node **target, u32 *id_out)
+{
+	return -EINVAL;
+}
+
 #endif	/* CONFIG_OF_IOMMU */
 
 extern struct of_device_id __iommu_of_table;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a..a23b44a 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_get_pci_domain_nr(struct device_node *node);
 int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out);
 #else
 static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn)
@@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
 	return -1;
 }
 
-static inline int of_pci_map_rid(struct device_node *np, u32 rid,
-			const char *map_name, const char *map_mask_name,
-			struct device_node **target, u32 *id_out)
-{
-	return -EINVAL;
-}
-
 static inline int
 of_pci_get_max_link_speed(struct device_node *node)
 {
-- 
1.9.1

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--
 drivers/of/irq.c         |   6 +--
 drivers/pci/of.c         | 101 --------------------------------------------
 include/linux/of_iommu.h |  11 +++++
 include/linux/of_pci.h   |  10 -----
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
 	return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+		   const char *map_name, const char *map_mask_name,
+		   struct device_node **target, u32 *id_out)
+{
+	u32 map_mask, masked_rid;
+	int map_len;
+	const __be32 *map = NULL;
+
+	if (!np || !map_name || (!target && !id_out))
+		return -EINVAL;
+
+	map = of_get_property(np, map_name, &map_len);
+	if (!map) {
+		if (target)
+			return -ENODEV;
+		/* Otherwise, no map implies no translation */
+		*id_out = rid;
+		return 0;
+	}
+
+	if (!map_len || map_len % (4 * sizeof(*map))) {
+		pr_err("%pOF: Error: Bad %s length: %d\n", np,
+			map_name, map_len);
+		return -EINVAL;
+	}
+
+	/* The default is to select all bits. */
+	map_mask = 0xffffffff;
+
+	/*
+	 * Can be overridden by "{iommu,msi}-map-mask" property.
+	 */
+	if (map_mask_name)
+		of_property_read_u32(np, map_mask_name, &map_mask);
+
+	masked_rid = map_mask & rid;
+	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+		struct device_node *phandle_node;
+		u32 rid_base = be32_to_cpup(map + 0);
+		u32 phandle = be32_to_cpup(map + 1);
+		u32 out_base = be32_to_cpup(map + 2);
+		u32 rid_len = be32_to_cpup(map + 3);
+
+		if (rid_base & ~map_mask) {
+			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+				np, map_name, map_name,
+				map_mask, rid_base);
+			return -EFAULT;
+		}
+
+		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+			continue;
+
+		phandle_node = of_find_node_by_phandle(phandle);
+		if (!phandle_node)
+			return -ENODEV;
+
+		if (target) {
+			if (*target)
+				of_node_put(phandle_node);
+			else
+				*target = phandle_node;
+
+			if (*target != phandle_node)
+				continue;
+		}
+
+		if (id_out)
+			*id_out = masked_rid - rid_base + out_base;
+
+		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
+			np, map_name, map_mask, rid_base, out_base,
+			rid_len, rid, masked_rid - rid_base + out_base);
+		return 0;
+	}
+
+	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+		np, map_name, rid, target && *target ? *target : NULL);
+	return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
 	struct device *dev;
 	struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	struct of_phandle_args iommu_spec = { .args_count = 1 };
 	int err;
 
-	err = of_pci_map_rid(info->np, alias, "iommu-map",
-			     "iommu-map-mask", &iommu_spec.np,
-			     iommu_spec.args);
+	err = of_map_rid(info->np, alias, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
 	if (err)
 		return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 02ad93a..b72eeec 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -22,7 +22,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
-#include <linux/of_pci.h>
+#include <linux/of_iommu.h>
 #include <linux/string.h>
 #include <linux/slab.h>
 
@@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 	 * "msi-map" property.
 	 */
 	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
-		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
-				    "msi-map-mask", np, &rid_out))
+		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
+				"msi-map-mask", np, &rid_out))
 			break;
 	return rid_out;
 }
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c..d2cebbe 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 #endif /* CONFIG_OF_ADDRESS */
 
-/**
- * of_pci_map_rid - Translate a requester ID through a downstream mapping.
- * @np: root complex device node.
- * @rid: PCI requester ID to map.
- * @map_name: property name of the map to use.
- * @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
- *
- * Given a PCI requester ID, look up the appropriate implementation-defined
- * platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
- *
- * Return: 0 on success or a standard error code on failure.
- */
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out)
-{
-	u32 map_mask, masked_rid;
-	int map_len;
-	const __be32 *map = NULL;
-
-	if (!np || !map_name || (!target && !id_out))
-		return -EINVAL;
-
-	map = of_get_property(np, map_name, &map_len);
-	if (!map) {
-		if (target)
-			return -ENODEV;
-		/* Otherwise, no map implies no translation */
-		*id_out = rid;
-		return 0;
-	}
-
-	if (!map_len || map_len % (4 * sizeof(*map))) {
-		pr_err("%pOF: Error: Bad %s length: %d\n", np,
-			map_name, map_len);
-		return -EINVAL;
-	}
-
-	/* The default is to select all bits. */
-	map_mask = 0xffffffff;
-
-	/*
-	 * Can be overridden by "{iommu,msi}-map-mask" property.
-	 * If of_property_read_u32() fails, the default is used.
-	 */
-	if (map_mask_name)
-		of_property_read_u32(np, map_mask_name, &map_mask);
-
-	masked_rid = map_mask & rid;
-	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
-		struct device_node *phandle_node;
-		u32 rid_base = be32_to_cpup(map + 0);
-		u32 phandle = be32_to_cpup(map + 1);
-		u32 out_base = be32_to_cpup(map + 2);
-		u32 rid_len = be32_to_cpup(map + 3);
-
-		if (rid_base & ~map_mask) {
-			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
-				np, map_name, map_name,
-				map_mask, rid_base);
-			return -EFAULT;
-		}
-
-		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
-			continue;
-
-		phandle_node = of_find_node_by_phandle(phandle);
-		if (!phandle_node)
-			return -ENODEV;
-
-		if (target) {
-			if (*target)
-				of_node_put(phandle_node);
-			else
-				*target = phandle_node;
-
-			if (*target != phandle_node)
-				continue;
-		}
-
-		if (id_out)
-			*id_out = masked_rid - rid_base + out_base;
-
-		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
-			np, map_name, map_mask, rid_base, out_base,
-			rid_len, rid, masked_rid - rid_base + out_base);
-		return 0;
-	}
-
-	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
-		np, map_name, rid, target && *target ? *target : NULL);
-	return -EFAULT;
-}
-
 #if IS_ENABLED(CONFIG_OF_IRQ)
 /**
  * of_irq_parse_pci - Resolve the interrupt for a PCI device
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 4fa654e..432b53c 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
 extern const struct iommu_ops *of_iommu_configure(struct device *dev,
 					struct device_node *master_np);
 
+int of_map_rid(struct device_node *np, u32 rid,
+	       const char *map_name, const char *map_mask_name,
+	       struct device_node **target, u32 *id_out);
+
 #else
 
 static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
@@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
 	return NULL;
 }
 
+static inline int of_map_rid(struct device_node *np, u32 rid,
+			     const char *map_name, const char *map_mask_name,
+			     struct device_node **target, u32 *id_out)
+{
+	return -EINVAL;
+}
+
 #endif	/* CONFIG_OF_IOMMU */
 
 extern struct of_device_id __iommu_of_table;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a..a23b44a 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_get_pci_domain_nr(struct device_node *node);
 int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out);
 #else
 static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn)
@@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
 	return -1;
 }
 
-static inline int of_pci_map_rid(struct device_node *np, u32 rid,
-			const char *map_name, const char *map_mask_name,
-			struct device_node **target, u32 *id_out)
-{
-	return -EINVAL;
-}
-
 static inline int
 of_pci_get_max_link_speed(struct device_node *node)
 {
-- 
1.9.1

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--
 drivers/of/irq.c         |   6 +--
 drivers/pci/of.c         | 101 --------------------------------------------
 include/linux/of_iommu.h |  11 +++++
 include/linux/of_pci.h   |  10 -----
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
 	return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+		   const char *map_name, const char *map_mask_name,
+		   struct device_node **target, u32 *id_out)
+{
+	u32 map_mask, masked_rid;
+	int map_len;
+	const __be32 *map = NULL;
+
+	if (!np || !map_name || (!target && !id_out))
+		return -EINVAL;
+
+	map = of_get_property(np, map_name, &map_len);
+	if (!map) {
+		if (target)
+			return -ENODEV;
+		/* Otherwise, no map implies no translation */
+		*id_out = rid;
+		return 0;
+	}
+
+	if (!map_len || map_len % (4 * sizeof(*map))) {
+		pr_err("%pOF: Error: Bad %s length: %d\n", np,
+			map_name, map_len);
+		return -EINVAL;
+	}
+
+	/* The default is to select all bits. */
+	map_mask = 0xffffffff;
+
+	/*
+	 * Can be overridden by "{iommu,msi}-map-mask" property.
+	 */
+	if (map_mask_name)
+		of_property_read_u32(np, map_mask_name, &map_mask);
+
+	masked_rid = map_mask & rid;
+	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+		struct device_node *phandle_node;
+		u32 rid_base = be32_to_cpup(map + 0);
+		u32 phandle = be32_to_cpup(map + 1);
+		u32 out_base = be32_to_cpup(map + 2);
+		u32 rid_len = be32_to_cpup(map + 3);
+
+		if (rid_base & ~map_mask) {
+			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+				np, map_name, map_name,
+				map_mask, rid_base);
+			return -EFAULT;
+		}
+
+		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+			continue;
+
+		phandle_node = of_find_node_by_phandle(phandle);
+		if (!phandle_node)
+			return -ENODEV;
+
+		if (target) {
+			if (*target)
+				of_node_put(phandle_node);
+			else
+				*target = phandle_node;
+
+			if (*target != phandle_node)
+				continue;
+		}
+
+		if (id_out)
+			*id_out = masked_rid - rid_base + out_base;
+
+		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
+			np, map_name, map_mask, rid_base, out_base,
+			rid_len, rid, masked_rid - rid_base + out_base);
+		return 0;
+	}
+
+	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+		np, map_name, rid, target && *target ? *target : NULL);
+	return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
 	struct device *dev;
 	struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	struct of_phandle_args iommu_spec = { .args_count = 1 };
 	int err;
 
-	err = of_pci_map_rid(info->np, alias, "iommu-map",
-			     "iommu-map-mask", &iommu_spec.np,
-			     iommu_spec.args);
+	err = of_map_rid(info->np, alias, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
 	if (err)
 		return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 02ad93a..b72eeec 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -22,7 +22,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
-#include <linux/of_pci.h>
+#include <linux/of_iommu.h>
 #include <linux/string.h>
 #include <linux/slab.h>
 
@@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 	 * "msi-map" property.
 	 */
 	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
-		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
-				    "msi-map-mask", np, &rid_out))
+		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
+				"msi-map-mask", np, &rid_out))
 			break;
 	return rid_out;
 }
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c..d2cebbe 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 #endif /* CONFIG_OF_ADDRESS */
 
-/**
- * of_pci_map_rid - Translate a requester ID through a downstream mapping.
- * @np: root complex device node.
- * @rid: PCI requester ID to map.
- * @map_name: property name of the map to use.
- * @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
- *
- * Given a PCI requester ID, look up the appropriate implementation-defined
- * platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
- *
- * Return: 0 on success or a standard error code on failure.
- */
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out)
-{
-	u32 map_mask, masked_rid;
-	int map_len;
-	const __be32 *map = NULL;
-
-	if (!np || !map_name || (!target && !id_out))
-		return -EINVAL;
-
-	map = of_get_property(np, map_name, &map_len);
-	if (!map) {
-		if (target)
-			return -ENODEV;
-		/* Otherwise, no map implies no translation */
-		*id_out = rid;
-		return 0;
-	}
-
-	if (!map_len || map_len % (4 * sizeof(*map))) {
-		pr_err("%pOF: Error: Bad %s length: %d\n", np,
-			map_name, map_len);
-		return -EINVAL;
-	}
-
-	/* The default is to select all bits. */
-	map_mask = 0xffffffff;
-
-	/*
-	 * Can be overridden by "{iommu,msi}-map-mask" property.
-	 * If of_property_read_u32() fails, the default is used.
-	 */
-	if (map_mask_name)
-		of_property_read_u32(np, map_mask_name, &map_mask);
-
-	masked_rid = map_mask & rid;
-	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
-		struct device_node *phandle_node;
-		u32 rid_base = be32_to_cpup(map + 0);
-		u32 phandle = be32_to_cpup(map + 1);
-		u32 out_base = be32_to_cpup(map + 2);
-		u32 rid_len = be32_to_cpup(map + 3);
-
-		if (rid_base & ~map_mask) {
-			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
-				np, map_name, map_name,
-				map_mask, rid_base);
-			return -EFAULT;
-		}
-
-		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
-			continue;
-
-		phandle_node = of_find_node_by_phandle(phandle);
-		if (!phandle_node)
-			return -ENODEV;
-
-		if (target) {
-			if (*target)
-				of_node_put(phandle_node);
-			else
-				*target = phandle_node;
-
-			if (*target != phandle_node)
-				continue;
-		}
-
-		if (id_out)
-			*id_out = masked_rid - rid_base + out_base;
-
-		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
-			np, map_name, map_mask, rid_base, out_base,
-			rid_len, rid, masked_rid - rid_base + out_base);
-		return 0;
-	}
-
-	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
-		np, map_name, rid, target && *target ? *target : NULL);
-	return -EFAULT;
-}
-
 #if IS_ENABLED(CONFIG_OF_IRQ)
 /**
  * of_irq_parse_pci - Resolve the interrupt for a PCI device
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 4fa654e..432b53c 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
 extern const struct iommu_ops *of_iommu_configure(struct device *dev,
 					struct device_node *master_np);
 
+int of_map_rid(struct device_node *np, u32 rid,
+	       const char *map_name, const char *map_mask_name,
+	       struct device_node **target, u32 *id_out);
+
 #else
 
 static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
@@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
 	return NULL;
 }
 
+static inline int of_map_rid(struct device_node *np, u32 rid,
+			     const char *map_name, const char *map_mask_name,
+			     struct device_node **target, u32 *id_out)
+{
+	return -EINVAL;
+}
+
 #endif	/* CONFIG_OF_IOMMU */
 
 extern struct of_device_id __iommu_of_table;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a..a23b44a 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_get_pci_domain_nr(struct device_node *node);
 int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out);
 #else
 static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn)
@@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
 	return -1;
 }
 
-static inline int of_pci_map_rid(struct device_node *np, u32 rid,
-			const char *map_name, const char *map_mask_name,
-			struct device_node **target, u32 *id_out)
-{
-	return -EINVAL;
-}
-
 static inline int
 of_pci_get_max_link_speed(struct device_node *node)
 {
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

iommu-map property is also used by devices with fsl-mc. This
patch moves the of_pci_map_rid to generic location, so that it
can be used by other busses too.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--
 drivers/of/irq.c         |   6 +--
 drivers/pci/of.c         | 101 --------------------------------------------
 include/linux/of_iommu.h |  11 +++++
 include/linux/of_pci.h   |  10 -----
 5 files changed, 117 insertions(+), 117 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 5c36a8b..4e7712f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
 	return ops->of_xlate(dev, iommu_spec);
 }
 
+/**
+ * of_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @rid: device requester ID to map.
+ * @map_name: property name of the map to use.
+ * @map_mask_name: optional property name of the mask to use.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Given a device requester ID, look up the appropriate implementation-defined
+ * platform ID and/or the target device which receives transactions on that
+ * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
+ * @id_out may be NULL if only the other is required. If @target points to
+ * a non-NULL device node pointer, only entries targeting that node will be
+ * matched; if it points to a NULL value, it will receive the device node of
+ * the first matching target phandle, with a reference held.
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_rid(struct device_node *np, u32 rid,
+		   const char *map_name, const char *map_mask_name,
+		   struct device_node **target, u32 *id_out)
+{
+	u32 map_mask, masked_rid;
+	int map_len;
+	const __be32 *map = NULL;
+
+	if (!np || !map_name || (!target && !id_out))
+		return -EINVAL;
+
+	map = of_get_property(np, map_name, &map_len);
+	if (!map) {
+		if (target)
+			return -ENODEV;
+		/* Otherwise, no map implies no translation */
+		*id_out = rid;
+		return 0;
+	}
+
+	if (!map_len || map_len % (4 * sizeof(*map))) {
+		pr_err("%pOF: Error: Bad %s length: %d\n", np,
+			map_name, map_len);
+		return -EINVAL;
+	}
+
+	/* The default is to select all bits. */
+	map_mask = 0xffffffff;
+
+	/*
+	 * Can be overridden by "{iommu,msi}-map-mask" property.
+	 */
+	if (map_mask_name)
+		of_property_read_u32(np, map_mask_name, &map_mask);
+
+	masked_rid = map_mask & rid;
+	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+		struct device_node *phandle_node;
+		u32 rid_base = be32_to_cpup(map + 0);
+		u32 phandle = be32_to_cpup(map + 1);
+		u32 out_base = be32_to_cpup(map + 2);
+		u32 rid_len = be32_to_cpup(map + 3);
+
+		if (rid_base & ~map_mask) {
+			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
+				np, map_name, map_name,
+				map_mask, rid_base);
+			return -EFAULT;
+		}
+
+		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
+			continue;
+
+		phandle_node = of_find_node_by_phandle(phandle);
+		if (!phandle_node)
+			return -ENODEV;
+
+		if (target) {
+			if (*target)
+				of_node_put(phandle_node);
+			else
+				*target = phandle_node;
+
+			if (*target != phandle_node)
+				continue;
+		}
+
+		if (id_out)
+			*id_out = masked_rid - rid_base + out_base;
+
+		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
+			np, map_name, map_mask, rid_base, out_base,
+			rid_len, rid, masked_rid - rid_base + out_base);
+		return 0;
+	}
+
+	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
+		np, map_name, rid, target && *target ? *target : NULL);
+	return -EFAULT;
+}
+
 struct of_pci_iommu_alias_info {
 	struct device *dev;
 	struct device_node *np;
@@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	struct of_phandle_args iommu_spec = { .args_count = 1 };
 	int err;
 
-	err = of_pci_map_rid(info->np, alias, "iommu-map",
-			     "iommu-map-mask", &iommu_spec.np,
-			     iommu_spec.args);
+	err = of_map_rid(info->np, alias, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
 	if (err)
 		return err == -ENODEV ? NO_IOMMU : err;
 
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 02ad93a..b72eeec 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -22,7 +22,7 @@
 #include <linux/module.h>
 #include <linux/of.h>
 #include <linux/of_irq.h>
-#include <linux/of_pci.h>
+#include <linux/of_iommu.h>
 #include <linux/string.h>
 #include <linux/slab.h>
 
@@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
 	 * "msi-map" property.
 	 */
 	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
-		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
-				    "msi-map-mask", np, &rid_out))
+		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
+				"msi-map-mask", np, &rid_out))
 			break;
 	return rid_out;
 }
diff --git a/drivers/pci/of.c b/drivers/pci/of.c
index a28355c..d2cebbe 100644
--- a/drivers/pci/of.c
+++ b/drivers/pci/of.c
@@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
 EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
 #endif /* CONFIG_OF_ADDRESS */
 
-/**
- * of_pci_map_rid - Translate a requester ID through a downstream mapping.
- * @np: root complex device node.
- * @rid: PCI requester ID to map.
- * @map_name: property name of the map to use.
- * @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
- *
- * Given a PCI requester ID, look up the appropriate implementation-defined
- * platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
- *
- * Return: 0 on success or a standard error code on failure.
- */
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out)
-{
-	u32 map_mask, masked_rid;
-	int map_len;
-	const __be32 *map = NULL;
-
-	if (!np || !map_name || (!target && !id_out))
-		return -EINVAL;
-
-	map = of_get_property(np, map_name, &map_len);
-	if (!map) {
-		if (target)
-			return -ENODEV;
-		/* Otherwise, no map implies no translation */
-		*id_out = rid;
-		return 0;
-	}
-
-	if (!map_len || map_len % (4 * sizeof(*map))) {
-		pr_err("%pOF: Error: Bad %s length: %d\n", np,
-			map_name, map_len);
-		return -EINVAL;
-	}
-
-	/* The default is to select all bits. */
-	map_mask = 0xffffffff;
-
-	/*
-	 * Can be overridden by "{iommu,msi}-map-mask" property.
-	 * If of_property_read_u32() fails, the default is used.
-	 */
-	if (map_mask_name)
-		of_property_read_u32(np, map_mask_name, &map_mask);
-
-	masked_rid = map_mask & rid;
-	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
-		struct device_node *phandle_node;
-		u32 rid_base = be32_to_cpup(map + 0);
-		u32 phandle = be32_to_cpup(map + 1);
-		u32 out_base = be32_to_cpup(map + 2);
-		u32 rid_len = be32_to_cpup(map + 3);
-
-		if (rid_base & ~map_mask) {
-			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
-				np, map_name, map_name,
-				map_mask, rid_base);
-			return -EFAULT;
-		}
-
-		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
-			continue;
-
-		phandle_node = of_find_node_by_phandle(phandle);
-		if (!phandle_node)
-			return -ENODEV;
-
-		if (target) {
-			if (*target)
-				of_node_put(phandle_node);
-			else
-				*target = phandle_node;
-
-			if (*target != phandle_node)
-				continue;
-		}
-
-		if (id_out)
-			*id_out = masked_rid - rid_base + out_base;
-
-		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
-			np, map_name, map_mask, rid_base, out_base,
-			rid_len, rid, masked_rid - rid_base + out_base);
-		return 0;
-	}
-
-	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
-		np, map_name, rid, target && *target ? *target : NULL);
-	return -EFAULT;
-}
-
 #if IS_ENABLED(CONFIG_OF_IRQ)
 /**
  * of_irq_parse_pci - Resolve the interrupt for a PCI device
diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
index 4fa654e..432b53c 100644
--- a/include/linux/of_iommu.h
+++ b/include/linux/of_iommu.h
@@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
 extern const struct iommu_ops *of_iommu_configure(struct device *dev,
 					struct device_node *master_np);
 
+int of_map_rid(struct device_node *np, u32 rid,
+	       const char *map_name, const char *map_mask_name,
+	       struct device_node **target, u32 *id_out);
+
 #else
 
 static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
@@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
 	return NULL;
 }
 
+static inline int of_map_rid(struct device_node *np, u32 rid,
+			     const char *map_name, const char *map_mask_name,
+			     struct device_node **target, u32 *id_out)
+{
+	return -EINVAL;
+}
+
 #endif	/* CONFIG_OF_IOMMU */
 
 extern struct of_device_id __iommu_of_table;
diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
index 091033a..a23b44a 100644
--- a/include/linux/of_pci.h
+++ b/include/linux/of_pci.h
@@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
 int of_get_pci_domain_nr(struct device_node *node);
 int of_pci_get_max_link_speed(struct device_node *node);
 void of_pci_check_probe_only(void);
-int of_pci_map_rid(struct device_node *np, u32 rid,
-		   const char *map_name, const char *map_mask_name,
-		   struct device_node **target, u32 *id_out);
 #else
 static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
 					     unsigned int devfn)
@@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
 	return -1;
 }
 
-static inline int of_pci_map_rid(struct device_node *np, u32 rid,
-			const char *map_name, const char *map_mask_name,
-			struct device_node **target, u32 *id_out)
-{
-	return -EINVAL;
-}
-
 static inline int
 of_pci_get_max_link_speed(struct device_node *node)
 {
-- 
1.9.1

Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Robin Murphy]

On 17/04/18 11:21, Nipun Gupta wrote:
> iommu-map property is also used by devices with fsl-mc. This
> patch moves the of_pci_map_rid to generic location, so that it
> can be used by other busses too.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>   drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--

Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess 
you don't want fsl-mc to have to depend on PCI, but this looks like a 
step in the wrong direction.

I'm not entirely sure where of_map_rid() fits best, but from a quick 
look around the least-worst option might be drivers/of/of_address.c, 
unless Rob and Frank have a better idea of where generic DT-based ID 
translation routines could live?

>   drivers/of/irq.c         |   6 +--
>   drivers/pci/of.c         | 101 --------------------------------------------
>   include/linux/of_iommu.h |  11 +++++
>   include/linux/of_pci.h   |  10 -----
>   5 files changed, 117 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5c36a8b..4e7712f 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
>   	return ops->of_xlate(dev, iommu_spec);
>   }
>   
> +/**
> + * of_map_rid - Translate a requester ID through a downstream mapping.
> + * @np: root complex device node.
> + * @rid: device requester ID to map.
> + * @map_name: property name of the map to use.
> + * @map_mask_name: optional property name of the mask to use.
> + * @target: optional pointer to a target device node.
> + * @id_out: optional pointer to receive the translated ID.
> + *
> + * Given a device requester ID, look up the appropriate implementation-defined
> + * platform ID and/or the target device which receives transactions on that
> + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> + * @id_out may be NULL if only the other is required. If @target points to
> + * a non-NULL device node pointer, only entries targeting that node will be
> + * matched; if it points to a NULL value, it will receive the device node of
> + * the first matching target phandle, with a reference held.
> + *
> + * Return: 0 on success or a standard error code on failure.
> + */
> +int of_map_rid(struct device_node *np, u32 rid,
> +		   const char *map_name, const char *map_mask_name,
> +		   struct device_node **target, u32 *id_out)
> +{
> +	u32 map_mask, masked_rid;
> +	int map_len;
> +	const __be32 *map = NULL;
> +
> +	if (!np || !map_name || (!target && !id_out))
> +		return -EINVAL;
> +
> +	map = of_get_property(np, map_name, &map_len);
> +	if (!map) {
> +		if (target)
> +			return -ENODEV;
> +		/* Otherwise, no map implies no translation */
> +		*id_out = rid;
> +		return 0;
> +	}
> +
> +	if (!map_len || map_len % (4 * sizeof(*map))) {
> +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> +			map_name, map_len);
> +		return -EINVAL;
> +	}
> +
> +	/* The default is to select all bits. */
> +	map_mask = 0xffffffff;
> +
> +	/*
> +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> +	 */
> +	if (map_mask_name)
> +		of_property_read_u32(np, map_mask_name, &map_mask);
> +
> +	masked_rid = map_mask & rid;
> +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> +		struct device_node *phandle_node;
> +		u32 rid_base = be32_to_cpup(map + 0);
> +		u32 phandle = be32_to_cpup(map + 1);
> +		u32 out_base = be32_to_cpup(map + 2);
> +		u32 rid_len = be32_to_cpup(map + 3);
> +
> +		if (rid_base & ~map_mask) {
> +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> +				np, map_name, map_name,
> +				map_mask, rid_base);
> +			return -EFAULT;
> +		}
> +
> +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> +			continue;
> +
> +		phandle_node = of_find_node_by_phandle(phandle);
> +		if (!phandle_node)
> +			return -ENODEV;
> +
> +		if (target) {
> +			if (*target)
> +				of_node_put(phandle_node);
> +			else
> +				*target = phandle_node;
> +
> +			if (*target != phandle_node)
> +				continue;
> +		}
> +
> +		if (id_out)
> +			*id_out = masked_rid - rid_base + out_base;
> +
> +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> +			np, map_name, map_mask, rid_base, out_base,
> +			rid_len, rid, masked_rid - rid_base + out_base);
> +		return 0;
> +	}
> +
> +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> +		np, map_name, rid, target && *target ? *target : NULL);
> +	return -EFAULT;
> +}
> +
>   struct of_pci_iommu_alias_info {
>   	struct device *dev;
>   	struct device_node *np;
> @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
>   	struct of_phandle_args iommu_spec = { .args_count = 1 };
>   	int err;
>   
> -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> -			     "iommu-map-mask", &iommu_spec.np,
> -			     iommu_spec.args);
> +	err = of_map_rid(info->np, alias, "iommu-map",
> +			 "iommu-map-mask", &iommu_spec.np,
> +			 iommu_spec.args);

Super-nit: Apparently I missed rewrapping this to 2 lines in 
d87beb749281, but if it's being touched again, that would be nice ;)

Robin.

>   	if (err)
>   		return err == -ENODEV ? NO_IOMMU : err;
>   
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 02ad93a..b72eeec 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -22,7 +22,7 @@
>   #include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/of_irq.h>
> -#include <linux/of_pci.h>
> +#include <linux/of_iommu.h>
>   #include <linux/string.h>
>   #include <linux/slab.h>
>   
> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>   	 * "msi-map" property.
>   	 */
>   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> -				    "msi-map-mask", np, &rid_out))
> +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> +				"msi-map-mask", np, &rid_out))
>   			break;
>   	return rid_out;
>   }
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index a28355c..d2cebbe 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
>   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>   #endif /* CONFIG_OF_ADDRESS */
>   
> -/**
> - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> - * @np: root complex device node.
> - * @rid: PCI requester ID to map.
> - * @map_name: property name of the map to use.
> - * @map_mask_name: optional property name of the mask to use.
> - * @target: optional pointer to a target device node.
> - * @id_out: optional pointer to receive the translated ID.
> - *
> - * Given a PCI requester ID, look up the appropriate implementation-defined
> - * platform ID and/or the target device which receives transactions on that
> - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> - * @id_out may be NULL if only the other is required. If @target points to
> - * a non-NULL device node pointer, only entries targeting that node will be
> - * matched; if it points to a NULL value, it will receive the device node of
> - * the first matching target phandle, with a reference held.
> - *
> - * Return: 0 on success or a standard error code on failure.
> - */
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out)
> -{
> -	u32 map_mask, masked_rid;
> -	int map_len;
> -	const __be32 *map = NULL;
> -
> -	if (!np || !map_name || (!target && !id_out))
> -		return -EINVAL;
> -
> -	map = of_get_property(np, map_name, &map_len);
> -	if (!map) {
> -		if (target)
> -			return -ENODEV;
> -		/* Otherwise, no map implies no translation */
> -		*id_out = rid;
> -		return 0;
> -	}
> -
> -	if (!map_len || map_len % (4 * sizeof(*map))) {
> -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> -			map_name, map_len);
> -		return -EINVAL;
> -	}
> -
> -	/* The default is to select all bits. */
> -	map_mask = 0xffffffff;
> -
> -	/*
> -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> -	 * If of_property_read_u32() fails, the default is used.
> -	 */
> -	if (map_mask_name)
> -		of_property_read_u32(np, map_mask_name, &map_mask);
> -
> -	masked_rid = map_mask & rid;
> -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> -		struct device_node *phandle_node;
> -		u32 rid_base = be32_to_cpup(map + 0);
> -		u32 phandle = be32_to_cpup(map + 1);
> -		u32 out_base = be32_to_cpup(map + 2);
> -		u32 rid_len = be32_to_cpup(map + 3);
> -
> -		if (rid_base & ~map_mask) {
> -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> -				np, map_name, map_name,
> -				map_mask, rid_base);
> -			return -EFAULT;
> -		}
> -
> -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> -			continue;
> -
> -		phandle_node = of_find_node_by_phandle(phandle);
> -		if (!phandle_node)
> -			return -ENODEV;
> -
> -		if (target) {
> -			if (*target)
> -				of_node_put(phandle_node);
> -			else
> -				*target = phandle_node;
> -
> -			if (*target != phandle_node)
> -				continue;
> -		}
> -
> -		if (id_out)
> -			*id_out = masked_rid - rid_base + out_base;
> -
> -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> -			np, map_name, map_mask, rid_base, out_base,
> -			rid_len, rid, masked_rid - rid_base + out_base);
> -		return 0;
> -	}
> -
> -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> -		np, map_name, rid, target && *target ? *target : NULL);
> -	return -EFAULT;
> -}
> -
>   #if IS_ENABLED(CONFIG_OF_IRQ)
>   /**
>    * of_irq_parse_pci - Resolve the interrupt for a PCI device
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 4fa654e..432b53c 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
>   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
>   					struct device_node *master_np);
>   
> +int of_map_rid(struct device_node *np, u32 rid,
> +	       const char *map_name, const char *map_mask_name,
> +	       struct device_node **target, u32 *id_out);
> +
>   #else
>   
>   static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>   	return NULL;
>   }
>   
> +static inline int of_map_rid(struct device_node *np, u32 rid,
> +			     const char *map_name, const char *map_mask_name,
> +			     struct device_node **target, u32 *id_out)
> +{
> +	return -EINVAL;
> +}
> +
>   #endif	/* CONFIG_OF_IOMMU */
>   
>   extern struct of_device_id __iommu_of_table;
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 091033a..a23b44a 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>   int of_get_pci_domain_nr(struct device_node *node);
>   int of_pci_get_max_link_speed(struct device_node *node);
>   void of_pci_check_probe_only(void);
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out);
>   #else
>   static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
>   					     unsigned int devfn)
> @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
>   	return -1;
>   }
>   
> -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> -			const char *map_name, const char *map_mask_name,
> -			struct device_node **target, u32 *id_out)
> -{
> -	return -EINVAL;
> -}
> -
>   static inline int
>   of_pci_get_max_link_speed(struct device_node *node)
>   {
> 

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Robin Murphy]

On 17/04/18 11:21, Nipun Gupta wrote:
> iommu-map property is also used by devices with fsl-mc. This
> patch moves the of_pci_map_rid to generic location, so that it
> can be used by other busses too.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> ---
>   drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--

Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess 
you don't want fsl-mc to have to depend on PCI, but this looks like a 
step in the wrong direction.

I'm not entirely sure where of_map_rid() fits best, but from a quick 
look around the least-worst option might be drivers/of/of_address.c, 
unless Rob and Frank have a better idea of where generic DT-based ID 
translation routines could live?

>   drivers/of/irq.c         |   6 +--
>   drivers/pci/of.c         | 101 --------------------------------------------
>   include/linux/of_iommu.h |  11 +++++
>   include/linux/of_pci.h   |  10 -----
>   5 files changed, 117 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5c36a8b..4e7712f 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
>   	return ops->of_xlate(dev, iommu_spec);
>   }
>   
> +/**
> + * of_map_rid - Translate a requester ID through a downstream mapping.
> + * @np: root complex device node.
> + * @rid: device requester ID to map.
> + * @map_name: property name of the map to use.
> + * @map_mask_name: optional property name of the mask to use.
> + * @target: optional pointer to a target device node.
> + * @id_out: optional pointer to receive the translated ID.
> + *
> + * Given a device requester ID, look up the appropriate implementation-defined
> + * platform ID and/or the target device which receives transactions on that
> + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> + * @id_out may be NULL if only the other is required. If @target points to
> + * a non-NULL device node pointer, only entries targeting that node will be
> + * matched; if it points to a NULL value, it will receive the device node of
> + * the first matching target phandle, with a reference held.
> + *
> + * Return: 0 on success or a standard error code on failure.
> + */
> +int of_map_rid(struct device_node *np, u32 rid,
> +		   const char *map_name, const char *map_mask_name,
> +		   struct device_node **target, u32 *id_out)
> +{
> +	u32 map_mask, masked_rid;
> +	int map_len;
> +	const __be32 *map = NULL;
> +
> +	if (!np || !map_name || (!target && !id_out))
> +		return -EINVAL;
> +
> +	map = of_get_property(np, map_name, &map_len);
> +	if (!map) {
> +		if (target)
> +			return -ENODEV;
> +		/* Otherwise, no map implies no translation */
> +		*id_out = rid;
> +		return 0;
> +	}
> +
> +	if (!map_len || map_len % (4 * sizeof(*map))) {
> +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> +			map_name, map_len);
> +		return -EINVAL;
> +	}
> +
> +	/* The default is to select all bits. */
> +	map_mask = 0xffffffff;
> +
> +	/*
> +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> +	 */
> +	if (map_mask_name)
> +		of_property_read_u32(np, map_mask_name, &map_mask);
> +
> +	masked_rid = map_mask & rid;
> +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> +		struct device_node *phandle_node;
> +		u32 rid_base = be32_to_cpup(map + 0);
> +		u32 phandle = be32_to_cpup(map + 1);
> +		u32 out_base = be32_to_cpup(map + 2);
> +		u32 rid_len = be32_to_cpup(map + 3);
> +
> +		if (rid_base & ~map_mask) {
> +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> +				np, map_name, map_name,
> +				map_mask, rid_base);
> +			return -EFAULT;
> +		}
> +
> +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> +			continue;
> +
> +		phandle_node = of_find_node_by_phandle(phandle);
> +		if (!phandle_node)
> +			return -ENODEV;
> +
> +		if (target) {
> +			if (*target)
> +				of_node_put(phandle_node);
> +			else
> +				*target = phandle_node;
> +
> +			if (*target != phandle_node)
> +				continue;
> +		}
> +
> +		if (id_out)
> +			*id_out = masked_rid - rid_base + out_base;
> +
> +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> +			np, map_name, map_mask, rid_base, out_base,
> +			rid_len, rid, masked_rid - rid_base + out_base);
> +		return 0;
> +	}
> +
> +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> +		np, map_name, rid, target && *target ? *target : NULL);
> +	return -EFAULT;
> +}
> +
>   struct of_pci_iommu_alias_info {
>   	struct device *dev;
>   	struct device_node *np;
> @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
>   	struct of_phandle_args iommu_spec = { .args_count = 1 };
>   	int err;
>   
> -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> -			     "iommu-map-mask", &iommu_spec.np,
> -			     iommu_spec.args);
> +	err = of_map_rid(info->np, alias, "iommu-map",
> +			 "iommu-map-mask", &iommu_spec.np,
> +			 iommu_spec.args);

Super-nit: Apparently I missed rewrapping this to 2 lines in 
d87beb749281, but if it's being touched again, that would be nice ;)

Robin.

>   	if (err)
>   		return err == -ENODEV ? NO_IOMMU : err;
>   
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 02ad93a..b72eeec 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -22,7 +22,7 @@
>   #include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/of_irq.h>
> -#include <linux/of_pci.h>
> +#include <linux/of_iommu.h>
>   #include <linux/string.h>
>   #include <linux/slab.h>
>   
> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>   	 * "msi-map" property.
>   	 */
>   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> -				    "msi-map-mask", np, &rid_out))
> +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> +				"msi-map-mask", np, &rid_out))
>   			break;
>   	return rid_out;
>   }
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index a28355c..d2cebbe 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
>   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>   #endif /* CONFIG_OF_ADDRESS */
>   
> -/**
> - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> - * @np: root complex device node.
> - * @rid: PCI requester ID to map.
> - * @map_name: property name of the map to use.
> - * @map_mask_name: optional property name of the mask to use.
> - * @target: optional pointer to a target device node.
> - * @id_out: optional pointer to receive the translated ID.
> - *
> - * Given a PCI requester ID, look up the appropriate implementation-defined
> - * platform ID and/or the target device which receives transactions on that
> - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> - * @id_out may be NULL if only the other is required. If @target points to
> - * a non-NULL device node pointer, only entries targeting that node will be
> - * matched; if it points to a NULL value, it will receive the device node of
> - * the first matching target phandle, with a reference held.
> - *
> - * Return: 0 on success or a standard error code on failure.
> - */
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out)
> -{
> -	u32 map_mask, masked_rid;
> -	int map_len;
> -	const __be32 *map = NULL;
> -
> -	if (!np || !map_name || (!target && !id_out))
> -		return -EINVAL;
> -
> -	map = of_get_property(np, map_name, &map_len);
> -	if (!map) {
> -		if (target)
> -			return -ENODEV;
> -		/* Otherwise, no map implies no translation */
> -		*id_out = rid;
> -		return 0;
> -	}
> -
> -	if (!map_len || map_len % (4 * sizeof(*map))) {
> -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> -			map_name, map_len);
> -		return -EINVAL;
> -	}
> -
> -	/* The default is to select all bits. */
> -	map_mask = 0xffffffff;
> -
> -	/*
> -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> -	 * If of_property_read_u32() fails, the default is used.
> -	 */
> -	if (map_mask_name)
> -		of_property_read_u32(np, map_mask_name, &map_mask);
> -
> -	masked_rid = map_mask & rid;
> -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> -		struct device_node *phandle_node;
> -		u32 rid_base = be32_to_cpup(map + 0);
> -		u32 phandle = be32_to_cpup(map + 1);
> -		u32 out_base = be32_to_cpup(map + 2);
> -		u32 rid_len = be32_to_cpup(map + 3);
> -
> -		if (rid_base & ~map_mask) {
> -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> -				np, map_name, map_name,
> -				map_mask, rid_base);
> -			return -EFAULT;
> -		}
> -
> -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> -			continue;
> -
> -		phandle_node = of_find_node_by_phandle(phandle);
> -		if (!phandle_node)
> -			return -ENODEV;
> -
> -		if (target) {
> -			if (*target)
> -				of_node_put(phandle_node);
> -			else
> -				*target = phandle_node;
> -
> -			if (*target != phandle_node)
> -				continue;
> -		}
> -
> -		if (id_out)
> -			*id_out = masked_rid - rid_base + out_base;
> -
> -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> -			np, map_name, map_mask, rid_base, out_base,
> -			rid_len, rid, masked_rid - rid_base + out_base);
> -		return 0;
> -	}
> -
> -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> -		np, map_name, rid, target && *target ? *target : NULL);
> -	return -EFAULT;
> -}
> -
>   #if IS_ENABLED(CONFIG_OF_IRQ)
>   /**
>    * of_irq_parse_pci - Resolve the interrupt for a PCI device
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 4fa654e..432b53c 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
>   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
>   					struct device_node *master_np);
>   
> +int of_map_rid(struct device_node *np, u32 rid,
> +	       const char *map_name, const char *map_mask_name,
> +	       struct device_node **target, u32 *id_out);
> +
>   #else
>   
>   static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>   	return NULL;
>   }
>   
> +static inline int of_map_rid(struct device_node *np, u32 rid,
> +			     const char *map_name, const char *map_mask_name,
> +			     struct device_node **target, u32 *id_out)
> +{
> +	return -EINVAL;
> +}
> +
>   #endif	/* CONFIG_OF_IOMMU */
>   
>   extern struct of_device_id __iommu_of_table;
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 091033a..a23b44a 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>   int of_get_pci_domain_nr(struct device_node *node);
>   int of_pci_get_max_link_speed(struct device_node *node);
>   void of_pci_check_probe_only(void);
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out);
>   #else
>   static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
>   					     unsigned int devfn)
> @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
>   	return -1;
>   }
>   
> -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> -			const char *map_name, const char *map_mask_name,
> -			struct device_node **target, u32 *id_out)
> -{
> -	return -EINVAL;
> -}
> -
>   static inline int
>   of_pci_get_max_link_speed(struct device_node *node)
>   {
> 

Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Robin Murphy]

On 17/04/18 11:21, Nipun Gupta wrote:
> iommu-map property is also used by devices with fsl-mc. This
> patch moves the of_pci_map_rid to generic location, so that it
> can be used by other busses too.
> 
> Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> ---
>   drivers/iommu/of_iommu.c | 106 +++++++++++++++++++++++++++++++++++++++++++++--

Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess 
you don't want fsl-mc to have to depend on PCI, but this looks like a 
step in the wrong direction.

I'm not entirely sure where of_map_rid() fits best, but from a quick 
look around the least-worst option might be drivers/of/of_address.c, 
unless Rob and Frank have a better idea of where generic DT-based ID 
translation routines could live?

>   drivers/of/irq.c         |   6 +--
>   drivers/pci/of.c         | 101 --------------------------------------------
>   include/linux/of_iommu.h |  11 +++++
>   include/linux/of_pci.h   |  10 -----
>   5 files changed, 117 insertions(+), 117 deletions(-)
> 
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 5c36a8b..4e7712f 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
>   	return ops->of_xlate(dev, iommu_spec);
>   }
>   
> +/**
> + * of_map_rid - Translate a requester ID through a downstream mapping.
> + * @np: root complex device node.
> + * @rid: device requester ID to map.
> + * @map_name: property name of the map to use.
> + * @map_mask_name: optional property name of the mask to use.
> + * @target: optional pointer to a target device node.
> + * @id_out: optional pointer to receive the translated ID.
> + *
> + * Given a device requester ID, look up the appropriate implementation-defined
> + * platform ID and/or the target device which receives transactions on that
> + * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> + * @id_out may be NULL if only the other is required. If @target points to
> + * a non-NULL device node pointer, only entries targeting that node will be
> + * matched; if it points to a NULL value, it will receive the device node of
> + * the first matching target phandle, with a reference held.
> + *
> + * Return: 0 on success or a standard error code on failure.
> + */
> +int of_map_rid(struct device_node *np, u32 rid,
> +		   const char *map_name, const char *map_mask_name,
> +		   struct device_node **target, u32 *id_out)
> +{
> +	u32 map_mask, masked_rid;
> +	int map_len;
> +	const __be32 *map = NULL;
> +
> +	if (!np || !map_name || (!target && !id_out))
> +		return -EINVAL;
> +
> +	map = of_get_property(np, map_name, &map_len);
> +	if (!map) {
> +		if (target)
> +			return -ENODEV;
> +		/* Otherwise, no map implies no translation */
> +		*id_out = rid;
> +		return 0;
> +	}
> +
> +	if (!map_len || map_len % (4 * sizeof(*map))) {
> +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> +			map_name, map_len);
> +		return -EINVAL;
> +	}
> +
> +	/* The default is to select all bits. */
> +	map_mask = 0xffffffff;
> +
> +	/*
> +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> +	 */
> +	if (map_mask_name)
> +		of_property_read_u32(np, map_mask_name, &map_mask);
> +
> +	masked_rid = map_mask & rid;
> +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> +		struct device_node *phandle_node;
> +		u32 rid_base = be32_to_cpup(map + 0);
> +		u32 phandle = be32_to_cpup(map + 1);
> +		u32 out_base = be32_to_cpup(map + 2);
> +		u32 rid_len = be32_to_cpup(map + 3);
> +
> +		if (rid_base & ~map_mask) {
> +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> +				np, map_name, map_name,
> +				map_mask, rid_base);
> +			return -EFAULT;
> +		}
> +
> +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> +			continue;
> +
> +		phandle_node = of_find_node_by_phandle(phandle);
> +		if (!phandle_node)
> +			return -ENODEV;
> +
> +		if (target) {
> +			if (*target)
> +				of_node_put(phandle_node);
> +			else
> +				*target = phandle_node;
> +
> +			if (*target != phandle_node)
> +				continue;
> +		}
> +
> +		if (id_out)
> +			*id_out = masked_rid - rid_base + out_base;
> +
> +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> +			np, map_name, map_mask, rid_base, out_base,
> +			rid_len, rid, masked_rid - rid_base + out_base);
> +		return 0;
> +	}
> +
> +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> +		np, map_name, rid, target && *target ? *target : NULL);
> +	return -EFAULT;
> +}
> +
>   struct of_pci_iommu_alias_info {
>   	struct device *dev;
>   	struct device_node *np;
> @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
>   	struct of_phandle_args iommu_spec = { .args_count = 1 };
>   	int err;
>   
> -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> -			     "iommu-map-mask", &iommu_spec.np,
> -			     iommu_spec.args);
> +	err = of_map_rid(info->np, alias, "iommu-map",
> +			 "iommu-map-mask", &iommu_spec.np,
> +			 iommu_spec.args);

Super-nit: Apparently I missed rewrapping this to 2 lines in 
d87beb749281, but if it's being touched again, that would be nice ;)

Robin.

>   	if (err)
>   		return err == -ENODEV ? NO_IOMMU : err;
>   
> diff --git a/drivers/of/irq.c b/drivers/of/irq.c
> index 02ad93a..b72eeec 100644
> --- a/drivers/of/irq.c
> +++ b/drivers/of/irq.c
> @@ -22,7 +22,7 @@
>   #include <linux/module.h>
>   #include <linux/of.h>
>   #include <linux/of_irq.h>
> -#include <linux/of_pci.h>
> +#include <linux/of_iommu.h>
>   #include <linux/string.h>
>   #include <linux/slab.h>
>   
> @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev, struct device_node **np,
>   	 * "msi-map" property.
>   	 */
>   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> -				    "msi-map-mask", np, &rid_out))
> +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> +				"msi-map-mask", np, &rid_out))
>   			break;
>   	return rid_out;
>   }
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index a28355c..d2cebbe 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct device_node *dev,
>   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
>   #endif /* CONFIG_OF_ADDRESS */
>   
> -/**
> - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> - * @np: root complex device node.
> - * @rid: PCI requester ID to map.
> - * @map_name: property name of the map to use.
> - * @map_mask_name: optional property name of the mask to use.
> - * @target: optional pointer to a target device node.
> - * @id_out: optional pointer to receive the translated ID.
> - *
> - * Given a PCI requester ID, look up the appropriate implementation-defined
> - * platform ID and/or the target device which receives transactions on that
> - * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
> - * @id_out may be NULL if only the other is required. If @target points to
> - * a non-NULL device node pointer, only entries targeting that node will be
> - * matched; if it points to a NULL value, it will receive the device node of
> - * the first matching target phandle, with a reference held.
> - *
> - * Return: 0 on success or a standard error code on failure.
> - */
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out)
> -{
> -	u32 map_mask, masked_rid;
> -	int map_len;
> -	const __be32 *map = NULL;
> -
> -	if (!np || !map_name || (!target && !id_out))
> -		return -EINVAL;
> -
> -	map = of_get_property(np, map_name, &map_len);
> -	if (!map) {
> -		if (target)
> -			return -ENODEV;
> -		/* Otherwise, no map implies no translation */
> -		*id_out = rid;
> -		return 0;
> -	}
> -
> -	if (!map_len || map_len % (4 * sizeof(*map))) {
> -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> -			map_name, map_len);
> -		return -EINVAL;
> -	}
> -
> -	/* The default is to select all bits. */
> -	map_mask = 0xffffffff;
> -
> -	/*
> -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> -	 * If of_property_read_u32() fails, the default is used.
> -	 */
> -	if (map_mask_name)
> -		of_property_read_u32(np, map_mask_name, &map_mask);
> -
> -	masked_rid = map_mask & rid;
> -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> -		struct device_node *phandle_node;
> -		u32 rid_base = be32_to_cpup(map + 0);
> -		u32 phandle = be32_to_cpup(map + 1);
> -		u32 out_base = be32_to_cpup(map + 2);
> -		u32 rid_len = be32_to_cpup(map + 3);
> -
> -		if (rid_base & ~map_mask) {
> -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores rid-base (0x%x)\n",
> -				np, map_name, map_name,
> -				map_mask, rid_base);
> -			return -EFAULT;
> -		}
> -
> -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> -			continue;
> -
> -		phandle_node = of_find_node_by_phandle(phandle);
> -		if (!phandle_node)
> -			return -ENODEV;
> -
> -		if (target) {
> -			if (*target)
> -				of_node_put(phandle_node);
> -			else
> -				*target = phandle_node;
> -
> -			if (*target != phandle_node)
> -				continue;
> -		}
> -
> -		if (id_out)
> -			*id_out = masked_rid - rid_base + out_base;
> -
> -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-base: %08x, length: %08x, rid: %08x -> %08x\n",
> -			np, map_name, map_mask, rid_base, out_base,
> -			rid_len, rid, masked_rid - rid_base + out_base);
> -		return 0;
> -	}
> -
> -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on %pOF\n",
> -		np, map_name, rid, target && *target ? *target : NULL);
> -	return -EFAULT;
> -}
> -
>   #if IS_ENABLED(CONFIG_OF_IRQ)
>   /**
>    * of_irq_parse_pci - Resolve the interrupt for a PCI device
> diff --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h
> index 4fa654e..432b53c 100644
> --- a/include/linux/of_iommu.h
> +++ b/include/linux/of_iommu.h
> @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node *dn, const char *prefix,
>   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
>   					struct device_node *master_np);
>   
> +int of_map_rid(struct device_node *np, u32 rid,
> +	       const char *map_name, const char *map_mask_name,
> +	       struct device_node **target, u32 *id_out);
> +
>   #else
>   
>   static inline int of_get_dma_window(struct device_node *dn, const char *prefix,
> @@ -30,6 +34,13 @@ static inline const struct iommu_ops *of_iommu_configure(struct device *dev,
>   	return NULL;
>   }
>   
> +static inline int of_map_rid(struct device_node *np, u32 rid,
> +			     const char *map_name, const char *map_mask_name,
> +			     struct device_node **target, u32 *id_out)
> +{
> +	return -EINVAL;
> +}
> +
>   #endif	/* CONFIG_OF_IOMMU */
>   
>   extern struct of_device_id __iommu_of_table;
> diff --git a/include/linux/of_pci.h b/include/linux/of_pci.h
> index 091033a..a23b44a 100644
> --- a/include/linux/of_pci.h
> +++ b/include/linux/of_pci.h
> @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct device_node *parent,
>   int of_get_pci_domain_nr(struct device_node *node);
>   int of_pci_get_max_link_speed(struct device_node *node);
>   void of_pci_check_probe_only(void);
> -int of_pci_map_rid(struct device_node *np, u32 rid,
> -		   const char *map_name, const char *map_mask_name,
> -		   struct device_node **target, u32 *id_out);
>   #else
>   static inline struct device_node *of_pci_find_child_device(struct device_node *parent,
>   					     unsigned int devfn)
> @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node *np)
>   	return -1;
>   }
>   
> -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> -			const char *map_name, const char *map_mask_name,
> -			struct device_node **target, u32 *id_out)
> -{
> -	return -EINVAL;
> -}
> -
>   static inline int
>   of_pci_get_max_link_speed(struct device_node *node)
>   {
> 

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org;
> frowand.list@gmail.com
> Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com;
> hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org;
> m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com;
> iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-
> dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is same.

> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> >   	return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +		   const char *map_name, const char *map_mask_name,
> > +		   struct device_node **target, u32 *id_out) {
> > +	u32 map_mask, masked_rid;
> > +	int map_len;
> > +	const __be32 *map = NULL;
> > +
> > +	if (!np || !map_name || (!target && !id_out))
> > +		return -EINVAL;
> > +
> > +	map = of_get_property(np, map_name, &map_len);
> > +	if (!map) {
> > +		if (target)
> > +			return -ENODEV;
> > +		/* Otherwise, no map implies no translation */
> > +		*id_out = rid;
> > +		return 0;
> > +	}
> > +
> > +	if (!map_len || map_len % (4 * sizeof(*map))) {
> > +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +			map_name, map_len);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* The default is to select all bits. */
> > +	map_mask = 0xffffffff;
> > +
> > +	/*
> > +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > +	 */
> > +	if (map_mask_name)
> > +		of_property_read_u32(np, map_mask_name, &map_mask);
> > +
> > +	masked_rid = map_mask & rid;
> > +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +		struct device_node *phandle_node;
> > +		u32 rid_base = be32_to_cpup(map + 0);
> > +		u32 phandle = be32_to_cpup(map + 1);
> > +		u32 out_base = be32_to_cpup(map + 2);
> > +		u32 rid_len = be32_to_cpup(map + 3);
> > +
> > +		if (rid_base & ~map_mask) {
> > +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > +				np, map_name, map_name,
> > +				map_mask, rid_base);
> > +			return -EFAULT;
> > +		}
> > +
> > +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > +			continue;
> > +
> > +		phandle_node = of_find_node_by_phandle(phandle);
> > +		if (!phandle_node)
> > +			return -ENODEV;
> > +
> > +		if (target) {
> > +			if (*target)
> > +				of_node_put(phandle_node);
> > +			else
> > +				*target = phandle_node;
> > +
> > +			if (*target != phandle_node)
> > +				continue;
> > +		}
> > +
> > +		if (id_out)
> > +			*id_out = masked_rid - rid_base + out_base;
> > +
> > +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > +			np, map_name, map_mask, rid_base, out_base,
> > +			rid_len, rid, masked_rid - rid_base + out_base);
> > +		return 0;
> > +	}
> > +
> > +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > +		np, map_name, rid, target && *target ? *target : NULL);
> > +	return -EFAULT;
> > +}
> > +
> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)
> 
> Robin.
> 
> >   	if (err)
> >   		return err == -ENODEV ? NO_IOMMU : err;
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index
> > 02ad93a..b72eeec 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -22,7 +22,7 @@
> >   #include <linux/module.h>
> >   #include <linux/of.h>
> >   #include <linux/of_irq.h>
> > -#include <linux/of_pci.h>
> > +#include <linux/of_iommu.h>
> >   #include <linux/string.h>
> >   #include <linux/slab.h>
> >
> > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev,
> struct device_node **np,
> >   	 * "msi-map" property.
> >   	 */
> >   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> > -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > -				    "msi-map-mask", np, &rid_out))
> > +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > +				"msi-map-mask", np, &rid_out))
> >   			break;
> >   	return rid_out;
> >   }
> > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index
> > a28355c..d2cebbe 100644
> > --- a/drivers/pci/of.c
> > +++ b/drivers/pci/of.c
> > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> >   #endif /* CONFIG_OF_ADDRESS */
> >
> > -/**
> > - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> > - * @np: root complex device node.
> > - * @rid: PCI requester ID to map.
> > - * @map_name: property name of the map to use.
> > - * @map_mask_name: optional property name of the mask to use.
> > - * @target: optional pointer to a target device node.
> > - * @id_out: optional pointer to receive the translated ID.
> > - *
> > - * Given a PCI requester ID, look up the appropriate
> > implementation-defined
> > - * platform ID and/or the target device which receives transactions
> > on that
> > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > @target or
> > - * @id_out may be NULL if only the other is required. If @target
> > points to
> > - * a non-NULL device node pointer, only entries targeting that node
> > will be
> > - * matched; if it points to a NULL value, it will receive the device
> > node of
> > - * the first matching target phandle, with a reference held.
> > - *
> > - * Return: 0 on success or a standard error code on failure.
> > - */
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out)
> > -{
> > -	u32 map_mask, masked_rid;
> > -	int map_len;
> > -	const __be32 *map = NULL;
> > -
> > -	if (!np || !map_name || (!target && !id_out))
> > -		return -EINVAL;
> > -
> > -	map = of_get_property(np, map_name, &map_len);
> > -	if (!map) {
> > -		if (target)
> > -			return -ENODEV;
> > -		/* Otherwise, no map implies no translation */
> > -		*id_out = rid;
> > -		return 0;
> > -	}
> > -
> > -	if (!map_len || map_len % (4 * sizeof(*map))) {
> > -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > -			map_name, map_len);
> > -		return -EINVAL;
> > -	}
> > -
> > -	/* The default is to select all bits. */
> > -	map_mask = 0xffffffff;
> > -
> > -	/*
> > -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > -	 * If of_property_read_u32() fails, the default is used.
> > -	 */
> > -	if (map_mask_name)
> > -		of_property_read_u32(np, map_mask_name, &map_mask);
> > -
> > -	masked_rid = map_mask & rid;
> > -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > -		struct device_node *phandle_node;
> > -		u32 rid_base = be32_to_cpup(map + 0);
> > -		u32 phandle = be32_to_cpup(map + 1);
> > -		u32 out_base = be32_to_cpup(map + 2);
> > -		u32 rid_len = be32_to_cpup(map + 3);
> > -
> > -		if (rid_base & ~map_mask) {
> > -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > -				np, map_name, map_name,
> > -				map_mask, rid_base);
> > -			return -EFAULT;
> > -		}
> > -
> > -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > -			continue;
> > -
> > -		phandle_node = of_find_node_by_phandle(phandle);
> > -		if (!phandle_node)
> > -			return -ENODEV;
> > -
> > -		if (target) {
> > -			if (*target)
> > -				of_node_put(phandle_node);
> > -			else
> > -				*target = phandle_node;
> > -
> > -			if (*target != phandle_node)
> > -				continue;
> > -		}
> > -
> > -		if (id_out)
> > -			*id_out = masked_rid - rid_base + out_base;
> > -
> > -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > -			np, map_name, map_mask, rid_base, out_base,
> > -			rid_len, rid, masked_rid - rid_base + out_base);
> > -		return 0;
> > -	}
> > -
> > -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > -		np, map_name, rid, target && *target ? *target : NULL);
> > -	return -EFAULT;
> > -}
> > -
> >   #if IS_ENABLED(CONFIG_OF_IRQ)
> >   /**
> >    * of_irq_parse_pci - Resolve the interrupt for a PCI device diff
> > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index
> > 4fa654e..432b53c 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node
> *dn, const char *prefix,
> >   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> >   					struct device_node *master_np);
> >
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +	       const char *map_name, const char *map_mask_name,
> > +	       struct device_node **target, u32 *id_out);
> > +
> >   #else
> >
> >   static inline int of_get_dma_window(struct device_node *dn, const
> > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops
> *of_iommu_configure(struct device *dev,
> >   	return NULL;
> >   }
> >
> > +static inline int of_map_rid(struct device_node *np, u32 rid,
> > +			     const char *map_name, const char
> *map_mask_name,
> > +			     struct device_node **target, u32 *id_out) {
> > +	return -EINVAL;
> > +}
> > +
> >   #endif	/* CONFIG_OF_IOMMU */
> >
> >   extern struct of_device_id __iommu_of_table; diff --git
> > a/include/linux/of_pci.h b/include/linux/of_pci.h index
> > 091033a..a23b44a 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct
> device_node *parent,
> >   int of_get_pci_domain_nr(struct device_node *node);
> >   int of_pci_get_max_link_speed(struct device_node *node);
> >   void of_pci_check_probe_only(void);
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out);
> >   #else
> >   static inline struct device_node *of_pci_find_child_device(struct device_node
> *parent,
> >   					     unsigned int devfn)
> > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node
> *np)
> >   	return -1;
> >   }
> >
> > -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> > -			const char *map_name, const char *map_mask_name,
> > -			struct device_node **target, u32 *id_out)
> > -{
> > -	return -EINVAL;
> > -}
> > -
> >   static inline int
> >   of_pci_get_max_link_speed(struct device_node *node)
> >   {
> >

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt at kernel.org;
> frowand.list at gmail.com
> Cc: will.deacon at arm.com; mark.rutland at arm.com; catalin.marinas at arm.com;
> hch at lst.de; gregkh at linuxfoundation.org; joro at 8bytes.org;
> m.szyprowski at samsung.com; shawnguo at kernel.org; bhelgaas at google.com;
> iommu at lists.linux-foundation.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linuxppc-
> dev at lists.ozlabs.org; linux-pci at vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is same.

> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> >   	return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > + at target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +		   const char *map_name, const char *map_mask_name,
> > +		   struct device_node **target, u32 *id_out) {
> > +	u32 map_mask, masked_rid;
> > +	int map_len;
> > +	const __be32 *map = NULL;
> > +
> > +	if (!np || !map_name || (!target && !id_out))
> > +		return -EINVAL;
> > +
> > +	map = of_get_property(np, map_name, &map_len);
> > +	if (!map) {
> > +		if (target)
> > +			return -ENODEV;
> > +		/* Otherwise, no map implies no translation */
> > +		*id_out = rid;
> > +		return 0;
> > +	}
> > +
> > +	if (!map_len || map_len % (4 * sizeof(*map))) {
> > +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +			map_name, map_len);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* The default is to select all bits. */
> > +	map_mask = 0xffffffff;
> > +
> > +	/*
> > +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > +	 */
> > +	if (map_mask_name)
> > +		of_property_read_u32(np, map_mask_name, &map_mask);
> > +
> > +	masked_rid = map_mask & rid;
> > +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +		struct device_node *phandle_node;
> > +		u32 rid_base = be32_to_cpup(map + 0);
> > +		u32 phandle = be32_to_cpup(map + 1);
> > +		u32 out_base = be32_to_cpup(map + 2);
> > +		u32 rid_len = be32_to_cpup(map + 3);
> > +
> > +		if (rid_base & ~map_mask) {
> > +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > +				np, map_name, map_name,
> > +				map_mask, rid_base);
> > +			return -EFAULT;
> > +		}
> > +
> > +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > +			continue;
> > +
> > +		phandle_node = of_find_node_by_phandle(phandle);
> > +		if (!phandle_node)
> > +			return -ENODEV;
> > +
> > +		if (target) {
> > +			if (*target)
> > +				of_node_put(phandle_node);
> > +			else
> > +				*target = phandle_node;
> > +
> > +			if (*target != phandle_node)
> > +				continue;
> > +		}
> > +
> > +		if (id_out)
> > +			*id_out = masked_rid - rid_base + out_base;
> > +
> > +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > +			np, map_name, map_mask, rid_base, out_base,
> > +			rid_len, rid, masked_rid - rid_base + out_base);
> > +		return 0;
> > +	}
> > +
> > +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > +		np, map_name, rid, target && *target ? *target : NULL);
> > +	return -EFAULT;
> > +}
> > +
> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)
> 
> Robin.
> 
> >   	if (err)
> >   		return err == -ENODEV ? NO_IOMMU : err;
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index
> > 02ad93a..b72eeec 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -22,7 +22,7 @@
> >   #include <linux/module.h>
> >   #include <linux/of.h>
> >   #include <linux/of_irq.h>
> > -#include <linux/of_pci.h>
> > +#include <linux/of_iommu.h>
> >   #include <linux/string.h>
> >   #include <linux/slab.h>
> >
> > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev,
> struct device_node **np,
> >   	 * "msi-map" property.
> >   	 */
> >   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> > -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > -				    "msi-map-mask", np, &rid_out))
> > +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > +				"msi-map-mask", np, &rid_out))
> >   			break;
> >   	return rid_out;
> >   }
> > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index
> > a28355c..d2cebbe 100644
> > --- a/drivers/pci/of.c
> > +++ b/drivers/pci/of.c
> > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> >   #endif /* CONFIG_OF_ADDRESS */
> >
> > -/**
> > - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> > - * @np: root complex device node.
> > - * @rid: PCI requester ID to map.
> > - * @map_name: property name of the map to use.
> > - * @map_mask_name: optional property name of the mask to use.
> > - * @target: optional pointer to a target device node.
> > - * @id_out: optional pointer to receive the translated ID.
> > - *
> > - * Given a PCI requester ID, look up the appropriate
> > implementation-defined
> > - * platform ID and/or the target device which receives transactions
> > on that
> > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > @target or
> > - * @id_out may be NULL if only the other is required. If @target
> > points to
> > - * a non-NULL device node pointer, only entries targeting that node
> > will be
> > - * matched; if it points to a NULL value, it will receive the device
> > node of
> > - * the first matching target phandle, with a reference held.
> > - *
> > - * Return: 0 on success or a standard error code on failure.
> > - */
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out)
> > -{
> > -	u32 map_mask, masked_rid;
> > -	int map_len;
> > -	const __be32 *map = NULL;
> > -
> > -	if (!np || !map_name || (!target && !id_out))
> > -		return -EINVAL;
> > -
> > -	map = of_get_property(np, map_name, &map_len);
> > -	if (!map) {
> > -		if (target)
> > -			return -ENODEV;
> > -		/* Otherwise, no map implies no translation */
> > -		*id_out = rid;
> > -		return 0;
> > -	}
> > -
> > -	if (!map_len || map_len % (4 * sizeof(*map))) {
> > -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > -			map_name, map_len);
> > -		return -EINVAL;
> > -	}
> > -
> > -	/* The default is to select all bits. */
> > -	map_mask = 0xffffffff;
> > -
> > -	/*
> > -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > -	 * If of_property_read_u32() fails, the default is used.
> > -	 */
> > -	if (map_mask_name)
> > -		of_property_read_u32(np, map_mask_name, &map_mask);
> > -
> > -	masked_rid = map_mask & rid;
> > -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > -		struct device_node *phandle_node;
> > -		u32 rid_base = be32_to_cpup(map + 0);
> > -		u32 phandle = be32_to_cpup(map + 1);
> > -		u32 out_base = be32_to_cpup(map + 2);
> > -		u32 rid_len = be32_to_cpup(map + 3);
> > -
> > -		if (rid_base & ~map_mask) {
> > -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > -				np, map_name, map_name,
> > -				map_mask, rid_base);
> > -			return -EFAULT;
> > -		}
> > -
> > -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > -			continue;
> > -
> > -		phandle_node = of_find_node_by_phandle(phandle);
> > -		if (!phandle_node)
> > -			return -ENODEV;
> > -
> > -		if (target) {
> > -			if (*target)
> > -				of_node_put(phandle_node);
> > -			else
> > -				*target = phandle_node;
> > -
> > -			if (*target != phandle_node)
> > -				continue;
> > -		}
> > -
> > -		if (id_out)
> > -			*id_out = masked_rid - rid_base + out_base;
> > -
> > -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > -			np, map_name, map_mask, rid_base, out_base,
> > -			rid_len, rid, masked_rid - rid_base + out_base);
> > -		return 0;
> > -	}
> > -
> > -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > -		np, map_name, rid, target && *target ? *target : NULL);
> > -	return -EFAULT;
> > -}
> > -
> >   #if IS_ENABLED(CONFIG_OF_IRQ)
> >   /**
> >    * of_irq_parse_pci - Resolve the interrupt for a PCI device diff
> > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index
> > 4fa654e..432b53c 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node
> *dn, const char *prefix,
> >   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> >   					struct device_node *master_np);
> >
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +	       const char *map_name, const char *map_mask_name,
> > +	       struct device_node **target, u32 *id_out);
> > +
> >   #else
> >
> >   static inline int of_get_dma_window(struct device_node *dn, const
> > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops
> *of_iommu_configure(struct device *dev,
> >   	return NULL;
> >   }
> >
> > +static inline int of_map_rid(struct device_node *np, u32 rid,
> > +			     const char *map_name, const char
> *map_mask_name,
> > +			     struct device_node **target, u32 *id_out) {
> > +	return -EINVAL;
> > +}
> > +
> >   #endif	/* CONFIG_OF_IOMMU */
> >
> >   extern struct of_device_id __iommu_of_table; diff --git
> > a/include/linux/of_pci.h b/include/linux/of_pci.h index
> > 091033a..a23b44a 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct
> device_node *parent,
> >   int of_get_pci_domain_nr(struct device_node *node);
> >   int of_pci_get_max_link_speed(struct device_node *node);
> >   void of_pci_check_probe_only(void);
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out);
> >   #else
> >   static inline struct device_node *of_pci_find_child_device(struct device_node
> *parent,
> >   					     unsigned int devfn)
> > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node
> *np)
> >   	return -1;
> >   }
> >
> > -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> > -			const char *map_name, const char *map_mask_name,
> > -			struct device_node **target, u32 *id_out)
> > -{
> > -	return -EINVAL;
> > -}
> > -
> >   static inline int
> >   of_pci_get_max_link_speed(struct device_node *node)
> >   {
> >

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAy
MDE4IDEwOjIzIFBNDQo+IFRvOiBOaXB1biBHdXB0YSA8bmlwdW4uZ3VwdGFAbnhwLmNvbT47IHJv
YmgrZHRAa2VybmVsLm9yZzsNCj4gZnJvd2FuZC5saXN0QGdtYWlsLmNvbQ0KPiBDYzogd2lsbC5k
ZWFjb25AYXJtLmNvbTsgbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0u
Y29tOw0KPiBoY2hAbHN0LmRlOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsgam9yb0A4Ynl0
ZXMub3JnOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IHNoYXduZ3VvQGtlcm5lbC5vcmc7
IGJoZWxnYWFzQGdvb2dsZS5jb207DQo+IGlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn
OyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy0NCj4g
ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IEJoYXJhdCBC
aHVzaGFuDQo+IDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsgc3R1eW9kZXJAZ21haWwuY29tOyBM
YXVyZW50aXUgVHVkb3INCj4gPGxhdXJlbnRpdS50dWRvckBueHAuY29tPjsgTGVvIExpIDxsZW95
YW5nLmxpQG54cC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi82IHYyXSBpb21tdTogb2Y6
IG1ha2Ugb2ZfcGNpX21hcF9yaWQoKSBhdmFpbGFibGUgZm9yDQo+IG90aGVyIGRldmljZXMgdG9v
DQo+IA0KPiBPbiAxNy8wNC8xOCAxMToyMSwgTmlwdW4gR3VwdGEgd3JvdGU6DQo+ID4gaW9tbXUt
bWFwIHByb3BlcnR5IGlzIGFsc28gdXNlZCBieSBkZXZpY2VzIHdpdGggZnNsLW1jLiBUaGlzIHBh
dGNoDQo+ID4gbW92ZXMgdGhlIG9mX3BjaV9tYXBfcmlkIHRvIGdlbmVyaWMgbG9jYXRpb24sIHNv
IHRoYXQgaXQgY2FuIGJlIHVzZWQNCj4gPiBieSBvdGhlciBidXNzZXMgdG9vLg0KDQpOaXB1biwg
cGxlYXNlIGNsYXJpZnkgdGhhdCBvbmx5IGZ1bmN0aW9uIG5hbWUgaXMgY2hhbmdlZCBhbmQgcmVz
dCBvZiBib2R5IGlzIHNhbWUuDQoNCj4gPg0KPiA+IFNpZ25lZC1vZmYtYnk6IE5pcHVuIEd1cHRh
IDxuaXB1bi5ndXB0YUBueHAuY29tPg0KPiA+IC0tLQ0KPiA+ICAgZHJpdmVycy9pb21tdS9vZl9p
b21tdS5jIHwgMTA2DQo+ID4gKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrLS0NCj4gDQo+IERvZXNuJ3QgdGhpcyBicmVhayAibXNpLXBhcmVudCIgcGFyc2luZyBm
b3IgIUNPTkZJR19PRl9JT01NVT8NCg0KWWVzLCB0aGlzIHdpbGwgYmUgYSBwcm9ibGVtIHdpdGgg
TVNJIA0KDQo+IEkgZ3Vlc3MgeW91DQo+IGRvbid0IHdhbnQgZnNsLW1jIHRvIGhhdmUgdG8gZGVw
ZW5kIG9uIFBDSSwgYnV0IHRoaXMgbG9va3MgbGlrZSBhIHN0ZXAgaW4gdGhlDQo+IHdyb25nIGRp
cmVjdGlvbi4NCj4gDQo+IEknbSBub3QgZW50aXJlbHkgc3VyZSB3aGVyZSBvZl9tYXBfcmlkKCkg
Zml0cyBiZXN0LCBidXQgZnJvbSBhIHF1aWNrIGxvb2sgYXJvdW5kDQo+IHRoZSBsZWFzdC13b3Jz
dCBvcHRpb24gbWlnaHQgYmUgZHJpdmVycy9vZi9vZl9hZGRyZXNzLmMsIHVubGVzcyBSb2IgYW5k
IEZyYW5rDQo+IGhhdmUgYSBiZXR0ZXIgaWRlYSBvZiB3aGVyZSBnZW5lcmljIERULWJhc2VkIElE
IHRyYW5zbGF0aW9uIHJvdXRpbmVzIGNvdWxkIGxpdmU/DQoNCmRyaXZlcnMvb2YvYWRkcmVzcy5j
IG1heSBiZSBwcm9wZXIgcGxhY2UgdG8gbW92ZSB1bnRpbCBzb21lb25lIGhhdmUgYmV0dGVyIGlk
ZWEuDQoNClRoYW5rcw0KLUJoYXJhdA0KDQo+IA0KPiA+ICAgZHJpdmVycy9vZi9pcnEuYyAgICAg
ICAgIHwgICA2ICstLQ0KPiA+ICAgZHJpdmVycy9wY2kvb2YuYyAgICAgICAgIHwgMTAxIC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gICBpbmNsdWRlL2xp
bnV4L29mX2lvbW11LmggfCAgMTEgKysrKysNCj4gPiAgIGluY2x1ZGUvbGludXgvb2ZfcGNpLmgg
ICB8ICAxMCAtLS0tLQ0KPiA+ICAgNSBmaWxlcyBjaGFuZ2VkLCAxMTcgaW5zZXJ0aW9ucygrKSwg
MTE3IGRlbGV0aW9ucygtKQ0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaW9tbXUvb2Zf
aW9tbXUuYyBiL2RyaXZlcnMvaW9tbXUvb2ZfaW9tbXUuYyBpbmRleA0KPiA+IDVjMzZhOGIuLjRl
NzcxMmYgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVycy9pb21tdS9vZl9pb21tdS5jDQo+ID4gKysr
IGIvZHJpdmVycy9pb21tdS9vZl9pb21tdS5jDQo+ID4gQEAgLTEzOCw2ICsxMzgsMTA2IEBAIHN0
YXRpYyBpbnQgb2ZfaW9tbXVfeGxhdGUoc3RydWN0IGRldmljZSAqZGV2LA0KPiA+ICAgCXJldHVy
biBvcHMtPm9mX3hsYXRlKGRldiwgaW9tbXVfc3BlYyk7DQo+ID4gICB9DQo+ID4NCj4gPiArLyoq
DQo+ID4gKyAqIG9mX21hcF9yaWQgLSBUcmFuc2xhdGUgYSByZXF1ZXN0ZXIgSUQgdGhyb3VnaCBh
IGRvd25zdHJlYW0gbWFwcGluZy4NCj4gPiArICogQG5wOiByb290IGNvbXBsZXggZGV2aWNlIG5v
ZGUuDQo+ID4gKyAqIEByaWQ6IGRldmljZSByZXF1ZXN0ZXIgSUQgdG8gbWFwLg0KPiA+ICsgKiBA
bWFwX25hbWU6IHByb3BlcnR5IG5hbWUgb2YgdGhlIG1hcCB0byB1c2UuDQo+ID4gKyAqIEBtYXBf
bWFza19uYW1lOiBvcHRpb25hbCBwcm9wZXJ0eSBuYW1lIG9mIHRoZSBtYXNrIHRvIHVzZS4NCj4g
PiArICogQHRhcmdldDogb3B0aW9uYWwgcG9pbnRlciB0byBhIHRhcmdldCBkZXZpY2Ugbm9kZS4N
Cj4gPiArICogQGlkX291dDogb3B0aW9uYWwgcG9pbnRlciB0byByZWNlaXZlIHRoZSB0cmFuc2xh
dGVkIElELg0KPiA+ICsgKg0KPiA+ICsgKiBHaXZlbiBhIGRldmljZSByZXF1ZXN0ZXIgSUQsIGxv
b2sgdXAgdGhlIGFwcHJvcHJpYXRlDQo+ID4gK2ltcGxlbWVudGF0aW9uLWRlZmluZWQNCj4gPiAr
ICogcGxhdGZvcm0gSUQgYW5kL29yIHRoZSB0YXJnZXQgZGV2aWNlIHdoaWNoIHJlY2VpdmVzIHRy
YW5zYWN0aW9ucw0KPiA+ICtvbiB0aGF0DQo+ID4gKyAqIElELCBhcyBwZXIgdGhlICJpb21tdS1t
YXAiIGFuZCAibXNpLW1hcCIgYmluZGluZ3MuIEVpdGhlciBvZg0KPiA+ICtAdGFyZ2V0IG9yDQo+
ID4gKyAqIEBpZF9vdXQgbWF5IGJlIE5VTEwgaWYgb25seSB0aGUgb3RoZXIgaXMgcmVxdWlyZWQu
IElmIEB0YXJnZXQNCj4gPiArcG9pbnRzIHRvDQo+ID4gKyAqIGEgbm9uLU5VTEwgZGV2aWNlIG5v
ZGUgcG9pbnRlciwgb25seSBlbnRyaWVzIHRhcmdldGluZyB0aGF0IG5vZGUNCj4gPiArd2lsbCBi
ZQ0KPiA+ICsgKiBtYXRjaGVkOyBpZiBpdCBwb2ludHMgdG8gYSBOVUxMIHZhbHVlLCBpdCB3aWxs
IHJlY2VpdmUgdGhlIGRldmljZQ0KPiA+ICtub2RlIG9mDQo+ID4gKyAqIHRoZSBmaXJzdCBtYXRj
aGluZyB0YXJnZXQgcGhhbmRsZSwgd2l0aCBhIHJlZmVyZW5jZSBoZWxkLg0KPiA+ICsgKg0KPiA+
ICsgKiBSZXR1cm46IDAgb24gc3VjY2VzcyBvciBhIHN0YW5kYXJkIGVycm9yIGNvZGUgb24gZmFp
bHVyZS4NCj4gPiArICovDQo+ID4gK2ludCBvZl9tYXBfcmlkKHN0cnVjdCBkZXZpY2Vfbm9kZSAq
bnAsIHUzMiByaWQsDQo+ID4gKwkJICAgY29uc3QgY2hhciAqbWFwX25hbWUsIGNvbnN0IGNoYXIg
Km1hcF9tYXNrX25hbWUsDQo+ID4gKwkJICAgc3RydWN0IGRldmljZV9ub2RlICoqdGFyZ2V0LCB1
MzIgKmlkX291dCkgew0KPiA+ICsJdTMyIG1hcF9tYXNrLCBtYXNrZWRfcmlkOw0KPiA+ICsJaW50
IG1hcF9sZW47DQo+ID4gKwljb25zdCBfX2JlMzIgKm1hcCA9IE5VTEw7DQo+ID4gKw0KPiA+ICsJ
aWYgKCFucCB8fCAhbWFwX25hbWUgfHwgKCF0YXJnZXQgJiYgIWlkX291dCkpDQo+ID4gKwkJcmV0
dXJuIC1FSU5WQUw7DQo+ID4gKw0KPiA+ICsJbWFwID0gb2ZfZ2V0X3Byb3BlcnR5KG5wLCBtYXBf
bmFtZSwgJm1hcF9sZW4pOw0KPiA+ICsJaWYgKCFtYXApIHsNCj4gPiArCQlpZiAodGFyZ2V0KQ0K
PiA+ICsJCQlyZXR1cm4gLUVOT0RFVjsNCj4gPiArCQkvKiBPdGhlcndpc2UsIG5vIG1hcCBpbXBs
aWVzIG5vIHRyYW5zbGF0aW9uICovDQo+ID4gKwkJKmlkX291dCA9IHJpZDsNCj4gPiArCQlyZXR1
cm4gMDsNCj4gPiArCX0NCj4gPiArDQo+ID4gKwlpZiAoIW1hcF9sZW4gfHwgbWFwX2xlbiAlICg0
ICogc2l6ZW9mKCptYXApKSkgew0KPiA+ICsJCXByX2VycigiJXBPRjogRXJyb3I6IEJhZCAlcyBs
ZW5ndGg6ICVkXG4iLCBucCwNCj4gPiArCQkJbWFwX25hbWUsIG1hcF9sZW4pOw0KPiA+ICsJCXJl
dHVybiAtRUlOVkFMOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCS8qIFRoZSBkZWZhdWx0IGlzIHRv
IHNlbGVjdCBhbGwgYml0cy4gKi8NCj4gPiArCW1hcF9tYXNrID0gMHhmZmZmZmZmZjsNCj4gPiAr
DQo+ID4gKwkvKg0KPiA+ICsJICogQ2FuIGJlIG92ZXJyaWRkZW4gYnkgIntpb21tdSxtc2l9LW1h
cC1tYXNrIiBwcm9wZXJ0eS4NCj4gPiArCSAqLw0KPiA+ICsJaWYgKG1hcF9tYXNrX25hbWUpDQo+
ID4gKwkJb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsIG1hcF9tYXNrX25hbWUsICZtYXBfbWFzayk7
DQo+ID4gKw0KPiA+ICsJbWFza2VkX3JpZCA9IG1hcF9tYXNrICYgcmlkOw0KPiA+ICsJZm9yICgg
OyBtYXBfbGVuID4gMDsgbWFwX2xlbiAtPSA0ICogc2l6ZW9mKCptYXApLCBtYXAgKz0gNCkgew0K
PiA+ICsJCXN0cnVjdCBkZXZpY2Vfbm9kZSAqcGhhbmRsZV9ub2RlOw0KPiA+ICsJCXUzMiByaWRf
YmFzZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAwKTsNCj4gPiArCQl1MzIgcGhhbmRsZSA9IGJlMzJf
dG9fY3B1cChtYXAgKyAxKTsNCj4gPiArCQl1MzIgb3V0X2Jhc2UgPSBiZTMyX3RvX2NwdXAobWFw
ICsgMik7DQo+ID4gKwkJdTMyIHJpZF9sZW4gPSBiZTMyX3RvX2NwdXAobWFwICsgMyk7DQo+ID4g
Kw0KPiA+ICsJCWlmIChyaWRfYmFzZSAmIH5tYXBfbWFzaykgew0KPiA+ICsJCQlwcl9lcnIoIiVw
T0Y6IEludmFsaWQgJXMgdHJhbnNsYXRpb24gLSAlcy1tYXNrICgweCV4KQ0KPiBpZ25vcmVzIHJp
ZC1iYXNlICgweCV4KVxuIiwNCj4gPiArCQkJCW5wLCBtYXBfbmFtZSwgbWFwX25hbWUsDQo+ID4g
KwkJCQltYXBfbWFzaywgcmlkX2Jhc2UpOw0KPiA+ICsJCQlyZXR1cm4gLUVGQVVMVDsNCj4gPiAr
CQl9DQo+ID4gKw0KPiA+ICsJCWlmIChtYXNrZWRfcmlkIDwgcmlkX2Jhc2UgfHwgbWFza2VkX3Jp
ZCA+PSByaWRfYmFzZSArIHJpZF9sZW4pDQo+ID4gKwkJCWNvbnRpbnVlOw0KPiA+ICsNCj4gPiAr
CQlwaGFuZGxlX25vZGUgPSBvZl9maW5kX25vZGVfYnlfcGhhbmRsZShwaGFuZGxlKTsNCj4gPiAr
CQlpZiAoIXBoYW5kbGVfbm9kZSkNCj4gPiArCQkJcmV0dXJuIC1FTk9ERVY7DQo+ID4gKw0KPiA+
ICsJCWlmICh0YXJnZXQpIHsNCj4gPiArCQkJaWYgKCp0YXJnZXQpDQo+ID4gKwkJCQlvZl9ub2Rl
X3B1dChwaGFuZGxlX25vZGUpOw0KPiA+ICsJCQllbHNlDQo+ID4gKwkJCQkqdGFyZ2V0ID0gcGhh
bmRsZV9ub2RlOw0KPiA+ICsNCj4gPiArCQkJaWYgKCp0YXJnZXQgIT0gcGhhbmRsZV9ub2RlKQ0K
PiA+ICsJCQkJY29udGludWU7DQo+ID4gKwkJfQ0KPiA+ICsNCj4gPiArCQlpZiAoaWRfb3V0KQ0K
PiA+ICsJCQkqaWRfb3V0ID0gbWFza2VkX3JpZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2U7DQo+ID4g
Kw0KPiA+ICsJCXByX2RlYnVnKCIlcE9GOiAlcywgdXNpbmcgbWFzayAlMDh4LCByaWQtYmFzZTog
JTA4eCwgb3V0LQ0KPiBiYXNlOiAlMDh4LCBsZW5ndGg6ICUwOHgsIHJpZDogJTA4eCAtPiAlMDh4
XG4iLA0KPiA+ICsJCQlucCwgbWFwX25hbWUsIG1hcF9tYXNrLCByaWRfYmFzZSwgb3V0X2Jhc2Us
DQo+ID4gKwkJCXJpZF9sZW4sIHJpZCwgbWFza2VkX3JpZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2Up
Ow0KPiA+ICsJCXJldHVybiAwOw0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCXByX2VycigiJXBPRjog
SW52YWxpZCAlcyB0cmFuc2xhdGlvbiAtIG5vIG1hdGNoIGZvciByaWQgMHgleCBvbg0KPiAlcE9G
XG4iLA0KPiA+ICsJCW5wLCBtYXBfbmFtZSwgcmlkLCB0YXJnZXQgJiYgKnRhcmdldCA/ICp0YXJn
ZXQgOiBOVUxMKTsNCj4gPiArCXJldHVybiAtRUZBVUxUOw0KPiA+ICt9DQo+ID4gKw0KPiA+ICAg
c3RydWN0IG9mX3BjaV9pb21tdV9hbGlhc19pbmZvIHsNCj4gPiAgIAlzdHJ1Y3QgZGV2aWNlICpk
ZXY7DQo+ID4gICAJc3RydWN0IGRldmljZV9ub2RlICpucDsNCj4gPiBAQCAtMTQ5LDkgKzI0OSw5
IEBAIHN0YXRpYyBpbnQgb2ZfcGNpX2lvbW11X2luaXQoc3RydWN0IHBjaV9kZXYgKnBkZXYsIHUx
Ng0KPiBhbGlhcywgdm9pZCAqZGF0YSkNCj4gPiAgIAlzdHJ1Y3Qgb2ZfcGhhbmRsZV9hcmdzIGlv
bW11X3NwZWMgPSB7IC5hcmdzX2NvdW50ID0gMSB9Ow0KPiA+ICAgCWludCBlcnI7DQo+ID4NCj4g
PiAtCWVyciA9IG9mX3BjaV9tYXBfcmlkKGluZm8tPm5wLCBhbGlhcywgImlvbW11LW1hcCIsDQo+
ID4gLQkJCSAgICAgImlvbW11LW1hcC1tYXNrIiwgJmlvbW11X3NwZWMubnAsDQo+ID4gLQkJCSAg
ICAgaW9tbXVfc3BlYy5hcmdzKTsNCj4gPiArCWVyciA9IG9mX21hcF9yaWQoaW5mby0+bnAsIGFs
aWFzLCAiaW9tbXUtbWFwIiwNCj4gPiArCQkJICJpb21tdS1tYXAtbWFzayIsICZpb21tdV9zcGVj
Lm5wLA0KPiA+ICsJCQkgaW9tbXVfc3BlYy5hcmdzKTsNCj4gDQo+IFN1cGVyLW5pdDogQXBwYXJl
bnRseSBJIG1pc3NlZCByZXdyYXBwaW5nIHRoaXMgdG8gMiBsaW5lcyBpbiBkODdiZWI3NDkyODEs
IGJ1dCBpZg0KPiBpdCdzIGJlaW5nIHRvdWNoZWQgYWdhaW4sIHRoYXQgd291bGQgYmUgbmljZSA7
KQ0KPiANCj4gUm9iaW4uDQo+IA0KPiA+ICAgCWlmIChlcnIpDQo+ID4gICAJCXJldHVybiBlcnIg
PT0gLUVOT0RFViA/IE5PX0lPTU1VIDogZXJyOw0KPiA+DQo+ID4gZGlmZiAtLWdpdCBhL2RyaXZl
cnMvb2YvaXJxLmMgYi9kcml2ZXJzL29mL2lycS5jIGluZGV4DQo+ID4gMDJhZDkzYS4uYjcyZWVl
YyAxMDA2NDQNCj4gPiAtLS0gYS9kcml2ZXJzL29mL2lycS5jDQo+ID4gKysrIGIvZHJpdmVycy9v
Zi9pcnEuYw0KPiA+IEBAIC0yMiw3ICsyMiw3IEBADQo+ID4gICAjaW5jbHVkZSA8bGludXgvbW9k
dWxlLmg+DQo+ID4gICAjaW5jbHVkZSA8bGludXgvb2YuaD4NCj4gPiAgICNpbmNsdWRlIDxsaW51
eC9vZl9pcnEuaD4NCj4gPiAtI2luY2x1ZGUgPGxpbnV4L29mX3BjaS5oPg0KPiA+ICsjaW5jbHVk
ZSA8bGludXgvb2ZfaW9tbXUuaD4NCj4gPiAgICNpbmNsdWRlIDxsaW51eC9zdHJpbmcuaD4NCj4g
PiAgICNpbmNsdWRlIDxsaW51eC9zbGFiLmg+DQo+ID4NCj4gPiBAQCAtNTg4LDggKzU4OCw4IEBA
IHN0YXRpYyB1MzIgX19vZl9tc2lfbWFwX3JpZChzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+IHN0cnVj
dCBkZXZpY2Vfbm9kZSAqKm5wLA0KPiA+ICAgCSAqICJtc2ktbWFwIiBwcm9wZXJ0eS4NCj4gPiAg
IAkgKi8NCj4gPiAgIAlmb3IgKHBhcmVudF9kZXYgPSBkZXY7IHBhcmVudF9kZXY7IHBhcmVudF9k
ZXYgPSBwYXJlbnRfZGV2LT5wYXJlbnQpDQo+ID4gLQkJaWYgKCFvZl9wY2lfbWFwX3JpZChwYXJl
bnRfZGV2LT5vZl9ub2RlLCByaWRfaW4sICJtc2ktbWFwIiwNCj4gPiAtCQkJCSAgICAibXNpLW1h
cC1tYXNrIiwgbnAsICZyaWRfb3V0KSkNCj4gPiArCQlpZiAoIW9mX21hcF9yaWQocGFyZW50X2Rl
di0+b2Zfbm9kZSwgcmlkX2luLCAibXNpLW1hcCIsDQo+ID4gKwkJCQkibXNpLW1hcC1tYXNrIiwg
bnAsICZyaWRfb3V0KSkNCj4gPiAgIAkJCWJyZWFrOw0KPiA+ICAgCXJldHVybiByaWRfb3V0Ow0K
PiA+ICAgfQ0KPiA+IGRpZmYgLS1naXQgYS9kcml2ZXJzL3BjaS9vZi5jIGIvZHJpdmVycy9wY2kv
b2YuYyBpbmRleA0KPiA+IGEyODM1NWMuLmQyY2ViYmUgMTAwNjQ0DQo+ID4gLS0tIGEvZHJpdmVy
cy9wY2kvb2YuYw0KPiA+ICsrKyBiL2RyaXZlcnMvcGNpL29mLmMNCj4gPiBAQCAtMzYyLDEwNyAr
MzYyLDYgQEAgaW50IG9mX3BjaV9nZXRfaG9zdF9icmlkZ2VfcmVzb3VyY2VzKHN0cnVjdA0KPiBk
ZXZpY2Vfbm9kZSAqZGV2LA0KPiA+ICAgRVhQT1JUX1NZTUJPTF9HUEwob2ZfcGNpX2dldF9ob3N0
X2JyaWRnZV9yZXNvdXJjZXMpOw0KPiA+ICAgI2VuZGlmIC8qIENPTkZJR19PRl9BRERSRVNTICov
DQo+ID4NCj4gPiAtLyoqDQo+ID4gLSAqIG9mX3BjaV9tYXBfcmlkIC0gVHJhbnNsYXRlIGEgcmVx
dWVzdGVyIElEIHRocm91Z2ggYSBkb3duc3RyZWFtIG1hcHBpbmcuDQo+ID4gLSAqIEBucDogcm9v
dCBjb21wbGV4IGRldmljZSBub2RlLg0KPiA+IC0gKiBAcmlkOiBQQ0kgcmVxdWVzdGVyIElEIHRv
IG1hcC4NCj4gPiAtICogQG1hcF9uYW1lOiBwcm9wZXJ0eSBuYW1lIG9mIHRoZSBtYXAgdG8gdXNl
Lg0KPiA+IC0gKiBAbWFwX21hc2tfbmFtZTogb3B0aW9uYWwgcHJvcGVydHkgbmFtZSBvZiB0aGUg
bWFzayB0byB1c2UuDQo+ID4gLSAqIEB0YXJnZXQ6IG9wdGlvbmFsIHBvaW50ZXIgdG8gYSB0YXJn
ZXQgZGV2aWNlIG5vZGUuDQo+ID4gLSAqIEBpZF9vdXQ6IG9wdGlvbmFsIHBvaW50ZXIgdG8gcmVj
ZWl2ZSB0aGUgdHJhbnNsYXRlZCBJRC4NCj4gPiAtICoNCj4gPiAtICogR2l2ZW4gYSBQQ0kgcmVx
dWVzdGVyIElELCBsb29rIHVwIHRoZSBhcHByb3ByaWF0ZQ0KPiA+IGltcGxlbWVudGF0aW9uLWRl
ZmluZWQNCj4gPiAtICogcGxhdGZvcm0gSUQgYW5kL29yIHRoZSB0YXJnZXQgZGV2aWNlIHdoaWNo
IHJlY2VpdmVzIHRyYW5zYWN0aW9ucw0KPiA+IG9uIHRoYXQNCj4gPiAtICogSUQsIGFzIHBlciB0
aGUgImlvbW11LW1hcCIgYW5kICJtc2ktbWFwIiBiaW5kaW5ncy4gRWl0aGVyIG9mDQo+ID4gQHRh
cmdldCBvcg0KPiA+IC0gKiBAaWRfb3V0IG1heSBiZSBOVUxMIGlmIG9ubHkgdGhlIG90aGVyIGlz
IHJlcXVpcmVkLiBJZiBAdGFyZ2V0DQo+ID4gcG9pbnRzIHRvDQo+ID4gLSAqIGEgbm9uLU5VTEwg
ZGV2aWNlIG5vZGUgcG9pbnRlciwgb25seSBlbnRyaWVzIHRhcmdldGluZyB0aGF0IG5vZGUNCj4g
PiB3aWxsIGJlDQo+ID4gLSAqIG1hdGNoZWQ7IGlmIGl0IHBvaW50cyB0byBhIE5VTEwgdmFsdWUs
IGl0IHdpbGwgcmVjZWl2ZSB0aGUgZGV2aWNlDQo+ID4gbm9kZSBvZg0KPiA+IC0gKiB0aGUgZmly
c3QgbWF0Y2hpbmcgdGFyZ2V0IHBoYW5kbGUsIHdpdGggYSByZWZlcmVuY2UgaGVsZC4NCj4gPiAt
ICoNCj4gPiAtICogUmV0dXJuOiAwIG9uIHN1Y2Nlc3Mgb3IgYSBzdGFuZGFyZCBlcnJvciBjb2Rl
IG9uIGZhaWx1cmUuDQo+ID4gLSAqLw0KPiA+IC1pbnQgb2ZfcGNpX21hcF9yaWQoc3RydWN0IGRl
dmljZV9ub2RlICpucCwgdTMyIHJpZCwNCj4gPiAtCQkgICBjb25zdCBjaGFyICptYXBfbmFtZSwg
Y29uc3QgY2hhciAqbWFwX21hc2tfbmFtZSwNCj4gPiAtCQkgICBzdHJ1Y3QgZGV2aWNlX25vZGUg
Kip0YXJnZXQsIHUzMiAqaWRfb3V0KQ0KPiA+IC17DQo+ID4gLQl1MzIgbWFwX21hc2ssIG1hc2tl
ZF9yaWQ7DQo+ID4gLQlpbnQgbWFwX2xlbjsNCj4gPiAtCWNvbnN0IF9fYmUzMiAqbWFwID0gTlVM
TDsNCj4gPiAtDQo+ID4gLQlpZiAoIW5wIHx8ICFtYXBfbmFtZSB8fCAoIXRhcmdldCAmJiAhaWRf
b3V0KSkNCj4gPiAtCQlyZXR1cm4gLUVJTlZBTDsNCj4gPiAtDQo+ID4gLQltYXAgPSBvZl9nZXRf
cHJvcGVydHkobnAsIG1hcF9uYW1lLCAmbWFwX2xlbik7DQo+ID4gLQlpZiAoIW1hcCkgew0KPiA+
IC0JCWlmICh0YXJnZXQpDQo+ID4gLQkJCXJldHVybiAtRU5PREVWOw0KPiA+IC0JCS8qIE90aGVy
d2lzZSwgbm8gbWFwIGltcGxpZXMgbm8gdHJhbnNsYXRpb24gKi8NCj4gPiAtCQkqaWRfb3V0ID0g
cmlkOw0KPiA+IC0JCXJldHVybiAwOw0KPiA+IC0JfQ0KPiA+IC0NCj4gPiAtCWlmICghbWFwX2xl
biB8fCBtYXBfbGVuICUgKDQgKiBzaXplb2YoKm1hcCkpKSB7DQo+ID4gLQkJcHJfZXJyKCIlcE9G
OiBFcnJvcjogQmFkICVzIGxlbmd0aDogJWRcbiIsIG5wLA0KPiA+IC0JCQltYXBfbmFtZSwgbWFw
X2xlbik7DQo+ID4gLQkJcmV0dXJuIC1FSU5WQUw7DQo+ID4gLQl9DQo+ID4gLQ0KPiA+IC0JLyog
VGhlIGRlZmF1bHQgaXMgdG8gc2VsZWN0IGFsbCBiaXRzLiAqLw0KPiA+IC0JbWFwX21hc2sgPSAw
eGZmZmZmZmZmOw0KPiA+IC0NCj4gPiAtCS8qDQo+ID4gLQkgKiBDYW4gYmUgb3ZlcnJpZGRlbiBi
eSAie2lvbW11LG1zaX0tbWFwLW1hc2siIHByb3BlcnR5Lg0KPiA+IC0JICogSWYgb2ZfcHJvcGVy
dHlfcmVhZF91MzIoKSBmYWlscywgdGhlIGRlZmF1bHQgaXMgdXNlZC4NCj4gPiAtCSAqLw0KPiA+
IC0JaWYgKG1hcF9tYXNrX25hbWUpDQo+ID4gLQkJb2ZfcHJvcGVydHlfcmVhZF91MzIobnAsIG1h
cF9tYXNrX25hbWUsICZtYXBfbWFzayk7DQo+ID4gLQ0KPiA+IC0JbWFza2VkX3JpZCA9IG1hcF9t
YXNrICYgcmlkOw0KPiA+IC0JZm9yICggOyBtYXBfbGVuID4gMDsgbWFwX2xlbiAtPSA0ICogc2l6
ZW9mKCptYXApLCBtYXAgKz0gNCkgew0KPiA+IC0JCXN0cnVjdCBkZXZpY2Vfbm9kZSAqcGhhbmRs
ZV9ub2RlOw0KPiA+IC0JCXUzMiByaWRfYmFzZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAwKTsNCj4g
PiAtCQl1MzIgcGhhbmRsZSA9IGJlMzJfdG9fY3B1cChtYXAgKyAxKTsNCj4gPiAtCQl1MzIgb3V0
X2Jhc2UgPSBiZTMyX3RvX2NwdXAobWFwICsgMik7DQo+ID4gLQkJdTMyIHJpZF9sZW4gPSBiZTMy
X3RvX2NwdXAobWFwICsgMyk7DQo+ID4gLQ0KPiA+IC0JCWlmIChyaWRfYmFzZSAmIH5tYXBfbWFz
aykgew0KPiA+IC0JCQlwcl9lcnIoIiVwT0Y6IEludmFsaWQgJXMgdHJhbnNsYXRpb24gLSAlcy1t
YXNrICgweCV4KQ0KPiBpZ25vcmVzIHJpZC1iYXNlICgweCV4KVxuIiwNCj4gPiAtCQkJCW5wLCBt
YXBfbmFtZSwgbWFwX25hbWUsDQo+ID4gLQkJCQltYXBfbWFzaywgcmlkX2Jhc2UpOw0KPiA+IC0J
CQlyZXR1cm4gLUVGQVVMVDsNCj4gPiAtCQl9DQo+ID4gLQ0KPiA+IC0JCWlmIChtYXNrZWRfcmlk
IDwgcmlkX2Jhc2UgfHwgbWFza2VkX3JpZCA+PSByaWRfYmFzZSArIHJpZF9sZW4pDQo+ID4gLQkJ
CWNvbnRpbnVlOw0KPiA+IC0NCj4gPiAtCQlwaGFuZGxlX25vZGUgPSBvZl9maW5kX25vZGVfYnlf
cGhhbmRsZShwaGFuZGxlKTsNCj4gPiAtCQlpZiAoIXBoYW5kbGVfbm9kZSkNCj4gPiAtCQkJcmV0
dXJuIC1FTk9ERVY7DQo+ID4gLQ0KPiA+IC0JCWlmICh0YXJnZXQpIHsNCj4gPiAtCQkJaWYgKCp0
YXJnZXQpDQo+ID4gLQkJCQlvZl9ub2RlX3B1dChwaGFuZGxlX25vZGUpOw0KPiA+IC0JCQllbHNl
DQo+ID4gLQkJCQkqdGFyZ2V0ID0gcGhhbmRsZV9ub2RlOw0KPiA+IC0NCj4gPiAtCQkJaWYgKCp0
YXJnZXQgIT0gcGhhbmRsZV9ub2RlKQ0KPiA+IC0JCQkJY29udGludWU7DQo+ID4gLQkJfQ0KPiA+
IC0NCj4gPiAtCQlpZiAoaWRfb3V0KQ0KPiA+IC0JCQkqaWRfb3V0ID0gbWFza2VkX3JpZCAtIHJp
ZF9iYXNlICsgb3V0X2Jhc2U7DQo+ID4gLQ0KPiA+IC0JCXByX2RlYnVnKCIlcE9GOiAlcywgdXNp
bmcgbWFzayAlMDh4LCByaWQtYmFzZTogJTA4eCwgb3V0LQ0KPiBiYXNlOiAlMDh4LCBsZW5ndGg6
ICUwOHgsIHJpZDogJTA4eCAtPiAlMDh4XG4iLA0KPiA+IC0JCQlucCwgbWFwX25hbWUsIG1hcF9t
YXNrLCByaWRfYmFzZSwgb3V0X2Jhc2UsDQo+ID4gLQkJCXJpZF9sZW4sIHJpZCwgbWFza2VkX3Jp
ZCAtIHJpZF9iYXNlICsgb3V0X2Jhc2UpOw0KPiA+IC0JCXJldHVybiAwOw0KPiA+IC0JfQ0KPiA+
IC0NCj4gPiAtCXByX2VycigiJXBPRjogSW52YWxpZCAlcyB0cmFuc2xhdGlvbiAtIG5vIG1hdGNo
IGZvciByaWQgMHgleCBvbg0KPiAlcE9GXG4iLA0KPiA+IC0JCW5wLCBtYXBfbmFtZSwgcmlkLCB0
YXJnZXQgJiYgKnRhcmdldCA/ICp0YXJnZXQgOiBOVUxMKTsNCj4gPiAtCXJldHVybiAtRUZBVUxU
Ow0KPiA+IC19DQo+ID4gLQ0KPiA+ICAgI2lmIElTX0VOQUJMRUQoQ09ORklHX09GX0lSUSkNCj4g
PiAgIC8qKg0KPiA+ICAgICogb2ZfaXJxX3BhcnNlX3BjaSAtIFJlc29sdmUgdGhlIGludGVycnVw
dCBmb3IgYSBQQ0kgZGV2aWNlIGRpZmYNCj4gPiAtLWdpdCBhL2luY2x1ZGUvbGludXgvb2ZfaW9t
bXUuaCBiL2luY2x1ZGUvbGludXgvb2ZfaW9tbXUuaCBpbmRleA0KPiA+IDRmYTY1NGUuLjQzMmI1
M2MgMTAwNjQ0DQo+ID4gLS0tIGEvaW5jbHVkZS9saW51eC9vZl9pb21tdS5oDQo+ID4gKysrIGIv
aW5jbHVkZS9saW51eC9vZl9pb21tdS5oDQo+ID4gQEAgLTE1LDYgKzE1LDEwIEBAIGV4dGVybiBp
bnQgb2ZfZ2V0X2RtYV93aW5kb3coc3RydWN0IGRldmljZV9ub2RlDQo+ICpkbiwgY29uc3QgY2hh
ciAqcHJlZml4LA0KPiA+ICAgZXh0ZXJuIGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgKm9mX2lvbW11
X2NvbmZpZ3VyZShzdHJ1Y3QgZGV2aWNlICpkZXYsDQo+ID4gICAJCQkJCXN0cnVjdCBkZXZpY2Vf
bm9kZSAqbWFzdGVyX25wKTsNCj4gPg0KPiA+ICtpbnQgb2ZfbWFwX3JpZChzdHJ1Y3QgZGV2aWNl
X25vZGUgKm5wLCB1MzIgcmlkLA0KPiA+ICsJICAgICAgIGNvbnN0IGNoYXIgKm1hcF9uYW1lLCBj
b25zdCBjaGFyICptYXBfbWFza19uYW1lLA0KPiA+ICsJICAgICAgIHN0cnVjdCBkZXZpY2Vfbm9k
ZSAqKnRhcmdldCwgdTMyICppZF9vdXQpOw0KPiA+ICsNCj4gPiAgICNlbHNlDQo+ID4NCj4gPiAg
IHN0YXRpYyBpbmxpbmUgaW50IG9mX2dldF9kbWFfd2luZG93KHN0cnVjdCBkZXZpY2Vfbm9kZSAq
ZG4sIGNvbnN0DQo+ID4gY2hhciAqcHJlZml4LCBAQCAtMzAsNiArMzQsMTMgQEAgc3RhdGljIGlu
bGluZSBjb25zdCBzdHJ1Y3QgaW9tbXVfb3BzDQo+ICpvZl9pb21tdV9jb25maWd1cmUoc3RydWN0
IGRldmljZSAqZGV2LA0KPiA+ICAgCXJldHVybiBOVUxMOw0KPiA+ICAgfQ0KPiA+DQo+ID4gK3N0
YXRpYyBpbmxpbmUgaW50IG9mX21hcF9yaWQoc3RydWN0IGRldmljZV9ub2RlICpucCwgdTMyIHJp
ZCwNCj4gPiArCQkJICAgICBjb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhcg0KPiAqbWFw
X21hc2tfbmFtZSwNCj4gPiArCQkJICAgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKip0YXJnZXQsIHUz
MiAqaWRfb3V0KSB7DQo+ID4gKwlyZXR1cm4gLUVJTlZBTDsNCj4gPiArfQ0KPiA+ICsNCj4gPiAg
ICNlbmRpZgkvKiBDT05GSUdfT0ZfSU9NTVUgKi8NCj4gPg0KPiA+ICAgZXh0ZXJuIHN0cnVjdCBv
Zl9kZXZpY2VfaWQgX19pb21tdV9vZl90YWJsZTsgZGlmZiAtLWdpdA0KPiA+IGEvaW5jbHVkZS9s
aW51eC9vZl9wY2kuaCBiL2luY2x1ZGUvbGludXgvb2ZfcGNpLmggaW5kZXgNCj4gPiAwOTEwMzNh
Li5hMjNiNDRhIDEwMDY0NA0KPiA+IC0tLSBhL2luY2x1ZGUvbGludXgvb2ZfcGNpLmgNCj4gPiAr
KysgYi9pbmNsdWRlL2xpbnV4L29mX3BjaS5oDQo+ID4gQEAgLTE3LDkgKzE3LDYgQEAgc3RydWN0
IGRldmljZV9ub2RlICpvZl9wY2lfZmluZF9jaGlsZF9kZXZpY2Uoc3RydWN0DQo+IGRldmljZV9u
b2RlICpwYXJlbnQsDQo+ID4gICBpbnQgb2ZfZ2V0X3BjaV9kb21haW5fbnIoc3RydWN0IGRldmlj
ZV9ub2RlICpub2RlKTsNCj4gPiAgIGludCBvZl9wY2lfZ2V0X21heF9saW5rX3NwZWVkKHN0cnVj
dCBkZXZpY2Vfbm9kZSAqbm9kZSk7DQo+ID4gICB2b2lkIG9mX3BjaV9jaGVja19wcm9iZV9vbmx5
KHZvaWQpOw0KPiA+IC1pbnQgb2ZfcGNpX21hcF9yaWQoc3RydWN0IGRldmljZV9ub2RlICpucCwg
dTMyIHJpZCwNCj4gPiAtCQkgICBjb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhciAqbWFw
X21hc2tfbmFtZSwNCj4gPiAtCQkgICBzdHJ1Y3QgZGV2aWNlX25vZGUgKip0YXJnZXQsIHUzMiAq
aWRfb3V0KTsNCj4gPiAgICNlbHNlDQo+ID4gICBzdGF0aWMgaW5saW5lIHN0cnVjdCBkZXZpY2Vf
bm9kZSAqb2ZfcGNpX2ZpbmRfY2hpbGRfZGV2aWNlKHN0cnVjdCBkZXZpY2Vfbm9kZQ0KPiAqcGFy
ZW50LA0KPiA+ICAgCQkJCQkgICAgIHVuc2lnbmVkIGludCBkZXZmbikNCj4gPiBAQCAtNDQsMTMg
KzQxLDYgQEAgc3RhdGljIGlubGluZSBpbnQgb2ZfcGNpX2dldF9kZXZmbihzdHJ1Y3QgZGV2aWNl
X25vZGUNCj4gKm5wKQ0KPiA+ICAgCXJldHVybiAtMTsNCj4gPiAgIH0NCj4gPg0KPiA+IC1zdGF0
aWMgaW5saW5lIGludCBvZl9wY2lfbWFwX3JpZChzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wLCB1MzIg
cmlkLA0KPiA+IC0JCQljb25zdCBjaGFyICptYXBfbmFtZSwgY29uc3QgY2hhciAqbWFwX21hc2tf
bmFtZSwNCj4gPiAtCQkJc3RydWN0IGRldmljZV9ub2RlICoqdGFyZ2V0LCB1MzIgKmlkX291dCkN
Cj4gPiAtew0KPiA+IC0JcmV0dXJuIC1FSU5WQUw7DQo+ID4gLX0NCj4gPiAtDQo+ID4gICBzdGF0
aWMgaW5saW5lIGludA0KPiA+ICAgb2ZfcGNpX2dldF9tYXhfbGlua19zcGVlZChzdHJ1Y3QgZGV2
aWNlX25vZGUgKm5vZGUpDQo+ID4gICB7DQo+ID4NCg==

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org;
> frowand.list@gmail.com
> Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com;
> hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org;
> m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com;
> iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-
> dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is same.

> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> >   	return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +		   const char *map_name, const char *map_mask_name,
> > +		   struct device_node **target, u32 *id_out) {
> > +	u32 map_mask, masked_rid;
> > +	int map_len;
> > +	const __be32 *map = NULL;
> > +
> > +	if (!np || !map_name || (!target && !id_out))
> > +		return -EINVAL;
> > +
> > +	map = of_get_property(np, map_name, &map_len);
> > +	if (!map) {
> > +		if (target)
> > +			return -ENODEV;
> > +		/* Otherwise, no map implies no translation */
> > +		*id_out = rid;
> > +		return 0;
> > +	}
> > +
> > +	if (!map_len || map_len % (4 * sizeof(*map))) {
> > +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +			map_name, map_len);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* The default is to select all bits. */
> > +	map_mask = 0xffffffff;
> > +
> > +	/*
> > +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > +	 */
> > +	if (map_mask_name)
> > +		of_property_read_u32(np, map_mask_name, &map_mask);
> > +
> > +	masked_rid = map_mask & rid;
> > +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +		struct device_node *phandle_node;
> > +		u32 rid_base = be32_to_cpup(map + 0);
> > +		u32 phandle = be32_to_cpup(map + 1);
> > +		u32 out_base = be32_to_cpup(map + 2);
> > +		u32 rid_len = be32_to_cpup(map + 3);
> > +
> > +		if (rid_base & ~map_mask) {
> > +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > +				np, map_name, map_name,
> > +				map_mask, rid_base);
> > +			return -EFAULT;
> > +		}
> > +
> > +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > +			continue;
> > +
> > +		phandle_node = of_find_node_by_phandle(phandle);
> > +		if (!phandle_node)
> > +			return -ENODEV;
> > +
> > +		if (target) {
> > +			if (*target)
> > +				of_node_put(phandle_node);
> > +			else
> > +				*target = phandle_node;
> > +
> > +			if (*target != phandle_node)
> > +				continue;
> > +		}
> > +
> > +		if (id_out)
> > +			*id_out = masked_rid - rid_base + out_base;
> > +
> > +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > +			np, map_name, map_mask, rid_base, out_base,
> > +			rid_len, rid, masked_rid - rid_base + out_base);
> > +		return 0;
> > +	}
> > +
> > +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > +		np, map_name, rid, target && *target ? *target : NULL);
> > +	return -EFAULT;
> > +}
> > +
> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)
> 
> Robin.
> 
> >   	if (err)
> >   		return err == -ENODEV ? NO_IOMMU : err;
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index
> > 02ad93a..b72eeec 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -22,7 +22,7 @@
> >   #include <linux/module.h>
> >   #include <linux/of.h>
> >   #include <linux/of_irq.h>
> > -#include <linux/of_pci.h>
> > +#include <linux/of_iommu.h>
> >   #include <linux/string.h>
> >   #include <linux/slab.h>
> >
> > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev,
> struct device_node **np,
> >   	 * "msi-map" property.
> >   	 */
> >   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> > -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > -				    "msi-map-mask", np, &rid_out))
> > +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > +				"msi-map-mask", np, &rid_out))
> >   			break;
> >   	return rid_out;
> >   }
> > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index
> > a28355c..d2cebbe 100644
> > --- a/drivers/pci/of.c
> > +++ b/drivers/pci/of.c
> > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> >   #endif /* CONFIG_OF_ADDRESS */
> >
> > -/**
> > - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> > - * @np: root complex device node.
> > - * @rid: PCI requester ID to map.
> > - * @map_name: property name of the map to use.
> > - * @map_mask_name: optional property name of the mask to use.
> > - * @target: optional pointer to a target device node.
> > - * @id_out: optional pointer to receive the translated ID.
> > - *
> > - * Given a PCI requester ID, look up the appropriate
> > implementation-defined
> > - * platform ID and/or the target device which receives transactions
> > on that
> > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > @target or
> > - * @id_out may be NULL if only the other is required. If @target
> > points to
> > - * a non-NULL device node pointer, only entries targeting that node
> > will be
> > - * matched; if it points to a NULL value, it will receive the device
> > node of
> > - * the first matching target phandle, with a reference held.
> > - *
> > - * Return: 0 on success or a standard error code on failure.
> > - */
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out)
> > -{
> > -	u32 map_mask, masked_rid;
> > -	int map_len;
> > -	const __be32 *map = NULL;
> > -
> > -	if (!np || !map_name || (!target && !id_out))
> > -		return -EINVAL;
> > -
> > -	map = of_get_property(np, map_name, &map_len);
> > -	if (!map) {
> > -		if (target)
> > -			return -ENODEV;
> > -		/* Otherwise, no map implies no translation */
> > -		*id_out = rid;
> > -		return 0;
> > -	}
> > -
> > -	if (!map_len || map_len % (4 * sizeof(*map))) {
> > -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > -			map_name, map_len);
> > -		return -EINVAL;
> > -	}
> > -
> > -	/* The default is to select all bits. */
> > -	map_mask = 0xffffffff;
> > -
> > -	/*
> > -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > -	 * If of_property_read_u32() fails, the default is used.
> > -	 */
> > -	if (map_mask_name)
> > -		of_property_read_u32(np, map_mask_name, &map_mask);
> > -
> > -	masked_rid = map_mask & rid;
> > -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > -		struct device_node *phandle_node;
> > -		u32 rid_base = be32_to_cpup(map + 0);
> > -		u32 phandle = be32_to_cpup(map + 1);
> > -		u32 out_base = be32_to_cpup(map + 2);
> > -		u32 rid_len = be32_to_cpup(map + 3);
> > -
> > -		if (rid_base & ~map_mask) {
> > -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > -				np, map_name, map_name,
> > -				map_mask, rid_base);
> > -			return -EFAULT;
> > -		}
> > -
> > -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > -			continue;
> > -
> > -		phandle_node = of_find_node_by_phandle(phandle);
> > -		if (!phandle_node)
> > -			return -ENODEV;
> > -
> > -		if (target) {
> > -			if (*target)
> > -				of_node_put(phandle_node);
> > -			else
> > -				*target = phandle_node;
> > -
> > -			if (*target != phandle_node)
> > -				continue;
> > -		}
> > -
> > -		if (id_out)
> > -			*id_out = masked_rid - rid_base + out_base;
> > -
> > -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > -			np, map_name, map_mask, rid_base, out_base,
> > -			rid_len, rid, masked_rid - rid_base + out_base);
> > -		return 0;
> > -	}
> > -
> > -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > -		np, map_name, rid, target && *target ? *target : NULL);
> > -	return -EFAULT;
> > -}
> > -
> >   #if IS_ENABLED(CONFIG_OF_IRQ)
> >   /**
> >    * of_irq_parse_pci - Resolve the interrupt for a PCI device diff
> > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index
> > 4fa654e..432b53c 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node
> *dn, const char *prefix,
> >   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> >   					struct device_node *master_np);
> >
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +	       const char *map_name, const char *map_mask_name,
> > +	       struct device_node **target, u32 *id_out);
> > +
> >   #else
> >
> >   static inline int of_get_dma_window(struct device_node *dn, const
> > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops
> *of_iommu_configure(struct device *dev,
> >   	return NULL;
> >   }
> >
> > +static inline int of_map_rid(struct device_node *np, u32 rid,
> > +			     const char *map_name, const char
> *map_mask_name,
> > +			     struct device_node **target, u32 *id_out) {
> > +	return -EINVAL;
> > +}
> > +
> >   #endif	/* CONFIG_OF_IOMMU */
> >
> >   extern struct of_device_id __iommu_of_table; diff --git
> > a/include/linux/of_pci.h b/include/linux/of_pci.h index
> > 091033a..a23b44a 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct
> device_node *parent,
> >   int of_get_pci_domain_nr(struct device_node *node);
> >   int of_pci_get_max_link_speed(struct device_node *node);
> >   void of_pci_check_probe_only(void);
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out);
> >   #else
> >   static inline struct device_node *of_pci_find_child_device(struct device_node
> *parent,
> >   					     unsigned int devfn)
> > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node
> *np)
> >   	return -1;
> >   }
> >
> > -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> > -			const char *map_name, const char *map_mask_name,
> > -			struct device_node **target, u32 *id_out)
> > -{
> > -	return -EINVAL;
> > -}
> > -
> >   static inline int
> >   of_pci_get_max_link_speed(struct device_node *node)
> >   {
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Bharat Bhushan]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
> frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org;
> hch-jcswGhMUV9g@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc-
> dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Bharat Bhushan
> <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor
> <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.

Nipun, please clarify that only function name is changed and rest of body is same.

> >
> > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU?

Yes, this will be a problem with MSI 

> I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.
> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?

drivers/of/address.c may be proper place to move until someone have better idea.

Thanks
-Bharat

> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c index
> > 5c36a8b..4e7712f 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -138,6 +138,106 @@ static int of_iommu_xlate(struct device *dev,
> >   	return ops->of_xlate(dev, iommu_spec);
> >   }
> >
> > +/**
> > + * of_map_rid - Translate a requester ID through a downstream mapping.
> > + * @np: root complex device node.
> > + * @rid: device requester ID to map.
> > + * @map_name: property name of the map to use.
> > + * @map_mask_name: optional property name of the mask to use.
> > + * @target: optional pointer to a target device node.
> > + * @id_out: optional pointer to receive the translated ID.
> > + *
> > + * Given a device requester ID, look up the appropriate
> > +implementation-defined
> > + * platform ID and/or the target device which receives transactions
> > +on that
> > + * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > +@target or
> > + * @id_out may be NULL if only the other is required. If @target
> > +points to
> > + * a non-NULL device node pointer, only entries targeting that node
> > +will be
> > + * matched; if it points to a NULL value, it will receive the device
> > +node of
> > + * the first matching target phandle, with a reference held.
> > + *
> > + * Return: 0 on success or a standard error code on failure.
> > + */
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +		   const char *map_name, const char *map_mask_name,
> > +		   struct device_node **target, u32 *id_out) {
> > +	u32 map_mask, masked_rid;
> > +	int map_len;
> > +	const __be32 *map = NULL;
> > +
> > +	if (!np || !map_name || (!target && !id_out))
> > +		return -EINVAL;
> > +
> > +	map = of_get_property(np, map_name, &map_len);
> > +	if (!map) {
> > +		if (target)
> > +			return -ENODEV;
> > +		/* Otherwise, no map implies no translation */
> > +		*id_out = rid;
> > +		return 0;
> > +	}
> > +
> > +	if (!map_len || map_len % (4 * sizeof(*map))) {
> > +		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > +			map_name, map_len);
> > +		return -EINVAL;
> > +	}
> > +
> > +	/* The default is to select all bits. */
> > +	map_mask = 0xffffffff;
> > +
> > +	/*
> > +	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > +	 */
> > +	if (map_mask_name)
> > +		of_property_read_u32(np, map_mask_name, &map_mask);
> > +
> > +	masked_rid = map_mask & rid;
> > +	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > +		struct device_node *phandle_node;
> > +		u32 rid_base = be32_to_cpup(map + 0);
> > +		u32 phandle = be32_to_cpup(map + 1);
> > +		u32 out_base = be32_to_cpup(map + 2);
> > +		u32 rid_len = be32_to_cpup(map + 3);
> > +
> > +		if (rid_base & ~map_mask) {
> > +			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > +				np, map_name, map_name,
> > +				map_mask, rid_base);
> > +			return -EFAULT;
> > +		}
> > +
> > +		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > +			continue;
> > +
> > +		phandle_node = of_find_node_by_phandle(phandle);
> > +		if (!phandle_node)
> > +			return -ENODEV;
> > +
> > +		if (target) {
> > +			if (*target)
> > +				of_node_put(phandle_node);
> > +			else
> > +				*target = phandle_node;
> > +
> > +			if (*target != phandle_node)
> > +				continue;
> > +		}
> > +
> > +		if (id_out)
> > +			*id_out = masked_rid - rid_base + out_base;
> > +
> > +		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > +			np, map_name, map_mask, rid_base, out_base,
> > +			rid_len, rid, masked_rid - rid_base + out_base);
> > +		return 0;
> > +	}
> > +
> > +	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > +		np, map_name, rid, target && *target ? *target : NULL);
> > +	return -EFAULT;
> > +}
> > +
> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)
> 
> Robin.
> 
> >   	if (err)
> >   		return err == -ENODEV ? NO_IOMMU : err;
> >
> > diff --git a/drivers/of/irq.c b/drivers/of/irq.c index
> > 02ad93a..b72eeec 100644
> > --- a/drivers/of/irq.c
> > +++ b/drivers/of/irq.c
> > @@ -22,7 +22,7 @@
> >   #include <linux/module.h>
> >   #include <linux/of.h>
> >   #include <linux/of_irq.h>
> > -#include <linux/of_pci.h>
> > +#include <linux/of_iommu.h>
> >   #include <linux/string.h>
> >   #include <linux/slab.h>
> >
> > @@ -588,8 +588,8 @@ static u32 __of_msi_map_rid(struct device *dev,
> struct device_node **np,
> >   	 * "msi-map" property.
> >   	 */
> >   	for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent)
> > -		if (!of_pci_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > -				    "msi-map-mask", np, &rid_out))
> > +		if (!of_map_rid(parent_dev->of_node, rid_in, "msi-map",
> > +				"msi-map-mask", np, &rid_out))
> >   			break;
> >   	return rid_out;
> >   }
> > diff --git a/drivers/pci/of.c b/drivers/pci/of.c index
> > a28355c..d2cebbe 100644
> > --- a/drivers/pci/of.c
> > +++ b/drivers/pci/of.c
> > @@ -362,107 +362,6 @@ int of_pci_get_host_bridge_resources(struct
> device_node *dev,
> >   EXPORT_SYMBOL_GPL(of_pci_get_host_bridge_resources);
> >   #endif /* CONFIG_OF_ADDRESS */
> >
> > -/**
> > - * of_pci_map_rid - Translate a requester ID through a downstream mapping.
> > - * @np: root complex device node.
> > - * @rid: PCI requester ID to map.
> > - * @map_name: property name of the map to use.
> > - * @map_mask_name: optional property name of the mask to use.
> > - * @target: optional pointer to a target device node.
> > - * @id_out: optional pointer to receive the translated ID.
> > - *
> > - * Given a PCI requester ID, look up the appropriate
> > implementation-defined
> > - * platform ID and/or the target device which receives transactions
> > on that
> > - * ID, as per the "iommu-map" and "msi-map" bindings. Either of
> > @target or
> > - * @id_out may be NULL if only the other is required. If @target
> > points to
> > - * a non-NULL device node pointer, only entries targeting that node
> > will be
> > - * matched; if it points to a NULL value, it will receive the device
> > node of
> > - * the first matching target phandle, with a reference held.
> > - *
> > - * Return: 0 on success or a standard error code on failure.
> > - */
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out)
> > -{
> > -	u32 map_mask, masked_rid;
> > -	int map_len;
> > -	const __be32 *map = NULL;
> > -
> > -	if (!np || !map_name || (!target && !id_out))
> > -		return -EINVAL;
> > -
> > -	map = of_get_property(np, map_name, &map_len);
> > -	if (!map) {
> > -		if (target)
> > -			return -ENODEV;
> > -		/* Otherwise, no map implies no translation */
> > -		*id_out = rid;
> > -		return 0;
> > -	}
> > -
> > -	if (!map_len || map_len % (4 * sizeof(*map))) {
> > -		pr_err("%pOF: Error: Bad %s length: %d\n", np,
> > -			map_name, map_len);
> > -		return -EINVAL;
> > -	}
> > -
> > -	/* The default is to select all bits. */
> > -	map_mask = 0xffffffff;
> > -
> > -	/*
> > -	 * Can be overridden by "{iommu,msi}-map-mask" property.
> > -	 * If of_property_read_u32() fails, the default is used.
> > -	 */
> > -	if (map_mask_name)
> > -		of_property_read_u32(np, map_mask_name, &map_mask);
> > -
> > -	masked_rid = map_mask & rid;
> > -	for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
> > -		struct device_node *phandle_node;
> > -		u32 rid_base = be32_to_cpup(map + 0);
> > -		u32 phandle = be32_to_cpup(map + 1);
> > -		u32 out_base = be32_to_cpup(map + 2);
> > -		u32 rid_len = be32_to_cpup(map + 3);
> > -
> > -		if (rid_base & ~map_mask) {
> > -			pr_err("%pOF: Invalid %s translation - %s-mask (0x%x)
> ignores rid-base (0x%x)\n",
> > -				np, map_name, map_name,
> > -				map_mask, rid_base);
> > -			return -EFAULT;
> > -		}
> > -
> > -		if (masked_rid < rid_base || masked_rid >= rid_base + rid_len)
> > -			continue;
> > -
> > -		phandle_node = of_find_node_by_phandle(phandle);
> > -		if (!phandle_node)
> > -			return -ENODEV;
> > -
> > -		if (target) {
> > -			if (*target)
> > -				of_node_put(phandle_node);
> > -			else
> > -				*target = phandle_node;
> > -
> > -			if (*target != phandle_node)
> > -				continue;
> > -		}
> > -
> > -		if (id_out)
> > -			*id_out = masked_rid - rid_base + out_base;
> > -
> > -		pr_debug("%pOF: %s, using mask %08x, rid-base: %08x, out-
> base: %08x, length: %08x, rid: %08x -> %08x\n",
> > -			np, map_name, map_mask, rid_base, out_base,
> > -			rid_len, rid, masked_rid - rid_base + out_base);
> > -		return 0;
> > -	}
> > -
> > -	pr_err("%pOF: Invalid %s translation - no match for rid 0x%x on
> %pOF\n",
> > -		np, map_name, rid, target && *target ? *target : NULL);
> > -	return -EFAULT;
> > -}
> > -
> >   #if IS_ENABLED(CONFIG_OF_IRQ)
> >   /**
> >    * of_irq_parse_pci - Resolve the interrupt for a PCI device diff
> > --git a/include/linux/of_iommu.h b/include/linux/of_iommu.h index
> > 4fa654e..432b53c 100644
> > --- a/include/linux/of_iommu.h
> > +++ b/include/linux/of_iommu.h
> > @@ -15,6 +15,10 @@ extern int of_get_dma_window(struct device_node
> *dn, const char *prefix,
> >   extern const struct iommu_ops *of_iommu_configure(struct device *dev,
> >   					struct device_node *master_np);
> >
> > +int of_map_rid(struct device_node *np, u32 rid,
> > +	       const char *map_name, const char *map_mask_name,
> > +	       struct device_node **target, u32 *id_out);
> > +
> >   #else
> >
> >   static inline int of_get_dma_window(struct device_node *dn, const
> > char *prefix, @@ -30,6 +34,13 @@ static inline const struct iommu_ops
> *of_iommu_configure(struct device *dev,
> >   	return NULL;
> >   }
> >
> > +static inline int of_map_rid(struct device_node *np, u32 rid,
> > +			     const char *map_name, const char
> *map_mask_name,
> > +			     struct device_node **target, u32 *id_out) {
> > +	return -EINVAL;
> > +}
> > +
> >   #endif	/* CONFIG_OF_IOMMU */
> >
> >   extern struct of_device_id __iommu_of_table; diff --git
> > a/include/linux/of_pci.h b/include/linux/of_pci.h index
> > 091033a..a23b44a 100644
> > --- a/include/linux/of_pci.h
> > +++ b/include/linux/of_pci.h
> > @@ -17,9 +17,6 @@ struct device_node *of_pci_find_child_device(struct
> device_node *parent,
> >   int of_get_pci_domain_nr(struct device_node *node);
> >   int of_pci_get_max_link_speed(struct device_node *node);
> >   void of_pci_check_probe_only(void);
> > -int of_pci_map_rid(struct device_node *np, u32 rid,
> > -		   const char *map_name, const char *map_mask_name,
> > -		   struct device_node **target, u32 *id_out);
> >   #else
> >   static inline struct device_node *of_pci_find_child_device(struct device_node
> *parent,
> >   					     unsigned int devfn)
> > @@ -44,13 +41,6 @@ static inline int of_pci_get_devfn(struct device_node
> *np)
> >   	return -1;
> >   }
> >
> > -static inline int of_pci_map_rid(struct device_node *np, u32 rid,
> > -			const char *map_name, const char *map_mask_name,
> > -			struct device_node **target, u32 *id_out)
> > -{
> > -	return -EINVAL;
> > -}
> > -
> >   static inline int
> >   of_pci_get_max_link_speed(struct device_node *node)
> >   {
> >

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org;
> frowand.list@gmail.com
> Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com;
> hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org;
> m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com;
> iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-
> dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.

Thanks for pointing out.
Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case.

> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?
> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >

[...]

> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)

Sure.. I'll take care of this in the next version :)

Regards,
Nipun

[PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt at kernel.org;
> frowand.list at gmail.com
> Cc: will.deacon at arm.com; mark.rutland at arm.com; catalin.marinas at arm.com;
> hch at lst.de; gregkh at linuxfoundation.org; joro at 8bytes.org;
> m.szyprowski at samsung.com; shawnguo at kernel.org; bhelgaas at google.com;
> iommu at lists.linux-foundation.org; linux-kernel at vger.kernel.org;
> devicetree at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linuxppc-
> dev at lists.ozlabs.org; linux-pci at vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder at gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.

Thanks for pointing out.
Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case.

> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?
> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >

[...]

> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)

Sure.. I'll take care of this in the next version :)

Regards,
Nipun

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9iaW4gTXVycGh5IFtt
YWlsdG86cm9iaW4ubXVycGh5QGFybS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDE3LCAy
MDE4IDEwOjIzIFBNDQo+IFRvOiBOaXB1biBHdXB0YSA8bmlwdW4uZ3VwdGFAbnhwLmNvbT47IHJv
YmgrZHRAa2VybmVsLm9yZzsNCj4gZnJvd2FuZC5saXN0QGdtYWlsLmNvbQ0KPiBDYzogd2lsbC5k
ZWFjb25AYXJtLmNvbTsgbWFyay5ydXRsYW5kQGFybS5jb207IGNhdGFsaW4ubWFyaW5hc0Bhcm0u
Y29tOw0KPiBoY2hAbHN0LmRlOyBncmVna2hAbGludXhmb3VuZGF0aW9uLm9yZzsgam9yb0A4Ynl0
ZXMub3JnOw0KPiBtLnN6eXByb3dza2lAc2Ftc3VuZy5jb207IHNoYXduZ3VvQGtlcm5lbC5vcmc7
IGJoZWxnYWFzQGdvb2dsZS5jb207DQo+IGlvbW11QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3Jn
OyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOw0KPiBkZXZpY2V0cmVlQHZnZXIua2VybmVs
Lm9yZzsgbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eHBwYy0NCj4g
ZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LXBjaUB2Z2VyLmtlcm5lbC5vcmc7IEJoYXJhdCBC
aHVzaGFuDQo+IDxiaGFyYXQuYmh1c2hhbkBueHAuY29tPjsgc3R1eW9kZXJAZ21haWwuY29tOyBM
YXVyZW50aXUgVHVkb3INCj4gPGxhdXJlbnRpdS50dWRvckBueHAuY29tPjsgTGVvIExpIDxsZW95
YW5nLmxpQG54cC5jb20+DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMi82IHYyXSBpb21tdTogb2Y6
IG1ha2Ugb2ZfcGNpX21hcF9yaWQoKSBhdmFpbGFibGUgZm9yDQo+IG90aGVyIGRldmljZXMgdG9v
DQo+IA0KPiBPbiAxNy8wNC8xOCAxMToyMSwgTmlwdW4gR3VwdGEgd3JvdGU6DQo+ID4gaW9tbXUt
bWFwIHByb3BlcnR5IGlzIGFsc28gdXNlZCBieSBkZXZpY2VzIHdpdGggZnNsLW1jLiBUaGlzIHBh
dGNoDQo+ID4gbW92ZXMgdGhlIG9mX3BjaV9tYXBfcmlkIHRvIGdlbmVyaWMgbG9jYXRpb24sIHNv
IHRoYXQgaXQgY2FuIGJlIHVzZWQNCj4gPiBieSBvdGhlciBidXNzZXMgdG9vLg0KPiA+DQo+ID4g
U2lnbmVkLW9mZi1ieTogTmlwdW4gR3VwdGEgPG5pcHVuLmd1cHRhQG54cC5jb20+DQo+ID4gLS0t
DQo+ID4gICBkcml2ZXJzL2lvbW11L29mX2lvbW11LmMgfCAxMDYNCj4gPiArKysrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLQ0KPiANCj4gRG9lc24ndCB0aGlzIGJy
ZWFrICJtc2ktcGFyZW50IiBwYXJzaW5nIGZvciAhQ09ORklHX09GX0lPTU1VPyBJIGd1ZXNzIHlv
dQ0KPiBkb24ndCB3YW50IGZzbC1tYyB0byBoYXZlIHRvIGRlcGVuZCBvbiBQQ0ksIGJ1dCB0aGlz
IGxvb2tzIGxpa2UgYSBzdGVwIGluIHRoZQ0KPiB3cm9uZyBkaXJlY3Rpb24uDQoNClRoYW5rcyBm
b3IgcG9pbnRpbmcgb3V0Lg0KQWdyZWUsIHRoaXMgd2lsbCBicmVhayAibXNpLXBhcmVudCIgcGFy
c2luZyBmb3IgIUNPTkZJR19PRl9JT01NVSBjYXNlLg0KDQo+IA0KPiBJJ20gbm90IGVudGlyZWx5
IHN1cmUgd2hlcmUgb2ZfbWFwX3JpZCgpIGZpdHMgYmVzdCwgYnV0IGZyb20gYSBxdWljayBsb29r
IGFyb3VuZA0KPiB0aGUgbGVhc3Qtd29yc3Qgb3B0aW9uIG1pZ2h0IGJlIGRyaXZlcnMvb2Yvb2Zf
YWRkcmVzcy5jLCB1bmxlc3MgUm9iIGFuZCBGcmFuaw0KPiBoYXZlIGEgYmV0dGVyIGlkZWEgb2Yg
d2hlcmUgZ2VuZXJpYyBEVC1iYXNlZCBJRCB0cmFuc2xhdGlvbiByb3V0aW5lcyBjb3VsZCBsaXZl
Pw0KPiANCj4gPiAgIGRyaXZlcnMvb2YvaXJxLmMgICAgICAgICB8ICAgNiArLS0NCj4gPiAgIGRy
aXZlcnMvcGNpL29mLmMgICAgICAgICB8IDEwMSAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICAgaW5jbHVkZS9saW51eC9vZl9pb21tdS5oIHwgIDExICsr
KysrDQo+ID4gICBpbmNsdWRlL2xpbnV4L29mX3BjaS5oICAgfCAgMTAgLS0tLS0NCj4gPiAgIDUg
ZmlsZXMgY2hhbmdlZCwgMTE3IGluc2VydGlvbnMoKyksIDExNyBkZWxldGlvbnMoLSkNCj4gPg0K
DQpbLi4uXQ0KDQo+ID4gICBzdHJ1Y3Qgb2ZfcGNpX2lvbW11X2FsaWFzX2luZm8gew0KPiA+ICAg
CXN0cnVjdCBkZXZpY2UgKmRldjsNCj4gPiAgIAlzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+
IEBAIC0xNDksOSArMjQ5LDkgQEAgc3RhdGljIGludCBvZl9wY2lfaW9tbXVfaW5pdChzdHJ1Y3Qg
cGNpX2RldiAqcGRldiwgdTE2DQo+IGFsaWFzLCB2b2lkICpkYXRhKQ0KPiA+ICAgCXN0cnVjdCBv
Zl9waGFuZGxlX2FyZ3MgaW9tbXVfc3BlYyA9IHsgLmFyZ3NfY291bnQgPSAxIH07DQo+ID4gICAJ
aW50IGVycjsNCj4gPg0KPiA+IC0JZXJyID0gb2ZfcGNpX21hcF9yaWQoaW5mby0+bnAsIGFsaWFz
LCAiaW9tbXUtbWFwIiwNCj4gPiAtCQkJICAgICAiaW9tbXUtbWFwLW1hc2siLCAmaW9tbXVfc3Bl
Yy5ucCwNCj4gPiAtCQkJICAgICBpb21tdV9zcGVjLmFyZ3MpOw0KPiA+ICsJZXJyID0gb2ZfbWFw
X3JpZChpbmZvLT5ucCwgYWxpYXMsICJpb21tdS1tYXAiLA0KPiA+ICsJCQkgImlvbW11LW1hcC1t
YXNrIiwgJmlvbW11X3NwZWMubnAsDQo+ID4gKwkJCSBpb21tdV9zcGVjLmFyZ3MpOw0KPiANCj4g
U3VwZXItbml0OiBBcHBhcmVudGx5IEkgbWlzc2VkIHJld3JhcHBpbmcgdGhpcyB0byAyIGxpbmVz
IGluIGQ4N2JlYjc0OTI4MSwgYnV0IGlmDQo+IGl0J3MgYmVpbmcgdG91Y2hlZCBhZ2FpbiwgdGhh
dCB3b3VsZCBiZSBuaWNlIDspDQoNClN1cmUuLiBJJ2xsIHRha2UgY2FyZSBvZiB0aGlzIGluIHRo
ZSBuZXh0IHZlcnNpb24gOikNCg0KUmVnYXJkcywNCk5pcHVuDQo=

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta@nxp.com>; robh+dt@kernel.org;
> frowand.list@gmail.com
> Cc: will.deacon@arm.com; mark.rutland@arm.com; catalin.marinas@arm.com;
> hch@lst.de; gregkh@linuxfoundation.org; joro@8bytes.org;
> m.szyprowski@samsung.com; shawnguo@kernel.org; bhelgaas@google.com;
> iommu@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linuxppc-
> dev@lists.ozlabs.org; linux-pci@vger.kernel.org; Bharat Bhushan
> <bharat.bhushan@nxp.com>; stuyoder@gmail.com; Laurentiu Tudor
> <laurentiu.tudor@nxp.com>; Leo Li <leoyang.li@nxp.com>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.

Thanks for pointing out.
Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case.

> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?
> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >

[...]

> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)

Sure.. I'll take care of this in the next version :)

Regards,
Nipun
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for other devices too

[Nipun Gupta]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy-5wv7dgnIgG8@public.gmane.org]
> Sent: Tuesday, April 17, 2018 10:23 PM
> To: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>; robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org;
> frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
> Cc: will.deacon-5wv7dgnIgG8@public.gmane.org; mark.rutland-5wv7dgnIgG8@public.gmane.org; catalin.marinas-5wv7dgnIgG8@public.gmane.org;
> hch-jcswGhMUV9g@public.gmane.org; gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; shawnguo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linuxppc-
> dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Bharat Bhushan
> <bharat.bhushan-3arQi8VN3Tc@public.gmane.org>; stuyoder-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org; Laurentiu Tudor
> <laurentiu.tudor-3arQi8VN3Tc@public.gmane.org>; Leo Li <leoyang.li-3arQi8VN3Tc@public.gmane.org>
> Subject: Re: [PATCH 2/6 v2] iommu: of: make of_pci_map_rid() available for
> other devices too
> 
> On 17/04/18 11:21, Nipun Gupta wrote:
> > iommu-map property is also used by devices with fsl-mc. This patch
> > moves the of_pci_map_rid to generic location, so that it can be used
> > by other busses too.
> >
> > Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
> > ---
> >   drivers/iommu/of_iommu.c | 106
> > +++++++++++++++++++++++++++++++++++++++++++++--
> 
> Doesn't this break "msi-parent" parsing for !CONFIG_OF_IOMMU? I guess you
> don't want fsl-mc to have to depend on PCI, but this looks like a step in the
> wrong direction.

Thanks for pointing out.
Agree, this will break "msi-parent" parsing for !CONFIG_OF_IOMMU case.

> 
> I'm not entirely sure where of_map_rid() fits best, but from a quick look around
> the least-worst option might be drivers/of/of_address.c, unless Rob and Frank
> have a better idea of where generic DT-based ID translation routines could live?
> 
> >   drivers/of/irq.c         |   6 +--
> >   drivers/pci/of.c         | 101 --------------------------------------------
> >   include/linux/of_iommu.h |  11 +++++
> >   include/linux/of_pci.h   |  10 -----
> >   5 files changed, 117 insertions(+), 117 deletions(-)
> >

[...]

> >   struct of_pci_iommu_alias_info {
> >   	struct device *dev;
> >   	struct device_node *np;
> > @@ -149,9 +249,9 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16
> alias, void *data)
> >   	struct of_phandle_args iommu_spec = { .args_count = 1 };
> >   	int err;
> >
> > -	err = of_pci_map_rid(info->np, alias, "iommu-map",
> > -			     "iommu-map-mask", &iommu_spec.np,
> > -			     iommu_spec.args);
> > +	err = of_map_rid(info->np, alias, "iommu-map",
> > +			 "iommu-map-mask", &iommu_spec.np,
> > +			 iommu_spec.args);
> 
> Super-nit: Apparently I missed rewrapping this to 2 lines in d87beb749281, but if
> it's being touched again, that would be nice ;)

Sure.. I'll take care of this in the next version :)

Regards,
Nipun

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+				struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec = { .args_count = 1 };
+	int err;
+
+	err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
+	if (err)
+		return err == -ENODEV ? NO_IOMMU : err;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+				struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec = { .args_count = 1 };
+	int err;
+
+	err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
+	if (err)
+		return err == -ENODEV ? NO_IOMMU : err;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+				struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec = { .args_count = 1 };
+	int err;
+
+	err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
+	if (err)
+		return err == -ENODEV ? NO_IOMMU : err;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 3/6 v2] iommu: support iommu configuration for fsl-mc devices

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/iommu/of_iommu.c | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 4e7712f..af4fc3b 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -24,6 +24,7 @@
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
 #include <linux/slab.h>
+#include <linux/fsl/mc.h>
 
 #define NO_IOMMU	1
 
@@ -260,6 +261,23 @@ static int of_pci_iommu_init(struct pci_dev *pdev, u16 alias, void *data)
 	return err;
 }
 
+static int of_fsl_mc_iommu_init(struct fsl_mc_device *mc_dev,
+				struct device_node *master_np)
+{
+	struct of_phandle_args iommu_spec = { .args_count = 1 };
+	int err;
+
+	err = of_map_rid(master_np, mc_dev->icid, "iommu-map",
+			 "iommu-map-mask", &iommu_spec.np,
+			 iommu_spec.args);
+	if (err)
+		return err == -ENODEV ? NO_IOMMU : err;
+
+	err = of_iommu_xlate(&mc_dev->dev, &iommu_spec);
+	of_node_put(iommu_spec.np);
+	return err;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
@@ -291,6 +309,8 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 
 		err = pci_for_each_dma_alias(to_pci_dev(dev),
 					     of_pci_iommu_init, &info);
+	} else if (dev_is_fsl_mc(dev)) {
+		err = of_fsl_mc_iommu_init(to_fsl_mc_device(dev), master_np);
 	} else {
 		struct of_phandle_args iommu_spec;
 		int idx = 0;
-- 
1.9.1

[PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 4/6 v2] iommu: arm-smmu: Add support for the fsl-mc bus

[Nipun Gupta]

Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/iommu/arm-smmu.c |  7 +++++++
 drivers/iommu/iommu.c    | 21 +++++++++++++++++++++
 include/linux/fsl/mc.h   |  8 ++++++++
 include/linux/iommu.h    |  2 ++
 4 files changed, 38 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 69e7c60..e1d5090 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -52,6 +52,7 @@
 #include <linux/spinlock.h>
 
 #include <linux/amba/bus.h>
+#include <linux/fsl/mc.h>
 
 #include "io-pgtable.h"
 #include "arm-smmu-regs.h"
@@ -1459,6 +1460,8 @@ static struct iommu_group *arm_smmu_device_group(struct device *dev)
 
 	if (dev_is_pci(dev))
 		group = pci_device_group(dev);
+	else if (dev_is_fsl_mc(dev))
+		group = fsl_mc_device_group(dev);
 	else
 		group = generic_device_group(dev);
 
@@ -2037,6 +2040,10 @@ static void arm_smmu_bus_init(void)
 		bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
 	}
 #endif
+#ifdef CONFIG_FSL_MC_BUS
+	if (!iommu_present(&fsl_mc_bus_type))
+		bus_set_iommu(&fsl_mc_bus_type, &arm_smmu_ops);
+#endif
 }
 
 static int arm_smmu_device_probe(struct platform_device *pdev)
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 69fef99..fbeebb2 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -32,6 +32,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <linux/property.h>
+#include <linux/fsl/mc.h>
 #include <trace/events/iommu.h>
 
 static struct kset *iommu_group_kset;
@@ -987,6 +988,26 @@ struct iommu_group *pci_device_group(struct device *dev)
 	return iommu_group_alloc();
 }
 
+/* Get the IOMMU group for device on fsl-mc bus */
+struct iommu_group *fsl_mc_device_group(struct device *dev)
+{
+	struct device *cont_dev = fsl_mc_cont_dev(dev);
+	struct iommu_group *group;
+
+	/* Container device is responsible for creating the iommu group */
+	if (fsl_mc_is_cont_dev(dev)) {
+		group = iommu_group_alloc();
+		if (IS_ERR(group))
+			return NULL;
+	} else {
+		get_device(cont_dev);
+		group = iommu_group_get(cont_dev);
+		put_device(cont_dev);
+	}
+
+	return group;
+}
+
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
  * @dev: target device
diff --git a/include/linux/fsl/mc.h b/include/linux/fsl/mc.h
index f27cb14..dddaca1 100644
--- a/include/linux/fsl/mc.h
+++ b/include/linux/fsl/mc.h
@@ -351,6 +351,14 @@ struct fsl_mc_io {
 #define dev_is_fsl_mc(_dev) (0)
 #endif
 
+/* Macro to check if a device is a container device */
+#define fsl_mc_is_cont_dev(_dev) (to_fsl_mc_device(_dev)->flags & \
+	FSL_MC_IS_DPRC)
+
+/* Macro to get the container device of a MC device */
+#define fsl_mc_cont_dev(_dev) (fsl_mc_is_cont_dev(_dev) ? \
+	(_dev) : (_dev)->parent)
+
 /*
  * module_fsl_mc_driver() - Helper macro for drivers that don't do
  * anything special in module init/exit.  This eliminates a lot of
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 41b8c57..00a460b 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -389,6 +389,8 @@ static inline size_t iommu_map_sg(struct iommu_domain *domain,
 extern struct iommu_group *pci_device_group(struct device *dev);
 /* Generic device grouping function */
 extern struct iommu_group *generic_device_group(struct device *dev);
+/* FSL-MC device grouping function */
+struct iommu_group *fsl_mc_device_group(struct device *dev);
 
 /**
  * struct iommu_fwspec - per-device IOMMU instance data
-- 
1.9.1

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
 	return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+	struct device *dma_dev = dev;
+
+	while (dev_is_fsl_mc(dma_dev))
+		dma_dev = dma_dev->parent;
+
+	return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
 	.name = "fsl-mc",
 	.match = fsl_mc_bus_match,
 	.uevent = fsl_mc_bus_uevent,
+	.dma_configure  = fsl_mc_dma_configure,
 	.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
 	return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+	struct device *dma_dev = dev;
+
+	while (dev_is_fsl_mc(dma_dev))
+		dma_dev = dma_dev->parent;
+
+	return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
 	.name = "fsl-mc",
 	.match = fsl_mc_bus_match,
 	.uevent = fsl_mc_bus_uevent,
+	.dma_configure  = fsl_mc_dma_configure,
 	.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[Nipun Gupta]

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 drivers/bus/fsl-mc/fsl-mc-bus.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/bus/fsl-mc/fsl-mc-bus.c b/drivers/bus/fsl-mc/fsl-mc-bus.c
index 5d8266c..624828b 100644
--- a/drivers/bus/fsl-mc/fsl-mc-bus.c
+++ b/drivers/bus/fsl-mc/fsl-mc-bus.c
@@ -127,6 +127,16 @@ static int fsl_mc_bus_uevent(struct device *dev, struct kobj_uevent_env *env)
 	return 0;
 }
 
+static int fsl_mc_dma_configure(struct device *dev)
+{
+	struct device *dma_dev = dev;
+
+	while (dev_is_fsl_mc(dma_dev))
+		dma_dev = dma_dev->parent;
+
+	return of_dma_configure(dev, dma_dev->of_node, 0);
+}
+
 static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
 			     char *buf)
 {
@@ -148,6 +158,7 @@ struct bus_type fsl_mc_bus_type = {
 	.name = "fsl-mc",
 	.match = fsl_mc_bus_match,
 	.uevent = fsl_mc_bus_uevent,
+	.dma_configure  = fsl_mc_dma_configure,
 	.dev_groups = fsl_mc_dev_groups,
 };
 EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
@@ -616,6 +627,7 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 		mc_dev->icid = parent_mc_dev->icid;
 		mc_dev->dma_mask = FSL_MC_DEFAULT_DMA_MASK;
 		mc_dev->dev.dma_mask = &mc_dev->dma_mask;
+		mc_dev->dev.coherent_dma_mask = mc_dev->dma_mask;
 		dev_set_msi_domain(&mc_dev->dev,
 				   dev_get_msi_domain(&parent_mc_dev->dev));
 	}
@@ -633,10 +645,6 @@ int fsl_mc_device_add(struct fsl_mc_obj_desc *obj_desc,
 			goto error_cleanup_dev;
 	}
 
-	/* Objects are coherent, unless 'no shareability' flag set. */
-	if (!(obj_desc->flags & FSL_MC_OBJ_FLAG_NO_MEM_SHAREABILITY))
-		arch_setup_dma_ops(&mc_dev->dev, 0, 0, NULL, true);
-
 	/*
 	 * The device-specific probe callback will get invoked by device_add()
 	 */
-- 
1.9.1

Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180424]
[cannot apply to iommu/next glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure':
>> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure'
     return of_dma_configure(dev, dma_dev->of_node, 0);
            ^~~~~~~~~~~~~~~~
   In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0:
   include/linux/of_device.h:58:5: note: declared here
    int of_dma_configure(struct device *dev, struct device_node *np);
        ^~~~~~~~~~~~~~~~
   drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
>> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure'
     .dma_configure  = fsl_mc_dma_configure,
      ^~~~~~~~~~~~~

vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c

   129	
   130	static int fsl_mc_dma_configure(struct device *dev)
   131	{
   132		struct device *dma_dev = dev;
   133	
   134		while (dev_is_fsl_mc(dma_dev))
   135			dma_dev = dma_dev->parent;
   136	
 > 137		return of_dma_configure(dev, dma_dev->of_node, 0);
   138	}
   139	
   140	static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
   141				     char *buf)
   142	{
   143		struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
   144	
   145		return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor,
   146			       mc_dev->obj_desc.type);
   147	}
   148	static DEVICE_ATTR_RO(modalias);
   149	
   150	static struct attribute *fsl_mc_dev_attrs[] = {
   151		&dev_attr_modalias.attr,
   152		NULL,
   153	};
   154	
   155	ATTRIBUTE_GROUPS(fsl_mc_dev);
   156	
   157	struct bus_type fsl_mc_bus_type = {
   158		.name = "fsl-mc",
   159		.match = fsl_mc_bus_match,
   160		.uevent = fsl_mc_bus_uevent,
 > 161		.dma_configure  = fsl_mc_dma_configure,
   162		.dev_groups = fsl_mc_dev_groups,
   163	};
   164	EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
   165	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56229 bytes --]

[PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[kbuild test robot]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180424]
[cannot apply to iommu/next glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure':
>> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure'
     return of_dma_configure(dev, dma_dev->of_node, 0);
            ^~~~~~~~~~~~~~~~
   In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0:
   include/linux/of_device.h:58:5: note: declared here
    int of_dma_configure(struct device *dev, struct device_node *np);
        ^~~~~~~~~~~~~~~~
   drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
>> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure'
     .dma_configure  = fsl_mc_dma_configure,
      ^~~~~~~~~~~~~

vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c

   129	
   130	static int fsl_mc_dma_configure(struct device *dev)
   131	{
   132		struct device *dma_dev = dev;
   133	
   134		while (dev_is_fsl_mc(dma_dev))
   135			dma_dev = dma_dev->parent;
   136	
 > 137		return of_dma_configure(dev, dma_dev->of_node, 0);
   138	}
   139	
   140	static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
   141				     char *buf)
   142	{
   143		struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
   144	
   145		return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor,
   146			       mc_dev->obj_desc.type);
   147	}
   148	static DEVICE_ATTR_RO(modalias);
   149	
   150	static struct attribute *fsl_mc_dev_attrs[] = {
   151		&dev_attr_modalias.attr,
   152		NULL,
   153	};
   154	
   155	ATTRIBUTE_GROUPS(fsl_mc_dev);
   156	
   157	struct bus_type fsl_mc_bus_type = {
   158		.name = "fsl-mc",
   159		.match = fsl_mc_bus_match,
   160		.uevent = fsl_mc_bus_uevent,
 > 161		.dma_configure  = fsl_mc_dma_configure,
   162		.dev_groups = fsl_mc_dev_groups,
   163	};
   164	EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
   165	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 56229 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180426/3bed7b4d/attachment-0001.gz>

Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180424]
[cannot apply to iommu/next glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure':
>> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure'
     return of_dma_configure(dev, dma_dev->of_node, 0);
            ^~~~~~~~~~~~~~~~
   In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0:
   include/linux/of_device.h:58:5: note: declared here
    int of_dma_configure(struct device *dev, struct device_node *np);
        ^~~~~~~~~~~~~~~~
   drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
>> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure'
     .dma_configure  = fsl_mc_dma_configure,
      ^~~~~~~~~~~~~

vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c

   129	
   130	static int fsl_mc_dma_configure(struct device *dev)
   131	{
   132		struct device *dma_dev = dev;
   133	
   134		while (dev_is_fsl_mc(dma_dev))
   135			dma_dev = dma_dev->parent;
   136	
 > 137		return of_dma_configure(dev, dma_dev->of_node, 0);
   138	}
   139	
   140	static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
   141				     char *buf)
   142	{
   143		struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
   144	
   145		return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor,
   146			       mc_dev->obj_desc.type);
   147	}
   148	static DEVICE_ATTR_RO(modalias);
   149	
   150	static struct attribute *fsl_mc_dev_attrs[] = {
   151		&dev_attr_modalias.attr,
   152		NULL,
   153	};
   154	
   155	ATTRIBUTE_GROUPS(fsl_mc_dev);
   156	
   157	struct bus_type fsl_mc_bus_type = {
   158		.name = "fsl-mc",
   159		.match = fsl_mc_bus_match,
   160		.uevent = fsl_mc_bus_uevent,
 > 161		.dma_configure  = fsl_mc_dma_configure,
   162		.dev_groups = fsl_mc_dev_groups,
   163	};
   164	EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
   165	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56229 bytes --]

[-- Attachment #3: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 5/6 v2] bus: fsl-mc: supoprt dma configure for devices on fsl-mc bus

[kbuild test robot]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

Hi Nipun,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.17-rc2 next-20180424]
[cannot apply to iommu/next glikely/devicetree/next]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]

url:    https://github.com/0day-ci/linux/commits/Nipun-Gupta/Support-for-fsl-mc-bus-and-its-devices-in-SMMU/20180418-034931
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # save the attached .config to linux build tree
        make.cross ARCH=powerpc64 

All errors (new ones prefixed by >>):

   drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_dma_configure':
>> drivers/bus/fsl-mc/fsl-mc-bus.c:137:9: error: too many arguments to function 'of_dma_configure'
     return of_dma_configure(dev, dma_dev->of_node, 0);
            ^~~~~~~~~~~~~~~~
   In file included from drivers/bus/fsl-mc/fsl-mc-bus.c:13:0:
   include/linux/of_device.h:58:5: note: declared here
    int of_dma_configure(struct device *dev, struct device_node *np);
        ^~~~~~~~~~~~~~~~
   drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
>> drivers/bus/fsl-mc/fsl-mc-bus.c:161:3: error: 'struct bus_type' has no member named 'dma_configure'
     .dma_configure  = fsl_mc_dma_configure,
      ^~~~~~~~~~~~~

vim +/of_dma_configure +137 drivers/bus/fsl-mc/fsl-mc-bus.c

   129	
   130	static int fsl_mc_dma_configure(struct device *dev)
   131	{
   132		struct device *dma_dev = dev;
   133	
   134		while (dev_is_fsl_mc(dma_dev))
   135			dma_dev = dma_dev->parent;
   136	
 > 137		return of_dma_configure(dev, dma_dev->of_node, 0);
   138	}
   139	
   140	static ssize_t modalias_show(struct device *dev, struct device_attribute *attr,
   141				     char *buf)
   142	{
   143		struct fsl_mc_device *mc_dev = to_fsl_mc_device(dev);
   144	
   145		return sprintf(buf, "fsl-mc:v%08Xd%s\n", mc_dev->obj_desc.vendor,
   146			       mc_dev->obj_desc.type);
   147	}
   148	static DEVICE_ATTR_RO(modalias);
   149	
   150	static struct attribute *fsl_mc_dev_attrs[] = {
   151		&dev_attr_modalias.attr,
   152		NULL,
   153	};
   154	
   155	ATTRIBUTE_GROUPS(fsl_mc_dev);
   156	
   157	struct bus_type fsl_mc_bus_type = {
   158		.name = "fsl-mc",
   159		.match = fsl_mc_bus_match,
   160		.uevent = fsl_mc_bus_uevent,
 > 161		.dma_configure  = fsl_mc_dma_configure,
   162		.dev_groups = fsl_mc_dev_groups,
   163	};
   164	EXPORT_SYMBOL_GPL(fsl_mc_bus_type);
   165	

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 56229 bytes --]

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

[PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

Fsl-mc bus now support the iommu-map property. Comply to this binding for
fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1b1c5eb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking@1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-map = <0 &smmu 0 0>;	/* This is fixed-up by u-boot */
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			#iommu-cells = <1>;
+			stream-match-mask = <0x7C00>;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi@2100000 {
-- 
1.9.1

[PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

Fsl-mc bus now support the iommu-map property. Comply to this binding for
fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration.

Signed-off-by: Nipun Gupta <nipun.gupta@nxp.com>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1b1c5eb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking at 1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-map = <0 &smmu 0 0>;	/* This is fixed-up by u-boot */
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			#iommu-cells = <1>;
+			stream-match-mask = <0x7C00>;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi at 2100000 {
-- 
1.9.1

[PATCH 6/6 v2] arm64: dts: ls208xa: comply with the iommu map binding for fsl_mc

[Nipun Gupta]

Fsl-mc bus now support the iommu-map property. Comply to this binding for
fsl_mc bus. This patch also updates the dts w.r.t. the DMA configuration.

Signed-off-by: Nipun Gupta <nipun.gupta-3arQi8VN3Tc@public.gmane.org>
---
 arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
index f3a40af..1b1c5eb 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls208xa.dtsi
@@ -135,6 +135,7 @@
 		#address-cells = <2>;
 		#size-cells = <2>;
 		ranges;
+		dma-ranges = <0x0 0x0 0x0 0x0 0x10000 0x00000000>;
 
 		clockgen: clocking@1300000 {
 			compatible = "fsl,ls2080a-clockgen";
@@ -357,6 +358,8 @@
 			reg = <0x00000008 0x0c000000 0 0x40>,	 /* MC portal base */
 			      <0x00000000 0x08340000 0 0x40000>; /* MC control reg */
 			msi-parent = <&its>;
+			iommu-map = <0 &smmu 0 0>;	/* This is fixed-up by u-boot */
+			dma-coherent;
 			#address-cells = <3>;
 			#size-cells = <1>;
 
@@ -460,6 +463,8 @@
 			compatible = "arm,mmu-500";
 			reg = <0 0x5000000 0 0x800000>;
 			#global-interrupts = <12>;
+			#iommu-cells = <1>;
+			stream-match-mask = <0x7C00>;
 			interrupts = <0 13 4>, /* global secure fault */
 				     <0 14 4>, /* combined secure interrupt */
 				     <0 15 4>, /* global non-secure fault */
@@ -502,7 +507,6 @@
 				     <0 204 4>, <0 205 4>,
 				     <0 206 4>, <0 207 4>,
 				     <0 208 4>, <0 209 4>;
-			mmu-masters = <&fsl_mc 0x300 0>;
 		};
 
 		dspi: dspi@2100000 {
-- 
1.9.1