[PATCH V7 00/11] IOMMU probe deferral support

[PATCH V7 00/11] IOMMU probe deferral support

[Sricharan R]

This series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly dma_deconfigure is called during
device/driver_detach path.

pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
       |                         |
pci_bus_add_device     (device_add/driver_register)
       |                         |
device_attach           device_initial_probe
       |                         |
__device_attach_driver    __device_attach_driver
       |
driver_probe_device
       |
really_probe
       |
dma_configure

Similarly on the device/driver_unregister path __device_release_driver is
called which inturn calls dma_deconfigure.

Took the reworked patches [2] from Robin's branch and
rebased on top of Lorenzo's ACPI IORT ARM support series [3].

* Tested with platform and pci devices for probe deferral
  and reprobe on arm64 based platform.
* Need help for testing with ACPI.

Previous post of this series [6]. 

 [V7]
     * Updated the subject and commit log for patch #6 as per
       comments from Lorenzo. No functional changes.

 [V6]
     * Fixed a bug in dma_configure function pointed out by
       Robin.
     * Reordered the patches as per comments from Robin and
       Lorenzo.
     * Added Tags.

 [V5]
     * Reworked the pci configuration code hanging outside and
       pushed it to dma_configure as in PATCH#5,6,7.
       Also added a couple of patches that Lorenzo provided for
       correcting the Probe deferring mechanism in case of
       ACPI devices from here [5].

 [V4]
     * Took the reworked patches [2] from Robin's branch and
       rebased on top of Lorenzo's ACPI IORT ARM support series [3].

     * Added the patches for moving the dma ops configuration of
       acpi based devices to probe time as well.
 [V3]
     * Removed the patch to split dma_masks/dma_ops configuration
       separately based on review comments that both masks and ops are
       required only during the device probe time.

     * Reworked the series based on Generic DT bindings series.

     * Added call to iommu's remove_device in the cleanup path for arm and
       arm64.

     * Removed the notifier trick in arm64 to handle early device
       registration.

     * Added reset of dma_ops in cleanup path for arm based on comments.

     * Fixed the pci_iommu_configure path and tested with PCI device as
       well.
 
     * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
       last post.

     * Fixed few other cosmetic comments.
  
 [V2]
     * Updated the Initial post to call dma_configure/deconfigure from
       generic code
 
     * Added iommu add_device callback from of_iommu_configure path

 [V1]
     * Initial post from Laurent Pinchart [1]

[1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
[2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
[3] https://lkml.org/lkml/2016/11/21/141
[4] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg13940.html
[5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
[6] https://www.spinics.net/lists/arm-kernel/msg556546.html

Laurent Pinchart (3):
  of: dma: Move range size workaround to of_dma_get_range()
  of: dma: Make of_dma_deconfigure() public
  iommu: of: Handle IOMMU lookup failure with deferred probing or error

Lorenzo Pieralisi (2):
  ACPI/IORT: Add function to check SMMUs drivers presence
  ACPI/IORT: Remove linker section for IORT entries probing

Robin Murphy (3):
  iommu/of: Refactor of_iommu_configure() for error handling
  iommu/of: Prepare for deferred IOMMU configuration
  iommu/arm-smmu: Clean up early-probing workarounds

Sricharan R (3):
  of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
  drivers: acpi: Handle IOMMU lookup failure with deferred probing or
    error
  arm64: dma-mapping: Remove the notifier trick to handle early setting
    of dma_ops

 arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
 drivers/acpi/arm64/iort.c         |  40 +++++++++++-
 drivers/acpi/glue.c               |   5 --
 drivers/acpi/scan.c               |   7 +-
 drivers/base/dd.c                 |   9 +++
 drivers/base/dma-mapping.c        |  41 ++++++++++++
 drivers/iommu/arm-smmu-v3.c       |  46 +------------
 drivers/iommu/arm-smmu.c          |  58 +++--------------
 drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
 drivers/of/address.c              |  20 +++++-
 drivers/of/device.c               |  36 ++++++-----
 drivers/of/platform.c             |  10 +--
 drivers/pci/probe.c               |  28 --------
 include/acpi/acpi_bus.h           |   2 +-
 include/asm-generic/vmlinux.lds.h |   1 -
 include/linux/acpi.h              |   7 +-
 include/linux/acpi_iort.h         |   3 -
 include/linux/dma-mapping.h       |   3 +
 include/linux/of_device.h         |  10 ++-
 19 files changed, 252 insertions(+), 320 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 00/11] IOMMU probe deferral support

[Sricharan R]

This series calls the dma ops configuration for the devices
at a generic place so that it works for all busses.
The dma_configure_ops for a device is now called during
the device_attach callback just before the probe of the
bus/driver is called. Similarly dma_deconfigure is called during
device/driver_detach path.

pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
       |                         |
pci_bus_add_device     (device_add/driver_register)
       |                         |
device_attach           device_initial_probe
       |                         |
__device_attach_driver    __device_attach_driver
       |
driver_probe_device
       |
really_probe
       |
dma_configure

Similarly on the device/driver_unregister path __device_release_driver is
called which inturn calls dma_deconfigure.

Took the reworked patches [2] from Robin's branch and
rebased on top of Lorenzo's ACPI IORT ARM support series [3].

* Tested with platform and pci devices for probe deferral
  and reprobe on arm64 based platform.
* Need help for testing with ACPI.

Previous post of this series [6]. 

 [V7]
     * Updated the subject and commit log for patch #6 as per
       comments from Lorenzo. No functional changes.

 [V6]
     * Fixed a bug in dma_configure function pointed out by
       Robin.
     * Reordered the patches as per comments from Robin and
       Lorenzo.
     * Added Tags.

 [V5]
     * Reworked the pci configuration code hanging outside and
       pushed it to dma_configure as in PATCH#5,6,7.
       Also added a couple of patches that Lorenzo provided for
       correcting the Probe deferring mechanism in case of
       ACPI devices from here [5].

 [V4]
     * Took the reworked patches [2] from Robin's branch and
       rebased on top of Lorenzo's ACPI IORT ARM support series [3].

     * Added the patches for moving the dma ops configuration of
       acpi based devices to probe time as well.
 [V3]
     * Removed the patch to split dma_masks/dma_ops configuration
       separately based on review comments that both masks and ops are
       required only during the device probe time.

     * Reworked the series based on Generic DT bindings series.

     * Added call to iommu's remove_device in the cleanup path for arm and
       arm64.

     * Removed the notifier trick in arm64 to handle early device
       registration.

     * Added reset of dma_ops in cleanup path for arm based on comments.

     * Fixed the pci_iommu_configure path and tested with PCI device as
       well.
 
     * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
       last post.

     * Fixed few other cosmetic comments.
  
 [V2]
     * Updated the Initial post to call dma_configure/deconfigure from
       generic code
 
     * Added iommu add_device callback from of_iommu_configure path

 [V1]
     * Initial post from Laurent Pinchart [1]

[1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
[2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
[3] https://lkml.org/lkml/2016/11/21/141
[4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
[5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
[6] https://www.spinics.net/lists/arm-kernel/msg556546.html

Laurent Pinchart (3):
  of: dma: Move range size workaround to of_dma_get_range()
  of: dma: Make of_dma_deconfigure() public
  iommu: of: Handle IOMMU lookup failure with deferred probing or error

Lorenzo Pieralisi (2):
  ACPI/IORT: Add function to check SMMUs drivers presence
  ACPI/IORT: Remove linker section for IORT entries probing

Robin Murphy (3):
  iommu/of: Refactor of_iommu_configure() for error handling
  iommu/of: Prepare for deferred IOMMU configuration
  iommu/arm-smmu: Clean up early-probing workarounds

Sricharan R (3):
  of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
  drivers: acpi: Handle IOMMU lookup failure with deferred probing or
    error
  arm64: dma-mapping: Remove the notifier trick to handle early setting
    of dma_ops

 arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
 drivers/acpi/arm64/iort.c         |  40 +++++++++++-
 drivers/acpi/glue.c               |   5 --
 drivers/acpi/scan.c               |   7 +-
 drivers/base/dd.c                 |   9 +++
 drivers/base/dma-mapping.c        |  41 ++++++++++++
 drivers/iommu/arm-smmu-v3.c       |  46 +------------
 drivers/iommu/arm-smmu.c          |  58 +++--------------
 drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
 drivers/of/address.c              |  20 +++++-
 drivers/of/device.c               |  36 ++++++-----
 drivers/of/platform.c             |  10 +--
 drivers/pci/probe.c               |  28 --------
 include/acpi/acpi_bus.h           |   2 +-
 include/asm-generic/vmlinux.lds.h |   1 -
 include/linux/acpi.h              |   7 +-
 include/linux/acpi_iort.h         |   3 -
 include/linux/dma-mapping.h       |   3 +
 include/linux/of_device.h         |  10 ++-
 19 files changed, 252 insertions(+), 320 deletions(-)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

In preparation for some upcoming cleverness, rework the control flow in
of_iommu_configure() to minimise duplication and improve the propogation
of errors. It's also as good a time as any to switch over from the
now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
IOMMU instance interface directly.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
 1 file changed, 53 insertions(+), 30 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 0f57ddc..ee49081 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);
 
+static const struct iommu_ops
+*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
+{
+	const struct iommu_ops *ops;
+	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
+	int err;
+
+	ops = iommu_get_instance(fwnode);
+	if (!ops || !ops->of_xlate)
+		return NULL;
+
+	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
+	if (err)
+		return ERR_PTR(err);
+
+	err = ops->of_xlate(dev, iommu_spec);
+	if (err)
+		return ERR_PTR(err);
+
+	return ops;
+}
+
 static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 {
 	struct of_phandle_args *iommu_spec = data;
@@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 }
 
 static const struct iommu_ops
-*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
+*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
 {
 	const struct iommu_ops *ops;
 	struct of_phandle_args iommu_spec;
+	int err;
 
 	/*
 	 * Start by tracing the RID alias down the PCI topology as
@@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 	 * bus into the system beyond, and which IOMMU it ends up at.
 	 */
 	iommu_spec.np = NULL;
-	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
-			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
-		return NULL;
+	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
+			     "iommu-map-mask", &iommu_spec.np,
+			     iommu_spec.args);
+	if (err)
+		return ERR_PTR(err);
 
-	ops = of_iommu_get_ops(iommu_spec.np);
-	if (!ops || !ops->of_xlate ||
-	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
-	    ops->of_xlate(&pdev->dev, &iommu_spec))
-		ops = NULL;
+	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
 
 	of_node_put(iommu_spec.np);
 	return ops;
 }
 
-const struct iommu_ops *of_iommu_configure(struct device *dev,
-					   struct device_node *master_np)
+static const struct iommu_ops
+*of_platform_iommu_init(struct device *dev, struct device_node *np)
 {
 	struct of_phandle_args iommu_spec;
-	struct device_node *np;
 	const struct iommu_ops *ops = NULL;
 	int idx = 0;
 
-	if (dev_is_pci(dev))
-		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
-
 	/*
 	 * We don't currently walk up the tree looking for a parent IOMMU.
 	 * See the `Notes:' section of
 	 * Documentation/devicetree/bindings/iommu/iommu.txt
 	 */
-	while (!of_parse_phandle_with_args(master_np, "iommus",
-					   "#iommu-cells", idx,
-					   &iommu_spec)) {
-		np = iommu_spec.np;
-		ops = of_iommu_get_ops(np);
-
-		if (!ops || !ops->of_xlate ||
-		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
-		    ops->of_xlate(dev, &iommu_spec))
-			goto err_put_node;
-
-		of_node_put(np);
+	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
+					   idx, &iommu_spec)) {
+		ops = of_iommu_xlate(dev, &iommu_spec);
+		of_node_put(iommu_spec.np);
 		idx++;
+		if (IS_ERR_OR_NULL(ops))
+			break;
 	}
 
 	return ops;
+}
+
+const struct iommu_ops *of_iommu_configure(struct device *dev,
+					   struct device_node *master_np)
+{
+	const struct iommu_ops *ops;
+
+	if (!master_np)
+		return NULL;
+
+	if (dev_is_pci(dev))
+		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
+	else
+		ops = of_platform_iommu_init(dev, master_np);
 
-err_put_node:
-	of_node_put(np);
-	return NULL;
+	return IS_ERR(ops) ? NULL : ops;
 }
 
 static int __init of_iommu_init(void)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

In preparation for some upcoming cleverness, rework the control flow in
of_iommu_configure() to minimise duplication and improve the propogation
of errors. It's also as good a time as any to switch over from the
now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
IOMMU instance interface directly.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
 1 file changed, 53 insertions(+), 30 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 0f57ddc..ee49081 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);
 
+static const struct iommu_ops
+*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
+{
+	const struct iommu_ops *ops;
+	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
+	int err;
+
+	ops = iommu_get_instance(fwnode);
+	if (!ops || !ops->of_xlate)
+		return NULL;
+
+	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
+	if (err)
+		return ERR_PTR(err);
+
+	err = ops->of_xlate(dev, iommu_spec);
+	if (err)
+		return ERR_PTR(err);
+
+	return ops;
+}
+
 static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 {
 	struct of_phandle_args *iommu_spec = data;
@@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 }
 
 static const struct iommu_ops
-*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
+*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
 {
 	const struct iommu_ops *ops;
 	struct of_phandle_args iommu_spec;
+	int err;
 
 	/*
 	 * Start by tracing the RID alias down the PCI topology as
@@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 	 * bus into the system beyond, and which IOMMU it ends up at.
 	 */
 	iommu_spec.np = NULL;
-	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
-			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
-		return NULL;
+	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
+			     "iommu-map-mask", &iommu_spec.np,
+			     iommu_spec.args);
+	if (err)
+		return ERR_PTR(err);
 
-	ops = of_iommu_get_ops(iommu_spec.np);
-	if (!ops || !ops->of_xlate ||
-	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
-	    ops->of_xlate(&pdev->dev, &iommu_spec))
-		ops = NULL;
+	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
 
 	of_node_put(iommu_spec.np);
 	return ops;
 }
 
-const struct iommu_ops *of_iommu_configure(struct device *dev,
-					   struct device_node *master_np)
+static const struct iommu_ops
+*of_platform_iommu_init(struct device *dev, struct device_node *np)
 {
 	struct of_phandle_args iommu_spec;
-	struct device_node *np;
 	const struct iommu_ops *ops = NULL;
 	int idx = 0;
 
-	if (dev_is_pci(dev))
-		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
-
 	/*
 	 * We don't currently walk up the tree looking for a parent IOMMU.
 	 * See the `Notes:' section of
 	 * Documentation/devicetree/bindings/iommu/iommu.txt
 	 */
-	while (!of_parse_phandle_with_args(master_np, "iommus",
-					   "#iommu-cells", idx,
-					   &iommu_spec)) {
-		np = iommu_spec.np;
-		ops = of_iommu_get_ops(np);
-
-		if (!ops || !ops->of_xlate ||
-		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
-		    ops->of_xlate(dev, &iommu_spec))
-			goto err_put_node;
-
-		of_node_put(np);
+	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
+					   idx, &iommu_spec)) {
+		ops = of_iommu_xlate(dev, &iommu_spec);
+		of_node_put(iommu_spec.np);
 		idx++;
+		if (IS_ERR_OR_NULL(ops))
+			break;
 	}
 
 	return ops;
+}
+
+const struct iommu_ops *of_iommu_configure(struct device *dev,
+					   struct device_node *master_np)
+{
+	const struct iommu_ops *ops;
+
+	if (!master_np)
+		return NULL;
+
+	if (dev_is_pci(dev))
+		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
+	else
+		ops = of_platform_iommu_init(dev, master_np);
 
-err_put_node:
-	of_node_put(np);
-	return NULL;
+	return IS_ERR(ops) ? NULL : ops;
 }
 
 static int __init of_iommu_init(void)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation


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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

In preparation for some upcoming cleverness, rework the control flow in
of_iommu_configure() to minimise duplication and improve the propogation
of errors. It's also as good a time as any to switch over from the
now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
IOMMU instance interface directly.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
 1 file changed, 53 insertions(+), 30 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 0f57ddc..ee49081 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);
 
+static const struct iommu_ops
+*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
+{
+	const struct iommu_ops *ops;
+	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
+	int err;
+
+	ops = iommu_get_instance(fwnode);
+	if (!ops || !ops->of_xlate)
+		return NULL;
+
+	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
+	if (err)
+		return ERR_PTR(err);
+
+	err = ops->of_xlate(dev, iommu_spec);
+	if (err)
+		return ERR_PTR(err);
+
+	return ops;
+}
+
 static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 {
 	struct of_phandle_args *iommu_spec = data;
@@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 }
 
 static const struct iommu_ops
-*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
+*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
 {
 	const struct iommu_ops *ops;
 	struct of_phandle_args iommu_spec;
+	int err;
 
 	/*
 	 * Start by tracing the RID alias down the PCI topology as
@@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
 	 * bus into the system beyond, and which IOMMU it ends up at.
 	 */
 	iommu_spec.np = NULL;
-	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
-			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
-		return NULL;
+	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
+			     "iommu-map-mask", &iommu_spec.np,
+			     iommu_spec.args);
+	if (err)
+		return ERR_PTR(err);
 
-	ops = of_iommu_get_ops(iommu_spec.np);
-	if (!ops || !ops->of_xlate ||
-	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
-	    ops->of_xlate(&pdev->dev, &iommu_spec))
-		ops = NULL;
+	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
 
 	of_node_put(iommu_spec.np);
 	return ops;
 }
 
-const struct iommu_ops *of_iommu_configure(struct device *dev,
-					   struct device_node *master_np)
+static const struct iommu_ops
+*of_platform_iommu_init(struct device *dev, struct device_node *np)
 {
 	struct of_phandle_args iommu_spec;
-	struct device_node *np;
 	const struct iommu_ops *ops = NULL;
 	int idx = 0;
 
-	if (dev_is_pci(dev))
-		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
-
 	/*
 	 * We don't currently walk up the tree looking for a parent IOMMU.
 	 * See the `Notes:' section of
 	 * Documentation/devicetree/bindings/iommu/iommu.txt
 	 */
-	while (!of_parse_phandle_with_args(master_np, "iommus",
-					   "#iommu-cells", idx,
-					   &iommu_spec)) {
-		np = iommu_spec.np;
-		ops = of_iommu_get_ops(np);
-
-		if (!ops || !ops->of_xlate ||
-		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
-		    ops->of_xlate(dev, &iommu_spec))
-			goto err_put_node;
-
-		of_node_put(np);
+	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
+					   idx, &iommu_spec)) {
+		ops = of_iommu_xlate(dev, &iommu_spec);
+		of_node_put(iommu_spec.np);
 		idx++;
+		if (IS_ERR_OR_NULL(ops))
+			break;
 	}
 
 	return ops;
+}
+
+const struct iommu_ops *of_iommu_configure(struct device *dev,
+					   struct device_node *master_np)
+{
+	const struct iommu_ops *ops;
+
+	if (!master_np)
+		return NULL;
+
+	if (dev_is_pci(dev))
+		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
+	else
+		ops = of_platform_iommu_init(dev, master_np);
 
-err_put_node:
-	of_node_put(np);
-	return NULL;
+	return IS_ERR(ops) ? NULL : ops;
 }
 
 static int __init of_iommu_init(void)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 02/11] iommu/of: Prepare for deferred IOMMU configuration

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

IOMMU configuration represents unchanging properties of the hardware,
and as such should only need happen once in a device's lifetime, but
the necessary interaction with the IOMMU device and driver complicates
exactly when that point should be.

Since the only reasonable tool available for handling the inter-device
dependency is probe deferral, we need to prepare of_iommu_configure()
to run later than it is currently called (i.e. at driver probe rather
than device creation), to handle being retried, and to tell whether a
not-yet present IOMMU should be waited for or skipped (by virtue of
having declared a built-in driver or not).

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index ee49081..349bd1d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
 	int err;
 
 	ops = iommu_get_instance(fwnode);
-	if (!ops || !ops->of_xlate)
+	if ((ops && !ops->of_xlate) ||
+	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
 		return NULL;
 
 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
 	if (err)
 		return ERR_PTR(err);
+	/*
+	 * The otherwise-empty fwspec handily serves to indicate the specific
+	 * IOMMU device we're waiting for, which will be useful if we ever get
+	 * a proper probe-ordering dependency mechanism in future.
+	 */
+	if (!ops)
+		return ERR_PTR(-EPROBE_DEFER);
 
 	err = ops->of_xlate(dev, iommu_spec);
 	if (err)
@@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
 	const struct iommu_ops *ops;
+	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
 
 	if (!master_np)
 		return NULL;
 
+	if (fwspec) {
+		if (fwspec->ops)
+			return fwspec->ops;
+
+		/* In the deferred case, start again from scratch */
+		iommu_fwspec_free(dev);
+	}
+
 	if (dev_is_pci(dev))
 		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
 	else
 		ops = of_platform_iommu_init(dev, master_np);
+	/*
+	 * If we have reason to believe the IOMMU driver missed the initial
+	 * add_device callback for dev, replay it to get things in order.
+	 */
+	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
+	    dev->bus && !dev->iommu_group) {
+		int err = ops->add_device(dev);
+
+		if (err)
+			ops = ERR_PTR(err);
+	}
 
 	return IS_ERR(ops) ? NULL : ops;
 }
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 02/11] iommu/of: Prepare for deferred IOMMU configuration

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

IOMMU configuration represents unchanging properties of the hardware,
and as such should only need happen once in a device's lifetime, but
the necessary interaction with the IOMMU device and driver complicates
exactly when that point should be.

Since the only reasonable tool available for handling the inter-device
dependency is probe deferral, we need to prepare of_iommu_configure()
to run later than it is currently called (i.e. at driver probe rather
than device creation), to handle being retried, and to tell whether a
not-yet present IOMMU should be waited for or skipped (by virtue of
having declared a built-in driver or not).

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 drivers/iommu/of_iommu.c | 30 +++++++++++++++++++++++++++++-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index ee49081..349bd1d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -104,12 +104,20 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
 	int err;
 
 	ops = iommu_get_instance(fwnode);
-	if (!ops || !ops->of_xlate)
+	if ((ops && !ops->of_xlate) ||
+	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
 		return NULL;
 
 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
 	if (err)
 		return ERR_PTR(err);
+	/*
+	 * The otherwise-empty fwspec handily serves to indicate the specific
+	 * IOMMU device we're waiting for, which will be useful if we ever get
+	 * a proper probe-ordering dependency mechanism in future.
+	 */
+	if (!ops)
+		return ERR_PTR(-EPROBE_DEFER);
 
 	err = ops->of_xlate(dev, iommu_spec);
 	if (err)
@@ -186,14 +194,34 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 					   struct device_node *master_np)
 {
 	const struct iommu_ops *ops;
+	struct iommu_fwspec *fwspec = dev->iommu_fwspec;
 
 	if (!master_np)
 		return NULL;
 
+	if (fwspec) {
+		if (fwspec->ops)
+			return fwspec->ops;
+
+		/* In the deferred case, start again from scratch */
+		iommu_fwspec_free(dev);
+	}
+
 	if (dev_is_pci(dev))
 		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
 	else
 		ops = of_platform_iommu_init(dev, master_np);
+	/*
+	 * If we have reason to believe the IOMMU driver missed the initial
+	 * add_device callback for dev, replay it to get things in order.
+	 */
+	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
+	    dev->bus && !dev->iommu_group) {
+		int err = ops->add_device(dev);
+
+		if (err)
+			ops = ERR_PTR(err);
+	}
 
 	return IS_ERR(ops) ? NULL : ops;
 }
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 03/11] of: dma: Move range size workaround to of_dma_get_range()

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Invalid dma-ranges values should be worked around when retrieving the
DMA range in of_dma_get_range(), not by all callers of the function.
This isn't much of a problem now that we have a single caller, but that
situation will change when moving DMA configuration to device probe
time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/of/address.c | 20 ++++++++++++++++++--
 drivers/of/device.c  | 15 ---------------
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..6aeb816 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -819,8 +819,8 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
  *	CPU addr (phys_addr_t)	: pna cells
  *	size			: nsize cells
  *
- * It returns -ENODEV if "dma-ranges" property was not found
- * for this device in DT.
+ * Return 0 on success, -ENODEV if the "dma-ranges" property was not found for
+ * this device in DT, or -EINVAL if the CPU address or size is invalid.
  */
 int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
 {
@@ -880,6 +880,22 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 	*dma_addr = dmaaddr;
 
 	*size = of_read_number(ranges + naddr + pna, nsize);
+	/*
+	 * DT nodes sometimes incorrectly set the size as a mask. Work around
+	 * those incorrect DT by computing the size as mask + 1.
+	 */
+	if (*size & 1) {
+		pr_warn("%s: size 0x%llx for dma-range in node(%s) set as mask\n",
+			__func__, *size, np->full_name);
+		*size = *size + 1;
+	}
+
+	if (!*size) {
+		pr_err("%s: invalid size zero for dma-range in node(%s)\n",
+		       __func__, np->full_name);
+		ret = -EINVAL;
+		goto out;
+	}
 
 	pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 		 *dma_addr, *paddr, *size);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad..d9898d9 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -110,21 +110,6 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 		size = dev->coherent_dma_mask + 1;
 	} else {
 		offset = PFN_DOWN(paddr - dma_addr);
-
-		/*
-		 * Add a work around to treat the size as mask + 1 in case
-		 * it is defined in DT as a mask.
-		 */
-		if (size & 1) {
-			dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
-				 size);
-			size = size + 1;
-		}
-
-		if (!size) {
-			dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
-			return;
-		}
 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
 	}
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 03/11] of: dma: Move range size workaround to of_dma_get_range()

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Invalid dma-ranges values should be worked around when retrieving the
DMA range in of_dma_get_range(), not by all callers of the function.
This isn't much of a problem now that we have a single caller, but that
situation will change when moving DMA configuration to device probe
time.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/of/address.c | 20 ++++++++++++++++++--
 drivers/of/device.c  | 15 ---------------
 2 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/drivers/of/address.c b/drivers/of/address.c
index 02b2903..6aeb816 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -819,8 +819,8 @@ void __iomem *of_io_request_and_map(struct device_node *np, int index,
  *	CPU addr (phys_addr_t)	: pna cells
  *	size			: nsize cells
  *
- * It returns -ENODEV if "dma-ranges" property was not found
- * for this device in DT.
+ * Return 0 on success, -ENODEV if the "dma-ranges" property was not found for
+ * this device in DT, or -EINVAL if the CPU address or size is invalid.
  */
 int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *size)
 {
@@ -880,6 +880,22 @@ int of_dma_get_range(struct device_node *np, u64 *dma_addr, u64 *paddr, u64 *siz
 	*dma_addr = dmaaddr;
 
 	*size = of_read_number(ranges + naddr + pna, nsize);
+	/*
+	 * DT nodes sometimes incorrectly set the size as a mask. Work around
+	 * those incorrect DT by computing the size as mask + 1.
+	 */
+	if (*size & 1) {
+		pr_warn("%s: size 0x%llx for dma-range in node(%s) set as mask\n",
+			__func__, *size, np->full_name);
+		*size = *size + 1;
+	}
+
+	if (!*size) {
+		pr_err("%s: invalid size zero for dma-range in node(%s)\n",
+		       __func__, np->full_name);
+		ret = -EINVAL;
+		goto out;
+	}
 
 	pr_debug("dma_addr(%llx) cpu_addr(%llx) size(%llx)\n",
 		 *dma_addr, *paddr, *size);
diff --git a/drivers/of/device.c b/drivers/of/device.c
index fd5cfad..d9898d9 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -110,21 +110,6 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 		size = dev->coherent_dma_mask + 1;
 	} else {
 		offset = PFN_DOWN(paddr - dma_addr);
-
-		/*
-		 * Add a work around to treat the size as mask + 1 in case
-		 * it is defined in DT as a mask.
-		 */
-		if (size & 1) {
-			dev_warn(dev, "Invalid size 0x%llx for dma-range\n",
-				 size);
-			size = size + 1;
-		}
-
-		if (!size) {
-			dev_err(dev, "Adjusted size 0x%llx invalid\n", size);
-			return;
-		}
 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
 	}
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 04/11] of: dma: Make of_dma_deconfigure() public

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>

As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
---
 drivers/of/device.c       | 12 ++++++++++++
 drivers/of/platform.c     |  5 -----
 include/linux/of_device.h |  3 +++
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index d9898d9..1c843e2 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -136,6 +136,18 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
 
+/**
+ * of_dma_deconfigure - Clean up DMA configuration
+ * @dev:	Device for which to clean up DMA configuration
+ *
+ * Clean up all configuration performed by of_dma_configure_ops() and free all
+ * resources that have been allocated.
+ */
+void of_dma_deconfigure(struct device *dev)
+{
+	arch_teardown_dma_ops(dev);
+}
+
 int of_device_register(struct platform_device *pdev)
 {
 	device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b8064bc..57418f7 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -158,11 +158,6 @@ struct platform_device *of_device_alloc(struct device_node *np,
 }
 EXPORT_SYMBOL(of_device_alloc);
 
-static void of_dma_deconfigure(struct device *dev)
-{
-	arch_teardown_dma_ops(dev);
-}
-
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687..d20a31a 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -56,6 +56,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 
 void of_dma_configure(struct device *dev, struct device_node *np);
+void of_dma_deconfigure(struct device *dev);
 #else /* CONFIG_OF */
 
 static inline int of_driver_match_device(struct device *dev,
@@ -100,6 +101,8 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 static inline void of_dma_configure(struct device *dev, struct device_node *np)
 {}
+static inline void of_dma_deconfigure(struct device *dev)
+{}
 #endif /* CONFIG_OF */
 
 #endif /* _LINUX_OF_DEVICE_H */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 04/11] of: dma: Make of_dma_deconfigure() public

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/of/device.c       | 12 ++++++++++++
 drivers/of/platform.c     |  5 -----
 include/linux/of_device.h |  3 +++
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index d9898d9..1c843e2 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -136,6 +136,18 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
 
+/**
+ * of_dma_deconfigure - Clean up DMA configuration
+ * @dev:	Device for which to clean up DMA configuration
+ *
+ * Clean up all configuration performed by of_dma_configure_ops() and free all
+ * resources that have been allocated.
+ */
+void of_dma_deconfigure(struct device *dev)
+{
+	arch_teardown_dma_ops(dev);
+}
+
 int of_device_register(struct platform_device *pdev)
 {
 	device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b8064bc..57418f7 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -158,11 +158,6 @@ struct platform_device *of_device_alloc(struct device_node *np,
 }
 EXPORT_SYMBOL(of_device_alloc);
 
-static void of_dma_deconfigure(struct device *dev)
-{
-	arch_teardown_dma_ops(dev);
-}
-
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687..d20a31a 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -56,6 +56,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 
 void of_dma_configure(struct device *dev, struct device_node *np);
+void of_dma_deconfigure(struct device *dev);
 #else /* CONFIG_OF */
 
 static inline int of_driver_match_device(struct device *dev,
@@ -100,6 +101,8 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 static inline void of_dma_configure(struct device *dev, struct device_node *np)
 {}
+static inline void of_dma_deconfigure(struct device *dev)
+{}
 #endif /* CONFIG_OF */
 
 #endif /* _LINUX_OF_DEVICE_H */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 04/11] of: dma: Make of_dma_deconfigure() public

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

As part of moving DMA initializing to probe time the
of_dma_deconfigure() function will need to be called from different
source files. Make it public and move it to drivers/of/device.c where
the of_dma_configure() function is.

Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
 drivers/of/device.c       | 12 ++++++++++++
 drivers/of/platform.c     |  5 -----
 include/linux/of_device.h |  3 +++
 3 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/drivers/of/device.c b/drivers/of/device.c
index d9898d9..1c843e2 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -136,6 +136,18 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
 
+/**
+ * of_dma_deconfigure - Clean up DMA configuration
+ * @dev:	Device for which to clean up DMA configuration
+ *
+ * Clean up all configuration performed by of_dma_configure_ops() and free all
+ * resources that have been allocated.
+ */
+void of_dma_deconfigure(struct device *dev)
+{
+	arch_teardown_dma_ops(dev);
+}
+
 int of_device_register(struct platform_device *pdev)
 {
 	device_initialize(&pdev->dev);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index b8064bc..57418f7 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -158,11 +158,6 @@ struct platform_device *of_device_alloc(struct device_node *np,
 }
 EXPORT_SYMBOL(of_device_alloc);
 
-static void of_dma_deconfigure(struct device *dev)
-{
-	arch_teardown_dma_ops(dev);
-}
-
 /**
  * of_platform_device_create_pdata - Alloc, initialize and register an of_device
  * @np: pointer to node to create device for
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index cc7dd687..d20a31a 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -56,6 +56,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 
 void of_dma_configure(struct device *dev, struct device_node *np);
+void of_dma_deconfigure(struct device *dev);
 #else /* CONFIG_OF */
 
 static inline int of_driver_match_device(struct device *dev,
@@ -100,6 +101,8 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 }
 static inline void of_dma_configure(struct device *dev, struct device_node *np)
 {}
+static inline void of_dma_deconfigure(struct device *dev)
+{}
 #endif /* CONFIG_OF */
 
 #endif /* _LINUX_OF_DEVICE_H */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 05/11] ACPI/IORT: Add function to check SMMUs drivers presence

[Sricharan R]

From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

The IOMMU probe deferral implementation requires a mechanism to detect
if drivers for SMMU components are built-in in the kernel to detect
whether IOMMU configuration for a given device should be deferred (ie
SMMU drivers present but still not probed) or not (drivers not present).

Add a simple function to IORT to detect if SMMU drivers for SMMU
components managed by IORT are built-in in the kernel.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..bf0ed09 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -523,6 +523,19 @@ static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
 	return ret;
 }
 
+static inline bool iort_iommu_driver_enabled(u8 type)
+{
+	switch (type) {
+	case ACPI_IORT_NODE_SMMU_V3:
+		return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
+	case ACPI_IORT_NODE_SMMU:
+		return IS_BUILTIN(CONFIG_ARM_SMMU);
+	default:
+		pr_warn("IORT node type %u does not describe an SMMU\n", type);
+		return false;
+	}
+}
+
 static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
 					struct acpi_iort_node *node,
 					u32 streamid)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 05/11] ACPI/IORT: Add function to check SMMUs drivers presence

[Sricharan R]

From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

The IOMMU probe deferral implementation requires a mechanism to detect
if drivers for SMMU components are built-in in the kernel to detect
whether IOMMU configuration for a given device should be deferred (ie
SMMU drivers present but still not probed) or not (drivers not present).

Add a simple function to IORT to detect if SMMU drivers for SMMU
components managed by IORT are built-in in the kernel.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index e0d2e6e..bf0ed09 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -523,6 +523,19 @@ static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
 	return ret;
 }
 
+static inline bool iort_iommu_driver_enabled(u8 type)
+{
+	switch (type) {
+	case ACPI_IORT_NODE_SMMU_V3:
+		return IS_BUILTIN(CONFIG_ARM_SMMU_V3);
+	case ACPI_IORT_NODE_SMMU:
+		return IS_BUILTIN(CONFIG_ARM_SMMU);
+	default:
+		pr_warn("IORT node type %u does not describe an SMMU\n", type);
+		return false;
+	}
+}
+
 static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
 					struct acpi_iort_node *node,
 					u32 streamid)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Sricharan R]

Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the device is
now called from the generic device_attach callback just before the
bus/driver probe is called. This way, configuring the DMA ops for the
device would be called at the same place for all bus_types, hence the
deferred probing mechanism should work for all buses as well.

pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
       |                         |
pci_bus_add_device     (device_add/driver_register)
       |                         |
device_attach           device_initial_probe
       |                         |
__device_attach_driver    __device_attach_driver
       |
driver_probe_device
       |
really_probe
       |
dma_configure

Similarly on the device/driver_unregister path __device_release_driver is
called which inturn calls dma_deconfigure.

This patch changes the dma ops configuration to probe time for
both OF and ACPI based platform/amba/pci bus devices.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 [V6 .. V7]
	* Updated the subject and commit log as per comments

 [V5 .. V6]
        * Squashed in patch 10 for configuring the dma ops of
          ACPI device at probe time from previous post.
        * Fixed a bug in dma_configure pointed out by Robin.

 drivers/acpi/glue.c         |  5 -----
 drivers/base/dd.c           |  9 +++++++++
 drivers/base/dma-mapping.c  | 40 ++++++++++++++++++++++++++++++++++++++++
 drivers/of/platform.c       |  5 +----
 drivers/pci/probe.c         | 28 ----------------------------
 include/linux/dma-mapping.h |  3 +++
 6 files changed, 53 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index fb19e1c..c05f241 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -176,7 +176,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
 	struct list_head *physnode_list;
 	unsigned int node_id;
 	int retval = -EINVAL;
-	enum dev_dma_attr attr;
 
 	if (has_acpi_companion(dev)) {
 		if (acpi_dev) {
@@ -233,10 +232,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
 	if (!has_acpi_companion(dev))
 		ACPI_COMPANION_SET(dev, acpi_dev);
 
-	attr = acpi_get_dma_attr(acpi_dev);
-	if (attr != DEV_DMA_NOT_SUPPORTED)
-		acpi_dma_configure(dev, attr);
-
 	acpi_physnode_link_name(physical_node_name, node_id);
 	retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
 				   physical_node_name);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a1fbf55..4882f06 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -19,6 +19,7 @@
 
 #include <linux/device.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/module.h>
 #include <linux/kthread.h>
 #include <linux/wait.h>
@@ -356,6 +357,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	if (ret)
 		goto pinctrl_bind_failed;
 
+	ret = dma_configure(dev);
+	if (ret)
+		goto dma_failed;
+
 	if (driver_sysfs_add(dev)) {
 		printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
 			__func__, dev_name(dev));
@@ -417,6 +422,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	goto done;
 
 probe_failed:
+	dma_deconfigure(dev);
+dma_failed:
 	if (dev->bus)
 		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
 					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
@@ -826,6 +833,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
 			drv->remove(dev);
 
 		device_links_driver_cleanup(dev);
+		dma_deconfigure(dev);
+
 		devres_release_all(dev);
 		dev->driver = NULL;
 		dev_set_drvdata(dev, NULL);
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index efd71cf..449b948 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -7,9 +7,11 @@
  * This file is released under the GPLv2.
  */
 
+#include <linux/acpi.h>
 #include <linux/dma-mapping.h>
 #include <linux/export.h>
 #include <linux/gfp.h>
+#include <linux/of_device.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
 
@@ -341,3 +343,41 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
 	vunmap(cpu_addr);
 }
 #endif
+
+/*
+ * Common configuration to enable DMA API use for a device
+ */
+#include <linux/pci.h>
+
+int dma_configure(struct device *dev)
+{
+	struct device *bridge = NULL, *dma_dev = dev;
+	enum dev_dma_attr attr;
+
+	if (dev_is_pci(dev)) {
+		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
+		dma_dev = bridge;
+		if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
+		    dma_dev->parent->of_node)
+			dma_dev = dma_dev->parent;
+	}
+
+	if (dma_dev->of_node) {
+		of_dma_configure(dev, dma_dev->of_node);
+	} else if (has_acpi_companion(dma_dev)) {
+		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
+		if (attr != DEV_DMA_NOT_SUPPORTED)
+			acpi_dma_configure(dev, attr);
+	}
+
+	if (bridge)
+		pci_put_host_bridge_device(bridge);
+
+	return 0;
+}
+
+void dma_deconfigure(struct device *dev)
+{
+	of_dma_deconfigure(dev);
+	acpi_dma_deconfigure(dev);
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 57418f7..cf35030 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
+#include <linux/of_iommu.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
@@ -186,11 +187,9 @@ static struct platform_device *of_platform_device_create_pdata(
 
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
-	of_dma_configure(&dev->dev, dev->dev.of_node);
 	of_msi_configure(&dev->dev, dev->dev.of_node);
 
 	if (of_device_add(dev) != 0) {
-		of_dma_deconfigure(&dev->dev);
 		platform_device_put(dev);
 		goto err_clear_flag;
 	}
@@ -248,7 +247,6 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
 		dev_set_name(&dev->dev, "%s", bus_id);
 	else
 		of_device_make_bus_id(&dev->dev);
-	of_dma_configure(&dev->dev, dev->dev.of_node);
 
 	/* Allow the HW Peripheral ID to be overridden */
 	prop = of_get_property(node, "arm,primecell-periphid", NULL);
@@ -542,7 +540,6 @@ static int of_platform_device_destroy(struct device *dev, void *data)
 		amba_device_unregister(to_amba_device(dev));
 #endif
 
-	of_dma_deconfigure(dev);
 	of_node_clear_flag(dev->of_node, OF_POPULATED);
 	of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
 	return 0;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 204960e..89ebb6c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1864,33 +1864,6 @@ static void pci_set_msi_domain(struct pci_dev *dev)
 	dev_set_msi_domain(&dev->dev, d);
 }
 
-/**
- * pci_dma_configure - Setup DMA configuration
- * @dev: ptr to pci_dev struct of the PCI device
- *
- * Function to update PCI devices's DMA configuration using the same
- * info from the OF node or ACPI node of host bridge's parent (if any).
- */
-static void pci_dma_configure(struct pci_dev *dev)
-{
-	struct device *bridge = pci_get_host_bridge_device(dev);
-
-	if (IS_ENABLED(CONFIG_OF) &&
-		bridge->parent && bridge->parent->of_node) {
-			of_dma_configure(&dev->dev, bridge->parent->of_node);
-	} else if (has_acpi_companion(bridge)) {
-		struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
-		enum dev_dma_attr attr = acpi_get_dma_attr(adev);
-
-		if (attr == DEV_DMA_NOT_SUPPORTED)
-			dev_warn(&dev->dev, "DMA not supported.\n");
-		else
-			acpi_dma_configure(&dev->dev, attr);
-	}
-
-	pci_put_host_bridge_device(bridge);
-}
-
 void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
 {
 	int ret;
@@ -1904,7 +1877,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
 	dev->dev.dma_mask = &dev->dma_mask;
 	dev->dev.dma_parms = &dev->dma_parms;
 	dev->dev.coherent_dma_mask = 0xffffffffull;
-	pci_dma_configure(dev);
 
 	pci_set_dma_max_seg_size(dev, 65536);
 	pci_set_dma_seg_boundary(dev, 0xffffffff);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 10c5a17b1..939bf77 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -708,6 +708,9 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
 }
 #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
 
+int dma_configure(struct device *dev);
+void dma_deconfigure(struct device *dev);
+
 /*
  * Managed DMA API
  */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Sricharan R]

Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet. The dma_configure for the device is
now called from the generic device_attach callback just before the
bus/driver probe is called. This way, configuring the DMA ops for the
device would be called at the same place for all bus_types, hence the
deferred probing mechanism should work for all buses as well.

pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
       |                         |
pci_bus_add_device     (device_add/driver_register)
       |                         |
device_attach           device_initial_probe
       |                         |
__device_attach_driver    __device_attach_driver
       |
driver_probe_device
       |
really_probe
       |
dma_configure

Similarly on the device/driver_unregister path __device_release_driver is
called which inturn calls dma_deconfigure.

This patch changes the dma ops configuration to probe time for
both OF and ACPI based platform/amba/pci bus devices.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 [V6 .. V7]
	* Updated the subject and commit log as per comments

 [V5 .. V6]
        * Squashed in patch 10 for configuring the dma ops of
          ACPI device at probe time from previous post.
        * Fixed a bug in dma_configure pointed out by Robin.

 drivers/acpi/glue.c         |  5 -----
 drivers/base/dd.c           |  9 +++++++++
 drivers/base/dma-mapping.c  | 40 ++++++++++++++++++++++++++++++++++++++++
 drivers/of/platform.c       |  5 +----
 drivers/pci/probe.c         | 28 ----------------------------
 include/linux/dma-mapping.h |  3 +++
 6 files changed, 53 insertions(+), 37 deletions(-)

diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
index fb19e1c..c05f241 100644
--- a/drivers/acpi/glue.c
+++ b/drivers/acpi/glue.c
@@ -176,7 +176,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
 	struct list_head *physnode_list;
 	unsigned int node_id;
 	int retval = -EINVAL;
-	enum dev_dma_attr attr;
 
 	if (has_acpi_companion(dev)) {
 		if (acpi_dev) {
@@ -233,10 +232,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
 	if (!has_acpi_companion(dev))
 		ACPI_COMPANION_SET(dev, acpi_dev);
 
-	attr = acpi_get_dma_attr(acpi_dev);
-	if (attr != DEV_DMA_NOT_SUPPORTED)
-		acpi_dma_configure(dev, attr);
-
 	acpi_physnode_link_name(physical_node_name, node_id);
 	retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
 				   physical_node_name);
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a1fbf55..4882f06 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -19,6 +19,7 @@
 
 #include <linux/device.h>
 #include <linux/delay.h>
+#include <linux/dma-mapping.h>
 #include <linux/module.h>
 #include <linux/kthread.h>
 #include <linux/wait.h>
@@ -356,6 +357,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	if (ret)
 		goto pinctrl_bind_failed;
 
+	ret = dma_configure(dev);
+	if (ret)
+		goto dma_failed;
+
 	if (driver_sysfs_add(dev)) {
 		printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
 			__func__, dev_name(dev));
@@ -417,6 +422,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
 	goto done;
 
 probe_failed:
+	dma_deconfigure(dev);
+dma_failed:
 	if (dev->bus)
 		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
 					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
@@ -826,6 +833,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
 			drv->remove(dev);
 
 		device_links_driver_cleanup(dev);
+		dma_deconfigure(dev);
+
 		devres_release_all(dev);
 		dev->driver = NULL;
 		dev_set_drvdata(dev, NULL);
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index efd71cf..449b948 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -7,9 +7,11 @@
  * This file is released under the GPLv2.
  */
 
+#include <linux/acpi.h>
 #include <linux/dma-mapping.h>
 #include <linux/export.h>
 #include <linux/gfp.h>
+#include <linux/of_device.h>
 #include <linux/slab.h>
 #include <linux/vmalloc.h>
 
@@ -341,3 +343,41 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
 	vunmap(cpu_addr);
 }
 #endif
+
+/*
+ * Common configuration to enable DMA API use for a device
+ */
+#include <linux/pci.h>
+
+int dma_configure(struct device *dev)
+{
+	struct device *bridge = NULL, *dma_dev = dev;
+	enum dev_dma_attr attr;
+
+	if (dev_is_pci(dev)) {
+		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
+		dma_dev = bridge;
+		if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
+		    dma_dev->parent->of_node)
+			dma_dev = dma_dev->parent;
+	}
+
+	if (dma_dev->of_node) {
+		of_dma_configure(dev, dma_dev->of_node);
+	} else if (has_acpi_companion(dma_dev)) {
+		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
+		if (attr != DEV_DMA_NOT_SUPPORTED)
+			acpi_dma_configure(dev, attr);
+	}
+
+	if (bridge)
+		pci_put_host_bridge_device(bridge);
+
+	return 0;
+}
+
+void dma_deconfigure(struct device *dev)
+{
+	of_dma_deconfigure(dev);
+	acpi_dma_deconfigure(dev);
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 57418f7..cf35030 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -22,6 +22,7 @@
 #include <linux/slab.h>
 #include <linux/of_address.h>
 #include <linux/of_device.h>
+#include <linux/of_iommu.h>
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/platform_device.h>
@@ -186,11 +187,9 @@ static struct platform_device *of_platform_device_create_pdata(
 
 	dev->dev.bus = &platform_bus_type;
 	dev->dev.platform_data = platform_data;
-	of_dma_configure(&dev->dev, dev->dev.of_node);
 	of_msi_configure(&dev->dev, dev->dev.of_node);
 
 	if (of_device_add(dev) != 0) {
-		of_dma_deconfigure(&dev->dev);
 		platform_device_put(dev);
 		goto err_clear_flag;
 	}
@@ -248,7 +247,6 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
 		dev_set_name(&dev->dev, "%s", bus_id);
 	else
 		of_device_make_bus_id(&dev->dev);
-	of_dma_configure(&dev->dev, dev->dev.of_node);
 
 	/* Allow the HW Peripheral ID to be overridden */
 	prop = of_get_property(node, "arm,primecell-periphid", NULL);
@@ -542,7 +540,6 @@ static int of_platform_device_destroy(struct device *dev, void *data)
 		amba_device_unregister(to_amba_device(dev));
 #endif
 
-	of_dma_deconfigure(dev);
 	of_node_clear_flag(dev->of_node, OF_POPULATED);
 	of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
 	return 0;
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 204960e..89ebb6c 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1864,33 +1864,6 @@ static void pci_set_msi_domain(struct pci_dev *dev)
 	dev_set_msi_domain(&dev->dev, d);
 }
 
-/**
- * pci_dma_configure - Setup DMA configuration
- * @dev: ptr to pci_dev struct of the PCI device
- *
- * Function to update PCI devices's DMA configuration using the same
- * info from the OF node or ACPI node of host bridge's parent (if any).
- */
-static void pci_dma_configure(struct pci_dev *dev)
-{
-	struct device *bridge = pci_get_host_bridge_device(dev);
-
-	if (IS_ENABLED(CONFIG_OF) &&
-		bridge->parent && bridge->parent->of_node) {
-			of_dma_configure(&dev->dev, bridge->parent->of_node);
-	} else if (has_acpi_companion(bridge)) {
-		struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
-		enum dev_dma_attr attr = acpi_get_dma_attr(adev);
-
-		if (attr == DEV_DMA_NOT_SUPPORTED)
-			dev_warn(&dev->dev, "DMA not supported.\n");
-		else
-			acpi_dma_configure(&dev->dev, attr);
-	}
-
-	pci_put_host_bridge_device(bridge);
-}
-
 void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
 {
 	int ret;
@@ -1904,7 +1877,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
 	dev->dev.dma_mask = &dev->dma_mask;
 	dev->dev.dma_parms = &dev->dma_parms;
 	dev->dev.coherent_dma_mask = 0xffffffffull;
-	pci_dma_configure(dev);
 
 	pci_set_dma_max_seg_size(dev, 65536);
 	pci_set_dma_seg_boundary(dev, 0xffffffff);
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 10c5a17b1..939bf77 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -708,6 +708,9 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
 }
 #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
 
+int dma_configure(struct device *dev);
+void dma_deconfigure(struct device *dev);
+
 /*
  * Managed DMA API
  */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Failures to look up an IOMMU when parsing the DT iommus property need to
be handled separately from the .of_xlate() failures to support deferred
probing.

The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred, or having failed.

The first case occurs when the device tree describes the bus master and
IOMMU topology correctly but no device driver exists for the IOMMU yet
or the device driver has not been compiled in. Return NULL, the caller
will configure the device without an IOMMU.

The second and third cases are handled by deferring the probe of the bus
master device which will eventually get reprobed after the IOMMU.

The last case is currently handled by deferring the probe of the bus
master device as well. A mechanism to either configure the bus master
device without an IOMMU or to fail the bus master device probe depending
on whether the IOMMU is optional or mandatory would be a good
enhancement.

Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/base/dma-mapping.c | 5 +++--
 drivers/iommu/of_iommu.c   | 5 +++--
 drivers/of/device.c        | 9 +++++++--
 include/linux/of_device.h  | 9 ++++++---
 4 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 449b948..82bd45c 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -353,6 +353,7 @@ int dma_configure(struct device *dev)
 {
 	struct device *bridge = NULL, *dma_dev = dev;
 	enum dev_dma_attr attr;
+	int ret = 0;
 
 	if (dev_is_pci(dev)) {
 		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
@@ -363,7 +364,7 @@ int dma_configure(struct device *dev)
 	}
 
 	if (dma_dev->of_node) {
-		of_dma_configure(dev, dma_dev->of_node);
+		ret = of_dma_configure(dev, dma_dev->of_node);
 	} else if (has_acpi_companion(dma_dev)) {
 		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
 		if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -373,7 +374,7 @@ int dma_configure(struct device *dev)
 	if (bridge)
 		pci_put_host_bridge_device(bridge);
 
-	return 0;
+	return ret;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 349bd1d..9529d6c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -23,6 +23,7 @@
 #include <linux/of.h>
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
+#include <linux/pci.h>
 #include <linux/slab.h>
 
 static const struct of_device_id __iommu_of_table_sentinel
@@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 			ops = ERR_PTR(err);
 	}
 
-	return IS_ERR(ops) ? NULL : ops;
+	return ops;
 }
 
 static int __init of_iommu_init(void)
@@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
 	for_each_matching_node_and_match(np, matches, &match) {
 		const of_iommu_init_fn init_fn = match->data;
 
-		if (init_fn(np))
+		if (init_fn && init_fn(np))
 			pr_err("Failed to initialise IOMMU %s\n",
 				of_node_full_name(np));
 	}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1c843e2..d58595c 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
  * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
  * to fix up DMA configuration.
  */
-void of_dma_configure(struct device *dev, struct device_node *np)
+int of_dma_configure(struct device *dev, struct device_node *np)
 {
 	u64 dma_addr, paddr, size;
 	int ret;
@@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
 	if (ret < 0) {
 		dma_addr = offset = 0;
-		size = dev->coherent_dma_mask + 1;
+		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
 	} else {
 		offset = PFN_DOWN(paddr - dma_addr);
 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
@@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 		coherent ? " " : " not ");
 
 	iommu = of_iommu_configure(dev, np);
+	if (IS_ERR(iommu))
+		return PTR_ERR(iommu);
+
 	dev_dbg(dev, "device is%sbehind an iommu\n",
 		iommu ? " " : " not ");
 
 	arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+
+	return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
 
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index d20a31a..6dca65c 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 	return of_node_get(cpu_dev->of_node);
 }
 
-void of_dma_configure(struct device *dev, struct device_node *np);
+int of_dma_configure(struct device *dev, struct device_node *np);
 void of_dma_deconfigure(struct device *dev);
 #else /* CONFIG_OF */
 
@@ -99,8 +99,11 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 {
 	return NULL;
 }
-static inline void of_dma_configure(struct device *dev, struct device_node *np)
-{}
+
+static inline int of_dma_configure(struct device *dev, struct device_node *np)
+{
+	return 0;
+}
 static inline void of_dma_deconfigure(struct device *dev)
 {}
 #endif /* CONFIG_OF */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan R]

From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>

Failures to look up an IOMMU when parsing the DT iommus property need to
be handled separately from the .of_xlate() failures to support deferred
probing.

The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred, or having failed.

The first case occurs when the device tree describes the bus master and
IOMMU topology correctly but no device driver exists for the IOMMU yet
or the device driver has not been compiled in. Return NULL, the caller
will configure the device without an IOMMU.

The second and third cases are handled by deferring the probe of the bus
master device which will eventually get reprobed after the IOMMU.

The last case is currently handled by deferring the probe of the bus
master device as well. A mechanism to either configure the bus master
device without an IOMMU or to fail the bus master device probe depending
on whether the IOMMU is optional or mandatory would be a good
enhancement.

Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/base/dma-mapping.c | 5 +++--
 drivers/iommu/of_iommu.c   | 5 +++--
 drivers/of/device.c        | 9 +++++++--
 include/linux/of_device.h  | 9 ++++++---
 4 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 449b948..82bd45c 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -353,6 +353,7 @@ int dma_configure(struct device *dev)
 {
 	struct device *bridge = NULL, *dma_dev = dev;
 	enum dev_dma_attr attr;
+	int ret = 0;
 
 	if (dev_is_pci(dev)) {
 		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
@@ -363,7 +364,7 @@ int dma_configure(struct device *dev)
 	}
 
 	if (dma_dev->of_node) {
-		of_dma_configure(dev, dma_dev->of_node);
+		ret = of_dma_configure(dev, dma_dev->of_node);
 	} else if (has_acpi_companion(dma_dev)) {
 		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
 		if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -373,7 +374,7 @@ int dma_configure(struct device *dev)
 	if (bridge)
 		pci_put_host_bridge_device(bridge);
 
-	return 0;
+	return ret;
 }
 
 void dma_deconfigure(struct device *dev)
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 349bd1d..9529d6c 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -23,6 +23,7 @@
 #include <linux/of.h>
 #include <linux/of_iommu.h>
 #include <linux/of_pci.h>
+#include <linux/pci.h>
 #include <linux/slab.h>
 
 static const struct of_device_id __iommu_of_table_sentinel
@@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
 			ops = ERR_PTR(err);
 	}
 
-	return IS_ERR(ops) ? NULL : ops;
+	return ops;
 }
 
 static int __init of_iommu_init(void)
@@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
 	for_each_matching_node_and_match(np, matches, &match) {
 		const of_iommu_init_fn init_fn = match->data;
 
-		if (init_fn(np))
+		if (init_fn && init_fn(np))
 			pr_err("Failed to initialise IOMMU %s\n",
 				of_node_full_name(np));
 	}
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 1c843e2..d58595c 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -82,7 +82,7 @@ int of_device_add(struct platform_device *ofdev)
  * can use a platform bus notifier and handle BUS_NOTIFY_ADD_DEVICE events
  * to fix up DMA configuration.
  */
-void of_dma_configure(struct device *dev, struct device_node *np)
+int of_dma_configure(struct device *dev, struct device_node *np)
 {
 	u64 dma_addr, paddr, size;
 	int ret;
@@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
 	if (ret < 0) {
 		dma_addr = offset = 0;
-		size = dev->coherent_dma_mask + 1;
+		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
 	} else {
 		offset = PFN_DOWN(paddr - dma_addr);
 		dev_dbg(dev, "dma_pfn_offset(%#08lx)\n", offset);
@@ -129,10 +129,15 @@ void of_dma_configure(struct device *dev, struct device_node *np)
 		coherent ? " " : " not ");
 
 	iommu = of_iommu_configure(dev, np);
+	if (IS_ERR(iommu))
+		return PTR_ERR(iommu);
+
 	dev_dbg(dev, "device is%sbehind an iommu\n",
 		iommu ? " " : " not ");
 
 	arch_setup_dma_ops(dev, dma_addr, size, iommu, coherent);
+
+	return 0;
 }
 EXPORT_SYMBOL_GPL(of_dma_configure);
 
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index d20a31a..6dca65c 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -55,7 +55,7 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 	return of_node_get(cpu_dev->of_node);
 }
 
-void of_dma_configure(struct device *dev, struct device_node *np);
+int of_dma_configure(struct device *dev, struct device_node *np);
 void of_dma_deconfigure(struct device *dev);
 #else /* CONFIG_OF */
 
@@ -99,8 +99,11 @@ static inline struct device_node *of_cpu_device_node_get(int cpu)
 {
 	return NULL;
 }
-static inline void of_dma_configure(struct device *dev, struct device_node *np)
-{}
+
+static inline int of_dma_configure(struct device *dev, struct device_node *np)
+{
+	return 0;
+}
 static inline void of_dma_deconfigure(struct device *dev)
 {}
 #endif /* CONFIG_OF */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan R]

This is an equivalent to the DT's handling of the iommu master's probe
with deferred probing when the corrsponding iommu is not probed yet.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred, or having failed.

The first case occurs when the firmware describes the bus master and
IOMMU topology correctly but no device driver exists for the IOMMU yet
or the device driver has not been compiled in. Return NULL, the caller
will configure the device without an IOMMU.

The second and third cases are handled by deferring the probe of the bus
master device which will eventually get reprobed after the IOMMU.

The last case is currently handled by deferring the probe of the bus
master device as well. A mechanism to either configure the bus master
device without an IOMMU or to fail the bus master device probe depending
on whether the IOMMU is optional or mandatory would be a good
enhancement.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
 drivers/acpi/scan.c        |  7 +++++--
 drivers/base/dma-mapping.c |  2 +-
 include/acpi/acpi_bus.h    |  2 +-
 include/linux/acpi.h       |  7 +++++--
 5 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index bf0ed09..d01bae8 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
 			return NULL;
 
 		ops = iommu_get_instance(iort_fwnode);
+		/*
+		 * If the ops look-up fails, this means that either
+		 * the SMMU drivers have not been probed yet or that
+		 * the SMMU drivers are not built in the kernel;
+		 * Depending on whether the SMMU drivers are built-in
+		 * in the kernel or not, defer the IOMMU configuration
+		 * or just abort it.
+		 */
 		if (!ops)
-			return NULL;
+			return iort_iommu_driver_enabled(node->type) ?
+			       ERR_PTR(-EPROBE_DEFER) : NULL;
 
 		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
 	}
@@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 
 		while (parent) {
 			ops = iort_iommu_xlate(dev, parent, streamid);
+			if (IS_ERR_OR_NULL(ops))
+				return ops;
 
 			parent = iort_node_get_id(node, &streamid,
 						  IORT_IOMMU_TYPE, i++);
 		}
 	}
 
+	/*
+	 * If we have reason to believe the IOMMU driver missed the initial
+	 * add_device callback for dev, replay it to get things in order.
+	 */
+	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
+	    dev->bus && !dev->iommu_group) {
+		int err = ops->add_device(dev);
+
+		if (err)
+			ops = ERR_PTR(err);
+	}
+
 	return ops;
 }
 
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1926918..823b005 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1373,20 +1373,23 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
  * @dev: The pointer to the device
  * @attr: device dma attributes
  */
-void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
+int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
 {
 	const struct iommu_ops *iommu;
 
 	iort_set_dma_mask(dev);
 
 	iommu = iort_iommu_configure(dev);
-
+	if (IS_ERR(iommu))
+		return PTR_ERR(iommu);
 	/*
 	 * Assume dma valid range starts at 0 and covers the whole
 	 * coherent_dma_mask.
 	 */
 	arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
 			   attr == DEV_DMA_COHERENT);
+
+	return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_dma_configure);
 
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 82bd45c..755a2b5 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -368,7 +368,7 @@ int dma_configure(struct device *dev)
 	} else if (has_acpi_companion(dma_dev)) {
 		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
 		if (attr != DEV_DMA_NOT_SUPPORTED)
-			acpi_dma_configure(dev, attr);
+			ret = acpi_dma_configure(dev, attr);
 	}
 
 	if (bridge)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 4242c31..9aa762fe 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -573,7 +573,7 @@ struct acpi_pci_root {
 
 bool acpi_dma_supported(struct acpi_device *adev);
 enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
-void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
+int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
 void acpi_dma_deconfigure(struct device *dev);
 
 struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 5b36974..8b958b6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -764,8 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
 	return DEV_DMA_NOT_SUPPORTED;
 }
 
-static inline void acpi_dma_configure(struct device *dev,
-				      enum dev_dma_attr attr) { }
+static inline int acpi_dma_configure(struct device *dev,
+				     enum dev_dma_attr attr)
+{
+	return 0;
+}
 
 static inline void acpi_dma_deconfigure(struct device *dev) { }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan R]

This is an equivalent to the DT's handling of the iommu master's probe
with deferred probing when the corrsponding iommu is not probed yet.
The lack of a registered IOMMU can be caused by the lack of a driver for
the IOMMU, the IOMMU device probe not having been performed yet, having
been deferred, or having failed.

The first case occurs when the firmware describes the bus master and
IOMMU topology correctly but no device driver exists for the IOMMU yet
or the device driver has not been compiled in. Return NULL, the caller
will configure the device without an IOMMU.

The second and third cases are handled by deferring the probe of the bus
master device which will eventually get reprobed after the IOMMU.

The last case is currently handled by deferring the probe of the bus
master device as well. A mechanism to either configure the bus master
device without an IOMMU or to fail the bus master device probe depending
on whether the IOMMU is optional or mandatory would be a good
enhancement.

Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
 drivers/acpi/scan.c        |  7 +++++--
 drivers/base/dma-mapping.c |  2 +-
 include/acpi/acpi_bus.h    |  2 +-
 include/linux/acpi.h       |  7 +++++--
 5 files changed, 36 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index bf0ed09..d01bae8 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
 			return NULL;
 
 		ops = iommu_get_instance(iort_fwnode);
+		/*
+		 * If the ops look-up fails, this means that either
+		 * the SMMU drivers have not been probed yet or that
+		 * the SMMU drivers are not built in the kernel;
+		 * Depending on whether the SMMU drivers are built-in
+		 * in the kernel or not, defer the IOMMU configuration
+		 * or just abort it.
+		 */
 		if (!ops)
-			return NULL;
+			return iort_iommu_driver_enabled(node->type) ?
+			       ERR_PTR(-EPROBE_DEFER) : NULL;
 
 		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
 	}
@@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 
 		while (parent) {
 			ops = iort_iommu_xlate(dev, parent, streamid);
+			if (IS_ERR_OR_NULL(ops))
+				return ops;
 
 			parent = iort_node_get_id(node, &streamid,
 						  IORT_IOMMU_TYPE, i++);
 		}
 	}
 
+	/*
+	 * If we have reason to believe the IOMMU driver missed the initial
+	 * add_device callback for dev, replay it to get things in order.
+	 */
+	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
+	    dev->bus && !dev->iommu_group) {
+		int err = ops->add_device(dev);
+
+		if (err)
+			ops = ERR_PTR(err);
+	}
+
 	return ops;
 }
 
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 1926918..823b005 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -1373,20 +1373,23 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
  * @dev: The pointer to the device
  * @attr: device dma attributes
  */
-void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
+int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
 {
 	const struct iommu_ops *iommu;
 
 	iort_set_dma_mask(dev);
 
 	iommu = iort_iommu_configure(dev);
-
+	if (IS_ERR(iommu))
+		return PTR_ERR(iommu);
 	/*
 	 * Assume dma valid range starts at 0 and covers the whole
 	 * coherent_dma_mask.
 	 */
 	arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
 			   attr == DEV_DMA_COHERENT);
+
+	return 0;
 }
 EXPORT_SYMBOL_GPL(acpi_dma_configure);
 
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 82bd45c..755a2b5 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -368,7 +368,7 @@ int dma_configure(struct device *dev)
 	} else if (has_acpi_companion(dma_dev)) {
 		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
 		if (attr != DEV_DMA_NOT_SUPPORTED)
-			acpi_dma_configure(dev, attr);
+			ret = acpi_dma_configure(dev, attr);
 	}
 
 	if (bridge)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 4242c31..9aa762fe 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -573,7 +573,7 @@ struct acpi_pci_root {
 
 bool acpi_dma_supported(struct acpi_device *adev);
 enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
-void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
+int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
 void acpi_dma_deconfigure(struct device *dev);
 
 struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 5b36974..8b958b6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -764,8 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
 	return DEV_DMA_NOT_SUPPORTED;
 }
 
-static inline void acpi_dma_configure(struct device *dev,
-				      enum dev_dma_attr attr) { }
+static inline int acpi_dma_configure(struct device *dev,
+				     enum dev_dma_attr attr)
+{
+	return 0;
+}
 
 static inline void acpi_dma_deconfigure(struct device *dev) { }
 
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Sricharan R]

With arch_setup_dma_ops now being called late during device's probe after
the device's iommu is probed, the notifier trick required to handle the
early setup of dma_ops before the iommu group gets created is not
required. So removing the notifier's here.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
[rm: clean up even more]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
 1 file changed, 12 insertions(+), 120 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index e040827..5845b13 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -803,140 +803,32 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
 	.mapping_error = iommu_dma_mapping_error,
 };
 
-/*
- * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
- * everything it needs to - the device is only partially created and the
- * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
- * need this delayed attachment dance. Once IOMMU probe ordering is sorted
- * to move the arch_setup_dma_ops() call later, all the notifier bits below
- * become unnecessary, and will go away.
- */
-struct iommu_dma_notifier_data {
-	struct list_head list;
-	struct device *dev;
-	const struct iommu_ops *ops;
-	u64 dma_base;
-	u64 size;
-};
-static LIST_HEAD(iommu_dma_masters);
-static DEFINE_MUTEX(iommu_dma_notifier_lock);
-
-static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			   u64 dma_base, u64 size)
-{
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-
-	/*
-	 * If the IOMMU driver has the DMA domain support that we require,
-	 * then the IOMMU core will have already configured a group for this
-	 * device, and allocated the default domain for that group.
-	 */
-	if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
-		pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
-			dev_name(dev));
-		return false;
-	}
-
-	dev->archdata.dma_ops = &iommu_dma_ops;
-	return true;
-}
-
-static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			      u64 dma_base, u64 size)
-{
-	struct iommu_dma_notifier_data *iommudata;
-
-	iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
-	if (!iommudata)
-		return;
-
-	iommudata->dev = dev;
-	iommudata->ops = ops;
-	iommudata->dma_base = dma_base;
-	iommudata->size = size;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_add(&iommudata->list, &iommu_dma_masters);
-	mutex_unlock(&iommu_dma_notifier_lock);
-}
-
-static int __iommu_attach_notifier(struct notifier_block *nb,
-				   unsigned long action, void *data)
-{
-	struct iommu_dma_notifier_data *master, *tmp;
-
-	if (action != BUS_NOTIFY_BIND_DRIVER)
-		return 0;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
-		if (data == master->dev && do_iommu_attach(master->dev,
-				master->ops, master->dma_base, master->size)) {
-			list_del(&master->list);
-			kfree(master);
-			break;
-		}
-	}
-	mutex_unlock(&iommu_dma_notifier_lock);
-	return 0;
-}
-
-static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
-{
-	struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
-	int ret;
-
-	if (!nb)
-		return -ENOMEM;
-
-	nb->notifier_call = __iommu_attach_notifier;
-
-	ret = bus_register_notifier(bus, nb);
-	if (ret) {
-		pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
-			bus->name);
-		kfree(nb);
-	}
-	return ret;
-}
-
 static int __init __iommu_dma_init(void)
 {
-	int ret;
-
-	ret = iommu_dma_init();
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&amba_bustype);
-#ifdef CONFIG_PCI
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&pci_bus_type);
-#endif
-	return ret;
+	return iommu_dma_init();
 }
 arch_initcall(__iommu_dma_init);
 
 static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 				  const struct iommu_ops *ops)
 {
-	struct iommu_group *group;
+	struct iommu_domain *domain;
 
 	if (!ops)
 		return;
+
 	/*
-	 * TODO: As a concession to the future, we're ready to handle being
-	 * called both early and late (i.e. after bus_add_device). Once all
-	 * the platform bus code is reworked to call us late and the notifier
-	 * junk above goes away, move the body of do_iommu_attach here.
+	 * The IOMMU core code allocates the default DMA domain, which the
+	 * underlying IOMMU driver needs to support via the dma-iommu layer.
 	 */
-	group = iommu_group_get(dev);
-	if (group) {
-		do_iommu_attach(dev, ops, dma_base, size);
-		iommu_group_put(group);
-	} else {
-		queue_iommu_attach(dev, ops, dma_base, size);
+	domain = iommu_get_domain_for_dev(dev);
+	if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
+		pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
+			dev_name(dev));
+		return;
 	}
+
+	dev->archdata.dma_ops = &iommu_dma_ops;
 }
 
 void arch_teardown_dma_ops(struct device *dev)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Sricharan R]

With arch_setup_dma_ops now being called late during device's probe after
the device's iommu is probed, the notifier trick required to handle the
early setup of dma_ops before the iommu group gets created is not
required. So removing the notifier's here.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
[rm: clean up even more]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
 arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
 1 file changed, 12 insertions(+), 120 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index e040827..5845b13 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -803,140 +803,32 @@ static void __iommu_unmap_sg_attrs(struct device *dev,
 	.mapping_error = iommu_dma_mapping_error,
 };
 
-/*
- * TODO: Right now __iommu_setup_dma_ops() gets called too early to do
- * everything it needs to - the device is only partially created and the
- * IOMMU driver hasn't seen it yet, so it can't have a group. Thus we
- * need this delayed attachment dance. Once IOMMU probe ordering is sorted
- * to move the arch_setup_dma_ops() call later, all the notifier bits below
- * become unnecessary, and will go away.
- */
-struct iommu_dma_notifier_data {
-	struct list_head list;
-	struct device *dev;
-	const struct iommu_ops *ops;
-	u64 dma_base;
-	u64 size;
-};
-static LIST_HEAD(iommu_dma_masters);
-static DEFINE_MUTEX(iommu_dma_notifier_lock);
-
-static bool do_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			   u64 dma_base, u64 size)
-{
-	struct iommu_domain *domain = iommu_get_domain_for_dev(dev);
-
-	/*
-	 * If the IOMMU driver has the DMA domain support that we require,
-	 * then the IOMMU core will have already configured a group for this
-	 * device, and allocated the default domain for that group.
-	 */
-	if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
-		pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
-			dev_name(dev));
-		return false;
-	}
-
-	dev->archdata.dma_ops = &iommu_dma_ops;
-	return true;
-}
-
-static void queue_iommu_attach(struct device *dev, const struct iommu_ops *ops,
-			      u64 dma_base, u64 size)
-{
-	struct iommu_dma_notifier_data *iommudata;
-
-	iommudata = kzalloc(sizeof(*iommudata), GFP_KERNEL);
-	if (!iommudata)
-		return;
-
-	iommudata->dev = dev;
-	iommudata->ops = ops;
-	iommudata->dma_base = dma_base;
-	iommudata->size = size;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_add(&iommudata->list, &iommu_dma_masters);
-	mutex_unlock(&iommu_dma_notifier_lock);
-}
-
-static int __iommu_attach_notifier(struct notifier_block *nb,
-				   unsigned long action, void *data)
-{
-	struct iommu_dma_notifier_data *master, *tmp;
-
-	if (action != BUS_NOTIFY_BIND_DRIVER)
-		return 0;
-
-	mutex_lock(&iommu_dma_notifier_lock);
-	list_for_each_entry_safe(master, tmp, &iommu_dma_masters, list) {
-		if (data == master->dev && do_iommu_attach(master->dev,
-				master->ops, master->dma_base, master->size)) {
-			list_del(&master->list);
-			kfree(master);
-			break;
-		}
-	}
-	mutex_unlock(&iommu_dma_notifier_lock);
-	return 0;
-}
-
-static int __init register_iommu_dma_ops_notifier(struct bus_type *bus)
-{
-	struct notifier_block *nb = kzalloc(sizeof(*nb), GFP_KERNEL);
-	int ret;
-
-	if (!nb)
-		return -ENOMEM;
-
-	nb->notifier_call = __iommu_attach_notifier;
-
-	ret = bus_register_notifier(bus, nb);
-	if (ret) {
-		pr_warn("Failed to register DMA domain notifier; IOMMU DMA ops unavailable on bus '%s'\n",
-			bus->name);
-		kfree(nb);
-	}
-	return ret;
-}
-
 static int __init __iommu_dma_init(void)
 {
-	int ret;
-
-	ret = iommu_dma_init();
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&platform_bus_type);
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&amba_bustype);
-#ifdef CONFIG_PCI
-	if (!ret)
-		ret = register_iommu_dma_ops_notifier(&pci_bus_type);
-#endif
-	return ret;
+	return iommu_dma_init();
 }
 arch_initcall(__iommu_dma_init);
 
 static void __iommu_setup_dma_ops(struct device *dev, u64 dma_base, u64 size,
 				  const struct iommu_ops *ops)
 {
-	struct iommu_group *group;
+	struct iommu_domain *domain;
 
 	if (!ops)
 		return;
+
 	/*
-	 * TODO: As a concession to the future, we're ready to handle being
-	 * called both early and late (i.e. after bus_add_device). Once all
-	 * the platform bus code is reworked to call us late and the notifier
-	 * junk above goes away, move the body of do_iommu_attach here.
+	 * The IOMMU core code allocates the default DMA domain, which the
+	 * underlying IOMMU driver needs to support via the dma-iommu layer.
 	 */
-	group = iommu_group_get(dev);
-	if (group) {
-		do_iommu_attach(dev, ops, dma_base, size);
-		iommu_group_put(group);
-	} else {
-		queue_iommu_attach(dev, ops, dma_base, size);
+	domain = iommu_get_domain_for_dev(dev);
+	if (!domain || iommu_dma_init_domain(domain, dma_base, size, dev)) {
+		pr_warn("Failed to set up IOMMU for device %s; retaining platform DMA ops\n",
+			dev_name(dev));
+		return;
 	}
+
+	dev->archdata.dma_ops = &iommu_dma_ops;
 }
 
 void arch_teardown_dma_ops(struct device *dev)
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

Now that the appropriate ordering is enforced via profe-deferral of
masters in core code, rip it all out and bask in the simplicity.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
[Sricharan: Rebased on top of ACPI IORT SMMU series]
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
 drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
 2 files changed, 10 insertions(+), 94 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4d6ec44..632b541 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2729,51 +2729,9 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 	.probe	= arm_smmu_device_probe,
 	.remove	= arm_smmu_device_remove,
 };
+module_platform_driver(arm_smmu_driver);
 
-static int __init arm_smmu_init(void)
-{
-	static bool registered;
-	int ret = 0;
-
-	if (!registered) {
-		ret = platform_driver_register(&arm_smmu_driver);
-		registered = !ret;
-	}
-	return ret;
-}
-
-static void __exit arm_smmu_exit(void)
-{
-	return platform_driver_unregister(&arm_smmu_driver);
-}
-
-subsys_initcall(arm_smmu_init);
-module_exit(arm_smmu_exit);
-
-static int __init arm_smmu_of_init(struct device_node *np)
-{
-	int ret = arm_smmu_init();
-
-	if (ret)
-		return ret;
-
-	if (!of_platform_device_create(np, NULL, platform_bus_type.dev_root))
-		return -ENODEV;
-
-	return 0;
-}
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", arm_smmu_of_init);
-
-#ifdef CONFIG_ACPI
-static int __init acpi_smmu_v3_init(struct acpi_table_header *table)
-{
-	if (iort_node_match(ACPI_IORT_NODE_SMMU_V3))
-		return arm_smmu_init();
-
-	return 0;
-}
-IORT_ACPI_DECLARE(arm_smmu_v3, ACPI_SIG_IORT, acpi_smmu_v3_init);
-#endif
+IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", NULL);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..93f77bb 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2134,56 +2134,14 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 	.probe	= arm_smmu_device_probe,
 	.remove	= arm_smmu_device_remove,
 };
-
-static int __init arm_smmu_init(void)
-{
-	static bool registered;
-	int ret = 0;
-
-	if (!registered) {
-		ret = platform_driver_register(&arm_smmu_driver);
-		registered = !ret;
-	}
-	return ret;
-}
-
-static void __exit arm_smmu_exit(void)
-{
-	return platform_driver_unregister(&arm_smmu_driver);
-}
-
-subsys_initcall(arm_smmu_init);
-module_exit(arm_smmu_exit);
-
-static int __init arm_smmu_of_init(struct device_node *np)
-{
-	int ret = arm_smmu_init();
-
-	if (ret)
-		return ret;
-
-	if (!of_platform_device_create(np, NULL, platform_bus_type.dev_root))
-		return -ENODEV;
-
-	return 0;
-}
-IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", arm_smmu_of_init);
-IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", arm_smmu_of_init);
-
-#ifdef CONFIG_ACPI
-static int __init arm_smmu_acpi_init(struct acpi_table_header *table)
-{
-	if (iort_node_match(ACPI_IORT_NODE_SMMU))
-		return arm_smmu_init();
-
-	return 0;
-}
-IORT_ACPI_DECLARE(arm_smmu, ACPI_SIG_IORT, arm_smmu_acpi_init);
-#endif
+module_platform_driver(arm_smmu_driver);
+
+IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", NULL);
+IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", NULL);
+IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", NULL);
+IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", NULL);
+IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", NULL);
+IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", NULL);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Sricharan R]

From: Robin Murphy <robin.murphy@arm.com>

Now that the appropriate ordering is enforced via profe-deferral of
masters in core code, rip it all out and bask in the simplicity.

Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
[Sricharan: Rebased on top of ACPI IORT SMMU series]
Signed-off-by: Sricharan R <sricharan@codeaurora.org>
---
 drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
 drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
 2 files changed, 10 insertions(+), 94 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 4d6ec44..632b541 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -2729,51 +2729,9 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 	.probe	= arm_smmu_device_probe,
 	.remove	= arm_smmu_device_remove,
 };
+module_platform_driver(arm_smmu_driver);
 
-static int __init arm_smmu_init(void)
-{
-	static bool registered;
-	int ret = 0;
-
-	if (!registered) {
-		ret = platform_driver_register(&arm_smmu_driver);
-		registered = !ret;
-	}
-	return ret;
-}
-
-static void __exit arm_smmu_exit(void)
-{
-	return platform_driver_unregister(&arm_smmu_driver);
-}
-
-subsys_initcall(arm_smmu_init);
-module_exit(arm_smmu_exit);
-
-static int __init arm_smmu_of_init(struct device_node *np)
-{
-	int ret = arm_smmu_init();
-
-	if (ret)
-		return ret;
-
-	if (!of_platform_device_create(np, NULL, platform_bus_type.dev_root))
-		return -ENODEV;
-
-	return 0;
-}
-IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", arm_smmu_of_init);
-
-#ifdef CONFIG_ACPI
-static int __init acpi_smmu_v3_init(struct acpi_table_header *table)
-{
-	if (iort_node_match(ACPI_IORT_NODE_SMMU_V3))
-		return arm_smmu_init();
-
-	return 0;
-}
-IORT_ACPI_DECLARE(arm_smmu_v3, ACPI_SIG_IORT, acpi_smmu_v3_init);
-#endif
+IOMMU_OF_DECLARE(arm_smmuv3, "arm,smmu-v3", NULL);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index a60cded..93f77bb 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -2134,56 +2134,14 @@ static int arm_smmu_device_remove(struct platform_device *pdev)
 	.probe	= arm_smmu_device_probe,
 	.remove	= arm_smmu_device_remove,
 };
-
-static int __init arm_smmu_init(void)
-{
-	static bool registered;
-	int ret = 0;
-
-	if (!registered) {
-		ret = platform_driver_register(&arm_smmu_driver);
-		registered = !ret;
-	}
-	return ret;
-}
-
-static void __exit arm_smmu_exit(void)
-{
-	return platform_driver_unregister(&arm_smmu_driver);
-}
-
-subsys_initcall(arm_smmu_init);
-module_exit(arm_smmu_exit);
-
-static int __init arm_smmu_of_init(struct device_node *np)
-{
-	int ret = arm_smmu_init();
-
-	if (ret)
-		return ret;
-
-	if (!of_platform_device_create(np, NULL, platform_bus_type.dev_root))
-		return -ENODEV;
-
-	return 0;
-}
-IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", arm_smmu_of_init);
-IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", arm_smmu_of_init);
-IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", arm_smmu_of_init);
-
-#ifdef CONFIG_ACPI
-static int __init arm_smmu_acpi_init(struct acpi_table_header *table)
-{
-	if (iort_node_match(ACPI_IORT_NODE_SMMU))
-		return arm_smmu_init();
-
-	return 0;
-}
-IORT_ACPI_DECLARE(arm_smmu, ACPI_SIG_IORT, arm_smmu_acpi_init);
-#endif
+module_platform_driver(arm_smmu_driver);
+
+IOMMU_OF_DECLARE(arm_smmuv1, "arm,smmu-v1", NULL);
+IOMMU_OF_DECLARE(arm_smmuv2, "arm,smmu-v2", NULL);
+IOMMU_OF_DECLARE(arm_mmu400, "arm,mmu-400", NULL);
+IOMMU_OF_DECLARE(arm_mmu401, "arm,mmu-401", NULL);
+IOMMU_OF_DECLARE(arm_mmu500, "arm,mmu-500", NULL);
+IOMMU_OF_DECLARE(cavium_smmuv2, "cavium,smmu-v2", NULL);
 
 MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
 MODULE_AUTHOR("Will Deacon <will.deacon@arm.com>");
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 11/11] ACPI/IORT: Remove linker section for IORT entries probing

[Sricharan R]

From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.

Through the introduction of deferred IOMMU configuration the linker
section based IORT probing infrastructure is not needed any longer, in
that device/SMMU probe dependencies are managed through the probe
deferral mechanism, making the IORT linker section infrastructure
unused, so that it can be removed.

Remove the unused IORT linker section probing infrastructure
from the kernel to complete the ACPI IORT IOMMU configure probe
deferral mechanism implementation.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c         | 2 --
 include/asm-generic/vmlinux.lds.h | 1 -
 include/linux/acpi_iort.h         | 3 ---
 3 files changed, 6 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index d01bae8..ac45623 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -992,6 +992,4 @@ void __init acpi_iort_init(void)
 	}
 
 	iort_init_platform_devices();
-
-	acpi_probe_device_table(iort);
 }
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 0968d13..9faa26c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -566,7 +566,6 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
-	ACPI_PROBE_TABLE(iort)						\
 	EARLYCON_TABLE()
 
 #define INIT_TEXT							\
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 77e0809..f167e1d04 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -52,7 +52,4 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
 #endif
 
-#define IORT_ACPI_DECLARE(name, table_id, fn)		\
-	ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
-
 #endif /* __ACPI_IORT_H__ */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

[PATCH V7 11/11] ACPI/IORT: Remove linker section for IORT entries probing

[Sricharan R]

From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

The IORT linker section introduced by commit 34ceea275f62
("ACPI/IORT: Introduce linker section for IORT entries probing")
was needed to make sure SMMU drivers are registered (and therefore
probed) in the kernel before devices using the SMMU have a chance
to probe in turn.

Through the introduction of deferred IOMMU configuration the linker
section based IORT probing infrastructure is not needed any longer, in
that device/SMMU probe dependencies are managed through the probe
deferral mechanism, making the IORT linker section infrastructure
unused, so that it can be removed.

Remove the unused IORT linker section probing infrastructure
from the kernel to complete the ACPI IORT IOMMU configure probe
deferral mechanism implementation.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Sricharan R <sricharan@codeaurora.org>
---
 drivers/acpi/arm64/iort.c         | 2 --
 include/asm-generic/vmlinux.lds.h | 1 -
 include/linux/acpi_iort.h         | 3 ---
 3 files changed, 6 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index d01bae8..ac45623 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -992,6 +992,4 @@ void __init acpi_iort_init(void)
 	}
 
 	iort_init_platform_devices();
-
-	acpi_probe_device_table(iort);
 }
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 0968d13..9faa26c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -566,7 +566,6 @@
 	IRQCHIP_OF_MATCH_TABLE()					\
 	ACPI_PROBE_TABLE(irqchip)					\
 	ACPI_PROBE_TABLE(clksrc)					\
-	ACPI_PROBE_TABLE(iort)						\
 	EARLYCON_TABLE()
 
 #define INIT_TEXT							\
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 77e0809..f167e1d04 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -52,7 +52,4 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
 #endif
 
-#define IORT_ACPI_DECLARE(name, table_id, fn)		\
-	ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
-
 #endif /* __ACPI_IORT_H__ */
-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Marek Szyprowski]

Hi Sricharan

On 2017-01-23 17:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>         |                         |
> pci_bus_add_device     (device_add/driver_register)
>         |                         |
> device_attach           device_initial_probe
>         |                         |
> __device_attach_driver    __device_attach_driver
>         |
> driver_probe_device
>         |
> really_probe
>         |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>    and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Once again:

Tested-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>

Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
urgently needed as more and more stuff depends on it and cannot be easily
workarounded without nasty hacks (for example pending runtime PM changes
for clocks and power domains integration for Exynos 5433).

Is there a chance to have it merged to v4.11?

> Previous post of this series [6].
>
>   [V7]
>       * Updated the subject and commit log for patch #6 as per
>         comments from Lorenzo. No functional changes.
>
>   [V6]
>       * Fixed a bug in dma_configure function pointed out by
>         Robin.
>       * Reordered the patches as per comments from Robin and
>         Lorenzo.
>       * Added Tags.
>
>   [V5]
>       * Reworked the pci configuration code hanging outside and
>         pushed it to dma_configure as in PATCH#5,6,7.
>         Also added a couple of patches that Lorenzo provided for
>         correcting the Probe deferring mechanism in case of
>         ACPI devices from here [5].
>
>   [V4]
>       * Took the reworked patches [2] from Robin's branch and
>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
>       * Added the patches for moving the dma ops configuration of
>         acpi based devices to probe time as well.
>   [V3]
>       * Removed the patch to split dma_masks/dma_ops configuration
>         separately based on review comments that both masks and ops are
>         required only during the device probe time.
>
>       * Reworked the series based on Generic DT bindings series.
>
>       * Added call to iommu's remove_device in the cleanup path for arm and
>         arm64.
>
>       * Removed the notifier trick in arm64 to handle early device
>         registration.
>
>       * Added reset of dma_ops in cleanup path for arm based on comments.
>
>       * Fixed the pci_iommu_configure path and tested with PCI device as
>         well.
>   
>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>         last post.
>
>       * Fixed few other cosmetic comments.
>    
>   [V2]
>       * Updated the Initial post to call dma_configure/deconfigure from
>         generic code
>   
>       * Added iommu add_device callback from of_iommu_configure path
>
>   [V1]
>       * Initial post from Laurent Pinchart [1]
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> [3] https://lkml.org/lkml/2016/11/21/141
> [4] https://www.mail-archive.com/iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org/msg13940.html
> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>
> Laurent Pinchart (3):
>    of: dma: Move range size workaround to of_dma_get_range()
>    of: dma: Make of_dma_deconfigure() public
>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Lorenzo Pieralisi (2):
>    ACPI/IORT: Add function to check SMMUs drivers presence
>    ACPI/IORT: Remove linker section for IORT entries probing
>
> Robin Murphy (3):
>    iommu/of: Refactor of_iommu_configure() for error handling
>    iommu/of: Prepare for deferred IOMMU configuration
>    iommu/arm-smmu: Clean up early-probing workarounds
>
> Sricharan R (3):
>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>      error
>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>      of dma_ops
>
>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>   drivers/acpi/glue.c               |   5 --
>   drivers/acpi/scan.c               |   7 +-
>   drivers/base/dd.c                 |   9 +++
>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>   drivers/of/address.c              |  20 +++++-
>   drivers/of/device.c               |  36 ++++++-----
>   drivers/of/platform.c             |  10 +--
>   drivers/pci/probe.c               |  28 --------
>   include/acpi/acpi_bus.h           |   2 +-
>   include/asm-generic/vmlinux.lds.h |   1 -
>   include/linux/acpi.h              |   7 +-
>   include/linux/acpi_iort.h         |   3 -
>   include/linux/dma-mapping.h       |   3 +
>   include/linux/of_device.h         |  10 ++-
>   19 files changed, 252 insertions(+), 320 deletions(-)
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Marek Szyprowski]

Hi Sricharan

On 2017-01-23 17:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>         |                         |
> pci_bus_add_device     (device_add/driver_register)
>         |                         |
> device_attach           device_initial_probe
>         |                         |
> __device_attach_driver    __device_attach_driver
>         |
> driver_probe_device
>         |
> really_probe
>         |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>    and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Once again:

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
urgently needed as more and more stuff depends on it and cannot be easily
workarounded without nasty hacks (for example pending runtime PM changes
for clocks and power domains integration for Exynos 5433).

Is there a chance to have it merged to v4.11?

> Previous post of this series [6].
>
>   [V7]
>       * Updated the subject and commit log for patch #6 as per
>         comments from Lorenzo. No functional changes.
>
>   [V6]
>       * Fixed a bug in dma_configure function pointed out by
>         Robin.
>       * Reordered the patches as per comments from Robin and
>         Lorenzo.
>       * Added Tags.
>
>   [V5]
>       * Reworked the pci configuration code hanging outside and
>         pushed it to dma_configure as in PATCH#5,6,7.
>         Also added a couple of patches that Lorenzo provided for
>         correcting the Probe deferring mechanism in case of
>         ACPI devices from here [5].
>
>   [V4]
>       * Took the reworked patches [2] from Robin's branch and
>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
>       * Added the patches for moving the dma ops configuration of
>         acpi based devices to probe time as well.
>   [V3]
>       * Removed the patch to split dma_masks/dma_ops configuration
>         separately based on review comments that both masks and ops are
>         required only during the device probe time.
>
>       * Reworked the series based on Generic DT bindings series.
>
>       * Added call to iommu's remove_device in the cleanup path for arm and
>         arm64.
>
>       * Removed the notifier trick in arm64 to handle early device
>         registration.
>
>       * Added reset of dma_ops in cleanup path for arm based on comments.
>
>       * Fixed the pci_iommu_configure path and tested with PCI device as
>         well.
>   
>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>         last post.
>
>       * Fixed few other cosmetic comments.
>    
>   [V2]
>       * Updated the Initial post to call dma_configure/deconfigure from
>         generic code
>   
>       * Added iommu add_device callback from of_iommu_configure path
>
>   [V1]
>       * Initial post from Laurent Pinchart [1]
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> [3] https://lkml.org/lkml/2016/11/21/141
> [4] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg13940.html
> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>
> Laurent Pinchart (3):
>    of: dma: Move range size workaround to of_dma_get_range()
>    of: dma: Make of_dma_deconfigure() public
>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Lorenzo Pieralisi (2):
>    ACPI/IORT: Add function to check SMMUs drivers presence
>    ACPI/IORT: Remove linker section for IORT entries probing
>
> Robin Murphy (3):
>    iommu/of: Refactor of_iommu_configure() for error handling
>    iommu/of: Prepare for deferred IOMMU configuration
>    iommu/arm-smmu: Clean up early-probing workarounds
>
> Sricharan R (3):
>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>      error
>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>      of dma_ops
>
>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>   drivers/acpi/glue.c               |   5 --
>   drivers/acpi/scan.c               |   7 +-
>   drivers/base/dd.c                 |   9 +++
>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>   drivers/of/address.c              |  20 +++++-
>   drivers/of/device.c               |  36 ++++++-----
>   drivers/of/platform.c             |  10 +--
>   drivers/pci/probe.c               |  28 --------
>   include/acpi/acpi_bus.h           |   2 +-
>   include/asm-generic/vmlinux.lds.h |   1 -
>   include/linux/acpi.h              |   7 +-
>   include/linux/acpi_iort.h         |   3 -
>   include/linux/dma-mapping.h       |   3 +
>   include/linux/of_device.h         |  10 ++-
>   19 files changed, 252 insertions(+), 320 deletions(-)
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


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

[PATCH V7 00/11] IOMMU probe deferral support

[Marek Szyprowski]

Hi Sricharan

On 2017-01-23 17:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>         |                         |
> pci_bus_add_device     (device_add/driver_register)
>         |                         |
> device_attach           device_initial_probe
>         |                         |
> __device_attach_driver    __device_attach_driver
>         |
> driver_probe_device
>         |
> really_probe
>         |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>    and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Once again:

Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>

Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
urgently needed as more and more stuff depends on it and cannot be easily
workarounded without nasty hacks (for example pending runtime PM changes
for clocks and power domains integration for Exynos 5433).

Is there a chance to have it merged to v4.11?

> Previous post of this series [6].
>
>   [V7]
>       * Updated the subject and commit log for patch #6 as per
>         comments from Lorenzo. No functional changes.
>
>   [V6]
>       * Fixed a bug in dma_configure function pointed out by
>         Robin.
>       * Reordered the patches as per comments from Robin and
>         Lorenzo.
>       * Added Tags.
>
>   [V5]
>       * Reworked the pci configuration code hanging outside and
>         pushed it to dma_configure as in PATCH#5,6,7.
>         Also added a couple of patches that Lorenzo provided for
>         correcting the Probe deferring mechanism in case of
>         ACPI devices from here [5].
>
>   [V4]
>       * Took the reworked patches [2] from Robin's branch and
>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
>       * Added the patches for moving the dma ops configuration of
>         acpi based devices to probe time as well.
>   [V3]
>       * Removed the patch to split dma_masks/dma_ops configuration
>         separately based on review comments that both masks and ops are
>         required only during the device probe time.
>
>       * Reworked the series based on Generic DT bindings series.
>
>       * Added call to iommu's remove_device in the cleanup path for arm and
>         arm64.
>
>       * Removed the notifier trick in arm64 to handle early device
>         registration.
>
>       * Added reset of dma_ops in cleanup path for arm based on comments.
>
>       * Fixed the pci_iommu_configure path and tested with PCI device as
>         well.
>   
>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>         last post.
>
>       * Fixed few other cosmetic comments.
>    
>   [V2]
>       * Updated the Initial post to call dma_configure/deconfigure from
>         generic code
>   
>       * Added iommu add_device callback from of_iommu_configure path
>
>   [V1]
>       * Initial post from Laurent Pinchart [1]
>
> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
> [3] https://lkml.org/lkml/2016/11/21/141
> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>
> Laurent Pinchart (3):
>    of: dma: Move range size workaround to of_dma_get_range()
>    of: dma: Make of_dma_deconfigure() public
>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
> Lorenzo Pieralisi (2):
>    ACPI/IORT: Add function to check SMMUs drivers presence
>    ACPI/IORT: Remove linker section for IORT entries probing
>
> Robin Murphy (3):
>    iommu/of: Refactor of_iommu_configure() for error handling
>    iommu/of: Prepare for deferred IOMMU configuration
>    iommu/arm-smmu: Clean up early-probing workarounds
>
> Sricharan R (3):
>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>      error
>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>      of dma_ops
>
>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>   drivers/acpi/glue.c               |   5 --
>   drivers/acpi/scan.c               |   7 +-
>   drivers/base/dd.c                 |   9 +++
>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>   drivers/of/address.c              |  20 +++++-
>   drivers/of/device.c               |  36 ++++++-----
>   drivers/of/platform.c             |  10 +--
>   drivers/pci/probe.c               |  28 --------
>   include/acpi/acpi_bus.h           |   2 +-
>   include/asm-generic/vmlinux.lds.h |   1 -
>   include/linux/acpi.h              |   7 +-
>   include/linux/acpi_iort.h         |   3 -
>   include/linux/dma-mapping.h       |   3 +
>   include/linux/of_device.h         |  10 ++-
>   19 files changed, 252 insertions(+), 320 deletions(-)
>

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Marek,

>On 2017-01-23 17:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>         |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>         |                         |
>> device_attach           device_initial_probe
>>         |                         |
>> __device_attach_driver    __device_attach_driver
>>         |
>> driver_probe_device
>>         |
>> really_probe
>>         |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>    and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Once again:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
>urgently needed as more and more stuff depends on it and cannot be easily
>workarounded without nasty hacks (for example pending runtime PM changes
>for clocks and power domains integration for Exynos 5433).
>

Ok, Thanks for the testing once again.

>Is there a chance to have it merged to v4.11?
>

Ya, hoping that this time it would get through.

Regards,
 Sricharan

>> Previous post of this series [6].
>>
>>   [V7]
>>       * Updated the subject and commit log for patch #6 as per
>>         comments from Lorenzo. No functional changes.
>>
>>   [V6]
>>       * Fixed a bug in dma_configure function pointed out by
>>         Robin.
>>       * Reordered the patches as per comments from Robin and
>>         Lorenzo.
>>       * Added Tags.
>>
>>   [V5]
>>       * Reworked the pci configuration code hanging outside and
>>         pushed it to dma_configure as in PATCH#5,6,7.
>>         Also added a couple of patches that Lorenzo provided for
>>         correcting the Probe deferring mechanism in case of
>>         ACPI devices from here [5].
>>
>>   [V4]
>>       * Took the reworked patches [2] from Robin's branch and
>>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>>       * Added the patches for moving the dma ops configuration of
>>         acpi based devices to probe time as well.
>>   [V3]
>>       * Removed the patch to split dma_masks/dma_ops configuration
>>         separately based on review comments that both masks and ops are
>>         required only during the device probe time.
>>
>>       * Reworked the series based on Generic DT bindings series.
>>
>>       * Added call to iommu's remove_device in the cleanup path for arm and
>>         arm64.
>>
>>       * Removed the notifier trick in arm64 to handle early device
>>         registration.
>>
>>       * Added reset of dma_ops in cleanup path for arm based on comments.
>>
>>       * Fixed the pci_iommu_configure path and tested with PCI device as
>>         well.
>>
>>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>>         last post.
>>
>>       * Fixed few other cosmetic comments.
>>
>>   [V2]
>>       * Updated the Initial post to call dma_configure/deconfigure from
>>         generic code
>>
>>       * Added iommu add_device callback from of_iommu_configure path
>>
>>   [V1]
>>       * Initial post from Laurent Pinchart [1]
>>
>> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
>> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
>> [3] https://lkml.org/lkml/2016/11/21/141
>> [4] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg13940.html
>> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
>> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>>
>> Laurent Pinchart (3):
>>    of: dma: Move range size workaround to of_dma_get_range()
>>    of: dma: Make of_dma_deconfigure() public
>>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>>
>> Lorenzo Pieralisi (2):
>>    ACPI/IORT: Add function to check SMMUs drivers presence
>>    ACPI/IORT: Remove linker section for IORT entries probing
>>
>> Robin Murphy (3):
>>    iommu/of: Refactor of_iommu_configure() for error handling
>>    iommu/of: Prepare for deferred IOMMU configuration
>>    iommu/arm-smmu: Clean up early-probing workarounds
>>
>> Sricharan R (3):
>>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>>      error
>>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>>      of dma_ops
>>
>>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>   drivers/acpi/glue.c               |   5 --
>>   drivers/acpi/scan.c               |   7 +-
>>   drivers/base/dd.c                 |   9 +++
>>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>   drivers/of/address.c              |  20 +++++-
>>   drivers/of/device.c               |  36 ++++++-----
>>   drivers/of/platform.c             |  10 +--
>>   drivers/pci/probe.c               |  28 --------
>>   include/acpi/acpi_bus.h           |   2 +-
>>   include/asm-generic/vmlinux.lds.h |   1 -
>>   include/linux/acpi.h              |   7 +-
>>   include/linux/acpi_iort.h         |   3 -
>>   include/linux/dma-mapping.h       |   3 +
>>   include/linux/of_device.h         |  10 ++-
>>   19 files changed, 252 insertions(+), 320 deletions(-)
>>
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Marek,

>On 2017-01-23 17:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>         |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>         |                         |
>> device_attach           device_initial_probe
>>         |                         |
>> __device_attach_driver    __device_attach_driver
>>         |
>> driver_probe_device
>>         |
>> really_probe
>>         |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>    and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Once again:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
>urgently needed as more and more stuff depends on it and cannot be easily
>workarounded without nasty hacks (for example pending runtime PM changes
>for clocks and power domains integration for Exynos 5433).
>

Ok, Thanks for the testing once again.

>Is there a chance to have it merged to v4.11?
>

Ya, hoping that this time it would get through.

Regards,
 Sricharan

>> Previous post of this series [6].
>>
>>   [V7]
>>       * Updated the subject and commit log for patch #6 as per
>>         comments from Lorenzo. No functional changes.
>>
>>   [V6]
>>       * Fixed a bug in dma_configure function pointed out by
>>         Robin.
>>       * Reordered the patches as per comments from Robin and
>>         Lorenzo.
>>       * Added Tags.
>>
>>   [V5]
>>       * Reworked the pci configuration code hanging outside and
>>         pushed it to dma_configure as in PATCH#5,6,7.
>>         Also added a couple of patches that Lorenzo provided for
>>         correcting the Probe deferring mechanism in case of
>>         ACPI devices from here [5].
>>
>>   [V4]
>>       * Took the reworked patches [2] from Robin's branch and
>>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>>       * Added the patches for moving the dma ops configuration of
>>         acpi based devices to probe time as well.
>>   [V3]
>>       * Removed the patch to split dma_masks/dma_ops configuration
>>         separately based on review comments that both masks and ops are
>>         required only during the device probe time.
>>
>>       * Reworked the series based on Generic DT bindings series.
>>
>>       * Added call to iommu's remove_device in the cleanup path for arm and
>>         arm64.
>>
>>       * Removed the notifier trick in arm64 to handle early device
>>         registration.
>>
>>       * Added reset of dma_ops in cleanup path for arm based on comments.
>>
>>       * Fixed the pci_iommu_configure path and tested with PCI device as
>>         well.
>>
>>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>>         last post.
>>
>>       * Fixed few other cosmetic comments.
>>
>>   [V2]
>>       * Updated the Initial post to call dma_configure/deconfigure from
>>         generic code
>>
>>       * Added iommu add_device callback from of_iommu_configure path
>>
>>   [V1]
>>       * Initial post from Laurent Pinchart [1]
>>
>> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
>> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
>> [3] https://lkml.org/lkml/2016/11/21/141
>> [4] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg13940.html
>> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
>> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>>
>> Laurent Pinchart (3):
>>    of: dma: Move range size workaround to of_dma_get_range()
>>    of: dma: Make of_dma_deconfigure() public
>>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>>
>> Lorenzo Pieralisi (2):
>>    ACPI/IORT: Add function to check SMMUs drivers presence
>>    ACPI/IORT: Remove linker section for IORT entries probing
>>
>> Robin Murphy (3):
>>    iommu/of: Refactor of_iommu_configure() for error handling
>>    iommu/of: Prepare for deferred IOMMU configuration
>>    iommu/arm-smmu: Clean up early-probing workarounds
>>
>> Sricharan R (3):
>>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>>      error
>>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>>      of dma_ops
>>
>>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>   drivers/acpi/glue.c               |   5 --
>>   drivers/acpi/scan.c               |   7 +-
>>   drivers/base/dd.c                 |   9 +++
>>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>   drivers/of/address.c              |  20 +++++-
>>   drivers/of/device.c               |  36 ++++++-----
>>   drivers/of/platform.c             |  10 +--
>>   drivers/pci/probe.c               |  28 --------
>>   include/acpi/acpi_bus.h           |   2 +-
>>   include/asm-generic/vmlinux.lds.h |   1 -
>>   include/linux/acpi.h              |   7 +-
>>   include/linux/acpi_iort.h         |   3 -
>>   include/linux/dma-mapping.h       |   3 +
>>   include/linux/of_device.h         |  10 ++-
>>   19 files changed, 252 insertions(+), 320 deletions(-)
>>
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Marek,

>On 2017-01-23 17:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>         |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>         |                         |
>> device_attach           device_initial_probe
>>         |                         |
>> __device_attach_driver    __device_attach_driver
>>         |
>> driver_probe_device
>>         |
>> really_probe
>>         |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>    and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Once again:
>
>Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
>
>Works fine on Exynos machines (both, ARM and ARM64 based). This patchset is
>urgently needed as more and more stuff depends on it and cannot be easily
>workarounded without nasty hacks (for example pending runtime PM changes
>for clocks and power domains integration for Exynos 5433).
>

Ok, Thanks for the testing once again.

>Is there a chance to have it merged to v4.11?
>

Ya, hoping that this time it would get through.

Regards,
 Sricharan

>> Previous post of this series [6].
>>
>>   [V7]
>>       * Updated the subject and commit log for patch #6 as per
>>         comments from Lorenzo. No functional changes.
>>
>>   [V6]
>>       * Fixed a bug in dma_configure function pointed out by
>>         Robin.
>>       * Reordered the patches as per comments from Robin and
>>         Lorenzo.
>>       * Added Tags.
>>
>>   [V5]
>>       * Reworked the pci configuration code hanging outside and
>>         pushed it to dma_configure as in PATCH#5,6,7.
>>         Also added a couple of patches that Lorenzo provided for
>>         correcting the Probe deferring mechanism in case of
>>         ACPI devices from here [5].
>>
>>   [V4]
>>       * Took the reworked patches [2] from Robin's branch and
>>         rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>>       * Added the patches for moving the dma ops configuration of
>>         acpi based devices to probe time as well.
>>   [V3]
>>       * Removed the patch to split dma_masks/dma_ops configuration
>>         separately based on review comments that both masks and ops are
>>         required only during the device probe time.
>>
>>       * Reworked the series based on Generic DT bindings series.
>>
>>       * Added call to iommu's remove_device in the cleanup path for arm and
>>         arm64.
>>
>>       * Removed the notifier trick in arm64 to handle early device
>>         registration.
>>
>>       * Added reset of dma_ops in cleanup path for arm based on comments.
>>
>>       * Fixed the pci_iommu_configure path and tested with PCI device as
>>         well.
>>
>>       * Fixed a bug to return the correct iommu_ops from patch 7 [4] in
>>         last post.
>>
>>       * Fixed few other cosmetic comments.
>>
>>   [V2]
>>       * Updated the Initial post to call dma_configure/deconfigure from
>>         generic code
>>
>>       * Added iommu add_device callback from of_iommu_configure path
>>
>>   [V1]
>>       * Initial post from Laurent Pinchart [1]
>>
>> [1] http://lists.linuxfoundation.org/pipermail/iommu/2015-May/013016.html
>> [2] http://www.linux-arm.org/git?p=linux-rm.git;a=shortlog;h=refs/heads/iommu/defer
>> [3] https://lkml.org/lkml/2016/11/21/141
>> [4] https://www.mail-archive.com/iommu at lists.linux-foundation.org/msg13940.html
>> [5] git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git iommu/probe-deferral
>> [6] https://www.spinics.net/lists/arm-kernel/msg556546.html
>>
>> Laurent Pinchart (3):
>>    of: dma: Move range size workaround to of_dma_get_range()
>>    of: dma: Make of_dma_deconfigure() public
>>    iommu: of: Handle IOMMU lookup failure with deferred probing or error
>>
>> Lorenzo Pieralisi (2):
>>    ACPI/IORT: Add function to check SMMUs drivers presence
>>    ACPI/IORT: Remove linker section for IORT entries probing
>>
>> Robin Murphy (3):
>>    iommu/of: Refactor of_iommu_configure() for error handling
>>    iommu/of: Prepare for deferred IOMMU configuration
>>    iommu/arm-smmu: Clean up early-probing workarounds
>>
>> Sricharan R (3):
>>    of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices
>>    drivers: acpi: Handle IOMMU lookup failure with deferred probing or
>>      error
>>    arm64: dma-mapping: Remove the notifier trick to handle early setting
>>      of dma_ops
>>
>>   arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>   drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>   drivers/acpi/glue.c               |   5 --
>>   drivers/acpi/scan.c               |   7 +-
>>   drivers/base/dd.c                 |   9 +++
>>   drivers/base/dma-mapping.c        |  41 ++++++++++++
>>   drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>   drivers/iommu/arm-smmu.c          |  58 +++--------------
>>   drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>   drivers/of/address.c              |  20 +++++-
>>   drivers/of/device.c               |  36 ++++++-----
>>   drivers/of/platform.c             |  10 +--
>>   drivers/pci/probe.c               |  28 --------
>>   include/acpi/acpi_bus.h           |   2 +-
>>   include/asm-generic/vmlinux.lds.h |   1 -
>>   include/linux/acpi.h              |   7 +-
>>   include/linux/acpi_iort.h         |   3 -
>>   include/linux/dma-mapping.h       |   3 +
>>   include/linux/of_device.h         |  10 ++-
>>   19 files changed, 252 insertions(+), 320 deletions(-)
>>
>
>Best regards
>--
>Marek Szyprowski, PhD
>Samsung R&D Institute Poland
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

[+hanjun, tomasz, sinan]

It is quite a key patchset, I would be glad if they can test on their
respective platforms with IORT.

On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
> This is an equivalent to the DT's handling of the iommu master's probe
> with deferred probing when the corrsponding iommu is not probed yet.
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the firmware describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
>  drivers/acpi/scan.c        |  7 +++++--
>  drivers/base/dma-mapping.c |  2 +-
>  include/acpi/acpi_bus.h    |  2 +-
>  include/linux/acpi.h       |  7 +++++--
>  5 files changed, 36 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bf0ed09..d01bae8 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>  			return NULL;
>  
>  		ops = iommu_get_instance(iort_fwnode);
> +		/*
> +		 * If the ops look-up fails, this means that either
> +		 * the SMMU drivers have not been probed yet or that
> +		 * the SMMU drivers are not built in the kernel;
> +		 * Depending on whether the SMMU drivers are built-in
> +		 * in the kernel or not, defer the IOMMU configuration
> +		 * or just abort it.
> +		 */
>  		if (!ops)
> -			return NULL;
> +			return iort_iommu_driver_enabled(node->type) ?
> +			       ERR_PTR(-EPROBE_DEFER) : NULL;
>  
>  		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>  	}
> @@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  
>  		while (parent) {
>  			ops = iort_iommu_xlate(dev, parent, streamid);
> +			if (IS_ERR_OR_NULL(ops))
> +				return ops;
>  
>  			parent = iort_node_get_id(node, &streamid,
>  						  IORT_IOMMU_TYPE, i++);
>  		}
>  	}
>  
> +	/*
> +	 * If we have reason to believe the IOMMU driver missed the initial
> +	 * add_device callback for dev, replay it to get things in order.
> +	 */
> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> +	    dev->bus && !dev->iommu_group) {
> +		int err = ops->add_device(dev);
> +
> +		if (err)
> +			ops = ERR_PTR(err);
> +	}

I think there is nothing ACPI specific in this add_device() replay
path, so there is room for further DT/ACPI consolidation here.

Without any further ado:

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> +
>  	return ops;
>  }
>  
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 1926918..823b005 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1373,20 +1373,23 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
>   * @dev: The pointer to the device
>   * @attr: device dma attributes
>   */
> -void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
>  {
>  	const struct iommu_ops *iommu;
>  
>  	iort_set_dma_mask(dev);
>  
>  	iommu = iort_iommu_configure(dev);
> -
> +	if (IS_ERR(iommu))
> +		return PTR_ERR(iommu);
>  	/*
>  	 * Assume dma valid range starts at 0 and covers the whole
>  	 * coherent_dma_mask.
>  	 */
>  	arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
>  			   attr == DEV_DMA_COHERENT);
> +
> +	return 0;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dma_configure);
>  
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 82bd45c..755a2b5 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -368,7 +368,7 @@ int dma_configure(struct device *dev)
>  	} else if (has_acpi_companion(dma_dev)) {
>  		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
>  		if (attr != DEV_DMA_NOT_SUPPORTED)
> -			acpi_dma_configure(dev, attr);
> +			ret = acpi_dma_configure(dev, attr);
>  	}
>  
>  	if (bridge)
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 4242c31..9aa762fe 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,7 +573,7 @@ struct acpi_pci_root {
>  
>  bool acpi_dma_supported(struct acpi_device *adev);
>  enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> -void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
>  void acpi_dma_deconfigure(struct device *dev);
>  
>  struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 5b36974..8b958b6 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,8 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
>  	return DEV_DMA_NOT_SUPPORTED;
>  }
>  
> -static inline void acpi_dma_configure(struct device *dev,
> -				      enum dev_dma_attr attr) { }
> +static inline int acpi_dma_configure(struct device *dev,
> +				     enum dev_dma_attr attr)
> +{
> +	return 0;
> +}
>  
>  static inline void acpi_dma_deconfigure(struct device *dev) { }
>  
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

[+hanjun, tomasz, sinan]

It is quite a key patchset, I would be glad if they can test on their
respective platforms with IORT.

On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
> This is an equivalent to the DT's handling of the iommu master's probe
> with deferred probing when the corrsponding iommu is not probed yet.
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the firmware describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
>  drivers/acpi/scan.c        |  7 +++++--
>  drivers/base/dma-mapping.c |  2 +-
>  include/acpi/acpi_bus.h    |  2 +-
>  include/linux/acpi.h       |  7 +++++--
>  5 files changed, 36 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index bf0ed09..d01bae8 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>  			return NULL;
>  
>  		ops = iommu_get_instance(iort_fwnode);
> +		/*
> +		 * If the ops look-up fails, this means that either
> +		 * the SMMU drivers have not been probed yet or that
> +		 * the SMMU drivers are not built in the kernel;
> +		 * Depending on whether the SMMU drivers are built-in
> +		 * in the kernel or not, defer the IOMMU configuration
> +		 * or just abort it.
> +		 */
>  		if (!ops)
> -			return NULL;
> +			return iort_iommu_driver_enabled(node->type) ?
> +			       ERR_PTR(-EPROBE_DEFER) : NULL;
>  
>  		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>  	}
> @@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  
>  		while (parent) {
>  			ops = iort_iommu_xlate(dev, parent, streamid);
> +			if (IS_ERR_OR_NULL(ops))
> +				return ops;
>  
>  			parent = iort_node_get_id(node, &streamid,
>  						  IORT_IOMMU_TYPE, i++);
>  		}
>  	}
>  
> +	/*
> +	 * If we have reason to believe the IOMMU driver missed the initial
> +	 * add_device callback for dev, replay it to get things in order.
> +	 */
> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
> +	    dev->bus && !dev->iommu_group) {
> +		int err = ops->add_device(dev);
> +
> +		if (err)
> +			ops = ERR_PTR(err);
> +	}

I think there is nothing ACPI specific in this add_device() replay
path, so there is room for further DT/ACPI consolidation here.

Without any further ado:

Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

> +
>  	return ops;
>  }
>  
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 1926918..823b005 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1373,20 +1373,23 @@ enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
>   * @dev: The pointer to the device
>   * @attr: device dma attributes
>   */
> -void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> +int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
>  {
>  	const struct iommu_ops *iommu;
>  
>  	iort_set_dma_mask(dev);
>  
>  	iommu = iort_iommu_configure(dev);
> -
> +	if (IS_ERR(iommu))
> +		return PTR_ERR(iommu);
>  	/*
>  	 * Assume dma valid range starts at 0 and covers the whole
>  	 * coherent_dma_mask.
>  	 */
>  	arch_setup_dma_ops(dev, 0, dev->coherent_dma_mask + 1, iommu,
>  			   attr == DEV_DMA_COHERENT);
> +
> +	return 0;
>  }
>  EXPORT_SYMBOL_GPL(acpi_dma_configure);
>  
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 82bd45c..755a2b5 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -368,7 +368,7 @@ int dma_configure(struct device *dev)
>  	} else if (has_acpi_companion(dma_dev)) {
>  		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
>  		if (attr != DEV_DMA_NOT_SUPPORTED)
> -			acpi_dma_configure(dev, attr);
> +			ret = acpi_dma_configure(dev, attr);
>  	}
>  
>  	if (bridge)
> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
> index 4242c31..9aa762fe 100644
> --- a/include/acpi/acpi_bus.h
> +++ b/include/acpi/acpi_bus.h
> @@ -573,7 +573,7 @@ struct acpi_pci_root {
>  
>  bool acpi_dma_supported(struct acpi_device *adev);
>  enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev);
> -void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
> +int acpi_dma_configure(struct device *dev, enum dev_dma_attr attr);
>  void acpi_dma_deconfigure(struct device *dev);
>  
>  struct acpi_device *acpi_find_child_device(struct acpi_device *parent,
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 5b36974..8b958b6 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -764,8 +764,11 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
>  	return DEV_DMA_NOT_SUPPORTED;
>  }
>  
> -static inline void acpi_dma_configure(struct device *dev,
> -				      enum dev_dma_attr attr) { }
> +static inline int acpi_dma_configure(struct device *dev,
> +				     enum dev_dma_attr attr)
> +{
> +	return 0;
> +}
>  
>  static inline void acpi_dma_deconfigure(struct device *dev) { }
>  
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

Hi Lorenzo, Sricharan,

On 01/24/2017 08:37 PM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
>
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.

ACPI patches are conflict with my acpi platform msi patches (I need
them to enable devices on my ARM64 platform then test this patch set),
I will fix the conflict and test it tomorrow (out of office now and
can't reach the test machines) :)

Thanks
Hanjun

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

Hi Lorenzo, Sricharan,

On 01/24/2017 08:37 PM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
>
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.

ACPI patches are conflict with my acpi platform msi patches (I need
them to enable devices on my ARM64 platform then test this patch set),
I will fix the conflict and test it tomorrow (out of office now and
can't reach the test machines) :)

Thanks
Hanjun

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

Hi Lorenzo, Sricharan,

On 01/24/2017 08:37 PM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
>
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.

ACPI patches are conflict with my acpi platform msi patches (I need
them to enable devices on my ARM64 platform then test this patch set),
I will fix the conflict and test it tomorrow (out of office now and
can't reach the test machines) :)

Thanks
Hanjun

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Hanjun Guo]

On 2017/1/24 0:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>   and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Cherry picked this patch set with no conflict with my platform
msi patches, and test it on Hisilicon D03 (ARM64 platform with
SMMUv3) with ACPI, it boots ok as before and the native NIC and
SAS (platform devices) are working properly.

for ACPI and the core code changes:

Tested-by: Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>

Thanks
Hanjun

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Hanjun Guo]

On 2017/1/24 0:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>   and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Cherry picked this patch set with no conflict with my platform
msi patches, and test it on Hisilicon D03 (ARM64 platform with
SMMUv3) with ACPI, it boots ok as before and the native NIC and
SAS (platform devices) are working properly.

for ACPI and the core code changes:

Tested-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks
Hanjun

[PATCH V7 00/11] IOMMU probe deferral support

[Hanjun Guo]

On 2017/1/24 0:18, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> Took the reworked patches [2] from Robin's branch and
> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>
> * Tested with platform and pci devices for probe deferral
>   and reprobe on arm64 based platform.
> * Need help for testing with ACPI.

Cherry picked this patch set with no conflict with my platform
msi patches, and test it on Hisilicon D03 (ARM64 platform with
SMMUv3) with ACPI, it boots ok as before and the native NIC and
SAS (platform devices) are working properly.

for ACPI and the core code changes:

Tested-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks
Hanjun

RE: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Lorenzo,

>[+hanjun, tomasz, sinan]
>
>It is quite a key patchset, I would be glad if they can test on their
>respective platforms with IORT.
>
>On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
>> This is an equivalent to the DT's handling of the iommu master's probe
>> with deferred probing when the corrsponding iommu is not probed yet.
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the firmware describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>>  drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
>>  drivers/acpi/scan.c        |  7 +++++--
>>  drivers/base/dma-mapping.c |  2 +-
>>  include/acpi/acpi_bus.h    |  2 +-
>>  include/linux/acpi.h       |  7 +++++--
>>  5 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bf0ed09..d01bae8 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>>  			return NULL;
>>
>>  		ops = iommu_get_instance(iort_fwnode);
>> +		/*
>> +		 * If the ops look-up fails, this means that either
>> +		 * the SMMU drivers have not been probed yet or that
>> +		 * the SMMU drivers are not built in the kernel;
>> +		 * Depending on whether the SMMU drivers are built-in
>> +		 * in the kernel or not, defer the IOMMU configuration
>> +		 * or just abort it.
>> +		 */
>>  		if (!ops)
>> -			return NULL;
>> +			return iort_iommu_driver_enabled(node->type) ?
>> +			       ERR_PTR(-EPROBE_DEFER) : NULL;
>>
>>  		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>>  	}
>> @@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>>
>>  		while (parent) {
>>  			ops = iort_iommu_xlate(dev, parent, streamid);
>> +			if (IS_ERR_OR_NULL(ops))
>> +				return ops;
>>
>>  			parent = iort_node_get_id(node, &streamid,
>>  						  IORT_IOMMU_TYPE, i++);
>>  		}
>>  	}
>>
>> +	/*
>> +	 * If we have reason to believe the IOMMU driver missed the initial
>> +	 * add_device callback for dev, replay it to get things in order.
>> +	 */
>> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
>> +	    dev->bus && !dev->iommu_group) {
>> +		int err = ops->add_device(dev);
>> +
>> +		if (err)
>> +			ops = ERR_PTR(err);
>> +	}
>
>I think there is nothing ACPI specific in this add_device() replay
>path, so there is room for further DT/ACPI consolidation here.
>

ok, the only way is keep this in a function and call it for both DT and ACPI
cases.

>Without any further ado:
>
>Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>

Thanks for that.

Regards,
 Sricharan

RE: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Lorenzo,

>[+hanjun, tomasz, sinan]
>
>It is quite a key patchset, I would be glad if they can test on their
>respective platforms with IORT.
>
>On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
>> This is an equivalent to the DT's handling of the iommu master's probe
>> with deferred probing when the corrsponding iommu is not probed yet.
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the firmware describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>>  drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
>>  drivers/acpi/scan.c        |  7 +++++--
>>  drivers/base/dma-mapping.c |  2 +-
>>  include/acpi/acpi_bus.h    |  2 +-
>>  include/linux/acpi.h       |  7 +++++--
>>  5 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bf0ed09..d01bae8 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>>  			return NULL;
>>
>>  		ops = iommu_get_instance(iort_fwnode);
>> +		/*
>> +		 * If the ops look-up fails, this means that either
>> +		 * the SMMU drivers have not been probed yet or that
>> +		 * the SMMU drivers are not built in the kernel;
>> +		 * Depending on whether the SMMU drivers are built-in
>> +		 * in the kernel or not, defer the IOMMU configuration
>> +		 * or just abort it.
>> +		 */
>>  		if (!ops)
>> -			return NULL;
>> +			return iort_iommu_driver_enabled(node->type) ?
>> +			       ERR_PTR(-EPROBE_DEFER) : NULL;
>>
>>  		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>>  	}
>> @@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>>
>>  		while (parent) {
>>  			ops = iort_iommu_xlate(dev, parent, streamid);
>> +			if (IS_ERR_OR_NULL(ops))
>> +				return ops;
>>
>>  			parent = iort_node_get_id(node, &streamid,
>>  						  IORT_IOMMU_TYPE, i++);
>>  		}
>>  	}
>>
>> +	/*
>> +	 * If we have reason to believe the IOMMU driver missed the initial
>> +	 * add_device callback for dev, replay it to get things in order.
>> +	 */
>> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
>> +	    dev->bus && !dev->iommu_group) {
>> +		int err = ops->add_device(dev);
>> +
>> +		if (err)
>> +			ops = ERR_PTR(err);
>> +	}
>
>I think there is nothing ACPI specific in this add_device() replay
>path, so there is room for further DT/ACPI consolidation here.
>

ok, the only way is keep this in a function and call it for both DT and ACPI
cases.

>Without any further ado:
>
>Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Thanks for that.

Regards,
 Sricharan



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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Lorenzo,

>[+hanjun, tomasz, sinan]
>
>It is quite a key patchset, I would be glad if they can test on their
>respective platforms with IORT.
>
>On Mon, Jan 23, 2017 at 09:48:10PM +0530, Sricharan R wrote:
>> This is an equivalent to the DT's handling of the iommu master's probe
>> with deferred probing when the corrsponding iommu is not probed yet.
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the firmware describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>>  drivers/acpi/arm64/iort.c  | 25 ++++++++++++++++++++++++-
>>  drivers/acpi/scan.c        |  7 +++++--
>>  drivers/base/dma-mapping.c |  2 +-
>>  include/acpi/acpi_bus.h    |  2 +-
>>  include/linux/acpi.h       |  7 +++++--
>>  5 files changed, 36 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
>> index bf0ed09..d01bae8 100644
>> --- a/drivers/acpi/arm64/iort.c
>> +++ b/drivers/acpi/arm64/iort.c
>> @@ -550,8 +550,17 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
>>  			return NULL;
>>
>>  		ops = iommu_get_instance(iort_fwnode);
>> +		/*
>> +		 * If the ops look-up fails, this means that either
>> +		 * the SMMU drivers have not been probed yet or that
>> +		 * the SMMU drivers are not built in the kernel;
>> +		 * Depending on whether the SMMU drivers are built-in
>> +		 * in the kernel or not, defer the IOMMU configuration
>> +		 * or just abort it.
>> +		 */
>>  		if (!ops)
>> -			return NULL;
>> +			return iort_iommu_driver_enabled(node->type) ?
>> +			       ERR_PTR(-EPROBE_DEFER) : NULL;
>>
>>  		ret = arm_smmu_iort_xlate(dev, streamid, iort_fwnode, ops);
>>  	}
>> @@ -625,12 +634,26 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>>
>>  		while (parent) {
>>  			ops = iort_iommu_xlate(dev, parent, streamid);
>> +			if (IS_ERR_OR_NULL(ops))
>> +				return ops;
>>
>>  			parent = iort_node_get_id(node, &streamid,
>>  						  IORT_IOMMU_TYPE, i++);
>>  		}
>>  	}
>>
>> +	/*
>> +	 * If we have reason to believe the IOMMU driver missed the initial
>> +	 * add_device callback for dev, replay it to get things in order.
>> +	 */
>> +	if (!IS_ERR_OR_NULL(ops) && ops->add_device &&
>> +	    dev->bus && !dev->iommu_group) {
>> +		int err = ops->add_device(dev);
>> +
>> +		if (err)
>> +			ops = ERR_PTR(err);
>> +	}
>
>I think there is nothing ACPI specific in this add_device() replay
>path, so there is room for further DT/ACPI consolidation here.
>

ok, the only way is keep this in a function and call it for both DT and ACPI
cases.

>Without any further ado:
>
>Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

Thanks for that.

Regards,
 Sricharan

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Hanjun,

>On 2017/1/24 0:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>        |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>        |                         |
>> device_attach           device_initial_probe
>>        |                         |
>> __device_attach_driver    __device_attach_driver
>>        |
>> driver_probe_device
>>        |
>> really_probe
>>        |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>   and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Cherry picked this patch set with no conflict with my platform
>msi patches, and test it on Hisilicon D03 (ARM64 platform with
>SMMUv3) with ACPI, it boots ok as before and the native NIC and
>SAS (platform devices) are working properly.
>
>for ACPI and the core code changes:
>
>Tested-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks for the testing with ACPI + SMMUV3

Regards,
 Sricharan

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Hanjun,

>On 2017/1/24 0:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>        |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>        |                         |
>> device_attach           device_initial_probe
>>        |                         |
>> __device_attach_driver    __device_attach_driver
>>        |
>> driver_probe_device
>>        |
>> really_probe
>>        |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>   and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Cherry picked this patch set with no conflict with my platform
>msi patches, and test it on Hisilicon D03 (ARM64 platform with
>SMMUv3) with ACPI, it boots ok as before and the native NIC and
>SAS (platform devices) are working properly.
>
>for ACPI and the core code changes:
>
>Tested-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks for the testing with ACPI + SMMUV3

Regards,
 Sricharan

[PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Hanjun,

>On 2017/1/24 0:18, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>>
>> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>>        |                         |
>> pci_bus_add_device     (device_add/driver_register)
>>        |                         |
>> device_attach           device_initial_probe
>>        |                         |
>> __device_attach_driver    __device_attach_driver
>>        |
>> driver_probe_device
>>        |
>> really_probe
>>        |
>> dma_configure
>>
>> Similarly on the device/driver_unregister path __device_release_driver is
>> called which inturn calls dma_deconfigure.
>>
>> Took the reworked patches [2] from Robin's branch and
>> rebased on top of Lorenzo's ACPI IORT ARM support series [3].
>>
>> * Tested with platform and pci devices for probe deferral
>>   and reprobe on arm64 based platform.
>> * Need help for testing with ACPI.
>
>Cherry picked this patch set with no conflict with my platform
>msi patches, and test it on Hisilicon D03 (ARM64 platform with
>SMMUv3) with ACPI, it boots ok as before and the native NIC and
>SAS (platform devices) are working properly.
>
>for ACPI and the core code changes:
>
>Tested-by: Hanjun Guo <hanjun.guo@linaro.org>

Thanks for the testing with ACPI + SMMUV3

Regards,
 Sricharan

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Tomasz Nowicki]

Hi Sricharan,

On 23.01.2017 17:18, Sricharan R wrote:
> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>
> In preparation for some upcoming cleverness, rework the control flow in
> of_iommu_configure() to minimise duplication and improve the propogation
> of errors. It's also as good a time as any to switch over from the
> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
> IOMMU instance interface directly.
>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>  drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
>  1 file changed, 53 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 0f57ddc..ee49081 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>  }
>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> +static const struct iommu_ops
> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> +{
> +	const struct iommu_ops *ops;
> +	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
> +	int err;
> +
> +	ops = iommu_get_instance(fwnode);
> +	if (!ops || !ops->of_xlate)
> +		return NULL;
> +
> +	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	err = ops->of_xlate(dev, iommu_spec);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	return ops;
> +}
> +
>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  {
>  	struct of_phandle_args *iommu_spec = data;
> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  }
>
>  static const struct iommu_ops
> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>  {
>  	const struct iommu_ops *ops;
>  	struct of_phandle_args iommu_spec;
> +	int err;
>
>  	/*
>  	 * Start by tracing the RID alias down the PCI topology as
> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  	 * bus into the system beyond, and which IOMMU it ends up at.
>  	 */
>  	iommu_spec.np = NULL;
> -	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> -			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
> -		return NULL;
> +	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> +			     "iommu-map-mask", &iommu_spec.np,
> +			     iommu_spec.args);
> +	if (err)
> +		return ERR_PTR(err);
>
> -	ops = of_iommu_get_ops(iommu_spec.np);
> -	if (!ops || !ops->of_xlate ||
> -	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
> -	    ops->of_xlate(&pdev->dev, &iommu_spec))
> -		ops = NULL;
> +	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>
>  	of_node_put(iommu_spec.np);
>  	return ops;
>  }
>
> -const struct iommu_ops *of_iommu_configure(struct device *dev,
> -					   struct device_node *master_np)
> +static const struct iommu_ops
> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>  {
>  	struct of_phandle_args iommu_spec;
> -	struct device_node *np;
>  	const struct iommu_ops *ops = NULL;
>  	int idx = 0;
>
> -	if (dev_is_pci(dev))
> -		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> -
>  	/*
>  	 * We don't currently walk up the tree looking for a parent IOMMU.
>  	 * See the `Notes:' section of
>  	 * Documentation/devicetree/bindings/iommu/iommu.txt
>  	 */
> -	while (!of_parse_phandle_with_args(master_np, "iommus",
> -					   "#iommu-cells", idx,
> -					   &iommu_spec)) {
> -		np = iommu_spec.np;
> -		ops = of_iommu_get_ops(np);
> -
> -		if (!ops || !ops->of_xlate ||
> -		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
> -		    ops->of_xlate(dev, &iommu_spec))
> -			goto err_put_node;
> -
> -		of_node_put(np);
> +	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
> +					   idx, &iommu_spec)) {
> +		ops = of_iommu_xlate(dev, &iommu_spec);
> +		of_node_put(iommu_spec.np);
>  		idx++;
> +		if (IS_ERR_OR_NULL(ops))
> +			break;
>  	}
>
>  	return ops;
> +}
> +
> +const struct iommu_ops *of_iommu_configure(struct device *dev,
> +					   struct device_node *master_np)
> +{
> +	const struct iommu_ops *ops;
> +
> +	if (!master_np)
> +		return NULL;
> +
> +	if (dev_is_pci(dev))
> +		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);

I gave the whole patch set a try on ThunderX. really_probe() is failing 
on dma_configure()->of_pci_iommu_init() for each PCI device. 
of_pci_iommu_init() tries to setup firmware stuff via "iommu-map" but 
ThunderX is using legacy "mmu-masters" binding. We need to take care of 
that case too.

> +	else
> +		ops = of_platform_iommu_init(dev, master_np);
>
> -err_put_node:
> -	of_node_put(np);
> -	return NULL;
> +	return IS_ERR(ops) ? NULL : ops;
>  }
>
>  static int __init of_iommu_init(void)
>

Thanks,
Tomasz

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Tomasz Nowicki]

Hi Sricharan,

On 23.01.2017 17:18, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> In preparation for some upcoming cleverness, rework the control flow in
> of_iommu_configure() to minimise duplication and improve the propogation
> of errors. It's also as good a time as any to switch over from the
> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
> IOMMU instance interface directly.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
>  1 file changed, 53 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 0f57ddc..ee49081 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>  }
>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> +static const struct iommu_ops
> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> +{
> +	const struct iommu_ops *ops;
> +	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
> +	int err;
> +
> +	ops = iommu_get_instance(fwnode);
> +	if (!ops || !ops->of_xlate)
> +		return NULL;
> +
> +	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	err = ops->of_xlate(dev, iommu_spec);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	return ops;
> +}
> +
>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  {
>  	struct of_phandle_args *iommu_spec = data;
> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  }
>
>  static const struct iommu_ops
> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>  {
>  	const struct iommu_ops *ops;
>  	struct of_phandle_args iommu_spec;
> +	int err;
>
>  	/*
>  	 * Start by tracing the RID alias down the PCI topology as
> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  	 * bus into the system beyond, and which IOMMU it ends up at.
>  	 */
>  	iommu_spec.np = NULL;
> -	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> -			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
> -		return NULL;
> +	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> +			     "iommu-map-mask", &iommu_spec.np,
> +			     iommu_spec.args);
> +	if (err)
> +		return ERR_PTR(err);
>
> -	ops = of_iommu_get_ops(iommu_spec.np);
> -	if (!ops || !ops->of_xlate ||
> -	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
> -	    ops->of_xlate(&pdev->dev, &iommu_spec))
> -		ops = NULL;
> +	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>
>  	of_node_put(iommu_spec.np);
>  	return ops;
>  }
>
> -const struct iommu_ops *of_iommu_configure(struct device *dev,
> -					   struct device_node *master_np)
> +static const struct iommu_ops
> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>  {
>  	struct of_phandle_args iommu_spec;
> -	struct device_node *np;
>  	const struct iommu_ops *ops = NULL;
>  	int idx = 0;
>
> -	if (dev_is_pci(dev))
> -		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> -
>  	/*
>  	 * We don't currently walk up the tree looking for a parent IOMMU.
>  	 * See the `Notes:' section of
>  	 * Documentation/devicetree/bindings/iommu/iommu.txt
>  	 */
> -	while (!of_parse_phandle_with_args(master_np, "iommus",
> -					   "#iommu-cells", idx,
> -					   &iommu_spec)) {
> -		np = iommu_spec.np;
> -		ops = of_iommu_get_ops(np);
> -
> -		if (!ops || !ops->of_xlate ||
> -		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
> -		    ops->of_xlate(dev, &iommu_spec))
> -			goto err_put_node;
> -
> -		of_node_put(np);
> +	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
> +					   idx, &iommu_spec)) {
> +		ops = of_iommu_xlate(dev, &iommu_spec);
> +		of_node_put(iommu_spec.np);
>  		idx++;
> +		if (IS_ERR_OR_NULL(ops))
> +			break;
>  	}
>
>  	return ops;
> +}
> +
> +const struct iommu_ops *of_iommu_configure(struct device *dev,
> +					   struct device_node *master_np)
> +{
> +	const struct iommu_ops *ops;
> +
> +	if (!master_np)
> +		return NULL;
> +
> +	if (dev_is_pci(dev))
> +		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);

I gave the whole patch set a try on ThunderX. really_probe() is failing 
on dma_configure()->of_pci_iommu_init() for each PCI device. 
of_pci_iommu_init() tries to setup firmware stuff via "iommu-map" but 
ThunderX is using legacy "mmu-masters" binding. We need to take care of 
that case too.

> +	else
> +		ops = of_platform_iommu_init(dev, master_np);
>
> -err_put_node:
> -	of_node_put(np);
> -	return NULL;
> +	return IS_ERR(ops) ? NULL : ops;
>  }
>
>  static int __init of_iommu_init(void)
>

Thanks,
Tomasz

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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Tomasz Nowicki]

Hi Sricharan,

On 23.01.2017 17:18, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> In preparation for some upcoming cleverness, rework the control flow in
> of_iommu_configure() to minimise duplication and improve the propogation
> of errors. It's also as good a time as any to switch over from the
> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
> IOMMU instance interface directly.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  drivers/iommu/of_iommu.c | 83 +++++++++++++++++++++++++++++++-----------------
>  1 file changed, 53 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 0f57ddc..ee49081 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const char *prefix, int index,
>  }
>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>
> +static const struct iommu_ops
> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> +{
> +	const struct iommu_ops *ops;
> +	struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
> +	int err;
> +
> +	ops = iommu_get_instance(fwnode);
> +	if (!ops || !ops->of_xlate)
> +		return NULL;
> +
> +	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	err = ops->of_xlate(dev, iommu_spec);
> +	if (err)
> +		return ERR_PTR(err);
> +
> +	return ops;
> +}
> +
>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  {
>  	struct of_phandle_args *iommu_spec = data;
> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  }
>
>  static const struct iommu_ops
> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node *bridge_np)
> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>  {
>  	const struct iommu_ops *ops;
>  	struct of_phandle_args iommu_spec;
> +	int err;
>
>  	/*
>  	 * Start by tracing the RID alias down the PCI topology as
> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>  	 * bus into the system beyond, and which IOMMU it ends up at.
>  	 */
>  	iommu_spec.np = NULL;
> -	if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> -			   "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
> -		return NULL;
> +	err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
> +			     "iommu-map-mask", &iommu_spec.np,
> +			     iommu_spec.args);
> +	if (err)
> +		return ERR_PTR(err);
>
> -	ops = of_iommu_get_ops(iommu_spec.np);
> -	if (!ops || !ops->of_xlate ||
> -	    iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
> -	    ops->of_xlate(&pdev->dev, &iommu_spec))
> -		ops = NULL;
> +	ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>
>  	of_node_put(iommu_spec.np);
>  	return ops;
>  }
>
> -const struct iommu_ops *of_iommu_configure(struct device *dev,
> -					   struct device_node *master_np)
> +static const struct iommu_ops
> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>  {
>  	struct of_phandle_args iommu_spec;
> -	struct device_node *np;
>  	const struct iommu_ops *ops = NULL;
>  	int idx = 0;
>
> -	if (dev_is_pci(dev))
> -		return of_pci_iommu_configure(to_pci_dev(dev), master_np);
> -
>  	/*
>  	 * We don't currently walk up the tree looking for a parent IOMMU.
>  	 * See the `Notes:' section of
>  	 * Documentation/devicetree/bindings/iommu/iommu.txt
>  	 */
> -	while (!of_parse_phandle_with_args(master_np, "iommus",
> -					   "#iommu-cells", idx,
> -					   &iommu_spec)) {
> -		np = iommu_spec.np;
> -		ops = of_iommu_get_ops(np);
> -
> -		if (!ops || !ops->of_xlate ||
> -		    iommu_fwspec_init(dev, &np->fwnode, ops) ||
> -		    ops->of_xlate(dev, &iommu_spec))
> -			goto err_put_node;
> -
> -		of_node_put(np);
> +	while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
> +					   idx, &iommu_spec)) {
> +		ops = of_iommu_xlate(dev, &iommu_spec);
> +		of_node_put(iommu_spec.np);
>  		idx++;
> +		if (IS_ERR_OR_NULL(ops))
> +			break;
>  	}
>
>  	return ops;
> +}
> +
> +const struct iommu_ops *of_iommu_configure(struct device *dev,
> +					   struct device_node *master_np)
> +{
> +	const struct iommu_ops *ops;
> +
> +	if (!master_np)
> +		return NULL;
> +
> +	if (dev_is_pci(dev))
> +		ops = of_pci_iommu_init(to_pci_dev(dev), master_np);

I gave the whole patch set a try on ThunderX. really_probe() is failing 
on dma_configure()->of_pci_iommu_init() for each PCI device. 
of_pci_iommu_init() tries to setup firmware stuff via "iommu-map" but 
ThunderX is using legacy "mmu-masters" binding. We need to take care of 
that case too.

> +	else
> +		ops = of_platform_iommu_init(dev, master_np);
>
> -err_put_node:
> -	of_node_put(np);
> -	return NULL;
> +	return IS_ERR(ops) ? NULL : ops;
>  }
>
>  static int __init of_iommu_init(void)
>

Thanks,
Tomasz

Re: [PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Tomasz Nowicki]

On 23.01.2017 17:18, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> Now that the appropriate ordering is enforced via profe-deferral of
> masters in core code, rip it all out and bask in the simplicity.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> [Sricharan: Rebased on top of ACPI IORT SMMU series]
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

[...]

> -
> -#ifdef CONFIG_ACPI
> -static int __init acpi_smmu_v3_init(struct acpi_table_header *table)
> -{
> -	if (iort_node_match(ACPI_IORT_NODE_SMMU_V3))
> -		return arm_smmu_init();

Since we clean the code we can remove iort_node_match() from iort.c. 
There is no user for it any more. Unless Lorenzo has some plans for it.

Thanks,
Tomasz

[PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Tomasz Nowicki]

On 23.01.2017 17:18, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
>
> Now that the appropriate ordering is enforced via profe-deferral of
> masters in core code, rip it all out and bask in the simplicity.
>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> [Sricharan: Rebased on top of ACPI IORT SMMU series]
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

[...]

> -
> -#ifdef CONFIG_ACPI
> -static int __init acpi_smmu_v3_init(struct acpi_table_header *table)
> -{
> -	if (iort_node_match(ACPI_IORT_NODE_SMMU_V3))
> -		return arm_smmu_init();

Since we clean the code we can remove iort_node_match() from iort.c. 
There is no user for it any more. Unless Lorenzo has some plans for it.

Thanks,
Tomasz

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

Hi Tomasz,

On 25/01/17 17:17, Tomasz Nowicki wrote:
> Hi Sricharan,
> 
> On 23.01.2017 17:18, Sricharan R wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> In preparation for some upcoming cleverness, rework the control flow in
>> of_iommu_configure() to minimise duplication and improve the propogation
>> of errors. It's also as good a time as any to switch over from the
>> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
>> IOMMU instance interface directly.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>  drivers/iommu/of_iommu.c | 83
>> +++++++++++++++++++++++++++++++-----------------
>>  1 file changed, 53 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 0f57ddc..ee49081 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const
>> char *prefix, int index,
>>  }
>>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>>
>> +static const struct iommu_ops
>> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
>> +{
>> +    const struct iommu_ops *ops;
>> +    struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
>> +    int err;
>> +
>> +    ops = iommu_get_instance(fwnode);
>> +    if (!ops || !ops->of_xlate)
>> +        return NULL;
>> +
>> +    err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>> +    if (err)
>> +        return ERR_PTR(err);
>> +
>> +    err = ops->of_xlate(dev, iommu_spec);
>> +    if (err)
>> +        return ERR_PTR(err);
>> +
>> +    return ops;
>> +}
>> +
>>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>  {
>>      struct of_phandle_args *iommu_spec = data;
>> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev,
>> u16 alias, void *data)
>>  }
>>
>>  static const struct iommu_ops
>> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node
>> *bridge_np)
>> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>>  {
>>      const struct iommu_ops *ops;
>>      struct of_phandle_args iommu_spec;
>> +    int err;
>>
>>      /*
>>       * Start by tracing the RID alias down the PCI topology as
>> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev,
>> u16 alias, void *data)
>>       * bus into the system beyond, and which IOMMU it ends up at.
>>       */
>>      iommu_spec.np = NULL;
>> -    if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>> -               "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
>> -        return NULL;
>> +    err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>> +                 "iommu-map-mask", &iommu_spec.np,
>> +                 iommu_spec.args);
>> +    if (err)
>> +        return ERR_PTR(err);
>>
>> -    ops = of_iommu_get_ops(iommu_spec.np);
>> -    if (!ops || !ops->of_xlate ||
>> -        iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
>> -        ops->of_xlate(&pdev->dev, &iommu_spec))
>> -        ops = NULL;
>> +    ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>>
>>      of_node_put(iommu_spec.np);
>>      return ops;
>>  }
>>
>> -const struct iommu_ops *of_iommu_configure(struct device *dev,
>> -                       struct device_node *master_np)
>> +static const struct iommu_ops
>> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>>  {
>>      struct of_phandle_args iommu_spec;
>> -    struct device_node *np;
>>      const struct iommu_ops *ops = NULL;
>>      int idx = 0;
>>
>> -    if (dev_is_pci(dev))
>> -        return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>> -
>>      /*
>>       * We don't currently walk up the tree looking for a parent IOMMU.
>>       * See the `Notes:' section of
>>       * Documentation/devicetree/bindings/iommu/iommu.txt
>>       */
>> -    while (!of_parse_phandle_with_args(master_np, "iommus",
>> -                       "#iommu-cells", idx,
>> -                       &iommu_spec)) {
>> -        np = iommu_spec.np;
>> -        ops = of_iommu_get_ops(np);
>> -
>> -        if (!ops || !ops->of_xlate ||
>> -            iommu_fwspec_init(dev, &np->fwnode, ops) ||
>> -            ops->of_xlate(dev, &iommu_spec))
>> -            goto err_put_node;
>> -
>> -        of_node_put(np);
>> +    while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>> +                       idx, &iommu_spec)) {
>> +        ops = of_iommu_xlate(dev, &iommu_spec);
>> +        of_node_put(iommu_spec.np);
>>          idx++;
>> +        if (IS_ERR_OR_NULL(ops))
>> +            break;
>>      }
>>
>>      return ops;
>> +}
>> +
>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>> +                       struct device_node *master_np)
>> +{
>> +    const struct iommu_ops *ops;
>> +
>> +    if (!master_np)
>> +        return NULL;
>> +
>> +    if (dev_is_pci(dev))
>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> 
> I gave the whole patch set a try on ThunderX. really_probe() is failing
> on dma_configure()->of_pci_iommu_init() for each PCI device.

When you say "failing", do you mean cleanly, or with a crash? I've
managed to hit __of_match_node() dereferencing NULL from
of_iommu_xlate() in a horribly complicated chain of events, which I'm
trying to figure out now, and I wonder if the two might be related.

> of_pci_iommu_init() tries to setup firmware stuff via "iommu-map" but
> ThunderX is using legacy "mmu-masters" binding. We need to take care of
> that case too.

That is by design. The "mmu-masters" binding is ARM-SMMU-specific and
will continue to provide the same level of DMA ops support it always has
(for which there really are practical implementation reasons, it's not
just an arbitrary "encourage people to move to the generic bindings"
decision).

Robin.

>> +    else
>> +        ops = of_platform_iommu_init(dev, master_np);
>>
>> -err_put_node:
>> -    of_node_put(np);
>> -    return NULL;
>> +    return IS_ERR(ops) ? NULL : ops;
>>  }
>>
>>  static int __init of_iommu_init(void)
>>
> 
> Thanks,
> Tomasz

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

Hi Tomasz,

On 25/01/17 17:17, Tomasz Nowicki wrote:
> Hi Sricharan,
> 
> On 23.01.2017 17:18, Sricharan R wrote:
>> From: Robin Murphy <robin.murphy@arm.com>
>>
>> In preparation for some upcoming cleverness, rework the control flow in
>> of_iommu_configure() to minimise duplication and improve the propogation
>> of errors. It's also as good a time as any to switch over from the
>> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
>> IOMMU instance interface directly.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>  drivers/iommu/of_iommu.c | 83
>> +++++++++++++++++++++++++++++++-----------------
>>  1 file changed, 53 insertions(+), 30 deletions(-)
>>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 0f57ddc..ee49081 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const
>> char *prefix, int index,
>>  }
>>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>>
>> +static const struct iommu_ops
>> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
>> +{
>> +    const struct iommu_ops *ops;
>> +    struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
>> +    int err;
>> +
>> +    ops = iommu_get_instance(fwnode);
>> +    if (!ops || !ops->of_xlate)
>> +        return NULL;
>> +
>> +    err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>> +    if (err)
>> +        return ERR_PTR(err);
>> +
>> +    err = ops->of_xlate(dev, iommu_spec);
>> +    if (err)
>> +        return ERR_PTR(err);
>> +
>> +    return ops;
>> +}
>> +
>>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>  {
>>      struct of_phandle_args *iommu_spec = data;
>> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev,
>> u16 alias, void *data)
>>  }
>>
>>  static const struct iommu_ops
>> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node
>> *bridge_np)
>> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>>  {
>>      const struct iommu_ops *ops;
>>      struct of_phandle_args iommu_spec;
>> +    int err;
>>
>>      /*
>>       * Start by tracing the RID alias down the PCI topology as
>> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev,
>> u16 alias, void *data)
>>       * bus into the system beyond, and which IOMMU it ends up at.
>>       */
>>      iommu_spec.np = NULL;
>> -    if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>> -               "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
>> -        return NULL;
>> +    err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>> +                 "iommu-map-mask", &iommu_spec.np,
>> +                 iommu_spec.args);
>> +    if (err)
>> +        return ERR_PTR(err);
>>
>> -    ops = of_iommu_get_ops(iommu_spec.np);
>> -    if (!ops || !ops->of_xlate ||
>> -        iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
>> -        ops->of_xlate(&pdev->dev, &iommu_spec))
>> -        ops = NULL;
>> +    ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>>
>>      of_node_put(iommu_spec.np);
>>      return ops;
>>  }
>>
>> -const struct iommu_ops *of_iommu_configure(struct device *dev,
>> -                       struct device_node *master_np)
>> +static const struct iommu_ops
>> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>>  {
>>      struct of_phandle_args iommu_spec;
>> -    struct device_node *np;
>>      const struct iommu_ops *ops = NULL;
>>      int idx = 0;
>>
>> -    if (dev_is_pci(dev))
>> -        return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>> -
>>      /*
>>       * We don't currently walk up the tree looking for a parent IOMMU.
>>       * See the `Notes:' section of
>>       * Documentation/devicetree/bindings/iommu/iommu.txt
>>       */
>> -    while (!of_parse_phandle_with_args(master_np, "iommus",
>> -                       "#iommu-cells", idx,
>> -                       &iommu_spec)) {
>> -        np = iommu_spec.np;
>> -        ops = of_iommu_get_ops(np);
>> -
>> -        if (!ops || !ops->of_xlate ||
>> -            iommu_fwspec_init(dev, &np->fwnode, ops) ||
>> -            ops->of_xlate(dev, &iommu_spec))
>> -            goto err_put_node;
>> -
>> -        of_node_put(np);
>> +    while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>> +                       idx, &iommu_spec)) {
>> +        ops = of_iommu_xlate(dev, &iommu_spec);
>> +        of_node_put(iommu_spec.np);
>>          idx++;
>> +        if (IS_ERR_OR_NULL(ops))
>> +            break;
>>      }
>>
>>      return ops;
>> +}
>> +
>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>> +                       struct device_node *master_np)
>> +{
>> +    const struct iommu_ops *ops;
>> +
>> +    if (!master_np)
>> +        return NULL;
>> +
>> +    if (dev_is_pci(dev))
>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
> 
> I gave the whole patch set a try on ThunderX. really_probe() is failing
> on dma_configure()->of_pci_iommu_init() for each PCI device.

When you say "failing", do you mean cleanly, or with a crash? I've
managed to hit __of_match_node() dereferencing NULL from
of_iommu_xlate() in a horribly complicated chain of events, which I'm
trying to figure out now, and I wonder if the two might be related.

> of_pci_iommu_init() tries to setup firmware stuff via "iommu-map" but
> ThunderX is using legacy "mmu-masters" binding. We need to take care of
> that case too.

That is by design. The "mmu-masters" binding is ARM-SMMU-specific and
will continue to provide the same level of DMA ops support it always has
(for which there really are practical implementation reasons, it's not
just an arbitrary "encourage people to move to the generic bindings"
decision).

Robin.

>> +    else
>> +        ops = of_platform_iommu_init(dev, master_np);
>>
>> -err_put_node:
>> -    of_node_put(np);
>> -    return NULL;
>> +    return IS_ERR(ops) ? NULL : ops;
>>  }
>>
>>  static int __init of_iommu_init(void)
>>
> 
> Thanks,
> Tomasz

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Tomasz Nowicki]

Hi Robin,

On 25.01.2017 18:35, Robin Murphy wrote:
> Hi Tomasz,
>
> On 25/01/17 17:17, Tomasz Nowicki wrote:
>> Hi Sricharan,
>>
>> On 23.01.2017 17:18, Sricharan R wrote:
>>> From: Robin Murphy <robin.murphy@arm.com>
>>>
>>> In preparation for some upcoming cleverness, rework the control flow in
>>> of_iommu_configure() to minimise duplication and improve the propogation
>>> of errors. It's also as good a time as any to switch over from the
>>> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
>>> IOMMU instance interface directly.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>> ---
>>>  drivers/iommu/of_iommu.c | 83
>>> +++++++++++++++++++++++++++++++-----------------
>>>  1 file changed, 53 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>>> index 0f57ddc..ee49081 100644
>>> --- a/drivers/iommu/of_iommu.c
>>> +++ b/drivers/iommu/of_iommu.c
>>> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const
>>> char *prefix, int index,
>>>  }
>>>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>>>
>>> +static const struct iommu_ops
>>> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +    struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
>>> +    int err;
>>> +
>>> +    ops = iommu_get_instance(fwnode);
>>> +    if (!ops || !ops->of_xlate)
>>> +        return NULL;
>>> +
>>> +    err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>> +
>>> +    err = ops->of_xlate(dev, iommu_spec);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>> +
>>> +    return ops;
>>> +}
>>> +
>>>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>>  {
>>>      struct of_phandle_args *iommu_spec = data;
>>> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev,
>>> u16 alias, void *data)
>>>  }
>>>
>>>  static const struct iommu_ops
>>> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node
>>> *bridge_np)
>>> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>>>  {
>>>      const struct iommu_ops *ops;
>>>      struct of_phandle_args iommu_spec;
>>> +    int err;
>>>
>>>      /*
>>>       * Start by tracing the RID alias down the PCI topology as
>>> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev,
>>> u16 alias, void *data)
>>>       * bus into the system beyond, and which IOMMU it ends up at.
>>>       */
>>>      iommu_spec.np = NULL;
>>> -    if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>>> -               "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
>>> -        return NULL;
>>> +    err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>>> +                 "iommu-map-mask", &iommu_spec.np,
>>> +                 iommu_spec.args);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>>
>>> -    ops = of_iommu_get_ops(iommu_spec.np);
>>> -    if (!ops || !ops->of_xlate ||
>>> -        iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
>>> -        ops->of_xlate(&pdev->dev, &iommu_spec))
>>> -        ops = NULL;
>>> +    ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>>>
>>>      of_node_put(iommu_spec.np);
>>>      return ops;
>>>  }
>>>
>>> -const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> -                       struct device_node *master_np)
>>> +static const struct iommu_ops
>>> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>>>  {
>>>      struct of_phandle_args iommu_spec;
>>> -    struct device_node *np;
>>>      const struct iommu_ops *ops = NULL;
>>>      int idx = 0;
>>>
>>> -    if (dev_is_pci(dev))
>>> -        return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>>> -
>>>      /*
>>>       * We don't currently walk up the tree looking for a parent IOMMU.
>>>       * See the `Notes:' section of
>>>       * Documentation/devicetree/bindings/iommu/iommu.txt
>>>       */
>>> -    while (!of_parse_phandle_with_args(master_np, "iommus",
>>> -                       "#iommu-cells", idx,
>>> -                       &iommu_spec)) {
>>> -        np = iommu_spec.np;
>>> -        ops = of_iommu_get_ops(np);
>>> -
>>> -        if (!ops || !ops->of_xlate ||
>>> -            iommu_fwspec_init(dev, &np->fwnode, ops) ||
>>> -            ops->of_xlate(dev, &iommu_spec))
>>> -            goto err_put_node;
>>> -
>>> -        of_node_put(np);
>>> +    while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>>> +                       idx, &iommu_spec)) {
>>> +        ops = of_iommu_xlate(dev, &iommu_spec);
>>> +        of_node_put(iommu_spec.np);
>>>          idx++;
>>> +        if (IS_ERR_OR_NULL(ops))
>>> +            break;
>>>      }
>>>
>>>      return ops;
>>> +}
>>> +
>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> +                       struct device_node *master_np)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +
>>> +    if (!master_np)
>>> +        return NULL;
>>> +
>>> +    if (dev_is_pci(dev))
>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>> on dma_configure()->of_pci_iommu_init() for each PCI device.
> When you say "failing", do you mean cleanly, or with a crash? I've
> managed to hit __of_match_node() dereferencing NULL from
> of_iommu_xlate() in a horribly complicated chain of events, which I'm
> trying to figure out now, and I wonder if the two might be related.
>

Cleanly, of_pci_iommu_init()->of_pci_map_rid() can't find "iommu-map" 
property for my case. Probably not related to your crash.

Thanks,
Tomasz

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Tomasz Nowicki]

Hi Robin,

On 25.01.2017 18:35, Robin Murphy wrote:
> Hi Tomasz,
>
> On 25/01/17 17:17, Tomasz Nowicki wrote:
>> Hi Sricharan,
>>
>> On 23.01.2017 17:18, Sricharan R wrote:
>>> From: Robin Murphy <robin.murphy@arm.com>
>>>
>>> In preparation for some upcoming cleverness, rework the control flow in
>>> of_iommu_configure() to minimise duplication and improve the propogation
>>> of errors. It's also as good a time as any to switch over from the
>>> now-just-a-compatibility-wrapper of_iommu_get_ops() to using the generic
>>> IOMMU instance interface directly.
>>>
>>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>>> ---
>>>  drivers/iommu/of_iommu.c | 83
>>> +++++++++++++++++++++++++++++++-----------------
>>>  1 file changed, 53 insertions(+), 30 deletions(-)
>>>
>>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>>> index 0f57ddc..ee49081 100644
>>> --- a/drivers/iommu/of_iommu.c
>>> +++ b/drivers/iommu/of_iommu.c
>>> @@ -96,6 +96,28 @@ int of_get_dma_window(struct device_node *dn, const
>>> char *prefix, int index,
>>>  }
>>>  EXPORT_SYMBOL_GPL(of_get_dma_window);
>>>
>>> +static const struct iommu_ops
>>> +*of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +    struct fwnode_handle *fwnode = &iommu_spec->np->fwnode;
>>> +    int err;
>>> +
>>> +    ops = iommu_get_instance(fwnode);
>>> +    if (!ops || !ops->of_xlate)
>>> +        return NULL;
>>> +
>>> +    err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>> +
>>> +    err = ops->of_xlate(dev, iommu_spec);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>> +
>>> +    return ops;
>>> +}
>>> +
>>>  static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
>>>  {
>>>      struct of_phandle_args *iommu_spec = data;
>>> @@ -105,10 +127,11 @@ static int __get_pci_rid(struct pci_dev *pdev,
>>> u16 alias, void *data)
>>>  }
>>>
>>>  static const struct iommu_ops
>>> -*of_pci_iommu_configure(struct pci_dev *pdev, struct device_node
>>> *bridge_np)
>>> +*of_pci_iommu_init(struct pci_dev *pdev, struct device_node *bridge_np)
>>>  {
>>>      const struct iommu_ops *ops;
>>>      struct of_phandle_args iommu_spec;
>>> +    int err;
>>>
>>>      /*
>>>       * Start by tracing the RID alias down the PCI topology as
>>> @@ -123,56 +146,56 @@ static int __get_pci_rid(struct pci_dev *pdev,
>>> u16 alias, void *data)
>>>       * bus into the system beyond, and which IOMMU it ends up at.
>>>       */
>>>      iommu_spec.np = NULL;
>>> -    if (of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>>> -               "iommu-map-mask", &iommu_spec.np, iommu_spec.args))
>>> -        return NULL;
>>> +    err = of_pci_map_rid(bridge_np, iommu_spec.args[0], "iommu-map",
>>> +                 "iommu-map-mask", &iommu_spec.np,
>>> +                 iommu_spec.args);
>>> +    if (err)
>>> +        return ERR_PTR(err);
>>>
>>> -    ops = of_iommu_get_ops(iommu_spec.np);
>>> -    if (!ops || !ops->of_xlate ||
>>> -        iommu_fwspec_init(&pdev->dev, &iommu_spec.np->fwnode, ops) ||
>>> -        ops->of_xlate(&pdev->dev, &iommu_spec))
>>> -        ops = NULL;
>>> +    ops = of_iommu_xlate(&pdev->dev, &iommu_spec);
>>>
>>>      of_node_put(iommu_spec.np);
>>>      return ops;
>>>  }
>>>
>>> -const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> -                       struct device_node *master_np)
>>> +static const struct iommu_ops
>>> +*of_platform_iommu_init(struct device *dev, struct device_node *np)
>>>  {
>>>      struct of_phandle_args iommu_spec;
>>> -    struct device_node *np;
>>>      const struct iommu_ops *ops = NULL;
>>>      int idx = 0;
>>>
>>> -    if (dev_is_pci(dev))
>>> -        return of_pci_iommu_configure(to_pci_dev(dev), master_np);
>>> -
>>>      /*
>>>       * We don't currently walk up the tree looking for a parent IOMMU.
>>>       * See the `Notes:' section of
>>>       * Documentation/devicetree/bindings/iommu/iommu.txt
>>>       */
>>> -    while (!of_parse_phandle_with_args(master_np, "iommus",
>>> -                       "#iommu-cells", idx,
>>> -                       &iommu_spec)) {
>>> -        np = iommu_spec.np;
>>> -        ops = of_iommu_get_ops(np);
>>> -
>>> -        if (!ops || !ops->of_xlate ||
>>> -            iommu_fwspec_init(dev, &np->fwnode, ops) ||
>>> -            ops->of_xlate(dev, &iommu_spec))
>>> -            goto err_put_node;
>>> -
>>> -        of_node_put(np);
>>> +    while (!of_parse_phandle_with_args(np, "iommus", "#iommu-cells",
>>> +                       idx, &iommu_spec)) {
>>> +        ops = of_iommu_xlate(dev, &iommu_spec);
>>> +        of_node_put(iommu_spec.np);
>>>          idx++;
>>> +        if (IS_ERR_OR_NULL(ops))
>>> +            break;
>>>      }
>>>
>>>      return ops;
>>> +}
>>> +
>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> +                       struct device_node *master_np)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +
>>> +    if (!master_np)
>>> +        return NULL;
>>> +
>>> +    if (dev_is_pci(dev))
>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>> on dma_configure()->of_pci_iommu_init() for each PCI device.
> When you say "failing", do you mean cleanly, or with a crash? I've
> managed to hit __of_match_node() dereferencing NULL from
> of_iommu_xlate() in a horribly complicated chain of events, which I'm
> trying to figure out now, and I wonder if the two might be related.
>

Cleanly, of_pci_iommu_init()->of_pci_map_rid() can't find "iommu-map" 
property for my case. Probably not related to your crash.

Thanks,
Tomasz

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

[..]

>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> +                       struct device_node *master_np)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +
>>> +    if (!master_np)
>>> +        return NULL;
>>> +
>>> +    if (dev_is_pci(dev))
>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>
>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>
>When you say "failing", do you mean cleanly, or with a crash? I've
>managed to hit __of_match_node() dereferencing NULL from
>of_iommu_xlate() in a horribly complicated chain of events, which I'm
>trying to figure out now, and I wonder if the two might be related.

Sorry that there is crash still. __of_match_node seems to checking
for NULL arguments , feels like some invalid pointer was passed in.
Is there any particular sequence to try for this ?

Regards,
 Sricharan

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

[..]

>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> +                       struct device_node *master_np)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +
>>> +    if (!master_np)
>>> +        return NULL;
>>> +
>>> +    if (dev_is_pci(dev))
>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>
>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>
>When you say "failing", do you mean cleanly, or with a crash? I've
>managed to hit __of_match_node() dereferencing NULL from
>of_iommu_xlate() in a horribly complicated chain of events, which I'm
>trying to figure out now, and I wonder if the two might be related.

Sorry that there is crash still. __of_match_node seems to checking
for NULL arguments , feels like some invalid pointer was passed in.
Is there any particular sequence to try for this ?

Regards,
 Sricharan





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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

[..]

>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>> +                       struct device_node *master_np)
>>> +{
>>> +    const struct iommu_ops *ops;
>>> +
>>> +    if (!master_np)
>>> +        return NULL;
>>> +
>>> +    if (dev_is_pci(dev))
>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>
>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>
>When you say "failing", do you mean cleanly, or with a crash? I've
>managed to hit __of_match_node() dereferencing NULL from
>of_iommu_xlate() in a horribly complicated chain of events, which I'm
>trying to figure out now, and I wonder if the two might be related.

Sorry that there is crash still. __of_match_node seems to checking
for NULL arguments , feels like some invalid pointer was passed in.
Is there any particular sequence to try for this ?

Regards,
 Sricharan

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 27/01/17 18:00, Sricharan wrote:
> Hi Robin,
> 
> [..]
> 
>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>> +                       struct device_node *master_np)
>>>> +{
>>>> +    const struct iommu_ops *ops;
>>>> +
>>>> +    if (!master_np)
>>>> +        return NULL;
>>>> +
>>>> +    if (dev_is_pci(dev))
>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>
>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>
>> When you say "failing", do you mean cleanly, or with a crash? I've
>> managed to hit __of_match_node() dereferencing NULL from
>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>> trying to figure out now, and I wonder if the two might be related.
> 
> Sorry that there is crash still. __of_match_node seems to checking
> for NULL arguments , feels like some invalid pointer was passed in.
> Is there any particular sequence to try for this ?

Ah, I did figure it out - it wasn't actually a NULL dereference, but an
unmapped address. Turns out __iommu_of_table is in initdata, so any
driver probing after init, connected to an unprobed IOMMU (in this case
disabled in DT), trips over trying to match the now-freed table. I'm
working on the fix - technically the bug's in my patch (#2) anyway ;)

Robin.

> 
> Regards,
>  Sricharan
> 
> 
> 
> 

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 27/01/17 18:00, Sricharan wrote:
> Hi Robin,
> 
> [..]
> 
>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>> +                       struct device_node *master_np)
>>>> +{
>>>> +    const struct iommu_ops *ops;
>>>> +
>>>> +    if (!master_np)
>>>> +        return NULL;
>>>> +
>>>> +    if (dev_is_pci(dev))
>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>
>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>
>> When you say "failing", do you mean cleanly, or with a crash? I've
>> managed to hit __of_match_node() dereferencing NULL from
>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>> trying to figure out now, and I wonder if the two might be related.
> 
> Sorry that there is crash still. __of_match_node seems to checking
> for NULL arguments , feels like some invalid pointer was passed in.
> Is there any particular sequence to try for this ?

Ah, I did figure it out - it wasn't actually a NULL dereference, but an
unmapped address. Turns out __iommu_of_table is in initdata, so any
driver probing after init, connected to an unprobed IOMMU (in this case
disabled in DT), trips over trying to match the now-freed table. I'm
working on the fix - technically the bug's in my patch (#2) anyway ;)

Robin.

> 
> Regards,
>  Sricharan
> 
> 
> 
> 


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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 27/01/17 18:00, Sricharan wrote:
> Hi Robin,
> 
> [..]
> 
>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>> +                       struct device_node *master_np)
>>>> +{
>>>> +    const struct iommu_ops *ops;
>>>> +
>>>> +    if (!master_np)
>>>> +        return NULL;
>>>> +
>>>> +    if (dev_is_pci(dev))
>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>
>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>
>> When you say "failing", do you mean cleanly, or with a crash? I've
>> managed to hit __of_match_node() dereferencing NULL from
>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>> trying to figure out now, and I wonder if the two might be related.
> 
> Sorry that there is crash still. __of_match_node seems to checking
> for NULL arguments , feels like some invalid pointer was passed in.
> Is there any particular sequence to try for this ?

Ah, I did figure it out - it wasn't actually a NULL dereference, but an
unmapped address. Turns out __iommu_of_table is in initdata, so any
driver probing after init, connected to an unprobed IOMMU (in this case
disabled in DT), trips over trying to match the now-freed table. I'm
working on the fix - technically the bug's in my patch (#2) anyway ;)

Robin.

> 
> Regards,
>  Sricharan
> 
> 
> 
> 

Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
> From: Laurent Pinchart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> 
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
> 
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the device tree describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ...

> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 349bd1d..9529d6c 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -23,6 +23,7 @@
>  #include <linux/of.h>
>  #include <linux/of_iommu.h>
>  #include <linux/of_pci.h>
> +#include <linux/pci.h>

Why do we need this?

>  #include <linux/slab.h>
>  
>  static const struct of_device_id __iommu_of_table_sentinel
> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>  			ops = ERR_PTR(err);
>  	}
>  
> -	return IS_ERR(ops) ? NULL : ops;
> +	return ops;
>  }
>  
>  static int __init of_iommu_init(void)
> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
>  	for_each_matching_node_and_match(np, matches, &match) {
>  		const of_iommu_init_fn init_fn = match->data;
>  
> -		if (init_fn(np))
> +		if (init_fn && init_fn(np))
>  			pr_err("Failed to initialise IOMMU %s\n",
>  				of_node_full_name(np));
>  	}

Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
> 
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the device tree describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ...

> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 349bd1d..9529d6c 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -23,6 +23,7 @@
>  #include <linux/of.h>
>  #include <linux/of_iommu.h>
>  #include <linux/of_pci.h>
> +#include <linux/pci.h>

Why do we need this?

>  #include <linux/slab.h>
>  
>  static const struct of_device_id __iommu_of_table_sentinel
> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>  			ops = ERR_PTR(err);
>  	}
>  
> -	return IS_ERR(ops) ? NULL : ops;
> +	return ops;
>  }
>  
>  static int __init of_iommu_init(void)
> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
>  	for_each_matching_node_and_match(np, matches, &match) {
>  		const of_iommu_init_fn init_fn = match->data;
>  
> -		if (init_fn(np))
> +		if (init_fn && init_fn(np))
>  			pr_err("Failed to initialise IOMMU %s\n",
>  				of_node_full_name(np));
>  	}

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> 
> Failures to look up an IOMMU when parsing the DT iommus property need to
> be handled separately from the .of_xlate() failures to support deferred
> probing.
> 
> The lack of a registered IOMMU can be caused by the lack of a driver for
> the IOMMU, the IOMMU device probe not having been performed yet, having
> been deferred, or having failed.
> 
> The first case occurs when the device tree describes the bus master and
> IOMMU topology correctly but no device driver exists for the IOMMU yet
> or the device driver has not been compiled in. Return NULL, the caller
> will configure the device without an IOMMU.
> 
> The second and third cases are handled by deferring the probe of the bus
> master device which will eventually get reprobed after the IOMMU.
> 
> The last case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
> 
> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ...

> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> index 349bd1d..9529d6c 100644
> --- a/drivers/iommu/of_iommu.c
> +++ b/drivers/iommu/of_iommu.c
> @@ -23,6 +23,7 @@
>  #include <linux/of.h>
>  #include <linux/of_iommu.h>
>  #include <linux/of_pci.h>
> +#include <linux/pci.h>

Why do we need this?

>  #include <linux/slab.h>
>  
>  static const struct of_device_id __iommu_of_table_sentinel
> @@ -223,7 +224,7 @@ const struct iommu_ops *of_iommu_configure(struct device *dev,
>  			ops = ERR_PTR(err);
>  	}
>  
> -	return IS_ERR(ops) ? NULL : ops;
> +	return ops;
>  }
>  
>  static int __init of_iommu_init(void)
> @@ -234,7 +235,7 @@ static int __init of_iommu_init(void)
>  	for_each_matching_node_and_match(np, matches, &match) {
>  		const of_iommu_init_fn init_fn = match->data;
>  
> -		if (init_fn(np))
> +		if (init_fn && init_fn(np))
>  			pr_err("Failed to initialise IOMMU %s\n",
>  				of_node_full_name(np));
>  	}

Re: [PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:11PM +0530, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after
> the device's iommu is probed, the notifier trick required to handle the
> early setup of dma_ops before the iommu group gets created is not
> required. So removing the notifier's here.

s/notifier's/notifiers/

Personally I'd capitalize "IOMMU" in the English text above, too.

> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> [rm: clean up even more]
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> ---
>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>  1 file changed, 12 insertions(+), 120 deletions(-)

Nice :)

Re: [PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:11PM +0530, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after
> the device's iommu is probed, the notifier trick required to handle the
> early setup of dma_ops before the iommu group gets created is not
> required. So removing the notifier's here.

s/notifier's/notifiers/

Personally I'd capitalize "IOMMU" in the English text above, too.

> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [rm: clean up even more]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>  1 file changed, 12 insertions(+), 120 deletions(-)

Nice :)

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

[PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:11PM +0530, Sricharan R wrote:
> With arch_setup_dma_ops now being called late during device's probe after
> the device's iommu is probed, the notifier trick required to handle the
> early setup of dma_ops before the iommu group gets created is not
> required. So removing the notifier's here.

s/notifier's/notifiers/

Personally I'd capitalize "IOMMU" in the English text above, too.

> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> [rm: clean up even more]
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> ---
>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>  1 file changed, 12 insertions(+), 120 deletions(-)

Nice :)

Re: [PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:12PM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> 
> Now that the appropriate ordering is enforced via profe-deferral of

s/profe-deferral/probe-deferral/

> masters in core code, rip it all out and bask in the simplicity.
> 
> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
> [Sricharan: Rebased on top of ACPI IORT SMMU series]
> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>  2 files changed, 10 insertions(+), 94 deletions(-)

Yay!

Re: [PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:12PM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
> 
> Now that the appropriate ordering is enforced via profe-deferral of

s/profe-deferral/probe-deferral/

> masters in core code, rip it all out and bask in the simplicity.
> 
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> [Sricharan: Rebased on top of ACPI IORT SMMU series]
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>  2 files changed, 10 insertions(+), 94 deletions(-)

Yay!

[PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:12PM +0530, Sricharan R wrote:
> From: Robin Murphy <robin.murphy@arm.com>
> 
> Now that the appropriate ordering is enforced via profe-deferral of

s/profe-deferral/probe-deferral/

> masters in core code, rip it all out and bask in the simplicity.
> 
> Acked-by: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
> [Sricharan: Rebased on top of ACPI IORT SMMU series]
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
> ---
>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>  2 files changed, 10 insertions(+), 94 deletions(-)

Yay!

Re: [PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:08PM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configuring the DMA ops for the
> device would be called at the same place for all bus_types, hence the
> deferred probing mechanism should work for all buses as well.
> 
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
> 
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
> 
> This patch changes the dma ops configuration to probe time for
> both OF and ACPI based platform/amba/pci bus devices.
> 
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci part)

> ---
>  [V6 .. V7]
> 	* Updated the subject and commit log as per comments
> 
>  [V5 .. V6]
>         * Squashed in patch 10 for configuring the dma ops of
>           ACPI device at probe time from previous post.
>         * Fixed a bug in dma_configure pointed out by Robin.
> 
>  drivers/acpi/glue.c         |  5 -----
>  drivers/base/dd.c           |  9 +++++++++
>  drivers/base/dma-mapping.c  | 40 ++++++++++++++++++++++++++++++++++++++++
>  drivers/of/platform.c       |  5 +----
>  drivers/pci/probe.c         | 28 ----------------------------
>  include/linux/dma-mapping.h |  3 +++
>  6 files changed, 53 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index fb19e1c..c05f241 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -176,7 +176,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>  	struct list_head *physnode_list;
>  	unsigned int node_id;
>  	int retval = -EINVAL;
> -	enum dev_dma_attr attr;
>  
>  	if (has_acpi_companion(dev)) {
>  		if (acpi_dev) {
> @@ -233,10 +232,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>  	if (!has_acpi_companion(dev))
>  		ACPI_COMPANION_SET(dev, acpi_dev);
>  
> -	attr = acpi_get_dma_attr(acpi_dev);
> -	if (attr != DEV_DMA_NOT_SUPPORTED)
> -		acpi_dma_configure(dev, attr);
> -
>  	acpi_physnode_link_name(physical_node_name, node_id);
>  	retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
>  				   physical_node_name);
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index a1fbf55..4882f06 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -19,6 +19,7 @@
>  
>  #include <linux/device.h>
>  #include <linux/delay.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  #include <linux/kthread.h>
>  #include <linux/wait.h>
> @@ -356,6 +357,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  	if (ret)
>  		goto pinctrl_bind_failed;
>  
> +	ret = dma_configure(dev);
> +	if (ret)
> +		goto dma_failed;
> +
>  	if (driver_sysfs_add(dev)) {
>  		printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
>  			__func__, dev_name(dev));
> @@ -417,6 +422,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  	goto done;
>  
>  probe_failed:
> +	dma_deconfigure(dev);
> +dma_failed:
>  	if (dev->bus)
>  		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
>  					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
> @@ -826,6 +833,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
>  			drv->remove(dev);
>  
>  		device_links_driver_cleanup(dev);
> +		dma_deconfigure(dev);
> +
>  		devres_release_all(dev);
>  		dev->driver = NULL;
>  		dev_set_drvdata(dev, NULL);
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index efd71cf..449b948 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -7,9 +7,11 @@
>   * This file is released under the GPLv2.
>   */
>  
> +#include <linux/acpi.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/export.h>
>  #include <linux/gfp.h>
> +#include <linux/of_device.h>
>  #include <linux/slab.h>
>  #include <linux/vmalloc.h>
>  
> @@ -341,3 +343,41 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
>  	vunmap(cpu_addr);
>  }
>  #endif
> +
> +/*
> + * Common configuration to enable DMA API use for a device
> + */
> +#include <linux/pci.h>
> +
> +int dma_configure(struct device *dev)
> +{
> +	struct device *bridge = NULL, *dma_dev = dev;
> +	enum dev_dma_attr attr;
> +
> +	if (dev_is_pci(dev)) {
> +		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> +		dma_dev = bridge;
> +		if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> +		    dma_dev->parent->of_node)
> +			dma_dev = dma_dev->parent;
> +	}
> +
> +	if (dma_dev->of_node) {
> +		of_dma_configure(dev, dma_dev->of_node);
> +	} else if (has_acpi_companion(dma_dev)) {
> +		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> +		if (attr != DEV_DMA_NOT_SUPPORTED)
> +			acpi_dma_configure(dev, attr);
> +	}
> +
> +	if (bridge)
> +		pci_put_host_bridge_device(bridge);
> +
> +	return 0;
> +}
> +
> +void dma_deconfigure(struct device *dev)
> +{
> +	of_dma_deconfigure(dev);
> +	acpi_dma_deconfigure(dev);
> +}
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 57418f7..cf35030 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -22,6 +22,7 @@
>  #include <linux/slab.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> +#include <linux/of_iommu.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> @@ -186,11 +187,9 @@ static struct platform_device *of_platform_device_create_pdata(
>  
>  	dev->dev.bus = &platform_bus_type;
>  	dev->dev.platform_data = platform_data;
> -	of_dma_configure(&dev->dev, dev->dev.of_node);
>  	of_msi_configure(&dev->dev, dev->dev.of_node);
>  
>  	if (of_device_add(dev) != 0) {
> -		of_dma_deconfigure(&dev->dev);
>  		platform_device_put(dev);
>  		goto err_clear_flag;
>  	}
> @@ -248,7 +247,6 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
>  		dev_set_name(&dev->dev, "%s", bus_id);
>  	else
>  		of_device_make_bus_id(&dev->dev);
> -	of_dma_configure(&dev->dev, dev->dev.of_node);
>  
>  	/* Allow the HW Peripheral ID to be overridden */
>  	prop = of_get_property(node, "arm,primecell-periphid", NULL);
> @@ -542,7 +540,6 @@ static int of_platform_device_destroy(struct device *dev, void *data)
>  		amba_device_unregister(to_amba_device(dev));
>  #endif
>  
> -	of_dma_deconfigure(dev);
>  	of_node_clear_flag(dev->of_node, OF_POPULATED);
>  	of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
>  	return 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 204960e..89ebb6c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1864,33 +1864,6 @@ static void pci_set_msi_domain(struct pci_dev *dev)
>  	dev_set_msi_domain(&dev->dev, d);
>  }
>  
> -/**
> - * pci_dma_configure - Setup DMA configuration
> - * @dev: ptr to pci_dev struct of the PCI device
> - *
> - * Function to update PCI devices's DMA configuration using the same
> - * info from the OF node or ACPI node of host bridge's parent (if any).
> - */
> -static void pci_dma_configure(struct pci_dev *dev)
> -{
> -	struct device *bridge = pci_get_host_bridge_device(dev);
> -
> -	if (IS_ENABLED(CONFIG_OF) &&
> -		bridge->parent && bridge->parent->of_node) {
> -			of_dma_configure(&dev->dev, bridge->parent->of_node);
> -	} else if (has_acpi_companion(bridge)) {
> -		struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> -		enum dev_dma_attr attr = acpi_get_dma_attr(adev);
> -
> -		if (attr == DEV_DMA_NOT_SUPPORTED)
> -			dev_warn(&dev->dev, "DMA not supported.\n");
> -		else
> -			acpi_dma_configure(&dev->dev, attr);
> -	}
> -
> -	pci_put_host_bridge_device(bridge);
> -}
> -
>  void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>  {
>  	int ret;
> @@ -1904,7 +1877,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>  	dev->dev.dma_mask = &dev->dma_mask;
>  	dev->dev.dma_parms = &dev->dma_parms;
>  	dev->dev.coherent_dma_mask = 0xffffffffull;
> -	pci_dma_configure(dev);
>  
>  	pci_set_dma_max_seg_size(dev, 65536);
>  	pci_set_dma_seg_boundary(dev, 0xffffffff);
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 10c5a17b1..939bf77 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -708,6 +708,9 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
>  }
>  #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
>  
> +int dma_configure(struct device *dev);
> +void dma_deconfigure(struct device *dev);
> +
>  /*
>   * Managed DMA API
>   */
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:08PM +0530, Sricharan R wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configuring the DMA ops for the
> device would be called at the same place for all bus_types, hence the
> deferred probing mechanism should work for all buses as well.
> 
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
> 
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
> 
> This patch changes the dma ops configuration to probe time for
> both OF and ACPI based platform/amba/pci bus devices.
> 
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

Acked-by: Bjorn Helgaas <bhelgaas@google.com> (drivers/pci part)

> ---
>  [V6 .. V7]
> 	* Updated the subject and commit log as per comments
> 
>  [V5 .. V6]
>         * Squashed in patch 10 for configuring the dma ops of
>           ACPI device at probe time from previous post.
>         * Fixed a bug in dma_configure pointed out by Robin.
> 
>  drivers/acpi/glue.c         |  5 -----
>  drivers/base/dd.c           |  9 +++++++++
>  drivers/base/dma-mapping.c  | 40 ++++++++++++++++++++++++++++++++++++++++
>  drivers/of/platform.c       |  5 +----
>  drivers/pci/probe.c         | 28 ----------------------------
>  include/linux/dma-mapping.h |  3 +++
>  6 files changed, 53 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/acpi/glue.c b/drivers/acpi/glue.c
> index fb19e1c..c05f241 100644
> --- a/drivers/acpi/glue.c
> +++ b/drivers/acpi/glue.c
> @@ -176,7 +176,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>  	struct list_head *physnode_list;
>  	unsigned int node_id;
>  	int retval = -EINVAL;
> -	enum dev_dma_attr attr;
>  
>  	if (has_acpi_companion(dev)) {
>  		if (acpi_dev) {
> @@ -233,10 +232,6 @@ int acpi_bind_one(struct device *dev, struct acpi_device *acpi_dev)
>  	if (!has_acpi_companion(dev))
>  		ACPI_COMPANION_SET(dev, acpi_dev);
>  
> -	attr = acpi_get_dma_attr(acpi_dev);
> -	if (attr != DEV_DMA_NOT_SUPPORTED)
> -		acpi_dma_configure(dev, attr);
> -
>  	acpi_physnode_link_name(physical_node_name, node_id);
>  	retval = sysfs_create_link(&acpi_dev->dev.kobj, &dev->kobj,
>  				   physical_node_name);
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index a1fbf55..4882f06 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -19,6 +19,7 @@
>  
>  #include <linux/device.h>
>  #include <linux/delay.h>
> +#include <linux/dma-mapping.h>
>  #include <linux/module.h>
>  #include <linux/kthread.h>
>  #include <linux/wait.h>
> @@ -356,6 +357,10 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  	if (ret)
>  		goto pinctrl_bind_failed;
>  
> +	ret = dma_configure(dev);
> +	if (ret)
> +		goto dma_failed;
> +
>  	if (driver_sysfs_add(dev)) {
>  		printk(KERN_ERR "%s: driver_sysfs_add(%s) failed\n",
>  			__func__, dev_name(dev));
> @@ -417,6 +422,8 @@ static int really_probe(struct device *dev, struct device_driver *drv)
>  	goto done;
>  
>  probe_failed:
> +	dma_deconfigure(dev);
> +dma_failed:
>  	if (dev->bus)
>  		blocking_notifier_call_chain(&dev->bus->p->bus_notifier,
>  					     BUS_NOTIFY_DRIVER_NOT_BOUND, dev);
> @@ -826,6 +833,8 @@ static void __device_release_driver(struct device *dev, struct device *parent)
>  			drv->remove(dev);
>  
>  		device_links_driver_cleanup(dev);
> +		dma_deconfigure(dev);
> +
>  		devres_release_all(dev);
>  		dev->driver = NULL;
>  		dev_set_drvdata(dev, NULL);
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index efd71cf..449b948 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -7,9 +7,11 @@
>   * This file is released under the GPLv2.
>   */
>  
> +#include <linux/acpi.h>
>  #include <linux/dma-mapping.h>
>  #include <linux/export.h>
>  #include <linux/gfp.h>
> +#include <linux/of_device.h>
>  #include <linux/slab.h>
>  #include <linux/vmalloc.h>
>  
> @@ -341,3 +343,41 @@ void dma_common_free_remap(void *cpu_addr, size_t size, unsigned long vm_flags)
>  	vunmap(cpu_addr);
>  }
>  #endif
> +
> +/*
> + * Common configuration to enable DMA API use for a device
> + */
> +#include <linux/pci.h>
> +
> +int dma_configure(struct device *dev)
> +{
> +	struct device *bridge = NULL, *dma_dev = dev;
> +	enum dev_dma_attr attr;
> +
> +	if (dev_is_pci(dev)) {
> +		bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> +		dma_dev = bridge;
> +		if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> +		    dma_dev->parent->of_node)
> +			dma_dev = dma_dev->parent;
> +	}
> +
> +	if (dma_dev->of_node) {
> +		of_dma_configure(dev, dma_dev->of_node);
> +	} else if (has_acpi_companion(dma_dev)) {
> +		attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> +		if (attr != DEV_DMA_NOT_SUPPORTED)
> +			acpi_dma_configure(dev, attr);
> +	}
> +
> +	if (bridge)
> +		pci_put_host_bridge_device(bridge);
> +
> +	return 0;
> +}
> +
> +void dma_deconfigure(struct device *dev)
> +{
> +	of_dma_deconfigure(dev);
> +	acpi_dma_deconfigure(dev);
> +}
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 57418f7..cf35030 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -22,6 +22,7 @@
>  #include <linux/slab.h>
>  #include <linux/of_address.h>
>  #include <linux/of_device.h>
> +#include <linux/of_iommu.h>
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/platform_device.h>
> @@ -186,11 +187,9 @@ static struct platform_device *of_platform_device_create_pdata(
>  
>  	dev->dev.bus = &platform_bus_type;
>  	dev->dev.platform_data = platform_data;
> -	of_dma_configure(&dev->dev, dev->dev.of_node);
>  	of_msi_configure(&dev->dev, dev->dev.of_node);
>  
>  	if (of_device_add(dev) != 0) {
> -		of_dma_deconfigure(&dev->dev);
>  		platform_device_put(dev);
>  		goto err_clear_flag;
>  	}
> @@ -248,7 +247,6 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
>  		dev_set_name(&dev->dev, "%s", bus_id);
>  	else
>  		of_device_make_bus_id(&dev->dev);
> -	of_dma_configure(&dev->dev, dev->dev.of_node);
>  
>  	/* Allow the HW Peripheral ID to be overridden */
>  	prop = of_get_property(node, "arm,primecell-periphid", NULL);
> @@ -542,7 +540,6 @@ static int of_platform_device_destroy(struct device *dev, void *data)
>  		amba_device_unregister(to_amba_device(dev));
>  #endif
>  
> -	of_dma_deconfigure(dev);
>  	of_node_clear_flag(dev->of_node, OF_POPULATED);
>  	of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
>  	return 0;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 204960e..89ebb6c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1864,33 +1864,6 @@ static void pci_set_msi_domain(struct pci_dev *dev)
>  	dev_set_msi_domain(&dev->dev, d);
>  }
>  
> -/**
> - * pci_dma_configure - Setup DMA configuration
> - * @dev: ptr to pci_dev struct of the PCI device
> - *
> - * Function to update PCI devices's DMA configuration using the same
> - * info from the OF node or ACPI node of host bridge's parent (if any).
> - */
> -static void pci_dma_configure(struct pci_dev *dev)
> -{
> -	struct device *bridge = pci_get_host_bridge_device(dev);
> -
> -	if (IS_ENABLED(CONFIG_OF) &&
> -		bridge->parent && bridge->parent->of_node) {
> -			of_dma_configure(&dev->dev, bridge->parent->of_node);
> -	} else if (has_acpi_companion(bridge)) {
> -		struct acpi_device *adev = to_acpi_device_node(bridge->fwnode);
> -		enum dev_dma_attr attr = acpi_get_dma_attr(adev);
> -
> -		if (attr == DEV_DMA_NOT_SUPPORTED)
> -			dev_warn(&dev->dev, "DMA not supported.\n");
> -		else
> -			acpi_dma_configure(&dev->dev, attr);
> -	}
> -
> -	pci_put_host_bridge_device(bridge);
> -}
> -
>  void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>  {
>  	int ret;
> @@ -1904,7 +1877,6 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus)
>  	dev->dev.dma_mask = &dev->dma_mask;
>  	dev->dev.dma_parms = &dev->dma_parms;
>  	dev->dev.coherent_dma_mask = 0xffffffffull;
> -	pci_dma_configure(dev);
>  
>  	pci_set_dma_max_seg_size(dev, 65536);
>  	pci_set_dma_seg_boundary(dev, 0xffffffff);
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 10c5a17b1..939bf77 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -708,6 +708,9 @@ void *dma_mark_declared_memory_occupied(struct device *dev,
>  }
>  #endif /* CONFIG_HAVE_GENERIC_DMA_COHERENT */
>  
> +int dma_configure(struct device *dev);
> +void dma_deconfigure(struct device *dev);
> +
>  /*
>   * Managed DMA API
>   */
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
> ...

>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>  drivers/acpi/glue.c               |   5 --
>  drivers/acpi/scan.c               |   7 +-
>  drivers/base/dd.c                 |   9 +++
>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>  drivers/of/address.c              |  20 +++++-
>  drivers/of/device.c               |  36 ++++++-----
>  drivers/of/platform.c             |  10 +--
>  drivers/pci/probe.c               |  28 --------
>  include/acpi/acpi_bus.h           |   2 +-
>  include/asm-generic/vmlinux.lds.h |   1 -
>  include/linux/acpi.h              |   7 +-
>  include/linux/acpi_iort.h         |   3 -
>  include/linux/dma-mapping.h       |   3 +
>  include/linux/of_device.h         |  10 ++-
>  19 files changed, 252 insertions(+), 320 deletions(-)

I'm assuming this will go via some other tree, maybe the IOMMU tree?
I acked the PCI parts, so let me know if you need anything more from me.

Re: [PATCH V7 00/11] IOMMU probe deferral support

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
> ...

>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>  drivers/acpi/glue.c               |   5 --
>  drivers/acpi/scan.c               |   7 +-
>  drivers/base/dd.c                 |   9 +++
>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>  drivers/of/address.c              |  20 +++++-
>  drivers/of/device.c               |  36 ++++++-----
>  drivers/of/platform.c             |  10 +--
>  drivers/pci/probe.c               |  28 --------
>  include/acpi/acpi_bus.h           |   2 +-
>  include/asm-generic/vmlinux.lds.h |   1 -
>  include/linux/acpi.h              |   7 +-
>  include/linux/acpi_iort.h         |   3 -
>  include/linux/dma-mapping.h       |   3 +
>  include/linux/of_device.h         |  10 ++-
>  19 files changed, 252 insertions(+), 320 deletions(-)

I'm assuming this will go via some other tree, maybe the IOMMU tree?
I acked the PCI parts, so let me know if you need anything more from me.

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

[PATCH V7 00/11] IOMMU probe deferral support

[Bjorn Helgaas]

On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
> This series calls the dma ops configuration for the devices
> at a generic place so that it works for all busses.
> The dma_configure_ops for a device is now called during
> the device_attach callback just before the probe of the
> bus/driver is called. Similarly dma_deconfigure is called during
> device/driver_detach path.
> ...

>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>  drivers/acpi/glue.c               |   5 --
>  drivers/acpi/scan.c               |   7 +-
>  drivers/base/dd.c                 |   9 +++
>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>  drivers/of/address.c              |  20 +++++-
>  drivers/of/device.c               |  36 ++++++-----
>  drivers/of/platform.c             |  10 +--
>  drivers/pci/probe.c               |  28 --------
>  include/acpi/acpi_bus.h           |   2 +-
>  include/asm-generic/vmlinux.lds.h |   1 -
>  include/linux/acpi.h              |   7 +-
>  include/linux/acpi_iort.h         |   3 -
>  include/linux/dma-mapping.h       |   3 +
>  include/linux/of_device.h         |  10 ++-
>  19 files changed, 252 insertions(+), 320 deletions(-)

I'm assuming this will go via some other tree, maybe the IOMMU tree?
I acked the PCI parts, so let me know if you need anything more from me.

Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/23/2017 11:18 AM, Sricharan R wrote:
> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>  	if (ret < 0) {
>  		dma_addr = offset = 0;
> -		size = dev->coherent_dma_mask + 1;
> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>  	} else {

what's happening here?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/23/2017 11:18 AM, Sricharan R wrote:
> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>  	if (ret < 0) {
>  		dma_addr = offset = 0;
> -		size = dev->coherent_dma_mask + 1;
> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>  	} else {

what's happening here?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/23/2017 11:18 AM, Sricharan R wrote:
> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>  	if (ret < 0) {
>  		dma_addr = offset = 0;
> -		size = dev->coherent_dma_mask + 1;
> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>  	} else {

what's happening here?

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
> 
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.
> 

Tested on top of 4.10-rc5.

1.	Platform Hidma device passed dmatest
2.	Seeing some USB stalls on a platform USB device.
3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
4. 	NVMe driver didn't probe following a hotplug insertion and received an
SMMU error event during the insertion.

/sys/bus/pci/slots/4 #
/sys/bus/pci/slots/4 # dmesg | grep nvme
[   14.041357] nvme nvme0: pci function 0003:01:00.0
[  198.399521] nvme nvme0: pci function 0003:01:00.0
[__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
[  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
[  264.402313] nvme nvme0: Identify Controller failed (-4)
[  264.421270] nvme nvme0: Removing after probe failure status: -5
/sys/bus/pci/slots/4 #



-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
> 
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.
> 

Tested on top of 4.10-rc5.

1.	Platform Hidma device passed dmatest
2.	Seeing some USB stalls on a platform USB device.
3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
4. 	NVMe driver didn't probe following a hotplug insertion and received an
SMMU error event during the insertion.

/sys/bus/pci/slots/4 #
/sys/bus/pci/slots/4 # dmesg | grep nvme
[   14.041357] nvme nvme0: pci function 0003:01:00.0
[  198.399521] nvme nvme0: pci function 0003:01:00.0
[__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
[  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
[  264.402313] nvme nvme0: Identify Controller failed (-4)
[  264.421270] nvme nvme0: Removing after probe failure status: -5
/sys/bus/pci/slots/4 #



-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> [+hanjun, tomasz, sinan]
> 
> It is quite a key patchset, I would be glad if they can test on their
> respective platforms with IORT.
> 

Tested on top of 4.10-rc5.

1.	Platform Hidma device passed dmatest
2.	Seeing some USB stalls on a platform USB device.
3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
4. 	NVMe driver didn't probe following a hotplug insertion and received an
SMMU error event during the insertion.

/sys/bus/pci/slots/4 #
/sys/bus/pci/slots/4 # dmesg | grep nvme
[   14.041357] nvme nvme0: pci function 0003:01:00.0
[  198.399521] nvme nvme0: pci function 0003:01:00.0
[__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
[  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
[  264.402313] nvme nvme0: Identify Controller failed (-4)
[  264.421270] nvme nvme0: Removing after probe failure status: -5
/sys/bus/pci/slots/4 #



-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>> [..]
>>
>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>> +                       struct device_node *master_np)
>>>>> +{
>>>>> +    const struct iommu_ops *ops;
>>>>> +
>>>>> +    if (!master_np)
>>>>> +        return NULL;
>>>>> +
>>>>> +    if (dev_is_pci(dev))
>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>
>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>
>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>> managed to hit __of_match_node() dereferencing NULL from
>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>> trying to figure out now, and I wonder if the two might be related.
>>
>> Sorry that there is crash still. __of_match_node seems to checking
>> for NULL arguments , feels like some invalid pointer was passed in.
>> Is there any particular sequence to try for this ?
>
>Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>unmapped address. Turns out __iommu_of_table is in initdata, so any
>driver probing after init, connected to an unprobed IOMMU (in this case
>disabled in DT), trips over trying to match the now-freed table. I'm
>working on the fix - technically the bug's in my patch (#2) anyway ;)
>

Ok, thanks for bringing this out. There is also an issue that
Sinan has mentioned while testing the ACPI hotplug path, probably
its related to the above, not sure. I will try to check more on that
in the meanwhile. Then, taking your fix and fixing the hotplug case
i will do one more repost.

Regards,
 Sricharan

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>> [..]
>>
>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>> +                       struct device_node *master_np)
>>>>> +{
>>>>> +    const struct iommu_ops *ops;
>>>>> +
>>>>> +    if (!master_np)
>>>>> +        return NULL;
>>>>> +
>>>>> +    if (dev_is_pci(dev))
>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>
>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>
>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>> managed to hit __of_match_node() dereferencing NULL from
>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>> trying to figure out now, and I wonder if the two might be related.
>>
>> Sorry that there is crash still. __of_match_node seems to checking
>> for NULL arguments , feels like some invalid pointer was passed in.
>> Is there any particular sequence to try for this ?
>
>Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>unmapped address. Turns out __iommu_of_table is in initdata, so any
>driver probing after init, connected to an unprobed IOMMU (in this case
>disabled in DT), trips over trying to match the now-freed table. I'm
>working on the fix - technically the bug's in my patch (#2) anyway ;)
>

Ok, thanks for bringing this out. There is also an issue that
Sinan has mentioned while testing the ACPI hotplug path, probably
its related to the above, not sure. I will try to check more on that
in the meanwhile. Then, taking your fix and fixing the hotplug case
i will do one more repost.

Regards,
 Sricharan

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>> [..]
>>
>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>> +                       struct device_node *master_np)
>>>>> +{
>>>>> +    const struct iommu_ops *ops;
>>>>> +
>>>>> +    if (!master_np)
>>>>> +        return NULL;
>>>>> +
>>>>> +    if (dev_is_pci(dev))
>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>
>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>
>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>> managed to hit __of_match_node() dereferencing NULL from
>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>> trying to figure out now, and I wonder if the two might be related.
>>
>> Sorry that there is crash still. __of_match_node seems to checking
>> for NULL arguments , feels like some invalid pointer was passed in.
>> Is there any particular sequence to try for this ?
>
>Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>unmapped address. Turns out __iommu_of_table is in initdata, so any
>driver probing after init, connected to an unprobed IOMMU (in this case
>disabled in DT), trips over trying to match the now-freed table. I'm
>working on the fix - technically the bug's in my patch (#2) anyway ;)
>

Ok, thanks for bringing this out. There is also an issue that
Sinan has mentioned while testing the ACPI hotplug path, probably
its related to the above, not sure. I will try to check more on that
in the meanwhile. Then, taking your fix and fixing the hotplug case
i will do one more repost.

Regards,
 Sricharan

Re: [PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Rafael J. Wysocki]

On Mon, Jan 23, 2017 at 5:18 PM, Sricharan R <sricharan@codeaurora.org> wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configuring the DMA ops for the
> device would be called at the same place for all bus_types, hence the
> deferred probing mechanism should work for all buses as well.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> This patch changes the dma ops configuration to probe time for
> both OF and ACPI based platform/amba/pci bus devices.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

[PATCH V7 06/11] of/acpi: Configure dma operations at probe time for platform/amba/pci bus devices

[Rafael J. Wysocki]

On Mon, Jan 23, 2017 at 5:18 PM, Sricharan R <sricharan@codeaurora.org> wrote:
> Configuring DMA ops at probe time will allow deferring device probe when
> the IOMMU isn't available yet. The dma_configure for the device is
> now called from the generic device_attach callback just before the
> bus/driver probe is called. This way, configuring the DMA ops for the
> device would be called at the same place for all bus_types, hence the
> deferred probing mechanism should work for all buses as well.
>
> pci_bus_add_devices    (platform/amba)(_device_create/driver_register)
>        |                         |
> pci_bus_add_device     (device_add/driver_register)
>        |                         |
> device_attach           device_initial_probe
>        |                         |
> __device_attach_driver    __device_attach_driver
>        |
> driver_probe_device
>        |
> really_probe
>        |
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> This patch changes the dma ops configuration to probe time for
> both OF and ACPI based platform/amba/pci bus devices.
>
> Signed-off-by: Sricharan R <sricharan@codeaurora.org>

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

RE: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Bjorn,

>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>Sent: Sunday, January 29, 2017 2:34 AM
>To: Sricharan R <sricharan@codeaurora.org>
>Cc: robin.murphy@arm.com; will.deacon@arm.com; joro@8bytes.org; lorenzo.pieralisi@arm.com; iommu@lists.linux-foundation.org;
>linux-arm-kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; m.szyprowski@samsung.com; bhelgaas@google.com; linux-
>pci@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ...
>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 349bd1d..9529d6c 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>>  #include <linux/of.h>
>>  #include <linux/of_iommu.h>
>>  #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>
>Why do we need this?

Right, will remove it.

Regards,
 Sricharan

RE: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Bjorn,

>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas@kernel.org]
>Sent: Sunday, January 29, 2017 2:34 AM
>To: Sricharan R <sricharan@codeaurora.org>
>Cc: robin.murphy@arm.com; will.deacon@arm.com; joro@8bytes.org; lorenzo.pieralisi@arm.com; iommu@lists.linux-foundation.org;
>linux-arm-kernel@lists.infradead.org; linux-arm-msm@vger.kernel.org; m.szyprowski@samsung.com; bhelgaas@google.com; linux-
>pci@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ...
>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 349bd1d..9529d6c 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>>  #include <linux/of.h>
>>  #include <linux/of_iommu.h>
>>  #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>
>Why do we need this?

Right, will remove it.

Regards,
 Sricharan

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi Bjorn,

>-----Original Message-----
>From: Bjorn Helgaas [mailto:helgaas at kernel.org]
>Sent: Sunday, January 29, 2017 2:34 AM
>To: Sricharan R <sricharan@codeaurora.org>
>Cc: robin.murphy at arm.com; will.deacon at arm.com; joro at 8bytes.org; lorenzo.pieralisi at arm.com; iommu at lists.linux-foundation.org;
>linux-arm-kernel at lists.infradead.org; linux-arm-msm at vger.kernel.org; m.szyprowski at samsung.com; bhelgaas at google.com; linux-
>pci at vger.kernel.org; linux-acpi at vger.kernel.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On Mon, Jan 23, 2017 at 09:48:09PM +0530, Sricharan R wrote:
>> From: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>> The lack of a registered IOMMU can be caused by the lack of a driver for
>> the IOMMU, the IOMMU device probe not having been performed yet, having
>> been deferred, or having failed.
>>
>> The first case occurs when the device tree describes the bus master and
>> IOMMU topology correctly but no device driver exists for the IOMMU yet
>> or the device driver has not been compiled in. Return NULL, the caller
>> will configure the device without an IOMMU.
>>
>> The second and third cases are handled by deferring the probe of the bus
>> master device which will eventually get reprobed after the IOMMU.
>>
>> The last case is currently handled by deferring the probe of the bus
>> master device as well. A mechanism to either configure the bus master
>> device without an IOMMU or to fail the bus master device probe depending
>> on whether the IOMMU is optional or mandatory would be a good
>> enhancement.
>>
>> Signed-off-by: Laurent Pichart <laurent.pinchart+renesas@ideasonboard.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ...
>
>> diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>> index 349bd1d..9529d6c 100644
>> --- a/drivers/iommu/of_iommu.c
>> +++ b/drivers/iommu/of_iommu.c
>> @@ -23,6 +23,7 @@
>>  #include <linux/of.h>
>>  #include <linux/of_iommu.h>
>>  #include <linux/of_pci.h>
>> +#include <linux/pci.h>
>
>Why do we need this?

Right, will remove it.

Regards,
 Sricharan

RE: [PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Sricharan]

>> With arch_setup_dma_ops now being called late during device's probe after
>> the device's iommu is probed, the notifier trick required to handle the
>> early setup of dma_ops before the iommu group gets created is not
>> required. So removing the notifier's here.
>
>s/notifier's/notifiers/
>
ok, will change.

>Personally I'd capitalize "IOMMU" in the English text above, too.
>
ok, will change this too.

Regards,
 Sricharan

>> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> [rm: clean up even more]
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> ---
>>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>>  1 file changed, 12 insertions(+), 120 deletions(-)
>
>Nice :)

RE: [PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Sricharan]

>> With arch_setup_dma_ops now being called late during device's probe after
>> the device's iommu is probed, the notifier trick required to handle the
>> early setup of dma_ops before the iommu group gets created is not
>> required. So removing the notifier's here.
>
>s/notifier's/notifiers/
>
ok, will change.

>Personally I'd capitalize "IOMMU" in the English text above, too.
>
ok, will change this too.

Regards,
 Sricharan

>> Acked-by: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: clean up even more]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>>  1 file changed, 12 insertions(+), 120 deletions(-)
>
>Nice :)

[PATCH V7 09/11] arm64: dma-mapping: Remove the notifier trick to handle early setting of dma_ops

[Sricharan]

>> With arch_setup_dma_ops now being called late during device's probe after
>> the device's iommu is probed, the notifier trick required to handle the
>> early setup of dma_ops before the iommu group gets created is not
>> required. So removing the notifier's here.
>
>s/notifier's/notifiers/
>
ok, will change.

>Personally I'd capitalize "IOMMU" in the English text above, too.
>
ok, will change this too.

Regards,
 Sricharan

>> Acked-by: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> [rm: clean up even more]
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>  arch/arm64/mm/dma-mapping.c | 132 ++++----------------------------------------
>>  1 file changed, 12 insertions(+), 120 deletions(-)
>
>Nice :)

RE: [PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Sricharan]

>> Now that the appropriate ordering is enforced via profe-deferral of
>
>s/profe-deferral/probe-deferral/
>

ha, will change it.

Regards,
 Sricharan


>> masters in core code, rip it all out and bask in the simplicity.
>>
>> Acked-by: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>
>> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
>> [Sricharan: Rebased on top of ACPI IORT SMMU series]
>> Signed-off-by: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> ---
>>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>>  2 files changed, 10 insertions(+), 94 deletions(-)
>
>Yay!

RE: [PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Sricharan]

>> Now that the appropriate ordering is enforced via profe-deferral of
>
>s/profe-deferral/probe-deferral/
>

ha, will change it.

Regards,
 Sricharan


>> masters in core code, rip it all out and bask in the simplicity.
>>
>> Acked-by: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> [Sricharan: Rebased on top of ACPI IORT SMMU series]
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>>  2 files changed, 10 insertions(+), 94 deletions(-)
>
>Yay!

[PATCH V7 10/11] iommu/arm-smmu: Clean up early-probing workarounds

[Sricharan]

>> Now that the appropriate ordering is enforced via profe-deferral of
>
>s/profe-deferral/probe-deferral/
>

ha, will change it.

Regards,
 Sricharan


>> masters in core code, rip it all out and bask in the simplicity.
>>
>> Acked-by: Will Deacon <will.deacon@arm.com>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> [Sricharan: Rebased on top of ACPI IORT SMMU series]
>> Signed-off-by: Sricharan R <sricharan@codeaurora.org>
>> ---
>>  drivers/iommu/arm-smmu-v3.c | 46 ++---------------------------------
>>  drivers/iommu/arm-smmu.c    | 58 +++++++--------------------------------------
>>  2 files changed, 10 insertions(+), 94 deletions(-)
>
>Yay!

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Bjorn,

>On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>> ...
>
>>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>  drivers/acpi/glue.c               |   5 --
>>  drivers/acpi/scan.c               |   7 +-
>>  drivers/base/dd.c                 |   9 +++
>>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>  drivers/of/address.c              |  20 +++++-
>>  drivers/of/device.c               |  36 ++++++-----
>>  drivers/of/platform.c             |  10 +--
>>  drivers/pci/probe.c               |  28 --------
>>  include/acpi/acpi_bus.h           |   2 +-
>>  include/asm-generic/vmlinux.lds.h |   1 -
>>  include/linux/acpi.h              |   7 +-
>>  include/linux/acpi_iort.h         |   3 -
>>  include/linux/dma-mapping.h       |   3 +
>>  include/linux/of_device.h         |  10 ++-
>>  19 files changed, 252 insertions(+), 320 deletions(-)
>
>I'm assuming this will go via some other tree, maybe the IOMMU tree?
>I acked the PCI parts, so let me know if you need anything more from me.

Thanks for the review/acks.
Ya, via the IOMMU tree looks correct.

Regards,
 Sricharan

RE: [PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Bjorn,

>On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>> ...
>
>>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>  drivers/acpi/glue.c               |   5 --
>>  drivers/acpi/scan.c               |   7 +-
>>  drivers/base/dd.c                 |   9 +++
>>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>  drivers/of/address.c              |  20 +++++-
>>  drivers/of/device.c               |  36 ++++++-----
>>  drivers/of/platform.c             |  10 +--
>>  drivers/pci/probe.c               |  28 --------
>>  include/acpi/acpi_bus.h           |   2 +-
>>  include/asm-generic/vmlinux.lds.h |   1 -
>>  include/linux/acpi.h              |   7 +-
>>  include/linux/acpi_iort.h         |   3 -
>>  include/linux/dma-mapping.h       |   3 +
>>  include/linux/of_device.h         |  10 ++-
>>  19 files changed, 252 insertions(+), 320 deletions(-)
>
>I'm assuming this will go via some other tree, maybe the IOMMU tree?
>I acked the PCI parts, so let me know if you need anything more from me.

Thanks for the review/acks.
Ya, via the IOMMU tree looks correct.

Regards,
 Sricharan

[PATCH V7 00/11] IOMMU probe deferral support

[Sricharan]

Hi Bjorn,

>On Mon, Jan 23, 2017 at 09:48:02PM +0530, Sricharan R wrote:
>> This series calls the dma ops configuration for the devices
>> at a generic place so that it works for all busses.
>> The dma_configure_ops for a device is now called during
>> the device_attach callback just before the probe of the
>> bus/driver is called. Similarly dma_deconfigure is called during
>> device/driver_detach path.
>> ...
>
>>  arch/arm64/mm/dma-mapping.c       | 132 ++++----------------------------------
>>  drivers/acpi/arm64/iort.c         |  40 +++++++++++-
>>  drivers/acpi/glue.c               |   5 --
>>  drivers/acpi/scan.c               |   7 +-
>>  drivers/base/dd.c                 |   9 +++
>>  drivers/base/dma-mapping.c        |  41 ++++++++++++
>>  drivers/iommu/arm-smmu-v3.c       |  46 +------------
>>  drivers/iommu/arm-smmu.c          |  58 +++--------------
>>  drivers/iommu/of_iommu.c          | 114 +++++++++++++++++++++++---------
>>  drivers/of/address.c              |  20 +++++-
>>  drivers/of/device.c               |  36 ++++++-----
>>  drivers/of/platform.c             |  10 +--
>>  drivers/pci/probe.c               |  28 --------
>>  include/acpi/acpi_bus.h           |   2 +-
>>  include/asm-generic/vmlinux.lds.h |   1 -
>>  include/linux/acpi.h              |   7 +-
>>  include/linux/acpi_iort.h         |   3 -
>>  include/linux/dma-mapping.h       |   3 +
>>  include/linux/of_device.h         |  10 ++-
>>  19 files changed, 252 insertions(+), 320 deletions(-)
>
>I'm assuming this will go via some other tree, maybe the IOMMU tree?
>I acked the PCI parts, so let me know if you need anything more from me.

Thanks for the review/acks.
Ya, via the IOMMU tree looks correct.

Regards,
 Sricharan

RE: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org] On Behalf Of Sinan Kaya
>Sent: Sunday, January 29, 2017 10:06 PM
>To: Sricharan R <sricharan-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>; robin.murphy-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
>lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-arm-
>msm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On 1/23/2017 11:18 AM, Sricharan R wrote:
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>  	if (ret < 0) {
>>  		dma_addr = offset = 0;
>> -		size = dev->coherent_dma_mask + 1;
>> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>  	} else {
>
>what's happening here?

Sorry, not relevant. Will remove this. Has come in because of some rebase mistake.

Regards,
 Sricharan

RE: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces@lists.infradead.org] On Behalf Of Sinan Kaya
>Sent: Sunday, January 29, 2017 10:06 PM
>To: Sricharan R <sricharan@codeaurora.org>; robin.murphy@arm.com; will.deacon@arm.com; joro@8bytes.org;
>lorenzo.pieralisi@arm.com; iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org; linux-arm-
>msm@vger.kernel.org; m.szyprowski@samsung.com; bhelgaas@google.com; linux-pci@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On 1/23/2017 11:18 AM, Sricharan R wrote:
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>  	if (ret < 0) {
>>  		dma_addr = offset = 0;
>> -		size = dev->coherent_dma_mask + 1;
>> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>  	} else {
>
>what's happening here?

Sorry, not relevant. Will remove this. Has come in because of some rebase mistake.

Regards,
 Sricharan


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

[PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>-----Original Message-----
>From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org] On Behalf Of Sinan Kaya
>Sent: Sunday, January 29, 2017 10:06 PM
>To: Sricharan R <sricharan@codeaurora.org>; robin.murphy at arm.com; will.deacon at arm.com; joro at 8bytes.org;
>lorenzo.pieralisi at arm.com; iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org; linux-arm-
>msm at vger.kernel.org; m.szyprowski at samsung.com; bhelgaas at google.com; linux-pci at vger.kernel.org; linux-acpi at vger.kernel.org
>Subject: Re: [PATCH V7 07/11] iommu: of: Handle IOMMU lookup failure with deferred probing or error
>
>On 1/23/2017 11:18 AM, Sricharan R wrote:
>> @@ -107,7 +107,7 @@ void of_dma_configure(struct device *dev, struct device_node *np)
>>  	ret = of_dma_get_range(np, &dma_addr, &paddr, &size);
>>  	if (ret < 0) {
>>  		dma_addr = offset = 0;
>> -		size = dev->coherent_dma_mask + 1;
>> +		size = max(dev->coherent_dma_mask, dev->coherent_dma_mask + 1);
>>  	} else {
>
>what's happening here?

Sorry, not relevant. Will remove this. Has come in because of some rebase mistake.

Regards,
 Sricharan

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Robin Murphy]

On 29/01/17 17:53, Sinan Kaya wrote:
> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> [+hanjun, tomasz, sinan]
>>
>> It is quite a key patchset, I would be glad if they can test on their
>> respective platforms with IORT.
>>
> 
> Tested on top of 4.10-rc5.
> 
> 1.	Platform Hidma device passed dmatest
> 2.	Seeing some USB stalls on a platform USB device.
> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
> SMMU error event during the insertion.

What was the SMMU error - a translation/permission fault (implying the
wrong DMA ops) or a bad STE fault (implying we totally failed to tell
the SMMU about the device at all)?

Robin.

> 
> /sys/bus/pci/slots/4 #
> /sys/bus/pci/slots/4 # dmesg | grep nvme
> [   14.041357] nvme nvme0: pci function 0003:01:00.0
> [  198.399521] nvme nvme0: pci function 0003:01:00.0
> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
> [  264.402313] nvme nvme0: Identify Controller failed (-4)
> [  264.421270] nvme nvme0: Removing after probe failure status: -5
> /sys/bus/pci/slots/4 #
> 
> 
> 

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Robin Murphy]

On 29/01/17 17:53, Sinan Kaya wrote:
> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> [+hanjun, tomasz, sinan]
>>
>> It is quite a key patchset, I would be glad if they can test on their
>> respective platforms with IORT.
>>
> 
> Tested on top of 4.10-rc5.
> 
> 1.	Platform Hidma device passed dmatest
> 2.	Seeing some USB stalls on a platform USB device.
> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
> SMMU error event during the insertion.

What was the SMMU error - a translation/permission fault (implying the
wrong DMA ops) or a bad STE fault (implying we totally failed to tell
the SMMU about the device at all)?

Robin.

> 
> /sys/bus/pci/slots/4 #
> /sys/bus/pci/slots/4 # dmesg | grep nvme
> [   14.041357] nvme nvme0: pci function 0003:01:00.0
> [  198.399521] nvme nvme0: pci function 0003:01:00.0
> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
> [  264.402313] nvme nvme0: Identify Controller failed (-4)
> [  264.421270] nvme nvme0: Removing after probe failure status: -5
> /sys/bus/pci/slots/4 #
> 
> 
> 


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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Robin Murphy]

On 29/01/17 17:53, Sinan Kaya wrote:
> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> [+hanjun, tomasz, sinan]
>>
>> It is quite a key patchset, I would be glad if they can test on their
>> respective platforms with IORT.
>>
> 
> Tested on top of 4.10-rc5.
> 
> 1.	Platform Hidma device passed dmatest
> 2.	Seeing some USB stalls on a platform USB device.
> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
> SMMU error event during the insertion.

What was the SMMU error - a translation/permission fault (implying the
wrong DMA ops) or a bad STE fault (implying we totally failed to tell
the SMMU about the device at all)?

Robin.

> 
> /sys/bus/pci/slots/4 #
> /sys/bus/pci/slots/4 # dmesg | grep nvme
> [   14.041357] nvme nvme0: pci function 0003:01:00.0
> [  198.399521] nvme nvme0: pci function 0003:01:00.0
> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
> [  264.402313] nvme nvme0: Identify Controller failed (-4)
> [  264.421270] nvme nvme0: Removing after probe failure status: -5
> /sys/bus/pci/slots/4 #
> 
> 
> 

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 7:22 AM, Robin Murphy wrote:
> On 29/01/17 17:53, Sinan Kaya wrote:
>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> [+hanjun, tomasz, sinan]
>>>
>>> It is quite a key patchset, I would be glad if they can test on their
>>> respective platforms with IORT.
>>>
>>
>> Tested on top of 4.10-rc5.
>>
>> 1.	Platform Hidma device passed dmatest
>> 2.	Seeing some USB stalls on a platform USB device.
>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
>> SMMU error event during the insertion.
> 
> What was the SMMU error - a translation/permission fault (implying the
> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> the SMMU about the device at all)?
> 

root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power

[__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
[  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
[  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event ignored; already powering off

root@ubuntu:/sys/bus/pci/slots/4#

[__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
[  254.820599] nvme nvme0: pci function 0003:01:00.0
[  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
[  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
[  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
[  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
root@ubuntu:/sys/bus/pci/slots/4#

root@ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
/dev/nvme0

I should have seen /dev/nvme0n1 partition here. 

> Robin.
> 
>>
>> /sys/bus/pci/slots/4 #
>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>> /sys/bus/pci/slots/4 #
>>
>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 7:22 AM, Robin Murphy wrote:
> On 29/01/17 17:53, Sinan Kaya wrote:
>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> [+hanjun, tomasz, sinan]
>>>
>>> It is quite a key patchset, I would be glad if they can test on their
>>> respective platforms with IORT.
>>>
>>
>> Tested on top of 4.10-rc5.
>>
>> 1.	Platform Hidma device passed dmatest
>> 2.	Seeing some USB stalls on a platform USB device.
>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
>> SMMU error event during the insertion.
> 
> What was the SMMU error - a translation/permission fault (implying the
> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> the SMMU about the device at all)?
> 

root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power

[__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
[  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
[  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event ignored; already powering off

root@ubuntu:/sys/bus/pci/slots/4#

[__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
[  254.820599] nvme nvme0: pci function 0003:01:00.0
[  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
[  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
[  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
[  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
root@ubuntu:/sys/bus/pci/slots/4#

root@ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
/dev/nvme0

I should have seen /dev/nvme0n1 partition here. 

> Robin.
> 
>>
>> /sys/bus/pci/slots/4 #
>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>> /sys/bus/pci/slots/4 #
>>
>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 7:22 AM, Robin Murphy wrote:
> On 29/01/17 17:53, Sinan Kaya wrote:
>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> [+hanjun, tomasz, sinan]
>>>
>>> It is quite a key patchset, I would be glad if they can test on their
>>> respective platforms with IORT.
>>>
>>
>> Tested on top of 4.10-rc5.
>>
>> 1.	Platform Hidma device passed dmatest
>> 2.	Seeing some USB stalls on a platform USB device.
>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> 4. 	NVMe driver didn't probe following a hotplug insertion and received an
>> SMMU error event during the insertion.
> 
> What was the SMMU error - a translation/permission fault (implying the
> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> the SMMU about the device at all)?
> 

root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power

[__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
[  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
[  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event ignored; already powering off

root at ubuntu:/sys/bus/pci/slots/4#

[__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
[  254.820599] nvme nvme0: pci function 0003:01:00.0
[  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
[  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
[  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
[  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
[  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
root at ubuntu:/sys/bus/pci/slots/4#

root at ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
/dev/nvme0

I should have seen /dev/nvme0n1 partition here. 

> Robin.
> 
>>
>> /sys/bus/pci/slots/4 #
>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>> /sys/bus/pci/slots/4 #
>>
>>
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 08:59, Sinan Kaya wrote:
> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>> [+hanjun, tomasz, sinan]
>>>> 
>>>> It is quite a key patchset, I would be glad if they can test on 
>>>> their
>>>> respective platforms with IORT.
>>>> 
>>> 
>>> Tested on top of 4.10-rc5.
>>> 
>>> 1.	Platform Hidma device passed dmatest
>>> 2.	Seeing some USB stalls on a platform USB device.
>>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after 
>>> boot.
>>> 4. 	NVMe driver didn't probe following a hotplug insertion and 
>>> received an
>>> SMMU error event during the insertion.
>> 
>> What was the SMMU error - a translation/permission fault (implying the
>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> the SMMU about the device at all)?
>> 
> 
> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> 
> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> ignored; already powering off
> 
> root@ubuntu:/sys/bus/pci/slots/4#
> 
> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
Looks like C_BAD_CD. Can you please try with:
iommu/arm-smmu-v3: Clear prior settings when updating STEs

> root@ubuntu:/sys/bus/pci/slots/4#
> 
> root@ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
> /dev/nvme0
> 
> I should have seen /dev/nvme0n1 partition here.
> 
>> Robin.
>> 
>>> 
>>> /sys/bus/pci/slots/4 #
>>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>>> /sys/bus/pci/slots/4 #
>>> 
>>> 
>>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
>> in
>> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 08:59, Sinan Kaya wrote:
> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>> [+hanjun, tomasz, sinan]
>>>> 
>>>> It is quite a key patchset, I would be glad if they can test on 
>>>> their
>>>> respective platforms with IORT.
>>>> 
>>> 
>>> Tested on top of 4.10-rc5.
>>> 
>>> 1.	Platform Hidma device passed dmatest
>>> 2.	Seeing some USB stalls on a platform USB device.
>>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after 
>>> boot.
>>> 4. 	NVMe driver didn't probe following a hotplug insertion and 
>>> received an
>>> SMMU error event during the insertion.
>> 
>> What was the SMMU error - a translation/permission fault (implying the
>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> the SMMU about the device at all)?
>> 
> 
> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> 
> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> ignored; already powering off
> 
> root@ubuntu:/sys/bus/pci/slots/4#
> 
> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
Looks like C_BAD_CD. Can you please try with:
iommu/arm-smmu-v3: Clear prior settings when updating STEs

> root@ubuntu:/sys/bus/pci/slots/4#
> 
> root@ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
> /dev/nvme0
> 
> I should have seen /dev/nvme0n1 partition here.
> 
>> Robin.
>> 
>>> 
>>> /sys/bus/pci/slots/4 #
>>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>>> /sys/bus/pci/slots/4 #
>>> 
>>> 
>>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 08:59, Sinan Kaya wrote:
> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>> [+hanjun, tomasz, sinan]
>>>> 
>>>> It is quite a key patchset, I would be glad if they can test on 
>>>> their
>>>> respective platforms with IORT.
>>>> 
>>> 
>>> Tested on top of 4.10-rc5.
>>> 
>>> 1.	Platform Hidma device passed dmatest
>>> 2.	Seeing some USB stalls on a platform USB device.
>>> 3.	PCIe NVME drive probed and worked fine with MSI interrupts after 
>>> boot.
>>> 4. 	NVMe driver didn't probe following a hotplug insertion and 
>>> received an
>>> SMMU error event during the insertion.
>> 
>> What was the SMMU error - a translation/permission fault (implying the
>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> the SMMU about the device at all)?
>> 
> 
> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> 
> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> ignored; already powering off
> 
> root at ubuntu:/sys/bus/pci/slots/4#
> 
> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
Looks like C_BAD_CD. Can you please try with:
iommu/arm-smmu-v3: Clear prior settings when updating STEs

> root at ubuntu:/sys/bus/pci/slots/4#
> 
> root at ubuntu:/sys/bus/pci/slots/4#ls /dev/nvme*
> /dev/nvme0
> 
> I should have seen /dev/nvme0n1 partition here.
> 
>> Robin.
>> 
>>> 
>>> /sys/bus/pci/slots/4 #
>>> /sys/bus/pci/slots/4 # dmesg | grep nvme
>>> [   14.041357] nvme nvme0: pci function 0003:01:00.0
>>> [  198.399521] nvme nvme0: pci function 0003:01:00.0
>>> [__198.416232]_nvme_0003:01:00.0:_enabling_device_(0000_->_0002)
>>> [  264.402216] nvme nvme0: I/O 228 QID 0 timeout, disable controller
>>> [  264.402313] nvme nvme0: Identify Controller failed (-4)
>>> [  264.421270] nvme nvme0: Removing after probe failure status: -5
>>> /sys/bus/pci/slots/4 #
>>> 
>>> 
>>> 
>> 
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" 
>> in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> 

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:23 AM, Nate Watterson wrote:
> On 2017-01-30 08:59, Sinan Kaya wrote:
>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>> [+hanjun, tomasz, sinan]
>>>>>
>>>>> It is quite a key patchset, I would be glad if they can test on their
>>>>> respective platforms with IORT.
>>>>>
>>>>
>>>> Tested on top of 4.10-rc5.
>>>>
>>>> 1.    Platform Hidma device passed dmatest
>>>> 2.    Seeing some USB stalls on a platform USB device.
>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>>> SMMU error event during the insertion.
>>>
>>> What was the SMMU error - a translation/permission fault (implying the
>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> the SMMU about the device at all)?
>>>
>>
>> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>
>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> ignored; already powering off
>>
>> root@ubuntu:/sys/bus/pci/slots/4#
>>
>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000

> Looks like C_BAD_CD. Can you please try with:
> iommu/arm-smmu-v3: Clear prior settings when updating STEs

This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
this issue again.

root@ubuntu:/sys/bus/pci/slots# cd 4
root@ubuntu:/sys/bus/pci/slots/4# ls
adapter  address  attention  cur_bus_speed  latch  max_bus_speed  module  power
root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
root@ubuntu:/sys/bus/pci/slots/4# echo 1 > power
root@ubuntu:/sys/bus/pci/slots/4# dmesg |tail -n 10
[   44.136028] pci 0003:01:00.0: BAR 0: assigned [mem 0xc0100110000-0xc0100113fff 64bit]
[   44.136044] pcieport 0003:00:00.0: PCI bridge to [bus 01]
[   44.136046] pcieport 0003:00:00.0:   bridge window [io  0x10000-0x10fff]
[   44.136048] pcieport 0003:00:00.0:   bridge window [mem 0xc0100100000-0xc01002fffff]
[   44.136050] pcieport 0003:00:00.0:   bridge window [mem 0xc0400000000-0xc04001fffff 64bit pref]
[   44.136059] pcieport 0003:00:00.0: Max Payload Size set to  256/ 512 (was  256), Max Read Rq  512
[   44.136073] pci 0003:01:00.0: Max Payload Size set to  256/ 256 (was  128), Max Read Rq  512
[   44.136124] iommu: Adding device 0003:01:00.0 to group 8
[   44.136275] nvme nvme0: pci function 0003:01:00.0
[   44.136292] nvme 0003:01:00.0: enabling device (0000 -> 0002)
root@ubuntu:/sys/bus/pci/slots/4# ls /dev/nvme*
/dev/nvme0  /dev/nvme0n1
root@ubuntu:/sys/bus/pci/slots/4#

I'll look at the USB stalls next.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:23 AM, Nate Watterson wrote:
> On 2017-01-30 08:59, Sinan Kaya wrote:
>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>> [+hanjun, tomasz, sinan]
>>>>>
>>>>> It is quite a key patchset, I would be glad if they can test on their
>>>>> respective platforms with IORT.
>>>>>
>>>>
>>>> Tested on top of 4.10-rc5.
>>>>
>>>> 1.    Platform Hidma device passed dmatest
>>>> 2.    Seeing some USB stalls on a platform USB device.
>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>>> SMMU error event during the insertion.
>>>
>>> What was the SMMU error - a translation/permission fault (implying the
>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> the SMMU about the device at all)?
>>>
>>
>> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>
>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> ignored; already powering off
>>
>> root@ubuntu:/sys/bus/pci/slots/4#
>>
>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000

> Looks like C_BAD_CD. Can you please try with:
> iommu/arm-smmu-v3: Clear prior settings when updating STEs

This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
this issue again.

root@ubuntu:/sys/bus/pci/slots# cd 4
root@ubuntu:/sys/bus/pci/slots/4# ls
adapter  address  attention  cur_bus_speed  latch  max_bus_speed  module  power
root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
root@ubuntu:/sys/bus/pci/slots/4# echo 1 > power
root@ubuntu:/sys/bus/pci/slots/4# dmesg |tail -n 10
[   44.136028] pci 0003:01:00.0: BAR 0: assigned [mem 0xc0100110000-0xc0100113fff 64bit]
[   44.136044] pcieport 0003:00:00.0: PCI bridge to [bus 01]
[   44.136046] pcieport 0003:00:00.0:   bridge window [io  0x10000-0x10fff]
[   44.136048] pcieport 0003:00:00.0:   bridge window [mem 0xc0100100000-0xc01002fffff]
[   44.136050] pcieport 0003:00:00.0:   bridge window [mem 0xc0400000000-0xc04001fffff 64bit pref]
[   44.136059] pcieport 0003:00:00.0: Max Payload Size set to  256/ 512 (was  256), Max Read Rq  512
[   44.136073] pci 0003:01:00.0: Max Payload Size set to  256/ 256 (was  128), Max Read Rq  512
[   44.136124] iommu: Adding device 0003:01:00.0 to group 8
[   44.136275] nvme nvme0: pci function 0003:01:00.0
[   44.136292] nvme 0003:01:00.0: enabling device (0000 -> 0002)
root@ubuntu:/sys/bus/pci/slots/4# ls /dev/nvme*
/dev/nvme0  /dev/nvme0n1
root@ubuntu:/sys/bus/pci/slots/4#

I'll look at the USB stalls next.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:23 AM, Nate Watterson wrote:
> On 2017-01-30 08:59, Sinan Kaya wrote:
>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>> [+hanjun, tomasz, sinan]
>>>>>
>>>>> It is quite a key patchset, I would be glad if they can test on their
>>>>> respective platforms with IORT.
>>>>>
>>>>
>>>> Tested on top of 4.10-rc5.
>>>>
>>>> 1.    Platform Hidma device passed dmatest
>>>> 2.    Seeing some USB stalls on a platform USB device.
>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>>> SMMU error event during the insertion.
>>>
>>> What was the SMMU error - a translation/permission fault (implying the
>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> the SMMU about the device at all)?
>>>
>>
>> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>
>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> ignored; already powering off
>>
>> root at ubuntu:/sys/bus/pci/slots/4#
>>
>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000

> Looks like C_BAD_CD. Can you please try with:
> iommu/arm-smmu-v3: Clear prior settings when updating STEs

This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
this issue again.

root at ubuntu:/sys/bus/pci/slots# cd 4
root at ubuntu:/sys/bus/pci/slots/4# ls
adapter  address  attention  cur_bus_speed  latch  max_bus_speed  module  power
root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
root at ubuntu:/sys/bus/pci/slots/4# echo 1 > power
root at ubuntu:/sys/bus/pci/slots/4# dmesg |tail -n 10
[   44.136028] pci 0003:01:00.0: BAR 0: assigned [mem 0xc0100110000-0xc0100113fff 64bit]
[   44.136044] pcieport 0003:00:00.0: PCI bridge to [bus 01]
[   44.136046] pcieport 0003:00:00.0:   bridge window [io  0x10000-0x10fff]
[   44.136048] pcieport 0003:00:00.0:   bridge window [mem 0xc0100100000-0xc01002fffff]
[   44.136050] pcieport 0003:00:00.0:   bridge window [mem 0xc0400000000-0xc04001fffff 64bit pref]
[   44.136059] pcieport 0003:00:00.0: Max Payload Size set to  256/ 512 (was  256), Max Read Rq  512
[   44.136073] pci 0003:01:00.0: Max Payload Size set to  256/ 256 (was  128), Max Read Rq  512
[   44.136124] iommu: Adding device 0003:01:00.0 to group 8
[   44.136275] nvme nvme0: pci function 0003:01:00.0
[   44.136292] nvme 0003:01:00.0: enabling device (0000 -> 0002)
root at ubuntu:/sys/bus/pci/slots/4# ls /dev/nvme*
/dev/nvme0  /dev/nvme0n1
root at ubuntu:/sys/bus/pci/slots/4#

I'll look at the USB stalls next.


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Will Deacon]

On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>> [+hanjun, tomasz, sinan]
> >>>>>
> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>> respective platforms with IORT.
> >>>>>
> >>>>
> >>>> Tested on top of 4.10-rc5.
> >>>>
> >>>> 1.    Platform Hidma device passed dmatest
> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>> SMMU error event during the insertion.
> >>>
> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> the SMMU about the device at all)?
> >>>
> >>
> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>
> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >> ignored; already powering off
> >>
> >> root@ubuntu:/sys/bus/pci/slots/4#
> >>
> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> 
> > Looks like C_BAD_CD. Can you please try with:
> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> 
> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> this issue again.

I already sent the pull request to Joerg for 4.11. Do you see this problem
without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
send the patch to stable after -rc1.

Will

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Will Deacon]

On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>> [+hanjun, tomasz, sinan]
> >>>>>
> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>> respective platforms with IORT.
> >>>>>
> >>>>
> >>>> Tested on top of 4.10-rc5.
> >>>>
> >>>> 1.    Platform Hidma device passed dmatest
> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>> SMMU error event during the insertion.
> >>>
> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> the SMMU about the device at all)?
> >>>
> >>
> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>
> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >> ignored; already powering off
> >>
> >> root@ubuntu:/sys/bus/pci/slots/4#
> >>
> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> 
> > Looks like C_BAD_CD. Can you please try with:
> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> 
> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> this issue again.

I already sent the pull request to Joerg for 4.11. Do you see this problem
without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
send the patch to stable after -rc1.

Will

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Will Deacon]

On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>> [+hanjun, tomasz, sinan]
> >>>>>
> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>> respective platforms with IORT.
> >>>>>
> >>>>
> >>>> Tested on top of 4.10-rc5.
> >>>>
> >>>> 1.    Platform Hidma device passed dmatest
> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>> SMMU error event during the insertion.
> >>>
> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> the SMMU about the device at all)?
> >>>
> >>
> >> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>
> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >> ignored; already powering off
> >>
> >> root at ubuntu:/sys/bus/pci/slots/4#
> >>
> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> 
> > Looks like C_BAD_CD. Can you please try with:
> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> 
> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> this issue again.

I already sent the pull request to Joerg for 4.11. Do you see this problem
without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
send the patch to stable after -rc1.

Will

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 09:38, Will Deacon wrote:
> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> >>>>> [+hanjun, tomasz, sinan]
>> >>>>>
>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>> >>>>> respective platforms with IORT.
>> >>>>>
>> >>>>
>> >>>> Tested on top of 4.10-rc5.
>> >>>>
>> >>>> 1.    Platform Hidma device passed dmatest
>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>> >>>> SMMU error event during the insertion.
>> >>>
>> >>> What was the SMMU error - a translation/permission fault (implying the
>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> >>> the SMMU about the device at all)?
>> >>>
>> >>
>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>> >>
>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> >> ignored; already powering off
>> >>
>> >> root@ubuntu:/sys/bus/pci/slots/4#
>> >>
>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> 
>> > Looks like C_BAD_CD. Can you please try with:
>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>> 
>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I 
>> don't see
>> this issue again.
> 
> I already sent the pull request to Joerg for 4.11. Do you see this 
> problem
> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need 
> to
> send the patch to stable after -rc1.
Using vanilla mainline, I see it most commonly when directly assigning
a device to a guest machine. I think I've also seen it after removing 
then
re-adding a PCI device. Basically anytime an STE's CTX pointer is 
changed
from a non-NULL value and STE[CFG] indicates translation will be 
performed.

Nate
> 
> Will

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 09:38, Will Deacon wrote:
> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> >>>>> [+hanjun, tomasz, sinan]
>> >>>>>
>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>> >>>>> respective platforms with IORT.
>> >>>>>
>> >>>>
>> >>>> Tested on top of 4.10-rc5.
>> >>>>
>> >>>> 1.    Platform Hidma device passed dmatest
>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>> >>>> SMMU error event during the insertion.
>> >>>
>> >>> What was the SMMU error - a translation/permission fault (implying the
>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> >>> the SMMU about the device at all)?
>> >>>
>> >>
>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>> >>
>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> >> ignored; already powering off
>> >>
>> >> root@ubuntu:/sys/bus/pci/slots/4#
>> >>
>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> 
>> > Looks like C_BAD_CD. Can you please try with:
>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>> 
>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I 
>> don't see
>> this issue again.
> 
> I already sent the pull request to Joerg for 4.11. Do you see this 
> problem
> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need 
> to
> send the patch to stable after -rc1.
Using vanilla mainline, I see it most commonly when directly assigning
a device to a guest machine. I think I've also seen it after removing 
then
re-adding a PCI device. Basically anytime an STE's CTX pointer is 
changed
from a non-NULL value and STE[CFG] indicates translation will be 
performed.

Nate
> 
> Will

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-01-30 09:38, Will Deacon wrote:
> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>> >>>>> [+hanjun, tomasz, sinan]
>> >>>>>
>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>> >>>>> respective platforms with IORT.
>> >>>>>
>> >>>>
>> >>>> Tested on top of 4.10-rc5.
>> >>>>
>> >>>> 1.    Platform Hidma device passed dmatest
>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>> >>>> SMMU error event during the insertion.
>> >>>
>> >>> What was the SMMU error - a translation/permission fault (implying the
>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>> >>> the SMMU about the device at all)?
>> >>>
>> >>
>> >> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>> >>
>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>> >> ignored; already powering off
>> >>
>> >> root at ubuntu:/sys/bus/pci/slots/4#
>> >>
>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>> 
>> > Looks like C_BAD_CD. Can you please try with:
>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>> 
>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I 
>> don't see
>> this issue again.
> 
> I already sent the pull request to Joerg for 4.11. Do you see this 
> problem
> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need 
> to
> send the patch to stable after -rc1.
Using vanilla mainline, I see it most commonly when directly assigning
a device to a guest machine. I think I've also seen it after removing 
then
re-adding a PCI device. Basically anytime an STE's CTX pointer is 
changed
from a non-NULL value and STE[CFG] indicates translation will be 
performed.

Nate
> 
> Will

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:54 AM, Nate Watterson wrote:
> On 2017-01-30 09:38, Will Deacon wrote:
>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> >>>>> [+hanjun, tomasz, sinan]
>>> >>>>>
>>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>>> >>>>> respective platforms with IORT.
>>> >>>>>
>>> >>>>
>>> >>>> Tested on top of 4.10-rc5.
>>> >>>>
>>> >>>> 1.    Platform Hidma device passed dmatest
>>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>> >>>> SMMU error event during the insertion.
>>> >>>
>>> >>> What was the SMMU error - a translation/permission fault (implying the
>>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> >>> the SMMU about the device at all)?
>>> >>>
>>> >>
>>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>> >>
>>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>>> >> ignored; already powering off
>>> >>
>>> >> root@ubuntu:/sys/bus/pci/slots/4#
>>> >>
>>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>
>>> > Looks like C_BAD_CD. Can you please try with:
>>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>>>
>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
>>> this issue again.
>>
>> I already sent the pull request to Joerg for 4.11. Do you see this problem
>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
>> send the patch to stable after -rc1.
> Using vanilla mainline, I see it most commonly when directly assigning
> a device to a guest machine. I think I've also seen it after removing then
> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> from a non-NULL value and STE[CFG] indicates translation will be performed.
> 

I was not able to reproduce the issue with Vanilla kernel. I only tested hotplug.

> Nate
>>
>> Will
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:54 AM, Nate Watterson wrote:
> On 2017-01-30 09:38, Will Deacon wrote:
>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> >>>>> [+hanjun, tomasz, sinan]
>>> >>>>>
>>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>>> >>>>> respective platforms with IORT.
>>> >>>>>
>>> >>>>
>>> >>>> Tested on top of 4.10-rc5.
>>> >>>>
>>> >>>> 1.    Platform Hidma device passed dmatest
>>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>> >>>> SMMU error event during the insertion.
>>> >>>
>>> >>> What was the SMMU error - a translation/permission fault (implying the
>>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> >>> the SMMU about the device at all)?
>>> >>>
>>> >>
>>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>> >>
>>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>>> >> ignored; already powering off
>>> >>
>>> >> root@ubuntu:/sys/bus/pci/slots/4#
>>> >>
>>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>
>>> > Looks like C_BAD_CD. Can you please try with:
>>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>>>
>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
>>> this issue again.
>>
>> I already sent the pull request to Joerg for 4.11. Do you see this problem
>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
>> send the patch to stable after -rc1.
> Using vanilla mainline, I see it most commonly when directly assigning
> a device to a guest machine. I think I've also seen it after removing then
> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> from a non-NULL value and STE[CFG] indicates translation will be performed.
> 

I was not able to reproduce the issue with Vanilla kernel. I only tested hotplug.

> Nate
>>
>> Will
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 9:54 AM, Nate Watterson wrote:
> On 2017-01-30 09:38, Will Deacon wrote:
>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>> > On 2017-01-30 08:59, Sinan Kaya wrote:
>>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
>>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>> >>>>> [+hanjun, tomasz, sinan]
>>> >>>>>
>>> >>>>> It is quite a key patchset, I would be glad if they can test on their
>>> >>>>> respective platforms with IORT.
>>> >>>>>
>>> >>>>
>>> >>>> Tested on top of 4.10-rc5.
>>> >>>>
>>> >>>> 1.    Platform Hidma device passed dmatest
>>> >>>> 2.    Seeing some USB stalls on a platform USB device.
>>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>> >>>> SMMU error event during the insertion.
>>> >>>
>>> >>> What was the SMMU error - a translation/permission fault (implying the
>>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>> >>> the SMMU about the device at all)?
>>> >>>
>>> >>
>>> >> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>> >>
>>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>>> >> ignored; already powering off
>>> >>
>>> >> root at ubuntu:/sys/bus/pci/slots/4#
>>> >>
>>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>
>>> > Looks like C_BAD_CD. Can you please try with:
>>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
>>>
>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
>>> this issue again.
>>
>> I already sent the pull request to Joerg for 4.11. Do you see this problem
>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
>> send the patch to stable after -rc1.
> Using vanilla mainline, I see it most commonly when directly assigning
> a device to a guest machine. I think I've also seen it after removing then
> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> from a non-NULL value and STE[CFG] indicates translation will be performed.
> 

I was not able to reproduce the issue with Vanilla kernel. I only tested hotplug.

> Nate
>>
>> Will
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> > On 2017-01-30 09:38, Will Deacon wrote:
> >> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>> >>>>> [+hanjun, tomasz, sinan]
> >>> >>>>>
> >>> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>> >>>>> respective platforms with IORT.
> >>> >>>>>
> >>> >>>>
> >>> >>>> Tested on top of 4.10-rc5.
> >>> >>>>
> >>> >>>> 1.    Platform Hidma device passed dmatest
> >>> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>> >>>> SMMU error event during the insertion.
> >>> >>>
> >>> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> >>> the SMMU about the device at all)?
> >>> >>>
> >>> >>
> >>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>> >>
> >>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>> >> ignored; already powering off
> >>> >>
> >>> >> root@ubuntu:/sys/bus/pci/slots/4#
> >>> >>
> >>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>
> >>> > Looks like C_BAD_CD. Can you please try with:
> >>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>
> >>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>> this issue again.
> >>
> >> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >> send the patch to stable after -rc1.
> > Using vanilla mainline, I see it most commonly when directly assigning
> > a device to a guest machine. I think I've also seen it after removing then
> > re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> > from a non-NULL value and STE[CFG] indicates translation will be performed.
> > 
> 
> I was not able to reproduce the issue with Vanilla kernel. I only
> tested hotplug.

I would like to get the complete code path leading to this issue, it is
not clear to me why the probe deferral code triggers it and why we are
not able to trigger it with vanilla mainline, we must understand that first
before applying any fix to this series.

I do not have a platform to reproduce this issue I will send you a patch
to trace what's going on here please help us debug it.

Thanks,
Lorenzo

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> > On 2017-01-30 09:38, Will Deacon wrote:
> >> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>> >>>>> [+hanjun, tomasz, sinan]
> >>> >>>>>
> >>> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>> >>>>> respective platforms with IORT.
> >>> >>>>>
> >>> >>>>
> >>> >>>> Tested on top of 4.10-rc5.
> >>> >>>>
> >>> >>>> 1.    Platform Hidma device passed dmatest
> >>> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>> >>>> SMMU error event during the insertion.
> >>> >>>
> >>> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> >>> the SMMU about the device at all)?
> >>> >>>
> >>> >>
> >>> >> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>> >>
> >>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>> >> ignored; already powering off
> >>> >>
> >>> >> root@ubuntu:/sys/bus/pci/slots/4#
> >>> >>
> >>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>
> >>> > Looks like C_BAD_CD. Can you please try with:
> >>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>
> >>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>> this issue again.
> >>
> >> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >> send the patch to stable after -rc1.
> > Using vanilla mainline, I see it most commonly when directly assigning
> > a device to a guest machine. I think I've also seen it after removing then
> > re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> > from a non-NULL value and STE[CFG] indicates translation will be performed.
> > 
> 
> I was not able to reproduce the issue with Vanilla kernel. I only
> tested hotplug.

I would like to get the complete code path leading to this issue, it is
not clear to me why the probe deferral code triggers it and why we are
not able to trigger it with vanilla mainline, we must understand that first
before applying any fix to this series.

I do not have a platform to reproduce this issue I will send you a patch
to trace what's going on here please help us debug it.

Thanks,
Lorenzo

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> > On 2017-01-30 09:38, Will Deacon wrote:
> >> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>> > On 2017-01-30 08:59, Sinan Kaya wrote:
> >>> >> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>> >>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>> >>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>> >>>>> [+hanjun, tomasz, sinan]
> >>> >>>>>
> >>> >>>>> It is quite a key patchset, I would be glad if they can test on their
> >>> >>>>> respective platforms with IORT.
> >>> >>>>>
> >>> >>>>
> >>> >>>> Tested on top of 4.10-rc5.
> >>> >>>>
> >>> >>>> 1.    Platform Hidma device passed dmatest
> >>> >>>> 2.    Seeing some USB stalls on a platform USB device.
> >>> >>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>> >>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>> >>>> SMMU error event during the insertion.
> >>> >>>
> >>> >>> What was the SMMU error - a translation/permission fault (implying the
> >>> >>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>> >>> the SMMU about the device at all)?
> >>> >>>
> >>> >>
> >>> >> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>> >>
> >>> >> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>> >> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>> >> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>> >> ignored; already powering off
> >>> >>
> >>> >> root at ubuntu:/sys/bus/pci/slots/4#
> >>> >>
> >>> >> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>> >> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>> >> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>> >> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>> >> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>> >> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>> >> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>
> >>> > Looks like C_BAD_CD. Can you please try with:
> >>> > iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>
> >>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>> this issue again.
> >>
> >> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >> send the patch to stable after -rc1.
> > Using vanilla mainline, I see it most commonly when directly assigning
> > a device to a guest machine. I think I've also seen it after removing then
> > re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> > from a non-NULL value and STE[CFG] indicates translation will be performed.
> > 
> 
> I was not able to reproduce the issue with Vanilla kernel. I only
> tested hotplug.

I would like to get the complete code path leading to this issue, it is
not clear to me why the probe deferral code triggers it and why we are
not able to trigger it with vanilla mainline, we must understand that first
before applying any fix to this series.

I do not have a platform to reproduce this issue I will send you a patch
to trace what's going on here please help us debug it.

Thanks,
Lorenzo

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 30/01/17 07:00, Sricharan wrote:
> Hi Robin,
> 
>>> [..]
>>>
>>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>>> +                       struct device_node *master_np)
>>>>>> +{
>>>>>> +    const struct iommu_ops *ops;
>>>>>> +
>>>>>> +    if (!master_np)
>>>>>> +        return NULL;
>>>>>> +
>>>>>> +    if (dev_is_pci(dev))
>>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>>
>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>
>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>> managed to hit __of_match_node() dereferencing NULL from
>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>> trying to figure out now, and I wonder if the two might be related.
>>>
>>> Sorry that there is crash still. __of_match_node seems to checking
>>> for NULL arguments , feels like some invalid pointer was passed in.
>>> Is there any particular sequence to try for this ?
>>
>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>> driver probing after init, connected to an unprobed IOMMU (in this case
>> disabled in DT), trips over trying to match the now-freed table. I'm
>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>
> 
> Ok, thanks for bringing this out. There is also an issue that
> Sinan has mentioned while testing the ACPI hotplug path, probably
> its related to the above, not sure. I will try to check more on that
> in the meanwhile. Then, taking your fix and fixing the hotplug case
> i will do one more repost.

OK, I've finally settled on the below fixup for patch #2 - I have some
follow-on ideas for eventually getting of the magic table altogether,
but they can wait until we've got the baseline functionality sorted.
Updated full patch here:

http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Robin.

-----8<-----

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 349bd1d01612..1f92d98237d5 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);

+static bool of_iommu_driver_present(struct device_node *np)
+{
+	/*
+	 * If the IOMMU still isn't ready by the time we reach init, assume
+	 * it never will be. We don't want to defer indefinitely, nor attempt
+	 * to dereference __iommu_of_table after it's been freed.
+	 */
+	if (system_state > SYSTEM_BOOTING)
+		return false;
+
+	return of_match_node(&__iommu_of_table, np);
+}
+
 static const struct iommu_ops
 *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
 {
@@ -105,7 +118,7 @@ static const struct iommu_ops

 	ops = iommu_get_instance(fwnode);
 	if ((ops && !ops->of_xlate) ||
-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
 		return NULL;

 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);

Re: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 30/01/17 07:00, Sricharan wrote:
> Hi Robin,
> 
>>> [..]
>>>
>>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>>> +                       struct device_node *master_np)
>>>>>> +{
>>>>>> +    const struct iommu_ops *ops;
>>>>>> +
>>>>>> +    if (!master_np)
>>>>>> +        return NULL;
>>>>>> +
>>>>>> +    if (dev_is_pci(dev))
>>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>>
>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>
>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>> managed to hit __of_match_node() dereferencing NULL from
>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>> trying to figure out now, and I wonder if the two might be related.
>>>
>>> Sorry that there is crash still. __of_match_node seems to checking
>>> for NULL arguments , feels like some invalid pointer was passed in.
>>> Is there any particular sequence to try for this ?
>>
>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>> driver probing after init, connected to an unprobed IOMMU (in this case
>> disabled in DT), trips over trying to match the now-freed table. I'm
>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>
> 
> Ok, thanks for bringing this out. There is also an issue that
> Sinan has mentioned while testing the ACPI hotplug path, probably
> its related to the above, not sure. I will try to check more on that
> in the meanwhile. Then, taking your fix and fixing the hotplug case
> i will do one more repost.

OK, I've finally settled on the below fixup for patch #2 - I have some
follow-on ideas for eventually getting of the magic table altogether,
but they can wait until we've got the baseline functionality sorted.
Updated full patch here:

http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Robin.

-----8<-----

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 349bd1d01612..1f92d98237d5 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);

+static bool of_iommu_driver_present(struct device_node *np)
+{
+	/*
+	 * If the IOMMU still isn't ready by the time we reach init, assume
+	 * it never will be. We don't want to defer indefinitely, nor attempt
+	 * to dereference __iommu_of_table after it's been freed.
+	 */
+	if (system_state > SYSTEM_BOOTING)
+		return false;
+
+	return of_match_node(&__iommu_of_table, np);
+}
+
 static const struct iommu_ops
 *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
 {
@@ -105,7 +118,7 @@ static const struct iommu_ops

 	ops = iommu_get_instance(fwnode);
 	if ((ops && !ops->of_xlate) ||
-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
 		return NULL;

 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);

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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Robin Murphy]

On 30/01/17 07:00, Sricharan wrote:
> Hi Robin,
> 
>>> [..]
>>>
>>>>>> +const struct iommu_ops *of_iommu_configure(struct device *dev,
>>>>>> +                       struct device_node *master_np)
>>>>>> +{
>>>>>> +    const struct iommu_ops *ops;
>>>>>> +
>>>>>> +    if (!master_np)
>>>>>> +        return NULL;
>>>>>> +
>>>>>> +    if (dev_is_pci(dev))
>>>>>> +        ops = of_pci_iommu_init(to_pci_dev(dev), master_np);
>>>>>
>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>
>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>> managed to hit __of_match_node() dereferencing NULL from
>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>> trying to figure out now, and I wonder if the two might be related.
>>>
>>> Sorry that there is crash still. __of_match_node seems to checking
>>> for NULL arguments , feels like some invalid pointer was passed in.
>>> Is there any particular sequence to try for this ?
>>
>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>> driver probing after init, connected to an unprobed IOMMU (in this case
>> disabled in DT), trips over trying to match the now-freed table. I'm
>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>
> 
> Ok, thanks for bringing this out. There is also an issue that
> Sinan has mentioned while testing the ACPI hotplug path, probably
> its related to the above, not sure. I will try to check more on that
> in the meanwhile. Then, taking your fix and fixing the hotplug case
> i will do one more repost.

OK, I've finally settled on the below fixup for patch #2 - I have some
follow-on ideas for eventually getting of the magic table altogether,
but they can wait until we've got the baseline functionality sorted.
Updated full patch here:

http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Robin.

-----8<-----

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 349bd1d01612..1f92d98237d5 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
char *prefix, int index,
 }
 EXPORT_SYMBOL_GPL(of_get_dma_window);

+static bool of_iommu_driver_present(struct device_node *np)
+{
+	/*
+	 * If the IOMMU still isn't ready by the time we reach init, assume
+	 * it never will be. We don't want to defer indefinitely, nor attempt
+	 * to dereference __iommu_of_table after it's been freed.
+	 */
+	if (system_state > SYSTEM_BOOTING)
+		return false;
+
+	return of_match_node(&__iommu_of_table, np);
+}
+
 static const struct iommu_ops
 *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
 {
@@ -105,7 +118,7 @@ static const struct iommu_ops

 	ops = iommu_get_instance(fwnode);
 	if ((ops && !ops->of_xlate) ||
-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
 		return NULL;

 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:54 AM, Nate Watterson wrote:
>>> On 2017-01-30 09:38, Will Deacon wrote:
>>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>>>>> On 2017-01-30 08:59, Sinan Kaya wrote:
>>>>>>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>>>>>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>>>>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>>>>>>> [+hanjun, tomasz, sinan]
>>>>>>>>>>
>>>>>>>>>> It is quite a key patchset, I would be glad if they can test on their
>>>>>>>>>> respective platforms with IORT.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tested on top of 4.10-rc5.
>>>>>>>>>
>>>>>>>>> 1.    Platform Hidma device passed dmatest
>>>>>>>>> 2.    Seeing some USB stalls on a platform USB device.
>>>>>>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>>>>>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>>>>>>>> SMMU error event during the insertion.
>>>>>>>>
>>>>>>>> What was the SMMU error - a translation/permission fault (implying the
>>>>>>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>>>>>>> the SMMU about the device at all)?
>>>>>>>>
>>>>>>>
>>>>>>> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>>>>>>
>>>>>>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>>>>>>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>>>>>>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>>>>>>> ignored; already powering off
>>>>>>>
>>>>>>> root@ubuntu:/sys/bus/pci/slots/4#
>>>>>>>
>>>>>>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>>>>>>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>>>>>>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>>>>>>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>>>>>>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>>>>>>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>
>>>>>> Looks like C_BAD_CD. Can you please try with:
>>>>>> iommu/arm-smmu-v3: Clear prior settings when updating STEs
>>>>>
>>>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
>>>>> this issue again.
>>>>
>>>> I already sent the pull request to Joerg for 4.11. Do you see this problem
>>>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
>>>> send the patch to stable after -rc1.
>>> Using vanilla mainline, I see it most commonly when directly assigning
>>> a device to a guest machine. I think I've also seen it after removing then
>>> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
>>> from a non-NULL value and STE[CFG] indicates translation will be performed.
>>>
>>
>> I was not able to reproduce the issue with Vanilla kernel. I only
>> tested hotplug.
> 
> I would like to get the complete code path leading to this issue, it is
> not clear to me why the probe deferral code triggers it and why we are
> not able to trigger it with vanilla mainline, we must understand that first
> before applying any fix to this series.
> 
> I do not have a platform to reproduce this issue I will send you a patch
> to trace what's going on here please help us debug it.

Sure, send it to both Nate and me.

> 
> Thanks,
> Lorenzo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
>> On 1/30/2017 9:54 AM, Nate Watterson wrote:
>>> On 2017-01-30 09:38, Will Deacon wrote:
>>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
>>>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
>>>>>> On 2017-01-30 08:59, Sinan Kaya wrote:
>>>>>>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
>>>>>>>> On 29/01/17 17:53, Sinan Kaya wrote:
>>>>>>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
>>>>>>>>>> [+hanjun, tomasz, sinan]
>>>>>>>>>>
>>>>>>>>>> It is quite a key patchset, I would be glad if they can test on their
>>>>>>>>>> respective platforms with IORT.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Tested on top of 4.10-rc5.
>>>>>>>>>
>>>>>>>>> 1.    Platform Hidma device passed dmatest
>>>>>>>>> 2.    Seeing some USB stalls on a platform USB device.
>>>>>>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
>>>>>>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
>>>>>>>>> SMMU error event during the insertion.
>>>>>>>>
>>>>>>>> What was the SMMU error - a translation/permission fault (implying the
>>>>>>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
>>>>>>>> the SMMU about the device at all)?
>>>>>>>>
>>>>>>>
>>>>>>> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
>>>>>>>
>>>>>>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
>>>>>>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
>>>>>>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
>>>>>>> ignored; already powering off
>>>>>>>
>>>>>>> root at ubuntu:/sys/bus/pci/slots/4#
>>>>>>>
>>>>>>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
>>>>>>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
>>>>>>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
>>>>>>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
>>>>>>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
>>>>>>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
>>>>>
>>>>>> Looks like C_BAD_CD. Can you please try with:
>>>>>> iommu/arm-smmu-v3: Clear prior settings when updating STEs
>>>>>
>>>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
>>>>> this issue again.
>>>>
>>>> I already sent the pull request to Joerg for 4.11. Do you see this problem
>>>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
>>>> send the patch to stable after -rc1.
>>> Using vanilla mainline, I see it most commonly when directly assigning
>>> a device to a guest machine. I think I've also seen it after removing then
>>> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
>>> from a non-NULL value and STE[CFG] indicates translation will be performed.
>>>
>>
>> I was not able to reproduce the issue with Vanilla kernel. I only
>> tested hotplug.
> 
> I would like to get the complete code path leading to this issue, it is
> not clear to me why the probe deferral code triggers it and why we are
> not able to trigger it with vanilla mainline, we must understand that first
> before applying any fix to this series.
> 
> I do not have a platform to reproduce this issue I will send you a patch
> to trace what's going on here please help us debug it.

Sure, send it to both Nate and me.

> 
> Thanks,
> Lorenzo
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>>
>>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>>> managed to hit __of_match_node() dereferencing NULL from
>>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>>> trying to figure out now, and I wonder if the two might be related.
>>>>
>>>> Sorry that there is crash still. __of_match_node seems to checking
>>>> for NULL arguments , feels like some invalid pointer was passed in.
>>>> Is there any particular sequence to try for this ?
>>>
>>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>>> driver probing after init, connected to an unprobed IOMMU (in this case
>>> disabled in DT), trips over trying to match the now-freed table. I'm
>>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>>
>>
>> Ok, thanks for bringing this out. There is also an issue that
>> Sinan has mentioned while testing the ACPI hotplug path, probably
>> its related to the above, not sure. I will try to check more on that
>> in the meanwhile. Then, taking your fix and fixing the hotplug case
>> i will do one more repost.
>
>OK, I've finally settled on the below fixup for patch #2 - I have some
>follow-on ideas for eventually getting of the magic table altogether,
>but they can wait until we've got the baseline functionality sorted.
>Updated full patch here:
>
>http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Thanks, will use this. Yes, the magic iommu_of_table makes little
use with probe deferral in place, except that we are using it at the
moment. And the other hotplug issue is not related this though.

Regards,
 Sricharan


>-----8<-----
>
>diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>index 349bd1d01612..1f92d98237d5 100644
>--- a/drivers/iommu/of_iommu.c
>+++ b/drivers/iommu/of_iommu.c
>@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
>char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
>+static bool of_iommu_driver_present(struct device_node *np)
>+{
>+	/*
>+	 * If the IOMMU still isn't ready by the time we reach init, assume
>+	 * it never will be. We don't want to defer indefinitely, nor attempt
>+	 * to dereference __iommu_of_table after it's been freed.
>+	 */
>+	if (system_state > SYSTEM_BOOTING)
>+		return false;
>+
>+	return of_match_node(&__iommu_of_table, np);
>+}
>+
> static const struct iommu_ops
> *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> {
>@@ -105,7 +118,7 @@ static const struct iommu_ops
>
> 	ops = iommu_get_instance(fwnode);
> 	if ((ops && !ops->of_xlate) ||
>-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
> 		return NULL;
>
> 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>>
>>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>>> managed to hit __of_match_node() dereferencing NULL from
>>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>>> trying to figure out now, and I wonder if the two might be related.
>>>>
>>>> Sorry that there is crash still. __of_match_node seems to checking
>>>> for NULL arguments , feels like some invalid pointer was passed in.
>>>> Is there any particular sequence to try for this ?
>>>
>>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>>> driver probing after init, connected to an unprobed IOMMU (in this case
>>> disabled in DT), trips over trying to match the now-freed table. I'm
>>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>>
>>
>> Ok, thanks for bringing this out. There is also an issue that
>> Sinan has mentioned while testing the ACPI hotplug path, probably
>> its related to the above, not sure. I will try to check more on that
>> in the meanwhile. Then, taking your fix and fixing the hotplug case
>> i will do one more repost.
>
>OK, I've finally settled on the below fixup for patch #2 - I have some
>follow-on ideas for eventually getting of the magic table altogether,
>but they can wait until we've got the baseline functionality sorted.
>Updated full patch here:
>
>http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Thanks, will use this. Yes, the magic iommu_of_table makes little
use with probe deferral in place, except that we are using it at the
moment. And the other hotplug issue is not related this though.

Regards,
 Sricharan


>-----8<-----
>
>diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>index 349bd1d01612..1f92d98237d5 100644
>--- a/drivers/iommu/of_iommu.c
>+++ b/drivers/iommu/of_iommu.c
>@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
>char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
>+static bool of_iommu_driver_present(struct device_node *np)
>+{
>+	/*
>+	 * If the IOMMU still isn't ready by the time we reach init, assume
>+	 * it never will be. We don't want to defer indefinitely, nor attempt
>+	 * to dereference __iommu_of_table after it's been freed.
>+	 */
>+	if (system_state > SYSTEM_BOOTING)
>+		return false;
>+
>+	return of_match_node(&__iommu_of_table, np);
>+}
>+
> static const struct iommu_ops
> *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> {
>@@ -105,7 +118,7 @@ static const struct iommu_ops
>
> 	ops = iommu_get_instance(fwnode);
> 	if ((ops && !ops->of_xlate) ||
>-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
> 		return NULL;
>
> 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

[PATCH V7 01/11] iommu/of: Refactor of_iommu_configure() for error handling

[Sricharan]

Hi Robin,

>>>>>> I gave the whole patch set a try on ThunderX. really_probe() is failing
>>>>>> on dma_configure()->of_pci_iommu_init() for each PCI device.
>>>>>
>>>>> When you say "failing", do you mean cleanly, or with a crash? I've
>>>>> managed to hit __of_match_node() dereferencing NULL from
>>>>> of_iommu_xlate() in a horribly complicated chain of events, which I'm
>>>>> trying to figure out now, and I wonder if the two might be related.
>>>>
>>>> Sorry that there is crash still. __of_match_node seems to checking
>>>> for NULL arguments , feels like some invalid pointer was passed in.
>>>> Is there any particular sequence to try for this ?
>>>
>>> Ah, I did figure it out - it wasn't actually a NULL dereference, but an
>>> unmapped address. Turns out __iommu_of_table is in initdata, so any
>>> driver probing after init, connected to an unprobed IOMMU (in this case
>>> disabled in DT), trips over trying to match the now-freed table. I'm
>>> working on the fix - technically the bug's in my patch (#2) anyway ;)
>>>
>>
>> Ok, thanks for bringing this out. There is also an issue that
>> Sinan has mentioned while testing the ACPI hotplug path, probably
>> its related to the above, not sure. I will try to check more on that
>> in the meanwhile. Then, taking your fix and fixing the hotplug case
>> i will do one more repost.
>
>OK, I've finally settled on the below fixup for patch #2 - I have some
>follow-on ideas for eventually getting of the magic table altogether,
>but they can wait until we've got the baseline functionality sorted.
>Updated full patch here:
>
>http://www.linux-arm.org/git?p=linux-rm.git;a=commitdiff;h=5616af885f7c5c24f7239d5c689583b2b583c407

Thanks, will use this. Yes, the magic iommu_of_table makes little
use with probe deferral in place, except that we are using it at the
moment. And the other hotplug issue is not related this though.

Regards,
 Sricharan


>-----8<-----
>
>diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
>index 349bd1d01612..1f92d98237d5 100644
>--- a/drivers/iommu/of_iommu.c
>+++ b/drivers/iommu/of_iommu.c
>@@ -96,6 +96,19 @@ int of_get_dma_window(struct device_node *dn, const
>char *prefix, int index,
> }
> EXPORT_SYMBOL_GPL(of_get_dma_window);
>
>+static bool of_iommu_driver_present(struct device_node *np)
>+{
>+	/*
>+	 * If the IOMMU still isn't ready by the time we reach init, assume
>+	 * it never will be. We don't want to defer indefinitely, nor attempt
>+	 * to dereference __iommu_of_table after it's been freed.
>+	 */
>+	if (system_state > SYSTEM_BOOTING)
>+		return false;
>+
>+	return of_match_node(&__iommu_of_table, np);
>+}
>+
> static const struct iommu_ops
> *of_iommu_xlate(struct device *dev, struct of_phandle_args *iommu_spec)
> {
>@@ -105,7 +118,7 @@ static const struct iommu_ops
>
> 	ops = iommu_get_instance(fwnode);
> 	if ((ops && !ops->of_xlate) ||
>-	    (!ops && !of_match_node(&__iommu_of_table, iommu_spec->np)))
>+	    (!ops && !of_iommu_driver_present(iommu_spec->np)))
> 		return NULL;
>
> 	err = iommu_fwspec_init(dev, &iommu_spec->np->fwnode, ops);
>--
>To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
>the body of a message to majordomo at vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 03:03:06PM -0500, Sinan Kaya wrote:
> On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> > On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> >> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> >>> On 2017-01-30 09:38, Will Deacon wrote:
> >>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>>>>> On 2017-01-30 08:59, Sinan Kaya wrote:
> >>>>>>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>>>>>>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>>>>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>>>>>>> [+hanjun, tomasz, sinan]
> >>>>>>>>>>
> >>>>>>>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>>>>>>> respective platforms with IORT.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Tested on top of 4.10-rc5.
> >>>>>>>>>
> >>>>>>>>> 1.    Platform Hidma device passed dmatest
> >>>>>>>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>>>>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>>>>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>>>>>>> SMMU error event during the insertion.
> >>>>>>>>
> >>>>>>>> What was the SMMU error - a translation/permission fault (implying the
> >>>>>>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>>>>>>> the SMMU about the device at all)?
> >>>>>>>>
> >>>>>>>
> >>>>>>> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>>>>>>
> >>>>>>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>>>>>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>>>>>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>>>>>> ignored; already powering off
> >>>>>>>
> >>>>>>> root@ubuntu:/sys/bus/pci/slots/4#
> >>>>>>>
> >>>>>>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>>>>>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>>>>>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>>>>>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>>>>>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>>>>>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>
> >>>>>> Looks like C_BAD_CD. Can you please try with:
> >>>>>> iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>>>
> >>>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>>>> this issue again.
> >>>>
> >>>> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >>>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >>>> send the patch to stable after -rc1.
> >>> Using vanilla mainline, I see it most commonly when directly assigning
> >>> a device to a guest machine. I think I've also seen it after removing then
> >>> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> >>> from a non-NULL value and STE[CFG] indicates translation will be performed.
> >>>
> >>
> >> I was not able to reproduce the issue with Vanilla kernel. I only
> >> tested hotplug.
> > 
> > I would like to get the complete code path leading to this issue, it is
> > not clear to me why the probe deferral code triggers it and why we are
> > not able to trigger it with vanilla mainline, we must understand that first
> > before applying any fix to this series.
> > 
> > I do not have a platform to reproduce this issue I will send you a patch
> > to trace what's going on here please help us debug it.
> 
> Sure, send it to both Nate and me.

I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing value), so
it may work or not depending on how the cdptr memory allocation
pattern turns out to be (which explains why Nate and I can hit it with
simple PCI device remove/add execution too).

So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
fix is already queued, so it is all good.

What about USB stalls ?

Thanks !
Lorenzo

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 03:03:06PM -0500, Sinan Kaya wrote:
> On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> > On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> >> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> >>> On 2017-01-30 09:38, Will Deacon wrote:
> >>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>>>>> On 2017-01-30 08:59, Sinan Kaya wrote:
> >>>>>>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>>>>>>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>>>>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>>>>>>> [+hanjun, tomasz, sinan]
> >>>>>>>>>>
> >>>>>>>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>>>>>>> respective platforms with IORT.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Tested on top of 4.10-rc5.
> >>>>>>>>>
> >>>>>>>>> 1.    Platform Hidma device passed dmatest
> >>>>>>>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>>>>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>>>>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>>>>>>> SMMU error event during the insertion.
> >>>>>>>>
> >>>>>>>> What was the SMMU error - a translation/permission fault (implying the
> >>>>>>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>>>>>>> the SMMU about the device at all)?
> >>>>>>>>
> >>>>>>>
> >>>>>>> root@ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>>>>>>
> >>>>>>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>>>>>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>>>>>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>>>>>> ignored; already powering off
> >>>>>>>
> >>>>>>> root@ubuntu:/sys/bus/pci/slots/4#
> >>>>>>>
> >>>>>>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>>>>>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>>>>>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>>>>>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>>>>>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>>>>>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>
> >>>>>> Looks like C_BAD_CD. Can you please try with:
> >>>>>> iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>>>
> >>>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>>>> this issue again.
> >>>>
> >>>> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >>>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >>>> send the patch to stable after -rc1.
> >>> Using vanilla mainline, I see it most commonly when directly assigning
> >>> a device to a guest machine. I think I've also seen it after removing then
> >>> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> >>> from a non-NULL value and STE[CFG] indicates translation will be performed.
> >>>
> >>
> >> I was not able to reproduce the issue with Vanilla kernel. I only
> >> tested hotplug.
> > 
> > I would like to get the complete code path leading to this issue, it is
> > not clear to me why the probe deferral code triggers it and why we are
> > not able to trigger it with vanilla mainline, we must understand that first
> > before applying any fix to this series.
> > 
> > I do not have a platform to reproduce this issue I will send you a patch
> > to trace what's going on here please help us debug it.
> 
> Sure, send it to both Nate and me.

I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing value), so
it may work or not depending on how the cdptr memory allocation
pattern turns out to be (which explains why Nate and I can hit it with
simple PCI device remove/add execution too).

So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
fix is already queued, so it is all good.

What about USB stalls ?

Thanks !
Lorenzo

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Lorenzo Pieralisi]

On Mon, Jan 30, 2017 at 03:03:06PM -0500, Sinan Kaya wrote:
> On 1/30/2017 11:51 AM, Lorenzo Pieralisi wrote:
> > On Mon, Jan 30, 2017 at 10:46:39AM -0500, Sinan Kaya wrote:
> >> On 1/30/2017 9:54 AM, Nate Watterson wrote:
> >>> On 2017-01-30 09:38, Will Deacon wrote:
> >>>> On Mon, Jan 30, 2017 at 09:33:50AM -0500, Sinan Kaya wrote:
> >>>>> On 1/30/2017 9:23 AM, Nate Watterson wrote:
> >>>>>> On 2017-01-30 08:59, Sinan Kaya wrote:
> >>>>>>> On 1/30/2017 7:22 AM, Robin Murphy wrote:
> >>>>>>>> On 29/01/17 17:53, Sinan Kaya wrote:
> >>>>>>>>> On 1/24/2017 7:37 AM, Lorenzo Pieralisi wrote:
> >>>>>>>>>> [+hanjun, tomasz, sinan]
> >>>>>>>>>>
> >>>>>>>>>> It is quite a key patchset, I would be glad if they can test on their
> >>>>>>>>>> respective platforms with IORT.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Tested on top of 4.10-rc5.
> >>>>>>>>>
> >>>>>>>>> 1.    Platform Hidma device passed dmatest
> >>>>>>>>> 2.    Seeing some USB stalls on a platform USB device.
> >>>>>>>>> 3.    PCIe NVME drive probed and worked fine with MSI interrupts after boot.
> >>>>>>>>> 4.     NVMe driver didn't probe following a hotplug insertion and received an
> >>>>>>>>> SMMU error event during the insertion.
> >>>>>>>>
> >>>>>>>> What was the SMMU error - a translation/permission fault (implying the
> >>>>>>>> wrong DMA ops) or a bad STE fault (implying we totally failed to tell
> >>>>>>>> the SMMU about the device at all)?
> >>>>>>>>
> >>>>>>>
> >>>>>>> root at ubuntu:/sys/bus/pci/slots/4# echo 0 > power
> >>>>>>>
> >>>>>>> [__204.698522]_iommu:_Removing_device_0003:01:00.0_from_group_0
> >>>>>>> [  204.708704] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down
> >>>>>>> [  204.708723] pciehp 0003:00:00.0:pcie004: Slot(4): Link Down event
> >>>>>>> ignored; already powering off
> >>>>>>>
> >>>>>>> root at ubuntu:/sys/bus/pci/slots/4#
> >>>>>>>
> >>>>>>> [__254.820440]_iommu:_Adding_device_0003:01:00.0_to_group_8
> >>>>>>> [  254.820599] nvme nvme0: pci function 0003:01:00.0
> >>>>>>> [  254.820621] nvme 0003:01:00.0: enabling device (0000 -> 0002)
> >>>>>>> [  261.948558] arm-smmu-v3 arm-smmu-v3.0.auto: event 0x0a received:
> >>>>>>> [  261.948561] arm-smmu-v3 arm-smmu-v3.0.auto:  0x000001000000000a
> >>>>>>> [  261.948563] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948564] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>>> [  261.948566] arm-smmu-v3 arm-smmu-v3.0.auto:  0x0000000000000000
> >>>>>
> >>>>>> Looks like C_BAD_CD. Can you please try with:
> >>>>>> iommu/arm-smmu-v3: Clear prior settings when updating STEs
> >>>>>
> >>>>> This resolved the issue. Can we pull Nate's patch to 4.10 so that I don't see
> >>>>> this issue again.
> >>>>
> >>>> I already sent the pull request to Joerg for 4.11. Do you see this problem
> >>>> without Sricharan's patches (i.e. vanilla mainline)? If so, we'll need to
> >>>> send the patch to stable after -rc1.
> >>> Using vanilla mainline, I see it most commonly when directly assigning
> >>> a device to a guest machine. I think I've also seen it after removing then
> >>> re-adding a PCI device. Basically anytime an STE's CTX pointer is changed
> >>> from a non-NULL value and STE[CFG] indicates translation will be performed.
> >>>
> >>
> >> I was not able to reproduce the issue with Vanilla kernel. I only
> >> tested hotplug.
> > 
> > I would like to get the complete code path leading to this issue, it is
> > not clear to me why the probe deferral code triggers it and why we are
> > not able to trigger it with vanilla mainline, we must understand that first
> > before applying any fix to this series.
> > 
> > I do not have a platform to reproduce this issue I will send you a patch
> > to trace what's going on here please help us debug it.
> 
> Sure, send it to both Nate and me.

I debugged the issue and Nate's fix is correct, the fact that you
can't it hit it with mainline is just a matter of timing because it has
to do with the CTX pointer value (we OR it with the existing value), so
it may work or not depending on how the cdptr memory allocation
pattern turns out to be (which explains why Nate and I can hit it with
simple PCI device remove/add execution too).

So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
fix is already queued, so it is all good.

What about USB stalls ?

Thanks !
Lorenzo

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 2/1/2017 1:52 PM, Lorenzo Pieralisi wrote:
>> Sure, send it to both Nate and me.
> I debugged the issue and Nate's fix is correct, the fact that you
> can't it hit it with mainline is just a matter of timing because it has
> to do with the CTX pointer value (we OR it with the existing value), so
> it may work or not depending on how the cdptr memory allocation
> pattern turns out to be (which explains why Nate and I can hit it with
> simple PCI device remove/add execution too).
> 
> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
> fix is already queued, so it is all good.
> 
> What about USB stalls ?
> 
> Thanks !
> Lorenzo
> 

I'll get a hold of Nate and debug this. We were waiting for you to send us
debug code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 2/1/2017 1:52 PM, Lorenzo Pieralisi wrote:
>> Sure, send it to both Nate and me.
> I debugged the issue and Nate's fix is correct, the fact that you
> can't it hit it with mainline is just a matter of timing because it has
> to do with the CTX pointer value (we OR it with the existing value), so
> it may work or not depending on how the cdptr memory allocation
> pattern turns out to be (which explains why Nate and I can hit it with
> simple PCI device remove/add execution too).
> 
> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
> fix is already queued, so it is all good.
> 
> What about USB stalls ?
> 
> Thanks !
> Lorenzo
> 

I'll get a hold of Nate and debug this. We were waiting for you to send us
debug code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sinan Kaya]

On 2/1/2017 1:52 PM, Lorenzo Pieralisi wrote:
>> Sure, send it to both Nate and me.
> I debugged the issue and Nate's fix is correct, the fact that you
> can't it hit it with mainline is just a matter of timing because it has
> to do with the CTX pointer value (we OR it with the existing value), so
> it may work or not depending on how the cdptr memory allocation
> pattern turns out to be (which explains why Nate and I can hit it with
> simple PCI device remove/add execution too).
> 
> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
> fix is already queued, so it is all good.
> 
> What about USB stalls ?
> 
> Thanks !
> Lorenzo
> 

I'll get a hold of Nate and debug this. We were waiting for you to send us
debug code.

-- 
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
> 
> I debugged the issue and Nate's fix is correct, the fact that you
> can't it hit it with mainline is just a matter of timing because it has
> to do with the CTX pointer value (we OR it with the existing value), so
> it may work or not depending on how the cdptr memory allocation
> pattern turns out to be (which explains why Nate and I can hit it with
> simple PCI device remove/add execution too).
> 
> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
> fix is already queued, so it is all good.
> 
> What about USB stalls ?
Our fault. The USB controller was getting 48-bit IOVAs, but the
bus it sits on only supports 44-bits so the controller's DMA
transactions ended up targeting addresses that were never mapped.

It started working once I applied the iort/dma-mapping patches I
sent out earlier this week that use the iort memory_address_limit
field to check if a dma_mask is sane.

Sorry for the false alarm.
Nate
> 
> Thanks !
> Lorenzo

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Nate Watterson]

On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
> 
> I debugged the issue and Nate's fix is correct, the fact that you
> can't it hit it with mainline is just a matter of timing because it has
> to do with the CTX pointer value (we OR it with the existing value), so
> it may work or not depending on how the cdptr memory allocation
> pattern turns out to be (which explains why Nate and I can hit it with
> simple PCI device remove/add execution too).
> 
> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
> fix is already queued, so it is all good.
> 
> What about USB stalls ?
Our fault. The USB controller was getting 48-bit IOVAs, but the
bus it sits on only supports 44-bits so the controller's DMA
transactions ended up targeting addresses that were never mapped.

It started working once I applied the iort/dma-mapping patches I
sent out earlier this week that use the iort memory_address_limit
field to check if a dma_mask is sane.

Sorry for the false alarm.
Nate
> 
> Thanks !
> Lorenzo

-- 
Qualcomm Datacenter Technologies, Inc. on behalf of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a 
Linux
Foundation Collaborative Project.

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

On 02/03/2017 03:01 AM, Nate Watterson wrote:
> On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
> Our fault. The USB controller was getting 48-bit IOVAs, but the
> bus it sits on only supports 44-bits so the controller's DMA
> transactions ended up targeting addresses that were never mapped.
>
> It started working once I applied the iort/dma-mapping patches I
> sent out earlier this week that use the iort memory_address_limit
> field to check if a dma_mask is sane.

OK, great, I tested this patch with platform USB device which was
working fine on Hisilicon D03, so I didn't miss anything here.

Thanks
Hanjun

Re: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

On 02/03/2017 03:01 AM, Nate Watterson wrote:
> On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
> Our fault. The USB controller was getting 48-bit IOVAs, but the
> bus it sits on only supports 44-bits so the controller's DMA
> transactions ended up targeting addresses that were never mapped.
>
> It started working once I applied the iort/dma-mapping patches I
> sent out earlier this week that use the iort memory_address_limit
> field to check if a dma_mask is sane.

OK, great, I tested this patch with platform USB device which was
working fine on Hisilicon D03, so I didn't miss anything here.

Thanks
Hanjun

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Hanjun Guo]

On 02/03/2017 03:01 AM, Nate Watterson wrote:
> On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
> Our fault. The USB controller was getting 48-bit IOVAs, but the
> bus it sits on only supports 44-bits so the controller's DMA
> transactions ended up targeting addresses that were never mapped.
>
> It started working once I applied the iort/dma-mapping patches I
> sent out earlier this week that use the iort memory_address_limit
> field to check if a dma_mask is sane.

OK, great, I tested this patch with platform USB device which was
working fine on Hisilicon D03, so I didn't miss anything here.

Thanks
Hanjun

RE: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
>Our fault. The USB controller was getting 48-bit IOVAs, but the
>bus it sits on only supports 44-bits so the controller's DMA
>transactions ended up targeting addresses that were never mapped.
>
>It started working once I applied the iort/dma-mapping patches I
>sent out earlier this week that use the iort memory_address_limit
>field to check if a dma_mask is sane.
>
>Sorry for the false alarm.

Ok, thanks for closing on it. I will just post V8 with all acks picked up and
Robin's fix , right away.

Regards,
 Sricharan

RE: [PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
>Our fault. The USB controller was getting 48-bit IOVAs, but the
>bus it sits on only supports 44-bits so the controller's DMA
>transactions ended up targeting addresses that were never mapped.
>
>It started working once I applied the iort/dma-mapping patches I
>sent out earlier this week that use the iort memory_address_limit
>field to check if a dma_mask is sane.
>
>Sorry for the false alarm.

Ok, thanks for closing on it. I will just post V8 with all acks picked up and
Robin's fix , right away.

Regards,
 Sricharan


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

[PATCH V7 08/11] drivers: acpi: Handle IOMMU lookup failure with deferred probing or error

[Sricharan]

Hi,

>On 2017-02-01 13:52, Lorenzo Pieralisi wrote:
>>
>> I debugged the issue and Nate's fix is correct, the fact that you
>> can't it hit it with mainline is just a matter of timing because it has
>> to do with the CTX pointer value (we OR it with the existing value), so
>> it may work or not depending on how the cdptr memory allocation
>> pattern turns out to be (which explains why Nate and I can hit it with
>> simple PCI device remove/add execution too).
>>
>> So it is neither an ACPI nor an IOMMU probe deferral issue per-se,
>> fix is already queued, so it is all good.
>>
>> What about USB stalls ?
>Our fault. The USB controller was getting 48-bit IOVAs, but the
>bus it sits on only supports 44-bits so the controller's DMA
>transactions ended up targeting addresses that were never mapped.
>
>It started working once I applied the iort/dma-mapping patches I
>sent out earlier this week that use the iort memory_address_limit
>field to check if a dma_mask is sane.
>
>Sorry for the false alarm.

Ok, thanks for closing on it. I will just post V8 with all acks picked up and
Robin's fix , right away.

Regards,
 Sricharan