[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameer Kolothum]

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.

The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
   associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
   associated msi controller base address from for a PCI RC
   msi-mapping and also platform device msi-parent.
3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
   platforms when SMMUv3 is enabled as there is no DT based solution
   for this as of now.

Changelog:

v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS 
 translater region only.
-Removed the DT support for MSI reservation and blacklisted
 HiSilicon PCIe controllers on DT based systems when SMMUv3 is
 enabled.

v7 --> v8
Addressed comments from Rob and Lorenzo:
 -Modified to use DT compatible string for errata.
 -Changed logic to retrieve the msi-parent for DT case.

v6 --> v7
Addressed request from Will to add DT support for the erratum:
 - added bt binding
 - add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions

v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
  is not applicable. Provided a generic function in iommu code and added
  back the quirk implementation in SMMU v3 driver(patch#3)
 
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward 
  HW topologies are handled while reserving ITS regions(patch #1).

v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into 
  iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).

v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
  iort helper function.

v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).

RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.

RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed  the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor specific CSRT table.


Shameer Kolothum (4):
  ACPI/IORT: Add msi address regions reservation helper
  iommu/dma: Add a helper function to reserve HW MSI address regions for
    IOMMU drivers
  iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
 drivers/iommu/dma-iommu.c        | 20 +++++++++
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 drivers/pci/dwc/pcie-hisi.c      | 12 +++++
 include/linux/acpi_iort.h        |  7 ++-
 include/linux/dma-iommu.h        |  7 +++
 7 files changed, 163 insertions(+), 10 deletions(-)

-- 
1.9.1

[Devel] [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameer Kolothum]

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

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.

The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
   associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
   associated msi controller base address from for a PCI RC
   msi-mapping and also platform device msi-parent.
3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
   platforms when SMMUv3 is enabled as there is no DT based solution
   for this as of now.

Changelog:

v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS 
 translater region only.
-Removed the DT support for MSI reservation and blacklisted
 HiSilicon PCIe controllers on DT based systems when SMMUv3 is
 enabled.

v7 --> v8
Addressed comments from Rob and Lorenzo:
 -Modified to use DT compatible string for errata.
 -Changed logic to retrieve the msi-parent for DT case.

v6 --> v7
Addressed request from Will to add DT support for the erratum:
 - added bt binding
 - add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions

v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
  is not applicable. Provided a generic function in iommu code and added
  back the quirk implementation in SMMU v3 driver(patch#3)
 
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward 
  HW topologies are handled while reserving ITS regions(patch #1).

v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into 
  iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).

v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
  iort helper function.

v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).

RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.

RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed  the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor specific CSRT table.


Shameer Kolothum (4):
  ACPI/IORT: Add msi address regions reservation helper
  iommu/dma: Add a helper function to reserve HW MSI address regions for
    IOMMU drivers
  iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
 drivers/iommu/dma-iommu.c        | 20 +++++++++
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 drivers/pci/dwc/pcie-hisi.c      | 12 +++++
 include/linux/acpi_iort.h        |  7 ++-
 include/linux/dma-iommu.h        |  7 +++
 7 files changed, 163 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameer Kolothum]

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.

The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
   associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
   associated msi controller base address from for a PCI RC
   msi-mapping and also platform device msi-parent.
3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
   platforms when SMMUv3 is enabled as there is no DT based solution
   for this as of now.

Changelog:

v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS 
 translater region only.
-Removed the DT support for MSI reservation and blacklisted
 HiSilicon PCIe controllers on DT based systems when SMMUv3 is
 enabled.

v7 --> v8
Addressed comments from Rob and Lorenzo:
 -Modified to use DT compatible string for errata.
 -Changed logic to retrieve the msi-parent for DT case.

v6 --> v7
Addressed request from Will to add DT support for the erratum:
 - added bt binding
 - add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions

v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
  is not applicable. Provided a generic function in iommu code and added
  back the quirk implementation in SMMU v3 driver(patch#3)
 
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward 
  HW topologies are handled while reserving ITS regions(patch #1).

v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into 
  iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).

v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
  iort helper function.

v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).

RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.

RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed  the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor specific CSRT table.


Shameer Kolothum (4):
  ACPI/IORT: Add msi address regions reservation helper
  iommu/dma: Add a helper function to reserve HW MSI address regions for
    IOMMU drivers
  iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
 drivers/iommu/dma-iommu.c        | 20 +++++++++
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 drivers/pci/dwc/pcie-hisi.c      | 12 +++++
 include/linux/acpi_iort.h        |  7 ++-
 include/linux/dma-iommu.h        |  7 +++
 7 files changed, 163 insertions(+), 10 deletions(-)

-- 
1.9.1

[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameer Kolothum]

On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
deviates from the standard implementation and this breaks PCIe MSI
functionality when SMMU is enabled.

The HiSilicon erratum 161010801 describes this limitation of certain
HiSilicon platforms to support the SMMU mappings for MSI transactions.
On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements an ACPI and DT based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

To implement this quirk, the following changes are incorporated:
1. Added a generic helper function to IORT code to retrieve the
   associated ITS base address from a device IORT node.
2. Added a generic helper function to of iommu code to retrieve the
   associated msi controller base address from for a PCI RC
   msi-mapping and also platform device msi-parent.
3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
   platforms when SMMUv3 is enabled as there is no DT based solution
   for this as of now.

Changelog:

v8 --> v9
-Thanks to Marc, fixed IORT helper function to reserve the ITS 
 translater region only.
-Removed the DT support for MSI reservation and blacklisted
 HiSilicon PCIe controllers on DT based systems when SMMUv3 is
 enabled.

v7 --> v8
Addressed comments from Rob and Lorenzo:
 -Modified to use DT compatible string for errata.
 -Changed logic to retrieve the msi-parent for DT case.

v6 --> v7
Addressed request from Will to add DT support for the erratum:
 - added bt binding
 - add of_iommu_msi_get_resv_regions()
New arm64 silicon errata entry
Rename iort_iommu_{its->msi}_get_resv_regions

v5 --> v6
Addressed comments from Robin and Lorenzo:
-No change to patch#1 .
-Reverted v5 patch#2 as this might break the platforms where this quirk
  is not applicable. Provided a generic function in iommu code and added
  back the quirk implementation in SMMU v3 driver(patch#3)
 
v4 --> v5
Addressed comments from Robin and Lorenzo:
-Added a comment to make it clear that, for now, only straightforward 
  HW topologies are handled while reserving ITS regions(patch #1).

v3 --> v4
Rebased on 4.13-rc1.
Addressed comments from Robin, Will and Lorenzo:
-As suggested by Robin, moved the ITS msi reservation into 
  iommu_dma_get_resv_regions().
-Added its_count != resv region failure case(patch #1).

v2 --> v3
Addressed comments from Lorenzo and Robin:
-Removed dev_is_pci() check in smmuV3 driver.
-Don't treat device not having an ITS mapping as an error in
  iort helper function.

v1 --> v2
-patch 2/2: Invoke iort helper fn based on fwnode type(acpi).

RFCv2 -->PATCH
-Incorporated Lorenzo's review comments.

RFC v1 --> RFC v2
Based on Robin's review comments,
-Removed  the generic erratum framework.
-Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor specific CSRT table.


Shameer Kolothum (4):
  ACPI/IORT: Add msi address regions reservation helper
  iommu/dma: Add a helper function to reserve HW MSI address regions for
    IOMMU drivers
  iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
 drivers/iommu/dma-iommu.c        | 20 +++++++++
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 drivers/pci/dwc/pcie-hisi.c      | 12 +++++
 include/linux/acpi_iort.h        |  7 ++-
 include/linux/dma-iommu.h        |  7 +++
 7 files changed, 163 insertions(+), 10 deletions(-)

-- 
1.9.1



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

[PATCH v9 1/4] ACPI/IORT: Add msi address regions reservation helper

[Shameer Kolothum]

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
[lorenzo.pieralisi@arm.com: updated commit log/added comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 include/linux/acpi_iort.h        |  7 ++-
 3 files changed, 102 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..876c0e1 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
 struct iort_its_msi_chip {
 	struct list_head	list;
 	struct fwnode_handle	*fw_node;
+	phys_addr_t		base_addr;
 	u32			translation_id;
 };
 
@@ -136,14 +137,16 @@ typedef acpi_status (*iort_find_node_callback)
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
 /**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
  * @trans_id: ITS ID.
+ * @base: ITS base address.
  * @fw_node: Domain token.
  *
  * Returns: 0 on success, -ENOMEM if no memory when allocating list element
  */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node)
 {
 	struct iort_its_msi_chip *its_msi_chip;
 
@@ -153,6 +156,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
 
 	its_msi_chip->fw_node = fw_node;
 	its_msi_chip->translation_id = trans_id;
+	its_msi_chip->base_addr = base;
 
 	spin_lock(&iort_msi_chip_lock);
 	list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -481,6 +485,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
 	return -ENODEV;
 }
 
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+	struct iort_its_msi_chip *its_msi_chip;
+	bool match = false;
+
+	spin_lock(&iort_msi_chip_lock);
+	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+		if (its_msi_chip->translation_id == its_id) {
+			*base = its_msi_chip->base_addr;
+			match = true;
+			break;
+		}
+	}
+	spin_unlock(&iort_msi_chip_lock);
+
+	return match ? 0 : -ENODEV;
+}
+
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
@@ -639,6 +661,73 @@ int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 
 	return err;
 }
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of reserved regions on success (0 if no associated msi
+ *          regions), appropriate error value otherwise. The ITS interrupt
+ *          translation space(ITS_base + 0x010000) associated with the device
+ *          are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+	struct acpi_iort_its_group *its;
+	struct acpi_iort_node *node, *its_node = NULL;
+	int i, resv = 0;
+
+	node = iort_find_dev_node(dev);
+	if (!node)
+		return -ENODEV;
+
+	/*
+	 * Current logic to reserve ITS regions relies on HW topologies
+	 * where a given PCI or named component maps its IDs to only one
+	 * ITS group; if a PCI or named component can map its IDs to
+	 * different ITS groups through IORT mappings this function has
+	 * to be reworked to ensure we reserve regions for all ITS groups
+	 * a given PCI or named component may map IDs to.
+	 */
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		its_node = iort_node_map_id(node, rid, NULL, IORT_MSI_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			its_node = iort_node_map_platform_id(node, NULL,
+							 IORT_MSI_TYPE, i);
+			if (its_node)
+				break;
+		}
+	}
+
+	if (!its_node)
+		return 0;
+
+	/* Move to ITS specific data */
+	its = (struct acpi_iort_its_group *)its_node->node_data;
+
+	for (i = 0; i < its->its_count; i++) {
+		phys_addr_t base;
+
+		if (!iort_find_its_base(its->identifiers[i], &base)) {
+			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+			struct iommu_resv_region *region;
+
+			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+							 prot, IOMMU_RESV_MSI);
+			if (region) {
+				list_add_tail(&region->list, head);
+				resv++;
+			}
+		}
+	}
+
+	return (resv == its->its_count) ? resv : -ENODEV;
+}
 #else
 static inline
 const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
@@ -646,6 +735,8 @@ const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
 static inline
 int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 { return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..19d1ff6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3197,7 +3197,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
 		return -ENOMEM;
 	}
 
-	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+	err = iort_register_domain_token(its_entry->translation_id, res.start,
+					 dom_handle);
 	if (err) {
 		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
 		       &res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8d3f0bf..182a577 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
 #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node);
 void iort_deregister_domain_token(int trans_id);
 struct fwnode_handle *iort_find_domain_token(int trans_id);
 #ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
 /* IOMMU interface */
 void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
 static inline
 const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
1.9.1

[Devel] [PATCH v9 1/4] ACPI/IORT: Add msi address regions reservation helper

[Shameer Kolothum]

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

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
[lorenzo.pieralisi(a)arm.com: updated commit log/added comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi(a)arm.com>
---
 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 include/linux/acpi_iort.h        |  7 ++-
 3 files changed, 102 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..876c0e1 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
 struct iort_its_msi_chip {
 	struct list_head	list;
 	struct fwnode_handle	*fw_node;
+	phys_addr_t		base_addr;
 	u32			translation_id;
 };
 
@@ -136,14 +137,16 @@ typedef acpi_status (*iort_find_node_callback)
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
 /**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
  * @trans_id: ITS ID.
+ * @base: ITS base address.
  * @fw_node: Domain token.
  *
  * Returns: 0 on success, -ENOMEM if no memory when allocating list element
  */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node)
 {
 	struct iort_its_msi_chip *its_msi_chip;
 
@@ -153,6 +156,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
 
 	its_msi_chip->fw_node = fw_node;
 	its_msi_chip->translation_id = trans_id;
+	its_msi_chip->base_addr = base;
 
 	spin_lock(&iort_msi_chip_lock);
 	list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -481,6 +485,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
 	return -ENODEV;
 }
 
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+	struct iort_its_msi_chip *its_msi_chip;
+	bool match = false;
+
+	spin_lock(&iort_msi_chip_lock);
+	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+		if (its_msi_chip->translation_id == its_id) {
+			*base = its_msi_chip->base_addr;
+			match = true;
+			break;
+		}
+	}
+	spin_unlock(&iort_msi_chip_lock);
+
+	return match ? 0 : -ENODEV;
+}
+
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
@@ -639,6 +661,73 @@ int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 
 	return err;
 }
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of reserved regions on success (0 if no associated msi
+ *          regions), appropriate error value otherwise. The ITS interrupt
+ *          translation space(ITS_base + 0x010000) associated with the device
+ *          are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+	struct acpi_iort_its_group *its;
+	struct acpi_iort_node *node, *its_node = NULL;
+	int i, resv = 0;
+
+	node = iort_find_dev_node(dev);
+	if (!node)
+		return -ENODEV;
+
+	/*
+	 * Current logic to reserve ITS regions relies on HW topologies
+	 * where a given PCI or named component maps its IDs to only one
+	 * ITS group; if a PCI or named component can map its IDs to
+	 * different ITS groups through IORT mappings this function has
+	 * to be reworked to ensure we reserve regions for all ITS groups
+	 * a given PCI or named component may map IDs to.
+	 */
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		its_node = iort_node_map_id(node, rid, NULL, IORT_MSI_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			its_node = iort_node_map_platform_id(node, NULL,
+							 IORT_MSI_TYPE, i);
+			if (its_node)
+				break;
+		}
+	}
+
+	if (!its_node)
+		return 0;
+
+	/* Move to ITS specific data */
+	its = (struct acpi_iort_its_group *)its_node->node_data;
+
+	for (i = 0; i < its->its_count; i++) {
+		phys_addr_t base;
+
+		if (!iort_find_its_base(its->identifiers[i], &base)) {
+			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+			struct iommu_resv_region *region;
+
+			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+							 prot, IOMMU_RESV_MSI);
+			if (region) {
+				list_add_tail(&region->list, head);
+				resv++;
+			}
+		}
+	}
+
+	return (resv == its->its_count) ? resv : -ENODEV;
+}
 #else
 static inline
 const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
@@ -646,6 +735,8 @@ const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
 static inline
 int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 { return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..19d1ff6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3197,7 +3197,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
 		return -ENOMEM;
 	}
 
-	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+	err = iort_register_domain_token(its_entry->translation_id, res.start,
+					 dom_handle);
 	if (err) {
 		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
 		       &res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8d3f0bf..182a577 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
 #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node);
 void iort_deregister_domain_token(int trans_id);
 struct fwnode_handle *iort_find_domain_token(int trans_id);
 #ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
 /* IOMMU interface */
 void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
 static inline
 const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
1.9.1

[PATCH v9 1/4] ACPI/IORT: Add msi address regions reservation helper

[Shameer Kolothum]

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
[lorenzo.pieralisi at arm.com: updated commit log/added comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 include/linux/acpi_iort.h        |  7 ++-
 3 files changed, 102 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..876c0e1 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
 struct iort_its_msi_chip {
 	struct list_head	list;
 	struct fwnode_handle	*fw_node;
+	phys_addr_t		base_addr;
 	u32			translation_id;
 };
 
@@ -136,14 +137,16 @@ typedef acpi_status (*iort_find_node_callback)
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
 /**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
  * @trans_id: ITS ID.
+ * @base: ITS base address.
  * @fw_node: Domain token.
  *
  * Returns: 0 on success, -ENOMEM if no memory when allocating list element
  */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node)
 {
 	struct iort_its_msi_chip *its_msi_chip;
 
@@ -153,6 +156,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
 
 	its_msi_chip->fw_node = fw_node;
 	its_msi_chip->translation_id = trans_id;
+	its_msi_chip->base_addr = base;
 
 	spin_lock(&iort_msi_chip_lock);
 	list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -481,6 +485,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
 	return -ENODEV;
 }
 
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+	struct iort_its_msi_chip *its_msi_chip;
+	bool match = false;
+
+	spin_lock(&iort_msi_chip_lock);
+	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+		if (its_msi_chip->translation_id == its_id) {
+			*base = its_msi_chip->base_addr;
+			match = true;
+			break;
+		}
+	}
+	spin_unlock(&iort_msi_chip_lock);
+
+	return match ? 0 : -ENODEV;
+}
+
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
@@ -639,6 +661,73 @@ int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 
 	return err;
 }
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of reserved regions on success (0 if no associated msi
+ *          regions), appropriate error value otherwise. The ITS interrupt
+ *          translation space(ITS_base + 0x010000) associated with the device
+ *          are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+	struct acpi_iort_its_group *its;
+	struct acpi_iort_node *node, *its_node = NULL;
+	int i, resv = 0;
+
+	node = iort_find_dev_node(dev);
+	if (!node)
+		return -ENODEV;
+
+	/*
+	 * Current logic to reserve ITS regions relies on HW topologies
+	 * where a given PCI or named component maps its IDs to only one
+	 * ITS group; if a PCI or named component can map its IDs to
+	 * different ITS groups through IORT mappings this function has
+	 * to be reworked to ensure we reserve regions for all ITS groups
+	 * a given PCI or named component may map IDs to.
+	 */
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		its_node = iort_node_map_id(node, rid, NULL, IORT_MSI_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			its_node = iort_node_map_platform_id(node, NULL,
+							 IORT_MSI_TYPE, i);
+			if (its_node)
+				break;
+		}
+	}
+
+	if (!its_node)
+		return 0;
+
+	/* Move to ITS specific data */
+	its = (struct acpi_iort_its_group *)its_node->node_data;
+
+	for (i = 0; i < its->its_count; i++) {
+		phys_addr_t base;
+
+		if (!iort_find_its_base(its->identifiers[i], &base)) {
+			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+			struct iommu_resv_region *region;
+
+			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+							 prot, IOMMU_RESV_MSI);
+			if (region) {
+				list_add_tail(&region->list, head);
+				resv++;
+			}
+		}
+	}
+
+	return (resv == its->its_count) ? resv : -ENODEV;
+}
 #else
 static inline
 const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
@@ -646,6 +735,8 @@ const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
 static inline
 int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 { return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..19d1ff6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3197,7 +3197,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
 		return -ENOMEM;
 	}
 
-	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+	err = iort_register_domain_token(its_entry->translation_id, res.start,
+					 dom_handle);
 	if (err) {
 		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
 		       &res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8d3f0bf..182a577 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
 #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node);
 void iort_deregister_domain_token(int trans_id);
 struct fwnode_handle *iort_find_domain_token(int trans_id);
 #ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
 /* IOMMU interface */
 void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
 static inline
 const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
1.9.1

[PATCH v9 1/4] ACPI/IORT: Add msi address regions reservation helper

[Shameer Kolothum]

On some platforms msi parent address regions have to be excluded from
normal IOVA allocation in that they are detected and decoded in a HW
specific way by system components and so they cannot be considered normal
IOVA address space.

Add a helper function that retrieves ITS address regions - the msi
parent - through IORT device <-> ITS mappings and reserves it so that
these regions will not be translated by IOMMU and will be excluded from
IOVA allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
[lorenzo.pieralisi@arm.com: updated commit log/added comments]
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
---
 drivers/acpi/arm64/iort.c        | 97 ++++++++++++++++++++++++++++++++++++++--
 drivers/irqchip/irq-gic-v3-its.c |  3 +-
 include/linux/acpi_iort.h        |  7 ++-
 3 files changed, 102 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 9565d57..876c0e1 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -39,6 +39,7 @@
 struct iort_its_msi_chip {
 	struct list_head	list;
 	struct fwnode_handle	*fw_node;
+	phys_addr_t		base_addr;
 	u32			translation_id;
 };
 
@@ -136,14 +137,16 @@ typedef acpi_status (*iort_find_node_callback)
 static DEFINE_SPINLOCK(iort_msi_chip_lock);
 
 /**
- * iort_register_domain_token() - register domain token and related ITS ID
- * to the list from where we can get it back later on.
+ * iort_register_domain_token() - register domain token along with related
+ * ITS ID and base address to the list from where we can get it back later on.
  * @trans_id: ITS ID.
+ * @base: ITS base address.
  * @fw_node: Domain token.
  *
  * Returns: 0 on success, -ENOMEM if no memory when allocating list element
  */
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node)
 {
 	struct iort_its_msi_chip *its_msi_chip;
 
@@ -153,6 +156,7 @@ int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node)
 
 	its_msi_chip->fw_node = fw_node;
 	its_msi_chip->translation_id = trans_id;
+	its_msi_chip->base_addr = base;
 
 	spin_lock(&iort_msi_chip_lock);
 	list_add(&its_msi_chip->list, &iort_msi_chip_list);
@@ -481,6 +485,24 @@ int iort_pmsi_get_dev_id(struct device *dev, u32 *dev_id)
 	return -ENODEV;
 }
 
+static int __maybe_unused iort_find_its_base(u32 its_id, phys_addr_t *base)
+{
+	struct iort_its_msi_chip *its_msi_chip;
+	bool match = false;
+
+	spin_lock(&iort_msi_chip_lock);
+	list_for_each_entry(its_msi_chip, &iort_msi_chip_list, list) {
+		if (its_msi_chip->translation_id == its_id) {
+			*base = its_msi_chip->base_addr;
+			match = true;
+			break;
+		}
+	}
+	spin_unlock(&iort_msi_chip_lock);
+
+	return match ? 0 : -ENODEV;
+}
+
 /**
  * iort_dev_find_its_id() - Find the ITS identifier for a device
  * @dev: The device.
@@ -639,6 +661,73 @@ int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 
 	return err;
 }
+
+/**
+ * iort_iommu_msi_get_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @head: Reserved region list from iommu_get_resv_regions()
+ *
+ * Returns: Number of reserved regions on success (0 if no associated msi
+ *          regions), appropriate error value otherwise. The ITS interrupt
+ *          translation space(ITS_base + 0x010000) associated with the device
+ *          are the msi reserved regions.
+ */
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{
+	struct acpi_iort_its_group *its;
+	struct acpi_iort_node *node, *its_node = NULL;
+	int i, resv = 0;
+
+	node = iort_find_dev_node(dev);
+	if (!node)
+		return -ENODEV;
+
+	/*
+	 * Current logic to reserve ITS regions relies on HW topologies
+	 * where a given PCI or named component maps its IDs to only one
+	 * ITS group; if a PCI or named component can map its IDs to
+	 * different ITS groups through IORT mappings this function has
+	 * to be reworked to ensure we reserve regions for all ITS groups
+	 * a given PCI or named component may map IDs to.
+	 */
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		its_node = iort_node_map_id(node, rid, NULL, IORT_MSI_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			its_node = iort_node_map_platform_id(node, NULL,
+							 IORT_MSI_TYPE, i);
+			if (its_node)
+				break;
+		}
+	}
+
+	if (!its_node)
+		return 0;
+
+	/* Move to ITS specific data */
+	its = (struct acpi_iort_its_group *)its_node->node_data;
+
+	for (i = 0; i < its->its_count; i++) {
+		phys_addr_t base;
+
+		if (!iort_find_its_base(its->identifiers[i], &base)) {
+			int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+			struct iommu_resv_region *region;
+
+			region = iommu_alloc_resv_region(base + SZ_64K, SZ_64K,
+							 prot, IOMMU_RESV_MSI);
+			if (region) {
+				list_add_tail(&region->list, head);
+				resv++;
+			}
+		}
+	}
+
+	return (resv == its->its_count) ? resv : -ENODEV;
+}
 #else
 static inline
 const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
@@ -646,6 +735,8 @@ const struct iommu_ops *iort_fwspec_iommu_ops(struct iommu_fwspec *fwspec)
 static inline
 int iort_add_device_replay(const struct iommu_ops *ops, struct device *dev)
 { return 0; }
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 static int iort_iommu_xlate(struct device *dev, struct acpi_iort_node *node,
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index e8d8934..19d1ff6 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -3197,7 +3197,8 @@ static int __init gic_acpi_parse_madt_its(struct acpi_subtable_header *header,
 		return -ENOMEM;
 	}
 
-	err = iort_register_domain_token(its_entry->translation_id, dom_handle);
+	err = iort_register_domain_token(its_entry->translation_id, res.start,
+					 dom_handle);
 	if (err) {
 		pr_err("ITS@%pa: Unable to register GICv3 ITS domain token (ITS ID %d) to IORT\n",
 		       &res.start, its_entry->translation_id);
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 8d3f0bf..182a577 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -26,7 +26,8 @@
 #define IORT_IRQ_MASK(irq)		(irq & 0xffffffffULL)
 #define IORT_IRQ_TRIGGER_MASK(irq)	((irq >> 32) & 0xffffffffULL)
 
-int iort_register_domain_token(int trans_id, struct fwnode_handle *fw_node);
+int iort_register_domain_token(int trans_id, phys_addr_t base,
+			       struct fwnode_handle *fw_node);
 void iort_deregister_domain_token(int trans_id);
 struct fwnode_handle *iort_find_domain_token(int trans_id);
 #ifdef CONFIG_ACPI_IORT
@@ -38,6 +39,7 @@
 /* IOMMU interface */
 void iort_dma_setup(struct device *dev, u64 *dma_addr, u64 *size);
 const struct iommu_ops *iort_iommu_configure(struct device *dev);
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head);
 #else
 static inline void acpi_iort_init(void) { }
 static inline u32 iort_msi_map_rid(struct device *dev, u32 req_id)
@@ -52,6 +54,9 @@ static inline void iort_dma_setup(struct device *dev, u64 *dma_addr,
 static inline
 const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
+static inline
+int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
+{ return -ENODEV; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */
-- 
1.9.1

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameer Kolothum]

IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
 include/linux/dma-iommu.h |  7 +++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..bae677e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -27,6 +28,7 @@
 #include <linux/iova.h>
 #include <linux/irq.h>
 #include <linux/mm.h>
+#include <linux/of_iommu.h>
 #include <linux/pci.h>
 #include <linux/scatterlist.h>
 #include <linux/vmalloc.h>
@@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_msi_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @list: Reserved region list from iommu_get_resv_regions()
+ *
+ * IOMMU drivers can use this to implement their .get_resv_regions
+ * callback for HW MSI specific reservations. For now, this only
+ * covers ITS MSI region reservation using ACPI IORT helper function.
+ */
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
+		return iort_iommu_msi_get_resv_regions(dev, list);
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
+
 static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
 		phys_addr_t start, phys_addr_t end)
 {
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 92f2083..6062ef0 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
 void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
+
 #else
 
 struct iommu_domain;
@@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
 {
 }
 
+static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	return -ENODEV;
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __KERNEL__ */
 #endif	/* __DMA_IOMMU_H */
-- 
1.9.1

[Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameer Kolothum]

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

IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
---
 drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
 include/linux/dma-iommu.h |  7 +++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..bae677e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -27,6 +28,7 @@
 #include <linux/iova.h>
 #include <linux/irq.h>
 #include <linux/mm.h>
+#include <linux/of_iommu.h>
 #include <linux/pci.h>
 #include <linux/scatterlist.h>
 #include <linux/vmalloc.h>
@@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_msi_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @list: Reserved region list from iommu_get_resv_regions()
+ *
+ * IOMMU drivers can use this to implement their .get_resv_regions
+ * callback for HW MSI specific reservations. For now, this only
+ * covers ITS MSI region reservation using ACPI IORT helper function.
+ */
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
+		return iort_iommu_msi_get_resv_regions(dev, list);
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
+
 static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
 		phys_addr_t start, phys_addr_t end)
 {
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 92f2083..6062ef0 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
 void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
+
 #else
 
 struct iommu_domain;
@@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
 {
 }
 
+static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	return -ENODEV;
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __KERNEL__ */
 #endif	/* __DMA_IOMMU_H */
-- 
1.9.1

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameer Kolothum]

IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
 include/linux/dma-iommu.h |  7 +++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..bae677e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -27,6 +28,7 @@
 #include <linux/iova.h>
 #include <linux/irq.h>
 #include <linux/mm.h>
+#include <linux/of_iommu.h>
 #include <linux/pci.h>
 #include <linux/scatterlist.h>
 #include <linux/vmalloc.h>
@@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_msi_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @list: Reserved region list from iommu_get_resv_regions()
+ *
+ * IOMMU drivers can use this to implement their .get_resv_regions
+ * callback for HW MSI specific reservations. For now, this only
+ * covers ITS MSI region reservation using ACPI IORT helper function.
+ */
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
+		return iort_iommu_msi_get_resv_regions(dev, list);
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
+
 static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
 		phys_addr_t start, phys_addr_t end)
 {
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 92f2083..6062ef0 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
 void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
+
 #else
 
 struct iommu_domain;
@@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
 {
 }
 
+static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	return -ENODEV;
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __KERNEL__ */
 #endif	/* __DMA_IOMMU_H */
-- 
1.9.1

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameer Kolothum]

IOMMU drivers can use this to implement their .get_resv_regions callback
for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
 include/linux/dma-iommu.h |  7 +++++++
 2 files changed, 27 insertions(+)

diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..bae677e 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -27,6 +28,7 @@
 #include <linux/iova.h>
 #include <linux/irq.h>
 #include <linux/mm.h>
+#include <linux/of_iommu.h>
 #include <linux/pci.h>
 #include <linux/scatterlist.h>
 #include <linux/vmalloc.h>
@@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 }
 EXPORT_SYMBOL(iommu_dma_get_resv_regions);
 
+/**
+ * iommu_dma_get_msi_resv_regions - Reserved region driver helper
+ * @dev: Device from iommu_get_resv_regions()
+ * @list: Reserved region list from iommu_get_resv_regions()
+ *
+ * IOMMU drivers can use this to implement their .get_resv_regions
+ * callback for HW MSI specific reservations. For now, this only
+ * covers ITS MSI region reservation using ACPI IORT helper function.
+ */
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
+		return iort_iommu_msi_get_resv_regions(dev, list);
+
+	return -ENODEV;
+}
+EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
+
 static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
 		phys_addr_t start, phys_addr_t end)
 {
diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
index 92f2083..6062ef0 100644
--- a/include/linux/dma-iommu.h
+++ b/include/linux/dma-iommu.h
@@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
 void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
 void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
 
+int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
+
 #else
 
 struct iommu_domain;
@@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
 {
 }
 
+static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
+{
+	return -ENODEV;
+}
+
 #endif	/* CONFIG_IOMMU_DMA */
 #endif	/* __KERNEL__ */
 #endif	/* __DMA_IOMMU_H */
-- 
1.9.1

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> IOMMU drivers can use this to implement their .get_resv_regions callback
> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>  include/linux/dma-iommu.h |  7 +++++++
>  2 files changed, 27 insertions(+)

I'd like to see Robin's Ack on this, because this is his code and he had
ideas on ways to solve this problem properly.

Will

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..bae677e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -27,6 +28,7 @@
>  #include <linux/iova.h>
>  #include <linux/irq.h>
>  #include <linux/mm.h>
> +#include <linux/of_iommu.h>
>  #include <linux/pci.h>
>  #include <linux/scatterlist.h>
>  #include <linux/vmalloc.h>
> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  }
>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>  
> +/**
> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @list: Reserved region list from iommu_get_resv_regions()
> + *
> + * IOMMU drivers can use this to implement their .get_resv_regions
> + * callback for HW MSI specific reservations. For now, this only
> + * covers ITS MSI region reservation using ACPI IORT helper function.
> + */
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> +		return iort_iommu_msi_get_resv_regions(dev, list);
> +
> +	return -ENODEV;
> +}
> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> +
>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>  		phys_addr_t start, phys_addr_t end)
>  {
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 92f2083..6062ef0 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
>  
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
> +
>  #else
>  
>  struct iommu_domain;
> @@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
>  {
>  }
>  
> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	return -ENODEV;
> +}
> +
>  #endif	/* CONFIG_IOMMU_DMA */
>  #endif	/* __KERNEL__ */
>  #endif	/* __DMA_IOMMU_H */
> -- 
> 1.9.1
> 
> 

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Will Deacon]

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

On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> IOMMU drivers can use this to implement their .get_resv_regions callback
> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
> ---
>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>  include/linux/dma-iommu.h |  7 +++++++
>  2 files changed, 27 insertions(+)

I'd like to see Robin's Ack on this, because this is his code and he had
ideas on ways to solve this problem properly.

Will

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..bae677e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -27,6 +28,7 @@
>  #include <linux/iova.h>
>  #include <linux/irq.h>
>  #include <linux/mm.h>
> +#include <linux/of_iommu.h>
>  #include <linux/pci.h>
>  #include <linux/scatterlist.h>
>  #include <linux/vmalloc.h>
> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  }
>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>  
> +/**
> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @list: Reserved region list from iommu_get_resv_regions()
> + *
> + * IOMMU drivers can use this to implement their .get_resv_regions
> + * callback for HW MSI specific reservations. For now, this only
> + * covers ITS MSI region reservation using ACPI IORT helper function.
> + */
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> +		return iort_iommu_msi_get_resv_regions(dev, list);
> +
> +	return -ENODEV;
> +}
> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> +
>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>  		phys_addr_t start, phys_addr_t end)
>  {
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 92f2083..6062ef0 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
>  
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
> +
>  #else
>  
>  struct iommu_domain;
> @@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
>  {
>  }
>  
> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	return -ENODEV;
> +}
> +
>  #endif	/* CONFIG_IOMMU_DMA */
>  #endif	/* __KERNEL__ */
>  #endif	/* __DMA_IOMMU_H */
> -- 
> 1.9.1
> 
> 

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> IOMMU drivers can use this to implement their .get_resv_regions callback
> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>  include/linux/dma-iommu.h |  7 +++++++
>  2 files changed, 27 insertions(+)

I'd like to see Robin's Ack on this, because this is his code and he had
ideas on ways to solve this problem properly.

Will

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..bae677e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -27,6 +28,7 @@
>  #include <linux/iova.h>
>  #include <linux/irq.h>
>  #include <linux/mm.h>
> +#include <linux/of_iommu.h>
>  #include <linux/pci.h>
>  #include <linux/scatterlist.h>
>  #include <linux/vmalloc.h>
> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  }
>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>  
> +/**
> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @list: Reserved region list from iommu_get_resv_regions()
> + *
> + * IOMMU drivers can use this to implement their .get_resv_regions
> + * callback for HW MSI specific reservations. For now, this only
> + * covers ITS MSI region reservation using ACPI IORT helper function.
> + */
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> +		return iort_iommu_msi_get_resv_regions(dev, list);
> +
> +	return -ENODEV;
> +}
> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> +
>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>  		phys_addr_t start, phys_addr_t end)
>  {
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 92f2083..6062ef0 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
>  
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
> +
>  #else
>  
>  struct iommu_domain;
> @@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
>  {
>  }
>  
> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	return -ENODEV;
> +}
> +
>  #endif	/* CONFIG_IOMMU_DMA */
>  #endif	/* __KERNEL__ */
>  #endif	/* __DMA_IOMMU_H */
> -- 
> 1.9.1
> 
> 

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> IOMMU drivers can use this to implement their .get_resv_regions callback
> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>  include/linux/dma-iommu.h |  7 +++++++
>  2 files changed, 27 insertions(+)

I'd like to see Robin's Ack on this, because this is his code and he had
ideas on ways to solve this problem properly.

Will

> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..bae677e 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -27,6 +28,7 @@
>  #include <linux/iova.h>
>  #include <linux/irq.h>
>  #include <linux/mm.h>
> +#include <linux/of_iommu.h>
>  #include <linux/pci.h>
>  #include <linux/scatterlist.h>
>  #include <linux/vmalloc.h>
> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  }
>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>  
> +/**
> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> + * @dev: Device from iommu_get_resv_regions()
> + * @list: Reserved region list from iommu_get_resv_regions()
> + *
> + * IOMMU drivers can use this to implement their .get_resv_regions
> + * callback for HW MSI specific reservations. For now, this only
> + * covers ITS MSI region reservation using ACPI IORT helper function.
> + */
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> +		return iort_iommu_msi_get_resv_regions(dev, list);
> +
> +	return -ENODEV;
> +}
> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> +
>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>  		phys_addr_t start, phys_addr_t end)
>  {
> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> index 92f2083..6062ef0 100644
> --- a/include/linux/dma-iommu.h
> +++ b/include/linux/dma-iommu.h
> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev, dma_addr_t handle,
>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list);
>  
> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list);
> +
>  #else
>  
>  struct iommu_domain;
> @@ -107,6 +109,11 @@ static inline void iommu_dma_get_resv_regions(struct device *dev, struct list_he
>  {
>  }
>  
> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head *list)
> +{
> +	return -ENODEV;
> +}
> +
>  #endif	/* CONFIG_IOMMU_DMA */
>  #endif	/* __KERNEL__ */
>  #endif	/* __DMA_IOMMU_H */
> -- 
> 1.9.1
> 
> 

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

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

Hi Robin,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Friday, October 13, 2017 8:24 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > IOMMU drivers can use this to implement their .get_resv_regions callback
> > for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > ---
> >  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >  include/linux/dma-iommu.h |  7 +++++++
> >  2 files changed, 27 insertions(+)
> 
> I'd like to see Robin's Ack on this, because this is his code and he had
> ideas on ways to solve this problem properly.

Please let us know if it is ok to go ahead with ACPI support for now.
It will help our customers to start using pass-through for PCIe.

Thanks,
Shameer

> 
> Will
> 
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..bae677e 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -27,6 +28,7 @@
> >  #include <linux/iova.h>
> >  #include <linux/irq.h>
> >  #include <linux/mm.h>
> > +#include <linux/of_iommu.h>
> >  #include <linux/pci.h>
> >  #include <linux/scatterlist.h>
> >  #include <linux/vmalloc.h>
> > @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  }
> >  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >
> > +/**
> > + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > + * @dev: Device from iommu_get_resv_regions()
> > + * @list: Reserved region list from iommu_get_resv_regions()
> > + *
> > + * IOMMU drivers can use this to implement their .get_resv_regions
> > + * callback for HW MSI specific reservations. For now, this only
> > + * covers ITS MSI region reservation using ACPI IORT helper function.
> > + */
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list)
> > +{
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > +		return iort_iommu_msi_get_resv_regions(dev, list);
> > +
> > +	return -ENODEV;
> > +}
> > +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> > +
> >  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
> >  		phys_addr_t start, phys_addr_t end)
> >  {
> > diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> > index 92f2083..6062ef0 100644
> > --- a/include/linux/dma-iommu.h
> > +++ b/include/linux/dma-iommu.h
> > @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
> dma_addr_t handle,
> >  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> >  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
> *list);
> >
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list);
> > +
> >  #else
> >
> >  struct iommu_domain;
> > @@ -107,6 +109,11 @@ static inline void
> iommu_dma_get_resv_regions(struct device *dev, struct list_he
> >  {
> >  }
> >
> > +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
> struct list_head *list)
> > +{
> > +	return -ENODEV;
> > +}
> > +
> >  #endif	/* CONFIG_IOMMU_DMA */
> >  #endif	/* __KERNEL__ */
> >  #endif	/* __DMA_IOMMU_H */
> > --
> > 1.9.1
> >
> >

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

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

Hi Robin,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon(a)arm.com]
> Sent: Friday, October 13, 2017 8:24 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > IOMMU drivers can use this to implement their .get_resv_regions callback
> > for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
> > ---
> >  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >  include/linux/dma-iommu.h |  7 +++++++
> >  2 files changed, 27 insertions(+)
> 
> I'd like to see Robin's Ack on this, because this is his code and he had
> ideas on ways to solve this problem properly.

Please let us know if it is ok to go ahead with ACPI support for now.
It will help our customers to start using pass-through for PCIe.

Thanks,
Shameer

> 
> Will
> 
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..bae677e 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -27,6 +28,7 @@
> >  #include <linux/iova.h>
> >  #include <linux/irq.h>
> >  #include <linux/mm.h>
> > +#include <linux/of_iommu.h>
> >  #include <linux/pci.h>
> >  #include <linux/scatterlist.h>
> >  #include <linux/vmalloc.h>
> > @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  }
> >  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >
> > +/**
> > + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > + * @dev: Device from iommu_get_resv_regions()
> > + * @list: Reserved region list from iommu_get_resv_regions()
> > + *
> > + * IOMMU drivers can use this to implement their .get_resv_regions
> > + * callback for HW MSI specific reservations. For now, this only
> > + * covers ITS MSI region reservation using ACPI IORT helper function.
> > + */
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list)
> > +{
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > +		return iort_iommu_msi_get_resv_regions(dev, list);
> > +
> > +	return -ENODEV;
> > +}
> > +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> > +
> >  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
> >  		phys_addr_t start, phys_addr_t end)
> >  {
> > diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> > index 92f2083..6062ef0 100644
> > --- a/include/linux/dma-iommu.h
> > +++ b/include/linux/dma-iommu.h
> > @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
> dma_addr_t handle,
> >  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> >  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
> *list);
> >
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list);
> > +
> >  #else
> >
> >  struct iommu_domain;
> > @@ -107,6 +109,11 @@ static inline void
> iommu_dma_get_resv_regions(struct device *dev, struct list_he
> >  {
> >  }
> >
> > +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
> struct list_head *list)
> > +{
> > +	return -ENODEV;
> > +}
> > +
> >  #endif	/* CONFIG_IOMMU_DMA */
> >  #endif	/* __KERNEL__ */
> >  #endif	/* __DMA_IOMMU_H */
> > --
> > 1.9.1
> >
> >

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

Hi Robin,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Friday, October 13, 2017 8:24 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > IOMMU drivers can use this to implement their .get_resv_regions callback
> > for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > ---
> >  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >  include/linux/dma-iommu.h |  7 +++++++
> >  2 files changed, 27 insertions(+)
> 
> I'd like to see Robin's Ack on this, because this is his code and he had
> ideas on ways to solve this problem properly.

Please let us know if it is ok to go ahead with ACPI support for now.
It will help our customers to start using pass-through for PCIe.

Thanks,
Shameer

> 
> Will
> 
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..bae677e 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -27,6 +28,7 @@
> >  #include <linux/iova.h>
> >  #include <linux/irq.h>
> >  #include <linux/mm.h>
> > +#include <linux/of_iommu.h>
> >  #include <linux/pci.h>
> >  #include <linux/scatterlist.h>
> >  #include <linux/vmalloc.h>
> > @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  }
> >  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >
> > +/**
> > + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > + * @dev: Device from iommu_get_resv_regions()
> > + * @list: Reserved region list from iommu_get_resv_regions()
> > + *
> > + * IOMMU drivers can use this to implement their .get_resv_regions
> > + * callback for HW MSI specific reservations. For now, this only
> > + * covers ITS MSI region reservation using ACPI IORT helper function.
> > + */
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list)
> > +{
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > +		return iort_iommu_msi_get_resv_regions(dev, list);
> > +
> > +	return -ENODEV;
> > +}
> > +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> > +
> >  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
> >  		phys_addr_t start, phys_addr_t end)
> >  {
> > diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> > index 92f2083..6062ef0 100644
> > --- a/include/linux/dma-iommu.h
> > +++ b/include/linux/dma-iommu.h
> > @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
> dma_addr_t handle,
> >  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> >  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
> *list);
> >
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list);
> > +
> >  #else
> >
> >  struct iommu_domain;
> > @@ -107,6 +109,11 @@ static inline void
> iommu_dma_get_resv_regions(struct device *dev, struct list_he
> >  {
> >  }
> >
> > +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
> struct list_head *list)
> > +{
> > +	return -ENODEV;
> > +}
> > +
> >  #endif	/* CONFIG_IOMMU_DMA */
> >  #endif	/* __KERNEL__ */
> >  #endif	/* __DMA_IOMMU_H */
> > --
> > 1.9.1
> >
> >

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

Hi Robin,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Friday, October 13, 2017 8:24 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > IOMMU drivers can use this to implement their .get_resv_regions callback
> > for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> > ---
> >  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >  include/linux/dma-iommu.h |  7 +++++++
> >  2 files changed, 27 insertions(+)
> 
> I'd like to see Robin's Ack on this, because this is his code and he had
> ideas on ways to solve this problem properly.

Please let us know if it is ok to go ahead with ACPI support for now.
It will help our customers to start using pass-through for PCIe.

Thanks,
Shameer

> 
> Will
> 
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..bae677e 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -27,6 +28,7 @@
> >  #include <linux/iova.h>
> >  #include <linux/irq.h>
> >  #include <linux/mm.h>
> > +#include <linux/of_iommu.h>
> >  #include <linux/pci.h>
> >  #include <linux/scatterlist.h>
> >  #include <linux/vmalloc.h>
> > @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  }
> >  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >
> > +/**
> > + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > + * @dev: Device from iommu_get_resv_regions()
> > + * @list: Reserved region list from iommu_get_resv_regions()
> > + *
> > + * IOMMU drivers can use this to implement their .get_resv_regions
> > + * callback for HW MSI specific reservations. For now, this only
> > + * covers ITS MSI region reservation using ACPI IORT helper function.
> > + */
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list)
> > +{
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > +		return iort_iommu_msi_get_resv_regions(dev, list);
> > +
> > +	return -ENODEV;
> > +}
> > +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
> > +
> >  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
> >  		phys_addr_t start, phys_addr_t end)
> >  {
> > diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
> > index 92f2083..6062ef0 100644
> > --- a/include/linux/dma-iommu.h
> > +++ b/include/linux/dma-iommu.h
> > @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
> dma_addr_t handle,
> >  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
> >  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
> *list);
> >
> > +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
> *list);
> > +
> >  #else
> >
> >  struct iommu_domain;
> > @@ -107,6 +109,11 @@ static inline void
> iommu_dma_get_resv_regions(struct device *dev, struct list_he
> >  {
> >  }
> >
> > +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
> struct list_head *list)
> > +{
> > +	return -ENODEV;
> > +}
> > +
> >  #endif	/* CONFIG_IOMMU_DMA */
> >  #endif	/* __KERNEL__ */
> >  #endif	/* __DMA_IOMMU_H */
> > --
> > 1.9.1
> >
> >

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

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Robin Murphy]

On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> Hi Robin,
> 
>> -----Original Message-----
>> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
>> Sent: Friday, October 13, 2017 8:24 PM
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
>> sudeep.holla-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
>> bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
>> John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
>> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
>> pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
>> Wangzhou (B) <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
>> <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
>> MSI address regions for IOMMU drivers
>>
>> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
>>> IOMMU drivers can use this to implement their .get_resv_regions callback
>>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
>>>
>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
>>> ---
>>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>>>  include/linux/dma-iommu.h |  7 +++++++
>>>  2 files changed, 27 insertions(+)
>>
>> I'd like to see Robin's Ack on this, because this is his code and he had
>> ideas on ways to solve this problem properly.
> 
> Please let us know if it is ok to go ahead with ACPI support for now.
> It will help our customers to start using pass-through for PCIe.
> 
> Thanks,
> Shameer
> 
>>
>> Will
>>
>>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>>> index 9d1cebe..bae677e 100644
>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
>>> @@ -19,6 +19,7 @@
>>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>   */
>>>
>>> +#include <linux/acpi_iort.h>
>>>  #include <linux/device.h>
>>>  #include <linux/dma-iommu.h>
>>>  #include <linux/gfp.h>
>>> @@ -27,6 +28,7 @@
>>>  #include <linux/iova.h>
>>>  #include <linux/irq.h>
>>>  #include <linux/mm.h>
>>> +#include <linux/of_iommu.h>
>>>  #include <linux/pci.h>
>>>  #include <linux/scatterlist.h>
>>>  #include <linux/vmalloc.h>
>>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
>> *dev, struct list_head *list)
>>>  }
>>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>>>
>>> +/**
>>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
>>> + * @dev: Device from iommu_get_resv_regions()
>>> + * @list: Reserved region list from iommu_get_resv_regions()
>>> + *
>>> + * IOMMU drivers can use this to implement their .get_resv_regions
>>> + * callback for HW MSI specific reservations. For now, this only

This doesn't make an awful lot of sense - there's only one reserved
region callback, so iommu-dma shouldn't be offering two separate and
non-overlapping implementations.

>>> + * covers ITS MSI region reservation using ACPI IORT helper function.
>>> + */
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list)
>>> +{
>>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
>>> +		return iort_iommu_msi_get_resv_regions(dev, list);

Either this call knows how to do the right thing for any platform and
should be made from iommu_dma_get_reserved_regions() directly, or it's
tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
iommu-dma doesn't need to know - the middle ground presented here is
surely the worst of both worlds.

Robin.

>>> +
>>> +	return -ENODEV;
>>> +}
>>> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
>>> +
>>>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>>>  		phys_addr_t start, phys_addr_t end)
>>>  {
>>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>>> index 92f2083..6062ef0 100644
>>> --- a/include/linux/dma-iommu.h
>>> +++ b/include/linux/dma-iommu.h
>>> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
>> dma_addr_t handle,
>>>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
>> *list);
>>>
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list);
>>> +
>>>  #else
>>>
>>>  struct iommu_domain;
>>> @@ -107,6 +109,11 @@ static inline void
>> iommu_dma_get_resv_regions(struct device *dev, struct list_he
>>>  {
>>>  }
>>>
>>> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
>> struct list_head *list)
>>> +{
>>> +	return -ENODEV;
>>> +}
>>> +
>>>  #endif	/* CONFIG_IOMMU_DMA */
>>>  #endif	/* __KERNEL__ */
>>>  #endif	/* __DMA_IOMMU_H */
>>> --
>>> 1.9.1
>>>
>>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Robin Murphy]

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

On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> Hi Robin,
> 
>> -----Original Message-----
>> From: Will Deacon [mailto:will.deacon(a)arm.com]
>> Sent: Friday, October 13, 2017 8:24 PM
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
>> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
>> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
>> bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
>> John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
>> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
>> pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
>> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
>> <guohanjun(a)huawei.com>
>> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
>> MSI address regions for IOMMU drivers
>>
>> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
>>> IOMMU drivers can use this to implement their .get_resv_regions callback
>>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
>>>
>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
>>> ---
>>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>>>  include/linux/dma-iommu.h |  7 +++++++
>>>  2 files changed, 27 insertions(+)
>>
>> I'd like to see Robin's Ack on this, because this is his code and he had
>> ideas on ways to solve this problem properly.
> 
> Please let us know if it is ok to go ahead with ACPI support for now.
> It will help our customers to start using pass-through for PCIe.
> 
> Thanks,
> Shameer
> 
>>
>> Will
>>
>>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>>> index 9d1cebe..bae677e 100644
>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
>>> @@ -19,6 +19,7 @@
>>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>   */
>>>
>>> +#include <linux/acpi_iort.h>
>>>  #include <linux/device.h>
>>>  #include <linux/dma-iommu.h>
>>>  #include <linux/gfp.h>
>>> @@ -27,6 +28,7 @@
>>>  #include <linux/iova.h>
>>>  #include <linux/irq.h>
>>>  #include <linux/mm.h>
>>> +#include <linux/of_iommu.h>
>>>  #include <linux/pci.h>
>>>  #include <linux/scatterlist.h>
>>>  #include <linux/vmalloc.h>
>>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
>> *dev, struct list_head *list)
>>>  }
>>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>>>
>>> +/**
>>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
>>> + * @dev: Device from iommu_get_resv_regions()
>>> + * @list: Reserved region list from iommu_get_resv_regions()
>>> + *
>>> + * IOMMU drivers can use this to implement their .get_resv_regions
>>> + * callback for HW MSI specific reservations. For now, this only

This doesn't make an awful lot of sense - there's only one reserved
region callback, so iommu-dma shouldn't be offering two separate and
non-overlapping implementations.

>>> + * covers ITS MSI region reservation using ACPI IORT helper function.
>>> + */
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list)
>>> +{
>>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
>>> +		return iort_iommu_msi_get_resv_regions(dev, list);

Either this call knows how to do the right thing for any platform and
should be made from iommu_dma_get_reserved_regions() directly, or it's
tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
iommu-dma doesn't need to know - the middle ground presented here is
surely the worst of both worlds.

Robin.

>>> +
>>> +	return -ENODEV;
>>> +}
>>> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
>>> +
>>>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>>>  		phys_addr_t start, phys_addr_t end)
>>>  {
>>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>>> index 92f2083..6062ef0 100644
>>> --- a/include/linux/dma-iommu.h
>>> +++ b/include/linux/dma-iommu.h
>>> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
>> dma_addr_t handle,
>>>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
>> *list);
>>>
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list);
>>> +
>>>  #else
>>>
>>>  struct iommu_domain;
>>> @@ -107,6 +109,11 @@ static inline void
>> iommu_dma_get_resv_regions(struct device *dev, struct list_he
>>>  {
>>>  }
>>>
>>> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
>> struct list_head *list)
>>> +{
>>> +	return -ENODEV;
>>> +}
>>> +
>>>  #endif	/* CONFIG_IOMMU_DMA */
>>>  #endif	/* __KERNEL__ */
>>>  #endif	/* __DMA_IOMMU_H */
>>> --
>>> 1.9.1
>>>
>>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Robin Murphy]

On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> Hi Robin,
> 
>> -----Original Message-----
>> From: Will Deacon [mailto:will.deacon at arm.com]
>> Sent: Friday, October 13, 2017 8:24 PM
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
>> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
>> bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
>> John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
>> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
>> pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
>> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
>> <guohanjun@huawei.com>
>> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
>> MSI address regions for IOMMU drivers
>>
>> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
>>> IOMMU drivers can use this to implement their .get_resv_regions callback
>>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
>>>
>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>>> ---
>>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>>>  include/linux/dma-iommu.h |  7 +++++++
>>>  2 files changed, 27 insertions(+)
>>
>> I'd like to see Robin's Ack on this, because this is his code and he had
>> ideas on ways to solve this problem properly.
> 
> Please let us know if it is ok to go ahead with ACPI support for now.
> It will help our customers to start using pass-through for PCIe.
> 
> Thanks,
> Shameer
> 
>>
>> Will
>>
>>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>>> index 9d1cebe..bae677e 100644
>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
>>> @@ -19,6 +19,7 @@
>>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>   */
>>>
>>> +#include <linux/acpi_iort.h>
>>>  #include <linux/device.h>
>>>  #include <linux/dma-iommu.h>
>>>  #include <linux/gfp.h>
>>> @@ -27,6 +28,7 @@
>>>  #include <linux/iova.h>
>>>  #include <linux/irq.h>
>>>  #include <linux/mm.h>
>>> +#include <linux/of_iommu.h>
>>>  #include <linux/pci.h>
>>>  #include <linux/scatterlist.h>
>>>  #include <linux/vmalloc.h>
>>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
>> *dev, struct list_head *list)
>>>  }
>>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>>>
>>> +/**
>>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
>>> + * @dev: Device from iommu_get_resv_regions()
>>> + * @list: Reserved region list from iommu_get_resv_regions()
>>> + *
>>> + * IOMMU drivers can use this to implement their .get_resv_regions
>>> + * callback for HW MSI specific reservations. For now, this only

This doesn't make an awful lot of sense - there's only one reserved
region callback, so iommu-dma shouldn't be offering two separate and
non-overlapping implementations.

>>> + * covers ITS MSI region reservation using ACPI IORT helper function.
>>> + */
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list)
>>> +{
>>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
>>> +		return iort_iommu_msi_get_resv_regions(dev, list);

Either this call knows how to do the right thing for any platform and
should be made from iommu_dma_get_reserved_regions() directly, or it's
tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
iommu-dma doesn't need to know - the middle ground presented here is
surely the worst of both worlds.

Robin.

>>> +
>>> +	return -ENODEV;
>>> +}
>>> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
>>> +
>>>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>>>  		phys_addr_t start, phys_addr_t end)
>>>  {
>>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>>> index 92f2083..6062ef0 100644
>>> --- a/include/linux/dma-iommu.h
>>> +++ b/include/linux/dma-iommu.h
>>> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
>> dma_addr_t handle,
>>>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
>> *list);
>>>
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list);
>>> +
>>>  #else
>>>
>>>  struct iommu_domain;
>>> @@ -107,6 +109,11 @@ static inline void
>> iommu_dma_get_resv_regions(struct device *dev, struct list_he
>>>  {
>>>  }
>>>
>>> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
>> struct list_head *list)
>>> +{
>>> +	return -ENODEV;
>>> +}
>>> +
>>>  #endif	/* CONFIG_IOMMU_DMA */
>>>  #endif	/* __KERNEL__ */
>>>  #endif	/* __DMA_IOMMU_H */
>>> --
>>> 1.9.1
>>>
>>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Robin Murphy]

On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> Hi Robin,
> 
>> -----Original Message-----
>> From: Will Deacon [mailto:will.deacon@arm.com]
>> Sent: Friday, October 13, 2017 8:24 PM
>> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
>> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
>> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
>> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
>> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
>> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
>> pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
>> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
>> <guohanjun@huawei.com>
>> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
>> MSI address regions for IOMMU drivers
>>
>> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
>>> IOMMU drivers can use this to implement their .get_resv_regions callback
>>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
>>>
>>> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
>>> ---
>>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
>>>  include/linux/dma-iommu.h |  7 +++++++
>>>  2 files changed, 27 insertions(+)
>>
>> I'd like to see Robin's Ack on this, because this is his code and he had
>> ideas on ways to solve this problem properly.
> 
> Please let us know if it is ok to go ahead with ACPI support for now.
> It will help our customers to start using pass-through for PCIe.
> 
> Thanks,
> Shameer
> 
>>
>> Will
>>
>>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>>> index 9d1cebe..bae677e 100644
>>> --- a/drivers/iommu/dma-iommu.c
>>> +++ b/drivers/iommu/dma-iommu.c
>>> @@ -19,6 +19,7 @@
>>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>>>   */
>>>
>>> +#include <linux/acpi_iort.h>
>>>  #include <linux/device.h>
>>>  #include <linux/dma-iommu.h>
>>>  #include <linux/gfp.h>
>>> @@ -27,6 +28,7 @@
>>>  #include <linux/iova.h>
>>>  #include <linux/irq.h>
>>>  #include <linux/mm.h>
>>> +#include <linux/of_iommu.h>
>>>  #include <linux/pci.h>
>>>  #include <linux/scatterlist.h>
>>>  #include <linux/vmalloc.h>
>>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
>> *dev, struct list_head *list)
>>>  }
>>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
>>>
>>> +/**
>>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
>>> + * @dev: Device from iommu_get_resv_regions()
>>> + * @list: Reserved region list from iommu_get_resv_regions()
>>> + *
>>> + * IOMMU drivers can use this to implement their .get_resv_regions
>>> + * callback for HW MSI specific reservations. For now, this only

This doesn't make an awful lot of sense - there's only one reserved
region callback, so iommu-dma shouldn't be offering two separate and
non-overlapping implementations.

>>> + * covers ITS MSI region reservation using ACPI IORT helper function.
>>> + */
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list)
>>> +{
>>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
>>> +		return iort_iommu_msi_get_resv_regions(dev, list);

Either this call knows how to do the right thing for any platform and
should be made from iommu_dma_get_reserved_regions() directly, or it's
tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
iommu-dma doesn't need to know - the middle ground presented here is
surely the worst of both worlds.

Robin.

>>> +
>>> +	return -ENODEV;
>>> +}
>>> +EXPORT_SYMBOL(iommu_dma_get_msi_resv_regions);
>>> +
>>>  static int cookie_init_hw_msi_region(struct iommu_dma_cookie *cookie,
>>>  		phys_addr_t start, phys_addr_t end)
>>>  {
>>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>>> index 92f2083..6062ef0 100644
>>> --- a/include/linux/dma-iommu.h
>>> +++ b/include/linux/dma-iommu.h
>>> @@ -74,6 +74,8 @@ void iommu_dma_unmap_resource(struct device *dev,
>> dma_addr_t handle,
>>>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>>  void iommu_dma_get_resv_regions(struct device *dev, struct list_head
>> *list);
>>>
>>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct list_head
>> *list);
>>> +
>>>  #else
>>>
>>>  struct iommu_domain;
>>> @@ -107,6 +109,11 @@ static inline void
>> iommu_dma_get_resv_regions(struct device *dev, struct list_he
>>>  {
>>>  }
>>>
>>> +static inline int iommu_dma_get_msi_resv_regions(struct device *dev,
>> struct list_head *list)
>>> +{
>>> +	return -ENODEV;
>>> +}
>>> +
>>>  #endif	/* CONFIG_IOMMU_DMA */
>>>  #endif	/* __KERNEL__ */
>>>  #endif	/* __DMA_IOMMU_H */
>>> --
>>> 1.9.1
>>>
>>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


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

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Wednesday, October 18, 2017 1:34 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Will Deacon <will.deacon@arm.com>
> Cc: lorenzo.pieralisi@arm.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; marc.zyngier@arm.com; linux-
> pci@vger.kernel.org; joro@8bytes.org; John Garry <john.garry@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Linuxarm
> <linuxarm@huawei.com>; linux-acpi@vger.kernel.org; iommu@lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1@hisilicon.com>;
> sudeep.holla@arm.com; bhelgaas@google.com; linux-arm-
> kernel@lists.infradead.org; devel@acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > Hi Robin,
> >
> >> -----Original Message-----
> >> From: Will Deacon [mailto:will.deacon@arm.com]
> >> Sent: Friday, October 13, 2017 8:24 PM
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> >> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> >> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> >> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> >> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> >> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> >> pci@vger.kernel.org; devel@acpica.org; Linuxarm
> <linuxarm@huawei.com>;
> >> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> >> <guohanjun@huawei.com>
> >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve
> HW
> >> MSI address regions for IOMMU drivers
> >>
> >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> >>> IOMMU drivers can use this to implement their .get_resv_regions callback
> >>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >>>
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >>>  include/linux/dma-iommu.h |  7 +++++++
> >>>  2 files changed, 27 insertions(+)
> >>
> >> I'd like to see Robin's Ack on this, because this is his code and he had
> >> ideas on ways to solve this problem properly.
> >
> > Please let us know if it is ok to go ahead with ACPI support for now.
> > It will help our customers to start using pass-through for PCIe.
> >
> > Thanks,
> > Shameer
> >
> >>
> >> Will
> >>
> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >>> index 9d1cebe..bae677e 100644
> >>> --- a/drivers/iommu/dma-iommu.c
> >>> +++ b/drivers/iommu/dma-iommu.c
> >>> @@ -19,6 +19,7 @@
> >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>>   */
> >>>
> >>> +#include <linux/acpi_iort.h>
> >>>  #include <linux/device.h>
> >>>  #include <linux/dma-iommu.h>
> >>>  #include <linux/gfp.h>
> >>> @@ -27,6 +28,7 @@
> >>>  #include <linux/iova.h>
> >>>  #include <linux/irq.h>
> >>>  #include <linux/mm.h>
> >>> +#include <linux/of_iommu.h>
> >>>  #include <linux/pci.h>
> >>>  #include <linux/scatterlist.h>
> >>>  #include <linux/vmalloc.h>
> >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> >> *dev, struct list_head *list)
> >>>  }
> >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >>>
> >>> +/**
> >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> >>> + * @dev: Device from iommu_get_resv_regions()
> >>> + * @list: Reserved region list from iommu_get_resv_regions()
> >>> + *
> >>> + * IOMMU drivers can use this to implement their .get_resv_regions
> >>> + * callback for HW MSI specific reservations. For now, this only
> 
> This doesn't make an awful lot of sense - there's only one reserved
> region callback, so iommu-dma shouldn't be offering two separate and
> non-overlapping implementations.
> 
> >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> >>> + */
> >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> list_head
> >> *list)
> >>> +{
> >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> 
> Either this call knows how to do the right thing for any platform and
> should be made from iommu_dma_get_reserved_regions() directly, or it's
> tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> iommu-dma doesn't need to know - the middle ground presented here is
> surely the worst of both worlds.

Right. I think we have discussed this earlier[1] and had a v4 based on invoking
the iort_iommu_its_get_resv_regions() within the iommu_dma_get_resv_regions().
But later as you rightly pointed out, we were not checking for platforms which
requires this quirk inside the iort code and that will break the platforms which are 
happy with MSI translations. Hence moved to the current implementation in v6
after this discussion here[2]
 
And earlier I think in the v3 version we had the function called from smmu driver
directly and the feedback was that it should be abstracted from the driver.

May be it is still possible to move the function call inside the 
iommu_dma_get_resv_regions() and do the smmu model check inside
 the iort helper function and selectively apply the HW MSI reservations.

But I think it is much neater if we can invoke the iort_get_msi_regions() directly
from SMMUv3 based on the model.

Thoughts?

Thanks,
Shameer
1. https://patches.linaro.org/patch/106268/
2. https://www.spinics.net/lists/arm-kernel/msg599162.html

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

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



> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy(a)arm.com]
> Sent: Wednesday, October 18, 2017 1:34 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>;
> Will Deacon <will.deacon(a)arm.com>
> Cc: lorenzo.pieralisi(a)arm.com; Gabriele Paoloni
> <gabriele.paoloni(a)huawei.com>; marc.zyngier(a)arm.com; linux-
> pci(a)vger.kernel.org; joro(a)8bytes.org; John Garry <john.garry(a)huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun(a)huawei.com>; Linuxarm
> <linuxarm(a)huawei.com>; linux-acpi(a)vger.kernel.org; iommu(a)lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1(a)hisilicon.com>;
> sudeep.holla(a)arm.com; bhelgaas(a)google.com; linux-arm-
> kernel(a)lists.infradead.org; devel(a)acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > Hi Robin,
> >
> >> -----Original Message-----
> >> From: Will Deacon [mailto:will.deacon(a)arm.com]
> >> Sent: Friday, October 13, 2017 8:24 PM
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> >> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> >> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> >> bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> >> John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> >> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> >> pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm
> <linuxarm(a)huawei.com>;
> >> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> >> <guohanjun(a)huawei.com>
> >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve
> HW
> >> MSI address regions for IOMMU drivers
> >>
> >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> >>> IOMMU drivers can use this to implement their .get_resv_regions callback
> >>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >>>
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi(a)huawei.com>
> >>> ---
> >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >>>  include/linux/dma-iommu.h |  7 +++++++
> >>>  2 files changed, 27 insertions(+)
> >>
> >> I'd like to see Robin's Ack on this, because this is his code and he had
> >> ideas on ways to solve this problem properly.
> >
> > Please let us know if it is ok to go ahead with ACPI support for now.
> > It will help our customers to start using pass-through for PCIe.
> >
> > Thanks,
> > Shameer
> >
> >>
> >> Will
> >>
> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >>> index 9d1cebe..bae677e 100644
> >>> --- a/drivers/iommu/dma-iommu.c
> >>> +++ b/drivers/iommu/dma-iommu.c
> >>> @@ -19,6 +19,7 @@
> >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>>   */
> >>>
> >>> +#include <linux/acpi_iort.h>
> >>>  #include <linux/device.h>
> >>>  #include <linux/dma-iommu.h>
> >>>  #include <linux/gfp.h>
> >>> @@ -27,6 +28,7 @@
> >>>  #include <linux/iova.h>
> >>>  #include <linux/irq.h>
> >>>  #include <linux/mm.h>
> >>> +#include <linux/of_iommu.h>
> >>>  #include <linux/pci.h>
> >>>  #include <linux/scatterlist.h>
> >>>  #include <linux/vmalloc.h>
> >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> >> *dev, struct list_head *list)
> >>>  }
> >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >>>
> >>> +/**
> >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> >>> + * @dev: Device from iommu_get_resv_regions()
> >>> + * @list: Reserved region list from iommu_get_resv_regions()
> >>> + *
> >>> + * IOMMU drivers can use this to implement their .get_resv_regions
> >>> + * callback for HW MSI specific reservations. For now, this only
> 
> This doesn't make an awful lot of sense - there's only one reserved
> region callback, so iommu-dma shouldn't be offering two separate and
> non-overlapping implementations.
> 
> >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> >>> + */
> >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> list_head
> >> *list)
> >>> +{
> >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> 
> Either this call knows how to do the right thing for any platform and
> should be made from iommu_dma_get_reserved_regions() directly, or it's
> tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> iommu-dma doesn't need to know - the middle ground presented here is
> surely the worst of both worlds.

Right. I think we have discussed this earlier[1] and had a v4 based on invoking
the iort_iommu_its_get_resv_regions() within the iommu_dma_get_resv_regions().
But later as you rightly pointed out, we were not checking for platforms which
requires this quirk inside the iort code and that will break the platforms which are 
happy with MSI translations. Hence moved to the current implementation in v6
after this discussion here[2]
 
And earlier I think in the v3 version we had the function called from smmu driver
directly and the feedback was that it should be abstracted from the driver.

May be it is still possible to move the function call inside the 
iommu_dma_get_resv_regions() and do the smmu model check inside
 the iort helper function and selectively apply the HW MSI reservations.

But I think it is much neater if we can invoke the iort_get_msi_regions() directly
from SMMUv3 based on the model.

Thoughts?

Thanks,
Shameer
1. https://patches.linaro.org/patch/106268/
2. https://www.spinics.net/lists/arm-kernel/msg599162.html

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Wednesday, October 18, 2017 1:34 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Will Deacon <will.deacon@arm.com>
> Cc: lorenzo.pieralisi at arm.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; marc.zyngier at arm.com; linux-
> pci at vger.kernel.org; joro at 8bytes.org; John Garry <john.garry@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Linuxarm
> <linuxarm@huawei.com>; linux-acpi at vger.kernel.org; iommu at lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1@hisilicon.com>;
> sudeep.holla at arm.com; bhelgaas at google.com; linux-arm-
> kernel at lists.infradead.org; devel at acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > Hi Robin,
> >
> >> -----Original Message-----
> >> From: Will Deacon [mailto:will.deacon at arm.com]
> >> Sent: Friday, October 13, 2017 8:24 PM
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> >> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> >> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> >> bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> >> John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> >> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> >> pci at vger.kernel.org; devel at acpica.org; Linuxarm
> <linuxarm@huawei.com>;
> >> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> >> <guohanjun@huawei.com>
> >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve
> HW
> >> MSI address regions for IOMMU drivers
> >>
> >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> >>> IOMMU drivers can use this to implement their .get_resv_regions callback
> >>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >>>
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >>>  include/linux/dma-iommu.h |  7 +++++++
> >>>  2 files changed, 27 insertions(+)
> >>
> >> I'd like to see Robin's Ack on this, because this is his code and he had
> >> ideas on ways to solve this problem properly.
> >
> > Please let us know if it is ok to go ahead with ACPI support for now.
> > It will help our customers to start using pass-through for PCIe.
> >
> > Thanks,
> > Shameer
> >
> >>
> >> Will
> >>
> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >>> index 9d1cebe..bae677e 100644
> >>> --- a/drivers/iommu/dma-iommu.c
> >>> +++ b/drivers/iommu/dma-iommu.c
> >>> @@ -19,6 +19,7 @@
> >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>>   */
> >>>
> >>> +#include <linux/acpi_iort.h>
> >>>  #include <linux/device.h>
> >>>  #include <linux/dma-iommu.h>
> >>>  #include <linux/gfp.h>
> >>> @@ -27,6 +28,7 @@
> >>>  #include <linux/iova.h>
> >>>  #include <linux/irq.h>
> >>>  #include <linux/mm.h>
> >>> +#include <linux/of_iommu.h>
> >>>  #include <linux/pci.h>
> >>>  #include <linux/scatterlist.h>
> >>>  #include <linux/vmalloc.h>
> >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> >> *dev, struct list_head *list)
> >>>  }
> >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >>>
> >>> +/**
> >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> >>> + * @dev: Device from iommu_get_resv_regions()
> >>> + * @list: Reserved region list from iommu_get_resv_regions()
> >>> + *
> >>> + * IOMMU drivers can use this to implement their .get_resv_regions
> >>> + * callback for HW MSI specific reservations. For now, this only
> 
> This doesn't make an awful lot of sense - there's only one reserved
> region callback, so iommu-dma shouldn't be offering two separate and
> non-overlapping implementations.
> 
> >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> >>> + */
> >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> list_head
> >> *list)
> >>> +{
> >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> 
> Either this call knows how to do the right thing for any platform and
> should be made from iommu_dma_get_reserved_regions() directly, or it's
> tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> iommu-dma doesn't need to know - the middle ground presented here is
> surely the worst of both worlds.

Right. I think we have discussed this earlier[1] and had a v4 based on invoking
the iort_iommu_its_get_resv_regions() within the iommu_dma_get_resv_regions().
But later as you rightly pointed out, we were not checking for platforms which
requires this quirk inside the iort code and that will break the platforms which are 
happy with MSI translations. Hence moved to the current implementation in v6
after this discussion here[2]
 
And earlier I think in the v3 version we had the function called from smmu driver
directly and the feedback was that it should be abstracted from the driver.

May be it is still possible to move the function call inside the 
iommu_dma_get_resv_regions() and do the smmu model check inside
 the iort helper function and selectively apply the HW MSI reservations.

But I think it is much neater if we can invoke the iort_get_msi_regions() directly
from SMMUv3 based on the model.

Thoughts?

Thanks,
Shameer
1. https://patches.linaro.org/patch/106268/
2. https://www.spinics.net/lists/arm-kernel/msg599162.html

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy@arm.com]
> Sent: Wednesday, October 18, 2017 1:34 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> Will Deacon <will.deacon@arm.com>
> Cc: lorenzo.pieralisi@arm.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; marc.zyngier@arm.com; linux-
> pci@vger.kernel.org; joro@8bytes.org; John Garry <john.garry@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Linuxarm
> <linuxarm@huawei.com>; linux-acpi@vger.kernel.org; iommu@lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1@hisilicon.com>;
> sudeep.holla@arm.com; bhelgaas@google.com; linux-arm-
> kernel@lists.infradead.org; devel@acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > Hi Robin,
> >
> >> -----Original Message-----
> >> From: Will Deacon [mailto:will.deacon@arm.com]
> >> Sent: Friday, October 13, 2017 8:24 PM
> >> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> >> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> >> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> >> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> >> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> >> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> >> pci@vger.kernel.org; devel@acpica.org; Linuxarm
> <linuxarm@huawei.com>;
> >> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> >> <guohanjun@huawei.com>
> >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve
> HW
> >> MSI address regions for IOMMU drivers
> >>
> >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> >>> IOMMU drivers can use this to implement their .get_resv_regions callback
> >>> for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI region).
> >>>
> >>> Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> >>> ---
> >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> >>>  include/linux/dma-iommu.h |  7 +++++++
> >>>  2 files changed, 27 insertions(+)
> >>
> >> I'd like to see Robin's Ack on this, because this is his code and he had
> >> ideas on ways to solve this problem properly.
> >
> > Please let us know if it is ok to go ahead with ACPI support for now.
> > It will help our customers to start using pass-through for PCIe.
> >
> > Thanks,
> > Shameer
> >
> >>
> >> Will
> >>
> >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> >>> index 9d1cebe..bae677e 100644
> >>> --- a/drivers/iommu/dma-iommu.c
> >>> +++ b/drivers/iommu/dma-iommu.c
> >>> @@ -19,6 +19,7 @@
> >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >>>   */
> >>>
> >>> +#include <linux/acpi_iort.h>
> >>>  #include <linux/device.h>
> >>>  #include <linux/dma-iommu.h>
> >>>  #include <linux/gfp.h>
> >>> @@ -27,6 +28,7 @@
> >>>  #include <linux/iova.h>
> >>>  #include <linux/irq.h>
> >>>  #include <linux/mm.h>
> >>> +#include <linux/of_iommu.h>
> >>>  #include <linux/pci.h>
> >>>  #include <linux/scatterlist.h>
> >>>  #include <linux/vmalloc.h>
> >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct device
> >> *dev, struct list_head *list)
> >>>  }
> >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> >>>
> >>> +/**
> >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> >>> + * @dev: Device from iommu_get_resv_regions()
> >>> + * @list: Reserved region list from iommu_get_resv_regions()
> >>> + *
> >>> + * IOMMU drivers can use this to implement their .get_resv_regions
> >>> + * callback for HW MSI specific reservations. For now, this only
> 
> This doesn't make an awful lot of sense - there's only one reserved
> region callback, so iommu-dma shouldn't be offering two separate and
> non-overlapping implementations.
> 
> >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> >>> + */
> >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> list_head
> >> *list)
> >>> +{
> >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> 
> Either this call knows how to do the right thing for any platform and
> should be made from iommu_dma_get_reserved_regions() directly, or it's
> tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> iommu-dma doesn't need to know - the middle ground presented here is
> surely the worst of both worlds.

Right. I think we have discussed this earlier[1] and had a v4 based on invoking
the iort_iommu_its_get_resv_regions() within the iommu_dma_get_resv_regions().
But later as you rightly pointed out, we were not checking for platforms which
requires this quirk inside the iort code and that will break the platforms which are 
happy with MSI translations. Hence moved to the current implementation in v6
after this discussion here[2]
 
And earlier I think in the v3 version we had the function called from smmu driver
directly and the feedback was that it should be abstracted from the driver.

May be it is still possible to move the function call inside the 
iommu_dma_get_resv_regions() and do the smmu model check inside
 the iort helper function and selectively apply the HW MSI reservations.

But I think it is much neater if we can invoke the iort_get_msi_regions() directly
from SMMUv3 based on the model.

Thoughts?

Thanks,
Shameer
1. https://patches.linaro.org/patch/106268/
2. https://www.spinics.net/lists/arm-kernel/msg599162.html



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

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

Hi Lorenzo/Will,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Wednesday, October 18, 2017 3:24 PM
> To: 'Robin Murphy' <robin.murphy@arm.com>; Will Deacon
> <will.deacon@arm.com>
> Cc: lorenzo.pieralisi@arm.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; marc.zyngier@arm.com; linux-
> pci@vger.kernel.org; joro@8bytes.org; John Garry <john.garry@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Linuxarm
> <linuxarm@huawei.com>; linux-acpi@vger.kernel.org; iommu@lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1@hisilicon.com>;
> sudeep.holla@arm.com; bhelgaas@google.com; linux-arm-
> kernel@lists.infradead.org; devel@acpica.org
> Subject: RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> 
> 
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy@arm.com]
> > Sent: Wednesday, October 18, 2017 1:34 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> > Will Deacon <will.deacon@arm.com>
> > Cc: lorenzo.pieralisi@arm.com; Gabriele Paoloni
> > <gabriele.paoloni@huawei.com>; marc.zyngier@arm.com; linux-
> > pci@vger.kernel.org; joro@8bytes.org; John Garry
> > <john.garry@huawei.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>; Linuxarm <linuxarm@huawei.com>;
> > linux-acpi@vger.kernel.org; iommu@lists.linux- foundation.org;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; sudeep.holla@arm.com;
> > bhelgaas@google.com; linux-arm- kernel@lists.infradead.org;
> > devel@acpica.org
> > Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > reserve HW MSI address regions for IOMMU drivers
> >
> > On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > > Hi Robin,
> > >
> > >> -----Original Message-----
> > >> From: Will Deacon [mailto:will.deacon@arm.com]
> > >> Sent: Friday, October 13, 2017 8:24 PM
> > >> To: Shameerali Kolothum Thodi
> > >> <shameerali.kolothum.thodi@huawei.com>
> > >> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > >> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > >> bhelgaas@google.com; Gabriele Paoloni
> > >> <gabriele.paoloni@huawei.com>; John Garry <john.garry@huawei.com>;
> > >> iommu@lists.linux-foundation.org;
> > >> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org;
> > >> linux- pci@vger.kernel.org; devel@acpica.org; Linuxarm
> > <linuxarm@huawei.com>;
> > >> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > >> <guohanjun@huawei.com>
> > >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > >> reserve
> > HW
> > >> MSI address regions for IOMMU drivers
> > >>
> > >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > >>> IOMMU drivers can use this to implement their .get_resv_regions
> > >>> callback for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI
> region).
> > >>>
> > >>> Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@huawei.com>
> > >>> ---
> > >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> > >>> include/linux/dma-iommu.h |  7 +++++++
> > >>>  2 files changed, 27 insertions(+)
> > >>
> > >> I'd like to see Robin's Ack on this, because this is his code and
> > >> he had ideas on ways to solve this problem properly.
> > >
> > > Please let us know if it is ok to go ahead with ACPI support for now.
> > > It will help our customers to start using pass-through for PCIe.
> > >
> > > Thanks,
> > > Shameer
> > >
> > >>
> > >> Will
> > >>
> > >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > >>> index 9d1cebe..bae677e 100644
> > >>> --- a/drivers/iommu/dma-iommu.c
> > >>> +++ b/drivers/iommu/dma-iommu.c
> > >>> @@ -19,6 +19,7 @@
> > >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > >>>   */
> > >>>
> > >>> +#include <linux/acpi_iort.h>
> > >>>  #include <linux/device.h>
> > >>>  #include <linux/dma-iommu.h>
> > >>>  #include <linux/gfp.h>
> > >>> @@ -27,6 +28,7 @@
> > >>>  #include <linux/iova.h>
> > >>>  #include <linux/irq.h>
> > >>>  #include <linux/mm.h>
> > >>> +#include <linux/of_iommu.h>
> > >>>  #include <linux/pci.h>
> > >>>  #include <linux/scatterlist.h>
> > >>>  #include <linux/vmalloc.h>
> > >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct
> device
> > >> *dev, struct list_head *list)
> > >>>  }
> > >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> > >>>
> > >>> +/**
> > >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > >>> + * @dev: Device from iommu_get_resv_regions()
> > >>> + * @list: Reserved region list from iommu_get_resv_regions()
> > >>> + *
> > >>> + * IOMMU drivers can use this to implement their
> > >>> +.get_resv_regions
> > >>> + * callback for HW MSI specific reservations. For now, this only
> >
> > This doesn't make an awful lot of sense - there's only one reserved
> > region callback, so iommu-dma shouldn't be offering two separate and
> > non-overlapping implementations.
> >
> > >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> > >>> + */
> > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > list_head
> > >> *list)
> > >>> +{
> > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> >
> > Either this call knows how to do the right thing for any platform and
> > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > iommu-dma doesn't need to know - the middle ground presented here is
> > surely the worst of both worlds.
> 
> Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> the iort_iommu_its_get_resv_regions() within the
> iommu_dma_get_resv_regions().
> But later as you rightly pointed out, we were not checking for platforms which
> requires this quirk inside the iort code and that will break the platforms which
> are happy with MSI translations. Hence moved to the current implementation
> in v6 after this discussion here[2]
> 
> And earlier I think in the v3 version we had the function called from smmu
> driver directly and the feedback was that it should be abstracted from the
> driver.
> 
> May be it is still possible to move the function call inside the
> iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> helper function and selectively apply the HW MSI reservations.
> 
> But I think it is much neater if we can invoke the iort_get_msi_regions()
> directly from SMMUv3 based on the model.
> 
> Thoughts?

As we still don’t have a clear resolution on how to invoke the 
iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
smmu model check inside the iort code. This means the function will selectively
apply HW MSI reservation based on the platform and also the function can be 
invoked from the iommu_dma_get_resv_regions() directly.

Could you please take a look at the below snippet and let me know your feedback.
Hope we can make some progress on this series.

Thanks,
Shameer

-->8--
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 876c0e1..a27233d 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
 	return 0;
 }
 
+static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
+					struct acpi_iort_node *node)
+{
+	struct acpi_iort_node *iommu = NULL;
+	int i;
+
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			iommu = iort_node_map_platform_id(node, NULL,
+							IORT_IOMMU_TYPE, i);
+			if (iommu)
+				break;
+		}
+	}
+
+	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+		struct acpi_iort_smmu_v3 *smmu;
+
+		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
+			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
+			return true;
+		}
+	}
+
+	return false;
+}
+
 static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
 			       struct fwnode_handle *fwnode,
 			       const struct iommu_ops *ops)
@@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 	if (!node)
 		return -ENODEV;
 
+	if (!iort_hw_msi_resv_enable(dev, node))
+		return 0;
+
 	/*
 	 * Current logic to reserve ITS regions relies on HW topologies
 	 * where a given PCI or named component maps its IDs to only one
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..67c6e30 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 	struct pci_host_bridge *bridge;
 	struct resource_entry *window;
 
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+		iort_iommu_msi_get_resv_regions(dev, list) < 0)
+		return;
+
 	if (!dev_is_pci(dev))
 		return;
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 182a577..88f17c9 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
 static inline
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
-{ return -ENODEV; }
+{ return 0; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */

-->8--

 

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

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

Hi Lorenzo/Will,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Wednesday, October 18, 2017 3:24 PM
> To: 'Robin Murphy' <robin.murphy(a)arm.com>; Will Deacon
> <will.deacon(a)arm.com>
> Cc: lorenzo.pieralisi(a)arm.com; Gabriele Paoloni
> <gabriele.paoloni(a)huawei.com>; marc.zyngier(a)arm.com; linux-
> pci(a)vger.kernel.org; joro(a)8bytes.org; John Garry <john.garry(a)huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun(a)huawei.com>; Linuxarm
> <linuxarm(a)huawei.com>; linux-acpi(a)vger.kernel.org; iommu(a)lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1(a)hisilicon.com>;
> sudeep.holla(a)arm.com; bhelgaas(a)google.com; linux-arm-
> kernel(a)lists.infradead.org; devel(a)acpica.org
> Subject: RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> 
> 
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy(a)arm.com]
> > Sent: Wednesday, October 18, 2017 1:34 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>;
> > Will Deacon <will.deacon(a)arm.com>
> > Cc: lorenzo.pieralisi(a)arm.com; Gabriele Paoloni
> > <gabriele.paoloni(a)huawei.com>; marc.zyngier(a)arm.com; linux-
> > pci(a)vger.kernel.org; joro(a)8bytes.org; John Garry
> > <john.garry(a)huawei.com>; Guohanjun (Hanjun Guo)
> > <guohanjun(a)huawei.com>; Linuxarm <linuxarm(a)huawei.com>;
> > linux-acpi(a)vger.kernel.org; iommu(a)lists.linux- foundation.org;
> > Wangzhou (B) <wangzhou1(a)hisilicon.com>; sudeep.holla(a)arm.com;
> > bhelgaas(a)google.com; linux-arm- kernel(a)lists.infradead.org;
> > devel(a)acpica.org
> > Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > reserve HW MSI address regions for IOMMU drivers
> >
> > On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > > Hi Robin,
> > >
> > >> -----Original Message-----
> > >> From: Will Deacon [mailto:will.deacon(a)arm.com]
> > >> Sent: Friday, October 13, 2017 8:24 PM
> > >> To: Shameerali Kolothum Thodi
> > >> <shameerali.kolothum.thodi(a)huawei.com>
> > >> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> > >> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> > >> bhelgaas(a)google.com; Gabriele Paoloni
> > >> <gabriele.paoloni(a)huawei.com>; John Garry <john.garry(a)huawei.com>;
> > >> iommu(a)lists.linux-foundation.org;
> > >> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org;
> > >> linux- pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm
> > <linuxarm(a)huawei.com>;
> > >> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> > >> <guohanjun(a)huawei.com>
> > >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > >> reserve
> > HW
> > >> MSI address regions for IOMMU drivers
> > >>
> > >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > >>> IOMMU drivers can use this to implement their .get_resv_regions
> > >>> callback for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI
> region).
> > >>>
> > >>> Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi(a)huawei.com>
> > >>> ---
> > >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> > >>> include/linux/dma-iommu.h |  7 +++++++
> > >>>  2 files changed, 27 insertions(+)
> > >>
> > >> I'd like to see Robin's Ack on this, because this is his code and
> > >> he had ideas on ways to solve this problem properly.
> > >
> > > Please let us know if it is ok to go ahead with ACPI support for now.
> > > It will help our customers to start using pass-through for PCIe.
> > >
> > > Thanks,
> > > Shameer
> > >
> > >>
> > >> Will
> > >>
> > >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > >>> index 9d1cebe..bae677e 100644
> > >>> --- a/drivers/iommu/dma-iommu.c
> > >>> +++ b/drivers/iommu/dma-iommu.c
> > >>> @@ -19,6 +19,7 @@
> > >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > >>>   */
> > >>>
> > >>> +#include <linux/acpi_iort.h>
> > >>>  #include <linux/device.h>
> > >>>  #include <linux/dma-iommu.h>
> > >>>  #include <linux/gfp.h>
> > >>> @@ -27,6 +28,7 @@
> > >>>  #include <linux/iova.h>
> > >>>  #include <linux/irq.h>
> > >>>  #include <linux/mm.h>
> > >>> +#include <linux/of_iommu.h>
> > >>>  #include <linux/pci.h>
> > >>>  #include <linux/scatterlist.h>
> > >>>  #include <linux/vmalloc.h>
> > >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct
> device
> > >> *dev, struct list_head *list)
> > >>>  }
> > >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> > >>>
> > >>> +/**
> > >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > >>> + * @dev: Device from iommu_get_resv_regions()
> > >>> + * @list: Reserved region list from iommu_get_resv_regions()
> > >>> + *
> > >>> + * IOMMU drivers can use this to implement their
> > >>> +.get_resv_regions
> > >>> + * callback for HW MSI specific reservations. For now, this only
> >
> > This doesn't make an awful lot of sense - there's only one reserved
> > region callback, so iommu-dma shouldn't be offering two separate and
> > non-overlapping implementations.
> >
> > >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> > >>> + */
> > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > list_head
> > >> *list)
> > >>> +{
> > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> >
> > Either this call knows how to do the right thing for any platform and
> > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > iommu-dma doesn't need to know - the middle ground presented here is
> > surely the worst of both worlds.
> 
> Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> the iort_iommu_its_get_resv_regions() within the
> iommu_dma_get_resv_regions().
> But later as you rightly pointed out, we were not checking for platforms which
> requires this quirk inside the iort code and that will break the platforms which
> are happy with MSI translations. Hence moved to the current implementation
> in v6 after this discussion here[2]
> 
> And earlier I think in the v3 version we had the function called from smmu
> driver directly and the feedback was that it should be abstracted from the
> driver.
> 
> May be it is still possible to move the function call inside the
> iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> helper function and selectively apply the HW MSI reservations.
> 
> But I think it is much neater if we can invoke the iort_get_msi_regions()
> directly from SMMUv3 based on the model.
> 
> Thoughts?

As we still don’t have a clear resolution on how to invoke the 
iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
smmu model check inside the iort code. This means the function will selectively
apply HW MSI reservation based on the platform and also the function can be 
invoked from the iommu_dma_get_resv_regions() directly.

Could you please take a look at the below snippet and let me know your feedback.
Hope we can make some progress on this series.

Thanks,
Shameer

-->8--
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 876c0e1..a27233d 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
 	return 0;
 }
 
+static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
+					struct acpi_iort_node *node)
+{
+	struct acpi_iort_node *iommu = NULL;
+	int i;
+
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			iommu = iort_node_map_platform_id(node, NULL,
+							IORT_IOMMU_TYPE, i);
+			if (iommu)
+				break;
+		}
+	}
+
+	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+		struct acpi_iort_smmu_v3 *smmu;
+
+		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
+			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
+			return true;
+		}
+	}
+
+	return false;
+}
+
 static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
 			       struct fwnode_handle *fwnode,
 			       const struct iommu_ops *ops)
@@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 	if (!node)
 		return -ENODEV;
 
+	if (!iort_hw_msi_resv_enable(dev, node))
+		return 0;
+
 	/*
 	 * Current logic to reserve ITS regions relies on HW topologies
 	 * where a given PCI or named component maps its IDs to only one
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..67c6e30 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 	struct pci_host_bridge *bridge;
 	struct resource_entry *window;
 
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+		iort_iommu_msi_get_resv_regions(dev, list) < 0)
+		return;
+
 	if (!dev_is_pci(dev))
 		return;
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 182a577..88f17c9 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
 static inline
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
-{ return -ENODEV; }
+{ return 0; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */

-->8--

 

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

Hi Lorenzo/Will,

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Wednesday, October 18, 2017 3:24 PM
> To: 'Robin Murphy' <robin.murphy@arm.com>; Will Deacon
> <will.deacon@arm.com>
> Cc: lorenzo.pieralisi at arm.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; marc.zyngier at arm.com; linux-
> pci at vger.kernel.org; joro at 8bytes.org; John Garry <john.garry@huawei.com>;
> Guohanjun (Hanjun Guo) <guohanjun@huawei.com>; Linuxarm
> <linuxarm@huawei.com>; linux-acpi at vger.kernel.org; iommu at lists.linux-
> foundation.org; Wangzhou (B) <wangzhou1@hisilicon.com>;
> sudeep.holla at arm.com; bhelgaas at google.com; linux-arm-
> kernel at lists.infradead.org; devel at acpica.org
> Subject: RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> 
> 
> > -----Original Message-----
> > From: Robin Murphy [mailto:robin.murphy at arm.com]
> > Sent: Wednesday, October 18, 2017 1:34 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>;
> > Will Deacon <will.deacon@arm.com>
> > Cc: lorenzo.pieralisi at arm.com; Gabriele Paoloni
> > <gabriele.paoloni@huawei.com>; marc.zyngier at arm.com; linux-
> > pci at vger.kernel.org; joro at 8bytes.org; John Garry
> > <john.garry@huawei.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>; Linuxarm <linuxarm@huawei.com>;
> > linux-acpi at vger.kernel.org; iommu at lists.linux- foundation.org;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; sudeep.holla at arm.com;
> > bhelgaas at google.com; linux-arm- kernel at lists.infradead.org;
> > devel at acpica.org
> > Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > reserve HW MSI address regions for IOMMU drivers
> >
> > On 16/10/17 17:09, Shameerali Kolothum Thodi wrote:
> > > Hi Robin,
> > >
> > >> -----Original Message-----
> > >> From: Will Deacon [mailto:will.deacon at arm.com]
> > >> Sent: Friday, October 13, 2017 8:24 PM
> > >> To: Shameerali Kolothum Thodi
> > >> <shameerali.kolothum.thodi@huawei.com>
> > >> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> > >> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> > >> bhelgaas at google.com; Gabriele Paoloni
> > >> <gabriele.paoloni@huawei.com>; John Garry <john.garry@huawei.com>;
> > >> iommu at lists.linux-foundation.org;
> > >> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org;
> > >> linux- pci at vger.kernel.org; devel at acpica.org; Linuxarm
> > <linuxarm@huawei.com>;
> > >> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > >> <guohanjun@huawei.com>
> > >> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to
> > >> reserve
> > HW
> > >> MSI address regions for IOMMU drivers
> > >>
> > >> On Fri, Oct 06, 2017 at 03:04:48PM +0100, Shameer Kolothum wrote:
> > >>> IOMMU drivers can use this to implement their .get_resv_regions
> > >>> callback for HW MSI specific reservations(e.g. ARM GICv3 ITS MSI
> region).
> > >>>
> > >>> Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@huawei.com>
> > >>> ---
> > >>>  drivers/iommu/dma-iommu.c | 20 ++++++++++++++++++++
> > >>> include/linux/dma-iommu.h |  7 +++++++
> > >>>  2 files changed, 27 insertions(+)
> > >>
> > >> I'd like to see Robin's Ack on this, because this is his code and
> > >> he had ideas on ways to solve this problem properly.
> > >
> > > Please let us know if it is ok to go ahead with ACPI support for now.
> > > It will help our customers to start using pass-through for PCIe.
> > >
> > > Thanks,
> > > Shameer
> > >
> > >>
> > >> Will
> > >>
> > >>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > >>> index 9d1cebe..bae677e 100644
> > >>> --- a/drivers/iommu/dma-iommu.c
> > >>> +++ b/drivers/iommu/dma-iommu.c
> > >>> @@ -19,6 +19,7 @@
> > >>>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> > >>>   */
> > >>>
> > >>> +#include <linux/acpi_iort.h>
> > >>>  #include <linux/device.h>
> > >>>  #include <linux/dma-iommu.h>
> > >>>  #include <linux/gfp.h>
> > >>> @@ -27,6 +28,7 @@
> > >>>  #include <linux/iova.h>
> > >>>  #include <linux/irq.h>
> > >>>  #include <linux/mm.h>
> > >>> +#include <linux/of_iommu.h>
> > >>>  #include <linux/pci.h>
> > >>>  #include <linux/scatterlist.h>
> > >>>  #include <linux/vmalloc.h>
> > >>> @@ -198,6 +200,24 @@ void iommu_dma_get_resv_regions(struct
> device
> > >> *dev, struct list_head *list)
> > >>>  }
> > >>>  EXPORT_SYMBOL(iommu_dma_get_resv_regions);
> > >>>
> > >>> +/**
> > >>> + * iommu_dma_get_msi_resv_regions - Reserved region driver helper
> > >>> + * @dev: Device from iommu_get_resv_regions()
> > >>> + * @list: Reserved region list from iommu_get_resv_regions()
> > >>> + *
> > >>> + * IOMMU drivers can use this to implement their
> > >>> +.get_resv_regions
> > >>> + * callback for HW MSI specific reservations. For now, this only
> >
> > This doesn't make an awful lot of sense - there's only one reserved
> > region callback, so iommu-dma shouldn't be offering two separate and
> > non-overlapping implementations.
> >
> > >>> + * covers ITS MSI region reservation using ACPI IORT helper function.
> > >>> + */
> > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > list_head
> > >> *list)
> > >>> +{
> > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> >
> > Either this call knows how to do the right thing for any platform and
> > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > iommu-dma doesn't need to know - the middle ground presented here is
> > surely the worst of both worlds.
> 
> Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> the iort_iommu_its_get_resv_regions() within the
> iommu_dma_get_resv_regions().
> But later as you rightly pointed out, we were not checking for platforms which
> requires this quirk inside the iort code and that will break the platforms which
> are happy with MSI translations. Hence moved to the current implementation
> in v6 after this discussion here[2]
> 
> And earlier I think in the v3 version we had the function called from smmu
> driver directly and the feedback was that it should be abstracted from the
> driver.
> 
> May be it is still possible to move the function call inside the
> iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> helper function and selectively apply the HW MSI reservations.
> 
> But I think it is much neater if we can invoke the iort_get_msi_regions()
> directly from SMMUv3 based on the model.
> 
> Thoughts?

As we still don?t have a clear resolution on how to invoke the 
iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
smmu model check inside the iort code. This means the function will selectively
apply HW MSI reservation based on the platform and also the function can be 
invoked from the iommu_dma_get_resv_regions() directly.

Could you please take a look at the below snippet and let me know your feedback.
Hope we can make some progress on this series.

Thanks,
Shameer

-->8--
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 876c0e1..a27233d 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
 	return 0;
 }
 
+static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
+					struct acpi_iort_node *node)
+{
+	struct acpi_iort_node *iommu = NULL;
+	int i;
+
+	if (dev_is_pci(dev)) {
+		u32 rid;
+
+		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
+		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
+	} else {
+		for (i = 0; i < node->mapping_count; i++) {
+			iommu = iort_node_map_platform_id(node, NULL,
+							IORT_IOMMU_TYPE, i);
+			if (iommu)
+				break;
+		}
+	}
+
+	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
+		struct acpi_iort_smmu_v3 *smmu;
+
+		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
+		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
+			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
+			return true;
+		}
+	}
+
+	return false;
+}
+
 static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
 			       struct fwnode_handle *fwnode,
 			       const struct iommu_ops *ops)
@@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
 	if (!node)
 		return -ENODEV;
 
+	if (!iort_hw_msi_resv_enable(dev, node))
+		return 0;
+
 	/*
 	 * Current logic to reserve ITS regions relies on HW topologies
 	 * where a given PCI or named component maps its IDs to only one
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 9d1cebe..67c6e30 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers/iommu/dma-iommu.c
@@ -19,6 +19,7 @@
  * along with this program.  If not, see <http://www.gnu.org/licenses/>.
  */
 
+#include <linux/acpi_iort.h>
 #include <linux/device.h>
 #include <linux/dma-iommu.h>
 #include <linux/gfp.h>
@@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
 	struct pci_host_bridge *bridge;
 	struct resource_entry *window;
 
+	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
+		iort_iommu_msi_get_resv_regions(dev, list) < 0)
+		return;
+
 	if (!dev_is_pci(dev))
 		return;
 
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 182a577..88f17c9 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
 { return NULL; }
 static inline
 int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
-{ return -ENODEV; }
+{ return 0; }
 #endif
 
 #endif /* __ACPI_IORT_H__ */

-->8--

 

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

SGkgTG9yZW56by9XaWxsLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206
IFNoYW1lZXJhbGkgS29sb3RodW0gVGhvZGkNCj4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE4
LCAyMDE3IDM6MjQgUE0NCj4gVG86ICdSb2JpbiBNdXJwaHknIDxyb2Jpbi5tdXJwaHlAYXJtLmNv
bT47IFdpbGwgRGVhY29uDQo+IDx3aWxsLmRlYWNvbkBhcm0uY29tPg0KPiBDYzogbG9yZW56by5w
aWVyYWxpc2lAYXJtLmNvbTsgR2FicmllbGUgUGFvbG9uaQ0KPiA8Z2FicmllbGUucGFvbG9uaUBo
dWF3ZWkuY29tPjsgbWFyYy56eW5naWVyQGFybS5jb207IGxpbnV4LQ0KPiBwY2lAdmdlci5rZXJu
ZWwub3JnOyBqb3JvQDhieXRlcy5vcmc7IEpvaG4gR2FycnkgPGpvaG4uZ2FycnlAaHVhd2VpLmNv
bT47DQo+IEd1b2hhbmp1biAoSGFuanVuIEd1bykgPGd1b2hhbmp1bkBodWF3ZWkuY29tPjsgTGlu
dXhhcm0NCj4gPGxpbnV4YXJtQGh1YXdlaS5jb20+OyBsaW51eC1hY3BpQHZnZXIua2VybmVsLm9y
ZzsgaW9tbXVAbGlzdHMubGludXgtDQo+IGZvdW5kYXRpb24ub3JnOyBXYW5nemhvdSAoQikgPHdh
bmd6aG91MUBoaXNpbGljb24uY29tPjsNCj4gc3VkZWVwLmhvbGxhQGFybS5jb207IGJoZWxnYWFz
QGdvb2dsZS5jb207IGxpbnV4LWFybS0NCj4ga2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGRl
dmVsQGFjcGljYS5vcmcNCj4gU3ViamVjdDogUkU6IFtQQVRDSCB2OSAyLzRdIGlvbW11L2RtYTog
QWRkIGEgaGVscGVyIGZ1bmN0aW9uIHRvIHJlc2VydmUgSFcNCj4gTVNJIGFkZHJlc3MgcmVnaW9u
cyBmb3IgSU9NTVUgZHJpdmVycw0KPiANCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+ID4gRnJvbTogUm9iaW4gTXVycGh5IFttYWlsdG86cm9iaW4ubXVycGh5QGFybS5j
b21dDQo+ID4gU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDE4LCAyMDE3IDE6MzQgUE0NCj4gPiBU
bzogU2hhbWVlcmFsaSBLb2xvdGh1bSBUaG9kaSA8c2hhbWVlcmFsaS5rb2xvdGh1bS50aG9kaUBo
dWF3ZWkuY29tPjsNCj4gPiBXaWxsIERlYWNvbiA8d2lsbC5kZWFjb25AYXJtLmNvbT4NCj4gPiBD
YzogbG9yZW56by5waWVyYWxpc2lAYXJtLmNvbTsgR2FicmllbGUgUGFvbG9uaQ0KPiA+IDxnYWJy
aWVsZS5wYW9sb25pQGh1YXdlaS5jb20+OyBtYXJjLnp5bmdpZXJAYXJtLmNvbTsgbGludXgtDQo+
ID4gcGNpQHZnZXIua2VybmVsLm9yZzsgam9yb0A4Ynl0ZXMub3JnOyBKb2huIEdhcnJ5DQo+ID4g
PGpvaG4uZ2FycnlAaHVhd2VpLmNvbT47IEd1b2hhbmp1biAoSGFuanVuIEd1bykNCj4gPiA8Z3Vv
aGFuanVuQGh1YXdlaS5jb20+OyBMaW51eGFybSA8bGludXhhcm1AaHVhd2VpLmNvbT47DQo+ID4g
bGludXgtYWNwaUB2Z2VyLmtlcm5lbC5vcmc7IGlvbW11QGxpc3RzLmxpbnV4LSBmb3VuZGF0aW9u
Lm9yZzsNCj4gPiBXYW5nemhvdSAoQikgPHdhbmd6aG91MUBoaXNpbGljb24uY29tPjsgc3VkZWVw
LmhvbGxhQGFybS5jb207DQo+ID4gYmhlbGdhYXNAZ29vZ2xlLmNvbTsgbGludXgtYXJtLSBrZXJu
ZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gPiBkZXZlbEBhY3BpY2Eub3JnDQo+ID4gU3ViamVj
dDogUmU6IFtQQVRDSCB2OSAyLzRdIGlvbW11L2RtYTogQWRkIGEgaGVscGVyIGZ1bmN0aW9uIHRv
DQo+ID4gcmVzZXJ2ZSBIVyBNU0kgYWRkcmVzcyByZWdpb25zIGZvciBJT01NVSBkcml2ZXJzDQo+
ID4NCj4gPiBPbiAxNi8xMC8xNyAxNzowOSwgU2hhbWVlcmFsaSBLb2xvdGh1bSBUaG9kaSB3cm90
ZToNCj4gPiA+IEhpIFJvYmluLA0KPiA+ID4NCj4gPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiA+ID4+IEZyb206IFdpbGwgRGVhY29uIFttYWlsdG86d2lsbC5kZWFjb25AYXJtLmNv
bV0NCj4gPiA+PiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMTMsIDIwMTcgODoyNCBQTQ0KPiA+ID4+
IFRvOiBTaGFtZWVyYWxpIEtvbG90aHVtIFRob2RpDQo+ID4gPj4gPHNoYW1lZXJhbGkua29sb3Ro
dW0udGhvZGlAaHVhd2VpLmNvbT4NCj4gPiA+PiBDYzogbG9yZW56by5waWVyYWxpc2lAYXJtLmNv
bTsgbWFyYy56eW5naWVyQGFybS5jb207DQo+ID4gPj4gc3VkZWVwLmhvbGxhQGFybS5jb207IHJv
YmluLm11cnBoeUBhcm0uY29tOyBqb3JvQDhieXRlcy5vcmc7DQo+ID4gPj4gYmhlbGdhYXNAZ29v
Z2xlLmNvbTsgR2FicmllbGUgUGFvbG9uaQ0KPiA+ID4+IDxnYWJyaWVsZS5wYW9sb25pQGh1YXdl
aS5jb20+OyBKb2huIEdhcnJ5IDxqb2huLmdhcnJ5QGh1YXdlaS5jb20+Ow0KPiA+ID4+IGlvbW11
QGxpc3RzLmxpbnV4LWZvdW5kYXRpb24ub3JnOw0KPiA+ID4+IGxpbnV4LWFybS1rZXJuZWxAbGlz
dHMuaW5mcmFkZWFkLm9yZzsgbGludXgtYWNwaUB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gPj4gbGlu
dXgtIHBjaUB2Z2VyLmtlcm5lbC5vcmc7IGRldmVsQGFjcGljYS5vcmc7IExpbnV4YXJtDQo+ID4g
PGxpbnV4YXJtQGh1YXdlaS5jb20+Ow0KPiA+ID4+IFdhbmd6aG91IChCKSA8d2FuZ3pob3UxQGhp
c2lsaWNvbi5jb20+OyBHdW9oYW5qdW4gKEhhbmp1biBHdW8pDQo+ID4gPj4gPGd1b2hhbmp1bkBo
dWF3ZWkuY29tPg0KPiA+ID4+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggdjkgMi80XSBpb21tdS9kbWE6
IEFkZCBhIGhlbHBlciBmdW5jdGlvbiB0bw0KPiA+ID4+IHJlc2VydmUNCj4gPiBIVw0KPiA+ID4+
IE1TSSBhZGRyZXNzIHJlZ2lvbnMgZm9yIElPTU1VIGRyaXZlcnMNCj4gPiA+Pg0KPiA+ID4+IE9u
IEZyaSwgT2N0IDA2LCAyMDE3IGF0IDAzOjA0OjQ4UE0gKzAxMDAsIFNoYW1lZXIgS29sb3RodW0g
d3JvdGU6DQo+ID4gPj4+IElPTU1VIGRyaXZlcnMgY2FuIHVzZSB0aGlzIHRvIGltcGxlbWVudCB0
aGVpciAuZ2V0X3Jlc3ZfcmVnaW9ucw0KPiA+ID4+PiBjYWxsYmFjayBmb3IgSFcgTVNJIHNwZWNp
ZmljIHJlc2VydmF0aW9ucyhlLmcuIEFSTSBHSUN2MyBJVFMgTVNJDQo+IHJlZ2lvbikuDQo+ID4g
Pj4+DQo+ID4gPj4+IFNpZ25lZC1vZmYtYnk6IFNoYW1lZXIgS29sb3RodW0NCj4gPiA8c2hhbWVl
cmFsaS5rb2xvdGh1bS50aG9kaUBodWF3ZWkuY29tPg0KPiA+ID4+PiAtLS0NCj4gPiA+Pj4gIGRy
aXZlcnMvaW9tbXUvZG1hLWlvbW11LmMgfCAyMCArKysrKysrKysrKysrKysrKysrKw0KPiA+ID4+
PiBpbmNsdWRlL2xpbnV4L2RtYS1pb21tdS5oIHwgIDcgKysrKysrKw0KPiA+ID4+PiAgMiBmaWxl
cyBjaGFuZ2VkLCAyNyBpbnNlcnRpb25zKCspDQo+ID4gPj4NCj4gPiA+PiBJJ2QgbGlrZSB0byBz
ZWUgUm9iaW4ncyBBY2sgb24gdGhpcywgYmVjYXVzZSB0aGlzIGlzIGhpcyBjb2RlIGFuZA0KPiA+
ID4+IGhlIGhhZCBpZGVhcyBvbiB3YXlzIHRvIHNvbHZlIHRoaXMgcHJvYmxlbSBwcm9wZXJseS4N
Cj4gPiA+DQo+ID4gPiBQbGVhc2UgbGV0IHVzIGtub3cgaWYgaXQgaXMgb2sgdG8gZ28gYWhlYWQg
d2l0aCBBQ1BJIHN1cHBvcnQgZm9yIG5vdy4NCj4gPiA+IEl0IHdpbGwgaGVscCBvdXIgY3VzdG9t
ZXJzIHRvIHN0YXJ0IHVzaW5nIHBhc3MtdGhyb3VnaCBmb3IgUENJZS4NCj4gPiA+DQo+ID4gPiBU
aGFua3MsDQo+ID4gPiBTaGFtZWVyDQo+ID4gPg0KPiA+ID4+DQo+ID4gPj4gV2lsbA0KPiA+ID4+
DQo+ID4gPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2lvbW11L2RtYS1pb21tdS5jIGIvZHJpdmVy
cy9pb21tdS9kbWEtaW9tbXUuYw0KPiA+ID4+PiBpbmRleCA5ZDFjZWJlLi5iYWU2NzdlIDEwMDY0
NA0KPiA+ID4+PiAtLS0gYS9kcml2ZXJzL2lvbW11L2RtYS1pb21tdS5jDQo+ID4gPj4+ICsrKyBi
L2RyaXZlcnMvaW9tbXUvZG1hLWlvbW11LmMNCj4gPiA+Pj4gQEAgLTE5LDYgKzE5LDcgQEANCj4g
PiA+Pj4gICAqIGFsb25nIHdpdGggdGhpcyBwcm9ncmFtLiAgSWYgbm90LCBzZWUgPGh0dHA6Ly93
d3cuZ251Lm9yZy9saWNlbnNlcy8+Lg0KPiA+ID4+PiAgICovDQo+ID4gPj4+DQo+ID4gPj4+ICsj
aW5jbHVkZSA8bGludXgvYWNwaV9pb3J0Lmg+DQo+ID4gPj4+ICAjaW5jbHVkZSA8bGludXgvZGV2
aWNlLmg+DQo+ID4gPj4+ICAjaW5jbHVkZSA8bGludXgvZG1hLWlvbW11Lmg+DQo+ID4gPj4+ICAj
aW5jbHVkZSA8bGludXgvZ2ZwLmg+DQo+ID4gPj4+IEBAIC0yNyw2ICsyOCw3IEBADQo+ID4gPj4+
ICAjaW5jbHVkZSA8bGludXgvaW92YS5oPg0KPiA+ID4+PiAgI2luY2x1ZGUgPGxpbnV4L2lycS5o
Pg0KPiA+ID4+PiAgI2luY2x1ZGUgPGxpbnV4L21tLmg+DQo+ID4gPj4+ICsjaW5jbHVkZSA8bGlu
dXgvb2ZfaW9tbXUuaD4NCj4gPiA+Pj4gICNpbmNsdWRlIDxsaW51eC9wY2kuaD4NCj4gPiA+Pj4g
ICNpbmNsdWRlIDxsaW51eC9zY2F0dGVybGlzdC5oPg0KPiA+ID4+PiAgI2luY2x1ZGUgPGxpbnV4
L3ZtYWxsb2MuaD4NCj4gPiA+Pj4gQEAgLTE5OCw2ICsyMDAsMjQgQEAgdm9pZCBpb21tdV9kbWFf
Z2V0X3Jlc3ZfcmVnaW9ucyhzdHJ1Y3QNCj4gZGV2aWNlDQo+ID4gPj4gKmRldiwgc3RydWN0IGxp
c3RfaGVhZCAqbGlzdCkNCj4gPiA+Pj4gIH0NCj4gPiA+Pj4gIEVYUE9SVF9TWU1CT0woaW9tbXVf
ZG1hX2dldF9yZXN2X3JlZ2lvbnMpOw0KPiA+ID4+Pg0KPiA+ID4+PiArLyoqDQo+ID4gPj4+ICsg
KiBpb21tdV9kbWFfZ2V0X21zaV9yZXN2X3JlZ2lvbnMgLSBSZXNlcnZlZCByZWdpb24gZHJpdmVy
IGhlbHBlcg0KPiA+ID4+PiArICogQGRldjogRGV2aWNlIGZyb20gaW9tbXVfZ2V0X3Jlc3ZfcmVn
aW9ucygpDQo+ID4gPj4+ICsgKiBAbGlzdDogUmVzZXJ2ZWQgcmVnaW9uIGxpc3QgZnJvbSBpb21t
dV9nZXRfcmVzdl9yZWdpb25zKCkNCj4gPiA+Pj4gKyAqDQo+ID4gPj4+ICsgKiBJT01NVSBkcml2
ZXJzIGNhbiB1c2UgdGhpcyB0byBpbXBsZW1lbnQgdGhlaXINCj4gPiA+Pj4gKy5nZXRfcmVzdl9y
ZWdpb25zDQo+ID4gPj4+ICsgKiBjYWxsYmFjayBmb3IgSFcgTVNJIHNwZWNpZmljIHJlc2VydmF0
aW9ucy4gRm9yIG5vdywgdGhpcyBvbmx5DQo+ID4NCj4gPiBUaGlzIGRvZXNuJ3QgbWFrZSBhbiBh
d2Z1bCBsb3Qgb2Ygc2Vuc2UgLSB0aGVyZSdzIG9ubHkgb25lIHJlc2VydmVkDQo+ID4gcmVnaW9u
IGNhbGxiYWNrLCBzbyBpb21tdS1kbWEgc2hvdWxkbid0IGJlIG9mZmVyaW5nIHR3byBzZXBhcmF0
ZSBhbmQNCj4gPiBub24tb3ZlcmxhcHBpbmcgaW1wbGVtZW50YXRpb25zLg0KPiA+DQo+ID4gPj4+
ICsgKiBjb3ZlcnMgSVRTIE1TSSByZWdpb24gcmVzZXJ2YXRpb24gdXNpbmcgQUNQSSBJT1JUIGhl
bHBlciBmdW5jdGlvbi4NCj4gPiA+Pj4gKyAqLw0KPiA+ID4+PiAraW50IGlvbW11X2RtYV9nZXRf
bXNpX3Jlc3ZfcmVnaW9ucyhzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdA0KPiA+IGxpc3RfaGVh
ZA0KPiA+ID4+ICpsaXN0KQ0KPiA+ID4+PiArew0KPiA+ID4+PiArCWlmICghaXNfb2Zfbm9kZShk
ZXYtPmlvbW11X2Z3c3BlYy0+aW9tbXVfZndub2RlKSkNCj4gPiA+Pj4gKwkJcmV0dXJuIGlvcnRf
aW9tbXVfbXNpX2dldF9yZXN2X3JlZ2lvbnMoZGV2LCBsaXN0KTsNCj4gPg0KPiA+IEVpdGhlciB0
aGlzIGNhbGwga25vd3MgaG93IHRvIGRvIHRoZSByaWdodCB0aGluZyBmb3IgYW55IHBsYXRmb3Jt
IGFuZA0KPiA+IHNob3VsZCBiZSBtYWRlIGZyb20gaW9tbXVfZG1hX2dldF9yZXNlcnZlZF9yZWdp
b25zKCkgZGlyZWN0bHksIG9yIGl0J3MNCj4gPiB0aWdodGx5IGNvdXBsZWQgdG8gdGhlIEhpU2ls
aWNvbiBxdWlyayBpbiB0aGUgU01NVXYzIGRyaXZlciBhbmQNCj4gPiBpb21tdS1kbWEgZG9lc24n
dCBuZWVkIHRvIGtub3cgLSB0aGUgbWlkZGxlIGdyb3VuZCBwcmVzZW50ZWQgaGVyZSBpcw0KPiA+
IHN1cmVseSB0aGUgd29yc3Qgb2YgYm90aCB3b3JsZHMuDQo+IA0KPiBSaWdodC4gSSB0aGluayB3
ZSBoYXZlIGRpc2N1c3NlZCB0aGlzIGVhcmxpZXJbMV0gYW5kIGhhZCBhIHY0IGJhc2VkIG9uIGlu
dm9raW5nDQo+IHRoZSBpb3J0X2lvbW11X2l0c19nZXRfcmVzdl9yZWdpb25zKCkgd2l0aGluIHRo
ZQ0KPiBpb21tdV9kbWFfZ2V0X3Jlc3ZfcmVnaW9ucygpLg0KPiBCdXQgbGF0ZXIgYXMgeW91IHJp
Z2h0bHkgcG9pbnRlZCBvdXQsIHdlIHdlcmUgbm90IGNoZWNraW5nIGZvciBwbGF0Zm9ybXMgd2hp
Y2gNCj4gcmVxdWlyZXMgdGhpcyBxdWlyayBpbnNpZGUgdGhlIGlvcnQgY29kZSBhbmQgdGhhdCB3
aWxsIGJyZWFrIHRoZSBwbGF0Zm9ybXMgd2hpY2gNCj4gYXJlIGhhcHB5IHdpdGggTVNJIHRyYW5z
bGF0aW9ucy4gSGVuY2UgbW92ZWQgdG8gdGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb24NCj4gaW4g
djYgYWZ0ZXIgdGhpcyBkaXNjdXNzaW9uIGhlcmVbMl0NCj4gDQo+IEFuZCBlYXJsaWVyIEkgdGhp
bmsgaW4gdGhlIHYzIHZlcnNpb24gd2UgaGFkIHRoZSBmdW5jdGlvbiBjYWxsZWQgZnJvbSBzbW11
DQo+IGRyaXZlciBkaXJlY3RseSBhbmQgdGhlIGZlZWRiYWNrIHdhcyB0aGF0IGl0IHNob3VsZCBi
ZSBhYnN0cmFjdGVkIGZyb20gdGhlDQo+IGRyaXZlci4NCj4gDQo+IE1heSBiZSBpdCBpcyBzdGls
bCBwb3NzaWJsZSB0byBtb3ZlIHRoZSBmdW5jdGlvbiBjYWxsIGluc2lkZSB0aGUNCj4gaW9tbXVf
ZG1hX2dldF9yZXN2X3JlZ2lvbnMoKSBhbmQgZG8gdGhlIHNtbXUgbW9kZWwgY2hlY2sgaW5zaWRl
ICB0aGUgaW9ydA0KPiBoZWxwZXIgZnVuY3Rpb24gYW5kIHNlbGVjdGl2ZWx5IGFwcGx5IHRoZSBI
VyBNU0kgcmVzZXJ2YXRpb25zLg0KPiANCj4gQnV0IEkgdGhpbmsgaXQgaXMgbXVjaCBuZWF0ZXIg
aWYgd2UgY2FuIGludm9rZSB0aGUgaW9ydF9nZXRfbXNpX3JlZ2lvbnMoKQ0KPiBkaXJlY3RseSBm
cm9tIFNNTVV2MyBiYXNlZCBvbiB0aGUgbW9kZWwuDQo+IA0KPiBUaG91Z2h0cz8NCg0KQXMgd2Ug
c3RpbGwgZG9u4oCZdCBoYXZlIGEgY2xlYXIgcmVzb2x1dGlvbiBvbiBob3cgdG8gaW52b2tlIHRo
ZSANCmlvcnRfaW9tbXVfbXNpX2dldF9yZXN2X3JlZ2lvbnMoKSwgSSBoYXZlIGdvbmUgYmFjayBh
bmQgYXR0ZW1wdGVkIHRvIG1vdmUgdGhlDQpzbW11IG1vZGVsIGNoZWNrIGluc2lkZSB0aGUgaW9y
dCBjb2RlLiBUaGlzIG1lYW5zIHRoZSBmdW5jdGlvbiB3aWxsIHNlbGVjdGl2ZWx5DQphcHBseSBI
VyBNU0kgcmVzZXJ2YXRpb24gYmFzZWQgb24gdGhlIHBsYXRmb3JtIGFuZCBhbHNvIHRoZSBmdW5j
dGlvbiBjYW4gYmUgDQppbnZva2VkIGZyb20gdGhlIGlvbW11X2RtYV9nZXRfcmVzdl9yZWdpb25z
KCkgZGlyZWN0bHkuDQoNCkNvdWxkIHlvdSBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGJlbG93
IHNuaXBwZXQgYW5kIGxldCBtZSBrbm93IHlvdXIgZmVlZGJhY2suDQpIb3BlIHdlIGNhbiBtYWtl
IHNvbWUgcHJvZ3Jlc3Mgb24gdGhpcyBzZXJpZXMuDQoNClRoYW5rcywNClNoYW1lZXINCg0KLS0+
OC0tDQpkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL2FybTY0L2lvcnQuYyBiL2RyaXZlcnMvYWNw
aS9hcm02NC9pb3J0LmMNCmluZGV4IDg3NmMwZTEuLmEyNzIzM2QgMTAwNjQ0DQotLS0gYS9kcml2
ZXJzL2FjcGkvYXJtNjQvaW9ydC5jDQorKysgYi9kcml2ZXJzL2FjcGkvYXJtNjQvaW9ydC5jDQpA
QCAtNjE5LDYgKzYxOSwzOSBAQCBzdGF0aWMgaW50IF9fbWF5YmVfdW51c2VkIF9fZ2V0X3BjaV9y
aWQoc3RydWN0IHBjaV9kZXYgKnBkZXYsIHUxNiBhbGlhcywNCiAJcmV0dXJuIDA7DQogfQ0KIA0K
K3N0YXRpYyBib29sIF9fbWF5YmVfdW51c2VkIGlvcnRfaHdfbXNpX3Jlc3ZfZW5hYmxlKHN0cnVj
dCBkZXZpY2UgKmRldiwNCisJCQkJCXN0cnVjdCBhY3BpX2lvcnRfbm9kZSAqbm9kZSkNCit7DQor
CXN0cnVjdCBhY3BpX2lvcnRfbm9kZSAqaW9tbXUgPSBOVUxMOw0KKwlpbnQgaTsNCisNCisJaWYg
KGRldl9pc19wY2koZGV2KSkgew0KKwkJdTMyIHJpZDsNCisNCisJCXBjaV9mb3JfZWFjaF9kbWFf
YWxpYXModG9fcGNpX2RldihkZXYpLCBfX2dldF9wY2lfcmlkLCAmcmlkKTsNCisJCWlvbW11ID0g
aW9ydF9ub2RlX21hcF9pZChub2RlLCByaWQsIE5VTEwsIElPUlRfSU9NTVVfVFlQRSk7DQorCX0g
ZWxzZSB7DQorCQlmb3IgKGkgPSAwOyBpIDwgbm9kZS0+bWFwcGluZ19jb3VudDsgaSsrKSB7DQor
CQkJaW9tbXUgPSBpb3J0X25vZGVfbWFwX3BsYXRmb3JtX2lkKG5vZGUsIE5VTEwsDQorCQkJCQkJ
CUlPUlRfSU9NTVVfVFlQRSwgaSk7DQorCQkJaWYgKGlvbW11KQ0KKwkJCQlicmVhazsNCisJCX0N
CisJfQ0KKw0KKwlpZiAoaW9tbXUgJiYgKGlvbW11LT50eXBlID09IEFDUElfSU9SVF9OT0RFX1NN
TVVfVjMpKSB7DQorCQlzdHJ1Y3QgYWNwaV9pb3J0X3NtbXVfdjMgKnNtbXU7DQorDQorCQlzbW11
ID0gKHN0cnVjdCBhY3BpX2lvcnRfc21tdV92MyAqKWlvbW11LT5ub2RlX2RhdGE7DQorCQlpZiAo
c21tdS0+bW9kZWwgPT0gQUNQSV9JT1JUX1NNTVVfVjNfSElTSUxJQ09OX0hJMTYxWCkgew0KKwkJ
CWRldl9ub3RpY2UoZGV2LCAiRW5hYmxpbmcgSGlTaWxpY29uIGVycmF0dW0gMTYxMDEwODAxXG4i
KTsNCisJCQlyZXR1cm4gdHJ1ZTsNCisJCX0NCisJfQ0KKw0KKwlyZXR1cm4gZmFsc2U7DQorfQ0K
Kw0KIHN0YXRpYyBpbnQgYXJtX3NtbXVfaW9ydF94bGF0ZShzdHJ1Y3QgZGV2aWNlICpkZXYsIHUz
MiBzdHJlYW1pZCwNCiAJCQkgICAgICAgc3RydWN0IGZ3bm9kZV9oYW5kbGUgKmZ3bm9kZSwNCiAJ
CQkgICAgICAgY29uc3Qgc3RydWN0IGlvbW11X29wcyAqb3BzKQ0KQEAgLTY4Miw2ICs3MTUsOSBA
QCBpbnQgaW9ydF9pb21tdV9tc2lfZ2V0X3Jlc3ZfcmVnaW9ucyhzdHJ1Y3QgZGV2aWNlICpkZXYs
IHN0cnVjdCBsaXN0X2hlYWQgKmhlYWQpDQogCWlmICghbm9kZSkNCiAJCXJldHVybiAtRU5PREVW
Ow0KIA0KKwlpZiAoIWlvcnRfaHdfbXNpX3Jlc3ZfZW5hYmxlKGRldiwgbm9kZSkpDQorCQlyZXR1
cm4gMDsNCisNCiAJLyoNCiAJICogQ3VycmVudCBsb2dpYyB0byByZXNlcnZlIElUUyByZWdpb25z
IHJlbGllcyBvbiBIVyB0b3BvbG9naWVzDQogCSAqIHdoZXJlIGEgZ2l2ZW4gUENJIG9yIG5hbWVk
IGNvbXBvbmVudCBtYXBzIGl0cyBJRHMgdG8gb25seSBvbmUNCmRpZmYgLS1naXQgYS9kcml2ZXJz
L2lvbW11L2RtYS1pb21tdS5jIGIvZHJpdmVycy9pb21tdS9kbWEtaW9tbXUuYw0KaW5kZXggOWQx
Y2ViZS4uNjdjNmUzMCAxMDA2NDQNCi0tLSBhL2RyaXZlcnMvaW9tbXUvZG1hLWlvbW11LmMNCisr
KyBiL2RyaXZlcnMvaW9tbXUvZG1hLWlvbW11LmMNCkBAIC0xOSw2ICsxOSw3IEBADQogICogYWxv
bmcgd2l0aCB0aGlzIHByb2dyYW0uICBJZiBub3QsIHNlZSA8aHR0cDovL3d3dy5nbnUub3JnL2xp
Y2Vuc2VzLz4uDQogICovDQogDQorI2luY2x1ZGUgPGxpbnV4L2FjcGlfaW9ydC5oPg0KICNpbmNs
dWRlIDxsaW51eC9kZXZpY2UuaD4NCiAjaW5jbHVkZSA8bGludXgvZG1hLWlvbW11Lmg+DQogI2lu
Y2x1ZGUgPGxpbnV4L2dmcC5oPg0KQEAgLTE3NCw2ICsxNzUsMTAgQEAgdm9pZCBpb21tdV9kbWFf
Z2V0X3Jlc3ZfcmVnaW9ucyhzdHJ1Y3QgZGV2aWNlICpkZXYsIHN0cnVjdCBsaXN0X2hlYWQgKmxp
c3QpDQogCXN0cnVjdCBwY2lfaG9zdF9icmlkZ2UgKmJyaWRnZTsNCiAJc3RydWN0IHJlc291cmNl
X2VudHJ5ICp3aW5kb3c7DQogDQorCWlmICghaXNfb2Zfbm9kZShkZXYtPmlvbW11X2Z3c3BlYy0+
aW9tbXVfZndub2RlKSAmJg0KKwkJaW9ydF9pb21tdV9tc2lfZ2V0X3Jlc3ZfcmVnaW9ucyhkZXYs
IGxpc3QpIDwgMCkNCisJCXJldHVybjsNCisNCiAJaWYgKCFkZXZfaXNfcGNpKGRldikpDQogCQly
ZXR1cm47DQogDQpkaWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9hY3BpX2lvcnQuaCBiL2luY2x1
ZGUvbGludXgvYWNwaV9pb3J0LmgNCmluZGV4IDE4MmE1NzcuLjg4ZjE3YzkgMTAwNjQ0DQotLS0g
YS9pbmNsdWRlL2xpbnV4L2FjcGlfaW9ydC5oDQorKysgYi9pbmNsdWRlL2xpbnV4L2FjcGlfaW9y
dC5oDQpAQCAtNTYsNyArNTYsNyBAQCBjb25zdCBzdHJ1Y3QgaW9tbXVfb3BzICppb3J0X2lvbW11
X2NvbmZpZ3VyZShzdHJ1Y3QgZGV2aWNlICpkZXYpDQogeyByZXR1cm4gTlVMTDsgfQ0KIHN0YXRp
YyBpbmxpbmUNCiBpbnQgaW9ydF9pb21tdV9tc2lfZ2V0X3Jlc3ZfcmVnaW9ucyhzdHJ1Y3QgZGV2
aWNlICpkZXYsIHN0cnVjdCBsaXN0X2hlYWQgKmhlYWQpDQoteyByZXR1cm4gLUVOT0RFVjsgfQ0K
K3sgcmV0dXJuIDA7IH0NCiAjZW5kaWYNCiANCiAjZW5kaWYgLyogX19BQ1BJX0lPUlRfSF9fICov
DQoNCi0tPjgtLQ0KDQogDQoNCg==

Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Lorenzo Pieralisi]

On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > > list_head
> > > >> *list)
> > > >>> +{
> > > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> > >
> > > Either this call knows how to do the right thing for any platform and
> > > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > > iommu-dma doesn't need to know - the middle ground presented here is
> > > surely the worst of both worlds.
> > 
> > Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> > the iort_iommu_its_get_resv_regions() within the
> > iommu_dma_get_resv_regions().
> > But later as you rightly pointed out, we were not checking for platforms which
> > requires this quirk inside the iort code and that will break the platforms which
> > are happy with MSI translations. Hence moved to the current implementation
> > in v6 after this discussion here[2]
> > 
> > And earlier I think in the v3 version we had the function called from smmu
> > driver directly and the feedback was that it should be abstracted from the
> > driver.
> > 
> > May be it is still possible to move the function call inside the
> > iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> > helper function and selectively apply the HW MSI reservations.
> > 
> > But I think it is much neater if we can invoke the iort_get_msi_regions()
> > directly from SMMUv3 based on the model.
> > 
> > Thoughts?
> 
> As we still don’t have a clear resolution on how to invoke the 
> iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
> smmu model check inside the iort code. This means the function will selectively
> apply HW MSI reservation based on the platform and also the function can be 
> invoked from the iommu_dma_get_resv_regions() directly.
> 
> Could you please take a look at the below snippet and let me know your feedback.
> Hope we can make some progress on this series.
> 
> Thanks,
> Shameer
> 
> -->8--
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 876c0e1..a27233d 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
>  	return 0;
>  }
>  
> +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> +					struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_node *iommu = NULL;
> +	int i;
> +
> +	if (dev_is_pci(dev)) {
> +		u32 rid;
> +
> +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> +		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
> +	} else {
> +		for (i = 0; i < node->mapping_count; i++) {
> +			iommu = iort_node_map_platform_id(node, NULL,
> +							IORT_IOMMU_TYPE, i);
> +			if (iommu)
> +				break;
> +		}
> +	}

You do not need (and I do not want this code) to do the mapping again.

You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
you can retrieve the SMMU IORT node by a simple look-up and carry out the
check below.

It would be simpler to set an option in the SMMUv3 driver but then
you go back to square one with DT/ACPI SMMUv3 driver awareness so, if,
with the change above this can make the generic approach work (ie Robin
is happy with it) I am fine with this IORT update as well.

Lorenzo

> +
> +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> +		struct acpi_iort_smmu_v3 *smmu;
> +
> +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> +		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> +			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
> +			return true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
>  			       struct fwnode_handle *fwnode,
>  			       const struct iommu_ops *ops)
> @@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
>  	if (!node)
>  		return -ENODEV;
>  
> +	if (!iort_hw_msi_resv_enable(dev, node))
> +		return 0;
> +
>  	/*
>  	 * Current logic to reserve ITS regions relies on HW topologies
>  	 * where a given PCI or named component maps its IDs to only one
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..67c6e30 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  	struct pci_host_bridge *bridge;
>  	struct resource_entry *window;
>  
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> +		return;
> +
>  	if (!dev_is_pci(dev))
>  		return;
>  
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 182a577..88f17c9 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  { return NULL; }
>  static inline
>  int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> -{ return -ENODEV; }
> +{ return 0; }
>  #endif
>  
>  #endif /* __ACPI_IORT_H__ */
> 
> -->8--
> 
>  
> 

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Lorenzo Pieralisi]

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

On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > > list_head
> > > >> *list)
> > > >>> +{
> > > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> > >
> > > Either this call knows how to do the right thing for any platform and
> > > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > > iommu-dma doesn't need to know - the middle ground presented here is
> > > surely the worst of both worlds.
> > 
> > Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> > the iort_iommu_its_get_resv_regions() within the
> > iommu_dma_get_resv_regions().
> > But later as you rightly pointed out, we were not checking for platforms which
> > requires this quirk inside the iort code and that will break the platforms which
> > are happy with MSI translations. Hence moved to the current implementation
> > in v6 after this discussion here[2]
> > 
> > And earlier I think in the v3 version we had the function called from smmu
> > driver directly and the feedback was that it should be abstracted from the
> > driver.
> > 
> > May be it is still possible to move the function call inside the
> > iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> > helper function and selectively apply the HW MSI reservations.
> > 
> > But I think it is much neater if we can invoke the iort_get_msi_regions()
> > directly from SMMUv3 based on the model.
> > 
> > Thoughts?
> 
> As we still don’t have a clear resolution on how to invoke the 
> iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
> smmu model check inside the iort code. This means the function will selectively
> apply HW MSI reservation based on the platform and also the function can be 
> invoked from the iommu_dma_get_resv_regions() directly.
> 
> Could you please take a look at the below snippet and let me know your feedback.
> Hope we can make some progress on this series.
> 
> Thanks,
> Shameer
> 
> -->8--
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 876c0e1..a27233d 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
>  	return 0;
>  }
>  
> +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> +					struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_node *iommu = NULL;
> +	int i;
> +
> +	if (dev_is_pci(dev)) {
> +		u32 rid;
> +
> +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> +		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
> +	} else {
> +		for (i = 0; i < node->mapping_count; i++) {
> +			iommu = iort_node_map_platform_id(node, NULL,
> +							IORT_IOMMU_TYPE, i);
> +			if (iommu)
> +				break;
> +		}
> +	}

You do not need (and I do not want this code) to do the mapping again.

You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
you can retrieve the SMMU IORT node by a simple look-up and carry out the
check below.

It would be simpler to set an option in the SMMUv3 driver but then
you go back to square one with DT/ACPI SMMUv3 driver awareness so, if,
with the change above this can make the generic approach work (ie Robin
is happy with it) I am fine with this IORT update as well.

Lorenzo

> +
> +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> +		struct acpi_iort_smmu_v3 *smmu;
> +
> +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> +		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> +			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
> +			return true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
>  			       struct fwnode_handle *fwnode,
>  			       const struct iommu_ops *ops)
> @@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
>  	if (!node)
>  		return -ENODEV;
>  
> +	if (!iort_hw_msi_resv_enable(dev, node))
> +		return 0;
> +
>  	/*
>  	 * Current logic to reserve ITS regions relies on HW topologies
>  	 * where a given PCI or named component maps its IDs to only one
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..67c6e30 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  	struct pci_host_bridge *bridge;
>  	struct resource_entry *window;
>  
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> +		return;
> +
>  	if (!dev_is_pci(dev))
>  		return;
>  
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 182a577..88f17c9 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  { return NULL; }
>  static inline
>  int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> -{ return -ENODEV; }
> +{ return 0; }
>  #endif
>  
>  #endif /* __ACPI_IORT_H__ */
> 
> -->8--
> 
>  
> 

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Lorenzo Pieralisi]

On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > >>> +int iommu_dma_get_msi_resv_regions(struct device *dev, struct
> > > list_head
> > > >> *list)
> > > >>> +{
> > > >>> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode))
> > > >>> +		return iort_iommu_msi_get_resv_regions(dev, list);
> > >
> > > Either this call knows how to do the right thing for any platform and
> > > should be made from iommu_dma_get_reserved_regions() directly, or it's
> > > tightly coupled to the HiSilicon quirk in the SMMUv3 driver and
> > > iommu-dma doesn't need to know - the middle ground presented here is
> > > surely the worst of both worlds.
> > 
> > Right. I think we have discussed this earlier[1] and had a v4 based on invoking
> > the iort_iommu_its_get_resv_regions() within the
> > iommu_dma_get_resv_regions().
> > But later as you rightly pointed out, we were not checking for platforms which
> > requires this quirk inside the iort code and that will break the platforms which
> > are happy with MSI translations. Hence moved to the current implementation
> > in v6 after this discussion here[2]
> > 
> > And earlier I think in the v3 version we had the function called from smmu
> > driver directly and the feedback was that it should be abstracted from the
> > driver.
> > 
> > May be it is still possible to move the function call inside the
> > iommu_dma_get_resv_regions() and do the smmu model check inside  the iort
> > helper function and selectively apply the HW MSI reservations.
> > 
> > But I think it is much neater if we can invoke the iort_get_msi_regions()
> > directly from SMMUv3 based on the model.
> > 
> > Thoughts?
> 
> As we still don?t have a clear resolution on how to invoke the 
> iort_iommu_msi_get_resv_regions(), I have gone back and attempted to move the
> smmu model check inside the iort code. This means the function will selectively
> apply HW MSI reservation based on the platform and also the function can be 
> invoked from the iommu_dma_get_resv_regions() directly.
> 
> Could you please take a look at the below snippet and let me know your feedback.
> Hope we can make some progress on this series.
> 
> Thanks,
> Shameer
> 
> -->8--
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 876c0e1..a27233d 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct pci_dev *pdev, u16 alias,
>  	return 0;
>  }
>  
> +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> +					struct acpi_iort_node *node)
> +{
> +	struct acpi_iort_node *iommu = NULL;
> +	int i;
> +
> +	if (dev_is_pci(dev)) {
> +		u32 rid;
> +
> +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> +		iommu = iort_node_map_id(node, rid, NULL, IORT_IOMMU_TYPE);
> +	} else {
> +		for (i = 0; i < node->mapping_count; i++) {
> +			iommu = iort_node_map_platform_id(node, NULL,
> +							IORT_IOMMU_TYPE, i);
> +			if (iommu)
> +				break;
> +		}
> +	}

You do not need (and I do not want this code) to do the mapping again.

You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
you can retrieve the SMMU IORT node by a simple look-up and carry out the
check below.

It would be simpler to set an option in the SMMUv3 driver but then
you go back to square one with DT/ACPI SMMUv3 driver awareness so, if,
with the change above this can make the generic approach work (ie Robin
is happy with it) I am fine with this IORT update as well.

Lorenzo

> +
> +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> +		struct acpi_iort_smmu_v3 *smmu;
> +
> +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> +		if (smmu->model == ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> +			dev_notice(dev, "Enabling HiSilicon erratum 161010801\n");
> +			return true;
> +		}
> +	}
> +
> +	return false;
> +}
> +
>  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
>  			       struct fwnode_handle *fwnode,
>  			       const struct iommu_ops *ops)
> @@ -682,6 +715,9 @@ int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
>  	if (!node)
>  		return -ENODEV;
>  
> +	if (!iort_hw_msi_resv_enable(dev, node))
> +		return 0;
> +
>  	/*
>  	 * Current logic to reserve ITS regions relies on HW topologies
>  	 * where a given PCI or named component maps its IDs to only one
> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> index 9d1cebe..67c6e30 100644
> --- a/drivers/iommu/dma-iommu.c
> +++ b/drivers/iommu/dma-iommu.c
> @@ -19,6 +19,7 @@
>   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
>   */
>  
> +#include <linux/acpi_iort.h>
>  #include <linux/device.h>
>  #include <linux/dma-iommu.h>
>  #include <linux/gfp.h>
> @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device *dev, struct list_head *list)
>  	struct pci_host_bridge *bridge;
>  	struct resource_entry *window;
>  
> +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> +		return;
> +
>  	if (!dev_is_pci(dev))
>  		return;
>  
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index 182a577..88f17c9 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct device *dev)
>  { return NULL; }
>  static inline
>  int iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head *head)
> -{ return -ENODEV; }
> +{ return 0; }
>  #endif
>  
>  #endif /* __ACPI_IORT_H__ */
> 
> -->8--
> 
>  
> 

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi@arm.com]
> Sent: Friday, November 03, 2017 11:35 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Robin Murphy <robin.murphy@arm.com>; Will Deacon
> <will.deacon@arm.com>; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> marc.zyngier@arm.com; linux-pci@vger.kernel.org; joro@8bytes.org; John
> Garry <john.garry@huawei.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>; Linuxarm <linuxarm@huawei.com>; linux-
> acpi@vger.kernel.org; iommu@lists.linux-foundation.org; Wangzhou (B)
> <wangzhou1@hisilicon.com>; sudeep.holla@arm.com; bhelgaas@google.com;
> linux-arm-kernel@lists.infradead.org; devel@acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:
> 
[..]

> >
> > As we still don’t have a clear resolution on how to invoke the
> > iort_iommu_msi_get_resv_regions(), I have gone back and attempted to
> > move the smmu model check inside the iort code. This means the
> > function will selectively apply HW MSI reservation based on the
> > platform and also the function can be invoked from the
> iommu_dma_get_resv_regions() directly.
> >
> > Could you please take a look at the below snippet and let me know your
> feedback.
> > Hope we can make some progress on this series.
> >
> > Thanks,
> > Shameer
> >
> > -->8--
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 876c0e1..a27233d 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct
> pci_dev *pdev, u16 alias,
> >  	return 0;
> >  }
> >
> > +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> > +					struct acpi_iort_node *node)
> > +{
> > +	struct acpi_iort_node *iommu = NULL;
> > +	int i;
> > +
> > +	if (dev_is_pci(dev)) {
> > +		u32 rid;
> > +
> > +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> > +		iommu = iort_node_map_id(node, rid, NULL,
> IORT_IOMMU_TYPE);
> > +	} else {
> > +		for (i = 0; i < node->mapping_count; i++) {
> > +			iommu = iort_node_map_platform_id(node, NULL,
> > +							IORT_IOMMU_TYPE,
> i);
> > +			if (iommu)
> > +				break;
> > +		}
> > +	}
> 
> You do not need (and I do not want this code) to do the mapping again.
> 
> You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
> you can retrieve the SMMU IORT node by a simple look-up and carry out the
> check below.

Ok. Understood. I will rework this part then.

> It would be simpler to set an option in the SMMUv3 driver but then you go back
> to square one with DT/ACPI SMMUv3 driver awareness so, if, with the change
> above this can make the generic approach work (ie Robin is happy with it) I am
> fine with this IORT update as well.

Thanks Lorenzo. I will rebase on top of rc1 and prepare v10 with these changes
and sent it out.

Shameer 

> > +
> > +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> > +		struct acpi_iort_smmu_v3 *smmu;
> > +
> > +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> > +		if (smmu->model ==
> ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> > +			dev_notice(dev, "Enabling HiSilicon erratum
> 161010801\n");
> > +			return true;
> > +		}
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
> >  			       struct fwnode_handle *fwnode,
> >  			       const struct iommu_ops *ops) @@ -682,6 +715,9
> @@ int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> *head)
> >  	if (!node)
> >  		return -ENODEV;
> >
> > +	if (!iort_hw_msi_resv_enable(dev, node))
> > +		return 0;
> > +
> >  	/*
> >  	 * Current logic to reserve ITS regions relies on HW topologies
> >  	 * where a given PCI or named component maps its IDs to only one
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..67c6e30 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  	struct pci_host_bridge *bridge;
> >  	struct resource_entry *window;
> >
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> > +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> > +		return;
> > +
> >  	if (!dev_is_pci(dev))
> >  		return;
> >
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index 182a577..88f17c9 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct
> > device *dev)  { return NULL; }  static inline  int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> > *head) -{ return -ENODEV; }
> > +{ return 0; }
> >  #endif
> >
> >  #endif /* __ACPI_IORT_H__ */
> >
> > -->8--
> >
> >
> >

Re: [Devel] [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

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



> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi(a)arm.com]
> Sent: Friday, November 03, 2017 11:35 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: Robin Murphy <robin.murphy(a)arm.com>; Will Deacon
> <will.deacon(a)arm.com>; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> marc.zyngier(a)arm.com; linux-pci(a)vger.kernel.org; joro(a)8bytes.org; John
> Garry <john.garry(a)huawei.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>; Linuxarm <linuxarm(a)huawei.com>; linux-
> acpi(a)vger.kernel.org; iommu(a)lists.linux-foundation.org; Wangzhou (B)
> <wangzhou1(a)hisilicon.com>; sudeep.holla(a)arm.com; bhelgaas(a)google.com;
> linux-arm-kernel(a)lists.infradead.org; devel(a)acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:
> 
[..]

> >
> > As we still don’t have a clear resolution on how to invoke the
> > iort_iommu_msi_get_resv_regions(), I have gone back and attempted to
> > move the smmu model check inside the iort code. This means the
> > function will selectively apply HW MSI reservation based on the
> > platform and also the function can be invoked from the
> iommu_dma_get_resv_regions() directly.
> >
> > Could you please take a look at the below snippet and let me know your
> feedback.
> > Hope we can make some progress on this series.
> >
> > Thanks,
> > Shameer
> >
> > -->8--
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 876c0e1..a27233d 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct
> pci_dev *pdev, u16 alias,
> >  	return 0;
> >  }
> >
> > +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> > +					struct acpi_iort_node *node)
> > +{
> > +	struct acpi_iort_node *iommu = NULL;
> > +	int i;
> > +
> > +	if (dev_is_pci(dev)) {
> > +		u32 rid;
> > +
> > +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> > +		iommu = iort_node_map_id(node, rid, NULL,
> IORT_IOMMU_TYPE);
> > +	} else {
> > +		for (i = 0; i < node->mapping_count; i++) {
> > +			iommu = iort_node_map_platform_id(node, NULL,
> > +							IORT_IOMMU_TYPE,
> i);
> > +			if (iommu)
> > +				break;
> > +		}
> > +	}
> 
> You do not need (and I do not want this code) to do the mapping again.
> 
> You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
> you can retrieve the SMMU IORT node by a simple look-up and carry out the
> check below.

Ok. Understood. I will rework this part then.

> It would be simpler to set an option in the SMMUv3 driver but then you go back
> to square one with DT/ACPI SMMUv3 driver awareness so, if, with the change
> above this can make the generic approach work (ie Robin is happy with it) I am
> fine with this IORT update as well.

Thanks Lorenzo. I will rebase on top of rc1 and prepare v10 with these changes
and sent it out.

Shameer 

> > +
> > +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> > +		struct acpi_iort_smmu_v3 *smmu;
> > +
> > +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> > +		if (smmu->model ==
> ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> > +			dev_notice(dev, "Enabling HiSilicon erratum
> 161010801\n");
> > +			return true;
> > +		}
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
> >  			       struct fwnode_handle *fwnode,
> >  			       const struct iommu_ops *ops) @@ -682,6 +715,9
> @@ int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> *head)
> >  	if (!node)
> >  		return -ENODEV;
> >
> > +	if (!iort_hw_msi_resv_enable(dev, node))
> > +		return 0;
> > +
> >  	/*
> >  	 * Current logic to reserve ITS regions relies on HW topologies
> >  	 * where a given PCI or named component maps its IDs to only one
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..67c6e30 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  	struct pci_host_bridge *bridge;
> >  	struct resource_entry *window;
> >
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> > +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> > +		return;
> > +
> >  	if (!dev_is_pci(dev))
> >  		return;
> >
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index 182a577..88f17c9 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct
> > device *dev)  { return NULL; }  static inline  int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> > *head) -{ return -ENODEV; }
> > +{ return 0; }
> >  #endif
> >
> >  #endif /* __ACPI_IORT_H__ */
> >
> > -->8--
> >
> >
> >

[PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Lorenzo Pieralisi [mailto:lorenzo.pieralisi at arm.com]
> Sent: Friday, November 03, 2017 11:35 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: Robin Murphy <robin.murphy@arm.com>; Will Deacon
> <will.deacon@arm.com>; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> marc.zyngier at arm.com; linux-pci at vger.kernel.org; joro at 8bytes.org; John
> Garry <john.garry@huawei.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>; Linuxarm <linuxarm@huawei.com>; linux-
> acpi at vger.kernel.org; iommu at lists.linux-foundation.org; Wangzhou (B)
> <wangzhou1@hisilicon.com>; sudeep.holla at arm.com; bhelgaas at google.com;
> linux-arm-kernel at lists.infradead.org; devel at acpica.org
> Subject: Re: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW
> MSI address regions for IOMMU drivers
> 
> On Thu, Oct 26, 2017 at 10:11:58AM +0000, Shameerali Kolothum Thodi wrote:
> 
[..]

> >
> > As we still don?t have a clear resolution on how to invoke the
> > iort_iommu_msi_get_resv_regions(), I have gone back and attempted to
> > move the smmu model check inside the iort code. This means the
> > function will selectively apply HW MSI reservation based on the
> > platform and also the function can be invoked from the
> iommu_dma_get_resv_regions() directly.
> >
> > Could you please take a look at the below snippet and let me know your
> feedback.
> > Hope we can make some progress on this series.
> >
> > Thanks,
> > Shameer
> >
> > -->8--
> > diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> > index 876c0e1..a27233d 100644
> > --- a/drivers/acpi/arm64/iort.c
> > +++ b/drivers/acpi/arm64/iort.c
> > @@ -619,6 +619,39 @@ static int __maybe_unused __get_pci_rid(struct
> pci_dev *pdev, u16 alias,
> >  	return 0;
> >  }
> >
> > +static bool __maybe_unused iort_hw_msi_resv_enable(struct device *dev,
> > +					struct acpi_iort_node *node)
> > +{
> > +	struct acpi_iort_node *iommu = NULL;
> > +	int i;
> > +
> > +	if (dev_is_pci(dev)) {
> > +		u32 rid;
> > +
> > +		pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid, &rid);
> > +		iommu = iort_node_map_id(node, rid, NULL,
> IORT_IOMMU_TYPE);
> > +	} else {
> > +		for (i = 0; i < node->mapping_count; i++) {
> > +			iommu = iort_node_map_platform_id(node, NULL,
> > +							IORT_IOMMU_TYPE,
> i);
> > +			if (iommu)
> > +				break;
> > +		}
> > +	}
> 
> You do not need (and I do not want this code) to do the mapping again.
> 
> You have the fwnode (ie dev->iommu_fwspec) corresponding to the IOMMU,
> you can retrieve the SMMU IORT node by a simple look-up and carry out the
> check below.

Ok. Understood. I will rework this part then.

> It would be simpler to set an option in the SMMUv3 driver but then you go back
> to square one with DT/ACPI SMMUv3 driver awareness so, if, with the change
> above this can make the generic approach work (ie Robin is happy with it) I am
> fine with this IORT update as well.

Thanks Lorenzo. I will rebase on top of rc1 and prepare v10 with these changes
and sent it out.

Shameer 

> > +
> > +	if (iommu && (iommu->type == ACPI_IORT_NODE_SMMU_V3)) {
> > +		struct acpi_iort_smmu_v3 *smmu;
> > +
> > +		smmu = (struct acpi_iort_smmu_v3 *)iommu->node_data;
> > +		if (smmu->model ==
> ACPI_IORT_SMMU_V3_HISILICON_HI161X) {
> > +			dev_notice(dev, "Enabling HiSilicon erratum
> 161010801\n");
> > +			return true;
> > +		}
> > +	}
> > +
> > +	return false;
> > +}
> > +
> >  static int arm_smmu_iort_xlate(struct device *dev, u32 streamid,
> >  			       struct fwnode_handle *fwnode,
> >  			       const struct iommu_ops *ops) @@ -682,6 +715,9
> @@ int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> *head)
> >  	if (!node)
> >  		return -ENODEV;
> >
> > +	if (!iort_hw_msi_resv_enable(dev, node))
> > +		return 0;
> > +
> >  	/*
> >  	 * Current logic to reserve ITS regions relies on HW topologies
> >  	 * where a given PCI or named component maps its IDs to only one
> > diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
> > index 9d1cebe..67c6e30 100644
> > --- a/drivers/iommu/dma-iommu.c
> > +++ b/drivers/iommu/dma-iommu.c
> > @@ -19,6 +19,7 @@
> >   * along with this program.  If not, see <http://www.gnu.org/licenses/>.
> >   */
> >
> > +#include <linux/acpi_iort.h>
> >  #include <linux/device.h>
> >  #include <linux/dma-iommu.h>
> >  #include <linux/gfp.h>
> > @@ -174,6 +175,10 @@ void iommu_dma_get_resv_regions(struct device
> *dev, struct list_head *list)
> >  	struct pci_host_bridge *bridge;
> >  	struct resource_entry *window;
> >
> > +	if (!is_of_node(dev->iommu_fwspec->iommu_fwnode) &&
> > +		iort_iommu_msi_get_resv_regions(dev, list) < 0)
> > +		return;
> > +
> >  	if (!dev_is_pci(dev))
> >  		return;
> >
> > diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> > index 182a577..88f17c9 100644
> > --- a/include/linux/acpi_iort.h
> > +++ b/include/linux/acpi_iort.h
> > @@ -56,7 +56,7 @@ const struct iommu_ops *iort_iommu_configure(struct
> > device *dev)  { return NULL; }  static inline  int
> > iort_iommu_msi_get_resv_regions(struct device *dev, struct list_head
> > *head) -{ return -ENODEV; }
> > +{ return 0; }
> >  #endif
> >
> >  #endif /* __ACPI_IORT_H__ */
> >
> > -->8--
> >
> >
> >

RE: [PATCH v9 2/4] iommu/dma: Add a helper function to reserve HW MSI address regions for IOMMU drivers

[Shameerali Kolothum Thodi]

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTG9yZW56byBQaWVyYWxp
c2kgW21haWx0bzpsb3JlbnpvLnBpZXJhbGlzaUBhcm0uY29tXQ0KPiBTZW50OiBGcmlkYXksIE5v
dmVtYmVyIDAzLCAyMDE3IDExOjM1IEFNDQo+IFRvOiBTaGFtZWVyYWxpIEtvbG90aHVtIFRob2Rp
IDxzaGFtZWVyYWxpLmtvbG90aHVtLnRob2RpQGh1YXdlaS5jb20+DQo+IENjOiBSb2JpbiBNdXJw
aHkgPHJvYmluLm11cnBoeUBhcm0uY29tPjsgV2lsbCBEZWFjb24NCj4gPHdpbGwuZGVhY29uQGFy
bS5jb20+OyBHYWJyaWVsZSBQYW9sb25pIDxnYWJyaWVsZS5wYW9sb25pQGh1YXdlaS5jb20+Ow0K
PiBtYXJjLnp5bmdpZXJAYXJtLmNvbTsgbGludXgtcGNpQHZnZXIua2VybmVsLm9yZzsgam9yb0A4
Ynl0ZXMub3JnOyBKb2huDQo+IEdhcnJ5IDxqb2huLmdhcnJ5QGh1YXdlaS5jb20+OyBHdW9oYW5q
dW4gKEhhbmp1biBHdW8pDQo+IDxndW9oYW5qdW5AaHVhd2VpLmNvbT47IExpbnV4YXJtIDxsaW51
eGFybUBodWF3ZWkuY29tPjsgbGludXgtDQo+IGFjcGlAdmdlci5rZXJuZWwub3JnOyBpb21tdUBs
aXN0cy5saW51eC1mb3VuZGF0aW9uLm9yZzsgV2FuZ3pob3UgKEIpDQo+IDx3YW5nemhvdTFAaGlz
aWxpY29uLmNvbT47IHN1ZGVlcC5ob2xsYUBhcm0uY29tOyBiaGVsZ2Fhc0Bnb29nbGUuY29tOw0K
PiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7IGRldmVsQGFjcGljYS5vcmcN
Cj4gU3ViamVjdDogUmU6IFtQQVRDSCB2OSAyLzRdIGlvbW11L2RtYTogQWRkIGEgaGVscGVyIGZ1
bmN0aW9uIHRvIHJlc2VydmUgSFcNCj4gTVNJIGFkZHJlc3MgcmVnaW9ucyBmb3IgSU9NTVUgZHJp
dmVycw0KPiANCj4gT24gVGh1LCBPY3QgMjYsIDIwMTcgYXQgMTA6MTE6NThBTSArMDAwMCwgU2hh
bWVlcmFsaSBLb2xvdGh1bSBUaG9kaSB3cm90ZToNCj4gDQpbLi5dDQoNCj4gPg0KPiA+IEFzIHdl
IHN0aWxsIGRvbuKAmXQgaGF2ZSBhIGNsZWFyIHJlc29sdXRpb24gb24gaG93IHRvIGludm9rZSB0
aGUNCj4gPiBpb3J0X2lvbW11X21zaV9nZXRfcmVzdl9yZWdpb25zKCksIEkgaGF2ZSBnb25lIGJh
Y2sgYW5kIGF0dGVtcHRlZCB0bw0KPiA+IG1vdmUgdGhlIHNtbXUgbW9kZWwgY2hlY2sgaW5zaWRl
IHRoZSBpb3J0IGNvZGUuIFRoaXMgbWVhbnMgdGhlDQo+ID4gZnVuY3Rpb24gd2lsbCBzZWxlY3Rp
dmVseSBhcHBseSBIVyBNU0kgcmVzZXJ2YXRpb24gYmFzZWQgb24gdGhlDQo+ID4gcGxhdGZvcm0g
YW5kIGFsc28gdGhlIGZ1bmN0aW9uIGNhbiBiZSBpbnZva2VkIGZyb20gdGhlDQo+IGlvbW11X2Rt
YV9nZXRfcmVzdl9yZWdpb25zKCkgZGlyZWN0bHkuDQo+ID4NCj4gPiBDb3VsZCB5b3UgcGxlYXNl
IHRha2UgYSBsb29rIGF0IHRoZSBiZWxvdyBzbmlwcGV0IGFuZCBsZXQgbWUga25vdyB5b3VyDQo+
IGZlZWRiYWNrLg0KPiA+IEhvcGUgd2UgY2FuIG1ha2Ugc29tZSBwcm9ncmVzcyBvbiB0aGlzIHNl
cmllcy4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBTaGFtZWVyDQo+ID4NCj4gPiAtLT44LS0NCj4g
PiBkaWZmIC0tZ2l0IGEvZHJpdmVycy9hY3BpL2FybTY0L2lvcnQuYyBiL2RyaXZlcnMvYWNwaS9h
cm02NC9pb3J0LmMNCj4gPiBpbmRleCA4NzZjMGUxLi5hMjcyMzNkIDEwMDY0NA0KPiA+IC0tLSBh
L2RyaXZlcnMvYWNwaS9hcm02NC9pb3J0LmMNCj4gPiArKysgYi9kcml2ZXJzL2FjcGkvYXJtNjQv
aW9ydC5jDQo+ID4gQEAgLTYxOSw2ICs2MTksMzkgQEAgc3RhdGljIGludCBfX21heWJlX3VudXNl
ZCBfX2dldF9wY2lfcmlkKHN0cnVjdA0KPiBwY2lfZGV2ICpwZGV2LCB1MTYgYWxpYXMsDQo+ID4g
IAlyZXR1cm4gMDsNCj4gPiAgfQ0KPiA+DQo+ID4gK3N0YXRpYyBib29sIF9fbWF5YmVfdW51c2Vk
IGlvcnRfaHdfbXNpX3Jlc3ZfZW5hYmxlKHN0cnVjdCBkZXZpY2UgKmRldiwNCj4gPiArCQkJCQlz
dHJ1Y3QgYWNwaV9pb3J0X25vZGUgKm5vZGUpDQo+ID4gK3sNCj4gPiArCXN0cnVjdCBhY3BpX2lv
cnRfbm9kZSAqaW9tbXUgPSBOVUxMOw0KPiA+ICsJaW50IGk7DQo+ID4gKw0KPiA+ICsJaWYgKGRl
dl9pc19wY2koZGV2KSkgew0KPiA+ICsJCXUzMiByaWQ7DQo+ID4gKw0KPiA+ICsJCXBjaV9mb3Jf
ZWFjaF9kbWFfYWxpYXModG9fcGNpX2RldihkZXYpLCBfX2dldF9wY2lfcmlkLCAmcmlkKTsNCj4g
PiArCQlpb21tdSA9IGlvcnRfbm9kZV9tYXBfaWQobm9kZSwgcmlkLCBOVUxMLA0KPiBJT1JUX0lP
TU1VX1RZUEUpOw0KPiA+ICsJfSBlbHNlIHsNCj4gPiArCQlmb3IgKGkgPSAwOyBpIDwgbm9kZS0+
bWFwcGluZ19jb3VudDsgaSsrKSB7DQo+ID4gKwkJCWlvbW11ID0gaW9ydF9ub2RlX21hcF9wbGF0
Zm9ybV9pZChub2RlLCBOVUxMLA0KPiA+ICsJCQkJCQkJSU9SVF9JT01NVV9UWVBFLA0KPiBpKTsN
Cj4gPiArCQkJaWYgKGlvbW11KQ0KPiA+ICsJCQkJYnJlYWs7DQo+ID4gKwkJfQ0KPiA+ICsJfQ0K
PiANCj4gWW91IGRvIG5vdCBuZWVkIChhbmQgSSBkbyBub3Qgd2FudCB0aGlzIGNvZGUpIHRvIGRv
IHRoZSBtYXBwaW5nIGFnYWluLg0KPiANCj4gWW91IGhhdmUgdGhlIGZ3bm9kZSAoaWUgZGV2LT5p
b21tdV9md3NwZWMpIGNvcnJlc3BvbmRpbmcgdG8gdGhlIElPTU1VLA0KPiB5b3UgY2FuIHJldHJp
ZXZlIHRoZSBTTU1VIElPUlQgbm9kZSBieSBhIHNpbXBsZSBsb29rLXVwIGFuZCBjYXJyeSBvdXQg
dGhlDQo+IGNoZWNrIGJlbG93Lg0KDQpPay4gVW5kZXJzdG9vZC4gSSB3aWxsIHJld29yayB0aGlz
IHBhcnQgdGhlbi4NCg0KPiBJdCB3b3VsZCBiZSBzaW1wbGVyIHRvIHNldCBhbiBvcHRpb24gaW4g
dGhlIFNNTVV2MyBkcml2ZXIgYnV0IHRoZW4geW91IGdvIGJhY2sNCj4gdG8gc3F1YXJlIG9uZSB3
aXRoIERUL0FDUEkgU01NVXYzIGRyaXZlciBhd2FyZW5lc3Mgc28sIGlmLCB3aXRoIHRoZSBjaGFu
Z2UNCj4gYWJvdmUgdGhpcyBjYW4gbWFrZSB0aGUgZ2VuZXJpYyBhcHByb2FjaCB3b3JrIChpZSBS
b2JpbiBpcyBoYXBweSB3aXRoIGl0KSBJIGFtDQo+IGZpbmUgd2l0aCB0aGlzIElPUlQgdXBkYXRl
IGFzIHdlbGwuDQoNClRoYW5rcyBMb3JlbnpvLiBJIHdpbGwgcmViYXNlIG9uIHRvcCBvZiByYzEg
YW5kIHByZXBhcmUgdjEwIHdpdGggdGhlc2UgY2hhbmdlcw0KYW5kIHNlbnQgaXQgb3V0Lg0KDQpT
aGFtZWVyIA0KDQo+ID4gKw0KPiA+ICsJaWYgKGlvbW11ICYmIChpb21tdS0+dHlwZSA9PSBBQ1BJ
X0lPUlRfTk9ERV9TTU1VX1YzKSkgew0KPiA+ICsJCXN0cnVjdCBhY3BpX2lvcnRfc21tdV92MyAq
c21tdTsNCj4gPiArDQo+ID4gKwkJc21tdSA9IChzdHJ1Y3QgYWNwaV9pb3J0X3NtbXVfdjMgKilp
b21tdS0+bm9kZV9kYXRhOw0KPiA+ICsJCWlmIChzbW11LT5tb2RlbCA9PQ0KPiBBQ1BJX0lPUlRf
U01NVV9WM19ISVNJTElDT05fSEkxNjFYKSB7DQo+ID4gKwkJCWRldl9ub3RpY2UoZGV2LCAiRW5h
YmxpbmcgSGlTaWxpY29uIGVycmF0dW0NCj4gMTYxMDEwODAxXG4iKTsNCj4gPiArCQkJcmV0dXJu
IHRydWU7DQo+ID4gKwkJfQ0KPiA+ICsJfQ0KPiA+ICsNCj4gPiArCXJldHVybiBmYWxzZTsNCj4g
PiArfQ0KPiA+ICsNCj4gPiAgc3RhdGljIGludCBhcm1fc21tdV9pb3J0X3hsYXRlKHN0cnVjdCBk
ZXZpY2UgKmRldiwgdTMyIHN0cmVhbWlkLA0KPiA+ICAJCQkgICAgICAgc3RydWN0IGZ3bm9kZV9o
YW5kbGUgKmZ3bm9kZSwNCj4gPiAgCQkJICAgICAgIGNvbnN0IHN0cnVjdCBpb21tdV9vcHMgKm9w
cykgQEAgLTY4Miw2ICs3MTUsOQ0KPiBAQCBpbnQNCj4gPiBpb3J0X2lvbW11X21zaV9nZXRfcmVz
dl9yZWdpb25zKHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGxpc3RfaGVhZA0KPiAqaGVhZCkN
Cj4gPiAgCWlmICghbm9kZSkNCj4gPiAgCQlyZXR1cm4gLUVOT0RFVjsNCj4gPg0KPiA+ICsJaWYg
KCFpb3J0X2h3X21zaV9yZXN2X2VuYWJsZShkZXYsIG5vZGUpKQ0KPiA+ICsJCXJldHVybiAwOw0K
PiA+ICsNCj4gPiAgCS8qDQo+ID4gIAkgKiBDdXJyZW50IGxvZ2ljIHRvIHJlc2VydmUgSVRTIHJl
Z2lvbnMgcmVsaWVzIG9uIEhXIHRvcG9sb2dpZXMNCj4gPiAgCSAqIHdoZXJlIGEgZ2l2ZW4gUENJ
IG9yIG5hbWVkIGNvbXBvbmVudCBtYXBzIGl0cyBJRHMgdG8gb25seSBvbmUNCj4gPiBkaWZmIC0t
Z2l0IGEvZHJpdmVycy9pb21tdS9kbWEtaW9tbXUuYyBiL2RyaXZlcnMvaW9tbXUvZG1hLWlvbW11
LmMNCj4gPiBpbmRleCA5ZDFjZWJlLi42N2M2ZTMwIDEwMDY0NA0KPiA+IC0tLSBhL2RyaXZlcnMv
aW9tbXUvZG1hLWlvbW11LmMNCj4gPiArKysgYi9kcml2ZXJzL2lvbW11L2RtYS1pb21tdS5jDQo+
ID4gQEAgLTE5LDYgKzE5LDcgQEANCj4gPiAgICogYWxvbmcgd2l0aCB0aGlzIHByb2dyYW0uICBJ
ZiBub3QsIHNlZSA8aHR0cDovL3d3dy5nbnUub3JnL2xpY2Vuc2VzLz4uDQo+ID4gICAqLw0KPiA+
DQo+ID4gKyNpbmNsdWRlIDxsaW51eC9hY3BpX2lvcnQuaD4NCj4gPiAgI2luY2x1ZGUgPGxpbnV4
L2RldmljZS5oPg0KPiA+ICAjaW5jbHVkZSA8bGludXgvZG1hLWlvbW11Lmg+DQo+ID4gICNpbmNs
dWRlIDxsaW51eC9nZnAuaD4NCj4gPiBAQCAtMTc0LDYgKzE3NSwxMCBAQCB2b2lkIGlvbW11X2Rt
YV9nZXRfcmVzdl9yZWdpb25zKHN0cnVjdCBkZXZpY2UNCj4gKmRldiwgc3RydWN0IGxpc3RfaGVh
ZCAqbGlzdCkNCj4gPiAgCXN0cnVjdCBwY2lfaG9zdF9icmlkZ2UgKmJyaWRnZTsNCj4gPiAgCXN0
cnVjdCByZXNvdXJjZV9lbnRyeSAqd2luZG93Ow0KPiA+DQo+ID4gKwlpZiAoIWlzX29mX25vZGUo
ZGV2LT5pb21tdV9md3NwZWMtPmlvbW11X2Z3bm9kZSkgJiYNCj4gPiArCQlpb3J0X2lvbW11X21z
aV9nZXRfcmVzdl9yZWdpb25zKGRldiwgbGlzdCkgPCAwKQ0KPiA+ICsJCXJldHVybjsNCj4gPiAr
DQo+ID4gIAlpZiAoIWRldl9pc19wY2koZGV2KSkNCj4gPiAgCQlyZXR1cm47DQo+ID4NCj4gPiBk
aWZmIC0tZ2l0IGEvaW5jbHVkZS9saW51eC9hY3BpX2lvcnQuaCBiL2luY2x1ZGUvbGludXgvYWNw
aV9pb3J0LmgNCj4gPiBpbmRleCAxODJhNTc3Li44OGYxN2M5IDEwMDY0NA0KPiA+IC0tLSBhL2lu
Y2x1ZGUvbGludXgvYWNwaV9pb3J0LmgNCj4gPiArKysgYi9pbmNsdWRlL2xpbnV4L2FjcGlfaW9y
dC5oDQo+ID4gQEAgLTU2LDcgKzU2LDcgQEAgY29uc3Qgc3RydWN0IGlvbW11X29wcyAqaW9ydF9p
b21tdV9jb25maWd1cmUoc3RydWN0DQo+ID4gZGV2aWNlICpkZXYpICB7IHJldHVybiBOVUxMOyB9
ICBzdGF0aWMgaW5saW5lICBpbnQNCj4gPiBpb3J0X2lvbW11X21zaV9nZXRfcmVzdl9yZWdpb25z
KHN0cnVjdCBkZXZpY2UgKmRldiwgc3RydWN0IGxpc3RfaGVhZA0KPiA+ICpoZWFkKSAteyByZXR1
cm4gLUVOT0RFVjsgfQ0KPiA+ICt7IHJldHVybiAwOyB9DQo+ID4gICNlbmRpZg0KPiA+DQo+ID4g
ICNlbmRpZiAvKiBfX0FDUElfSU9SVF9IX18gKi8NCj4gPg0KPiA+IC0tPjgtLQ0KPiA+DQo+ID4N
Cj4gPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbGlu
dXgtYXJtLWtlcm5lbCBtYWlsaW5nIGxpc3QKbGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRl
YWQub3JnCmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgt
YXJtLWtlcm5lbAo=

[PATCH v9 3/4] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.

On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the
MSI payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements a ACPI table based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..dd42ae9 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -608,6 +608,7 @@ struct arm_smmu_device {
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
 #define ARM_SMMU_OPT_PAGE0_REGS_ONLY	(1 << 1)
+#define ARM_SMMU_OPT_RESV_HW_MSI	(1 << 2)
 	u32				options;
 
 	struct arm_smmu_cmdq		cmdq;
@@ -1934,14 +1935,29 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
 	struct iommu_resv_region *region;
+	struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
+	struct arm_smmu_device *smmu = master->smmu;
 	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	int resv = 0;
 
-	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
-		return;
+	if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) {
 
-	list_add_tail(&region->list, head);
+		resv = iommu_dma_get_msi_resv_regions(dev, head);
+
+		if (resv < 0) {
+			dev_warn(dev, "HW MSI region resv failed: %d\n", resv);
+			return;
+		}
+	}
+
+	if (!resv) {
+		region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+						 prot, IOMMU_RESV_SW_MSI);
+		if (!region)
+			return;
+
+		list_add_tail(&region->list, head);
+	}
 
 	iommu_dma_get_resv_regions(dev, head);
 }
@@ -2667,6 +2683,7 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
 		break;
 	case ACPI_IORT_SMMU_HISILICON_HI161X:
 		smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
+		smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI;
 		break;
 	}
 
-- 
1.9.1

[Devel] [PATCH v9 3/4] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

[Shameer Kolothum]

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

The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.

On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the
MSI payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements a ACPI table based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
---
 drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..dd42ae9 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -608,6 +608,7 @@ struct arm_smmu_device {
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
 #define ARM_SMMU_OPT_PAGE0_REGS_ONLY	(1 << 1)
+#define ARM_SMMU_OPT_RESV_HW_MSI	(1 << 2)
 	u32				options;
 
 	struct arm_smmu_cmdq		cmdq;
@@ -1934,14 +1935,29 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
 	struct iommu_resv_region *region;
+	struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
+	struct arm_smmu_device *smmu = master->smmu;
 	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	int resv = 0;
 
-	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
-		return;
+	if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) {
 
-	list_add_tail(&region->list, head);
+		resv = iommu_dma_get_msi_resv_regions(dev, head);
+
+		if (resv < 0) {
+			dev_warn(dev, "HW MSI region resv failed: %d\n", resv);
+			return;
+		}
+	}
+
+	if (!resv) {
+		region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+						 prot, IOMMU_RESV_SW_MSI);
+		if (!region)
+			return;
+
+		list_add_tail(&region->list, head);
+	}
 
 	iommu_dma_get_resv_regions(dev, head);
 }
@@ -2667,6 +2683,7 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
 		break;
 	case ACPI_IORT_SMMU_HISILICON_HI161X:
 		smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
+		smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI;
 		break;
 	}
 
-- 
1.9.1

[PATCH v9 3/4] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.

On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the
MSI payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements a ACPI table based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..dd42ae9 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -608,6 +608,7 @@ struct arm_smmu_device {
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
 #define ARM_SMMU_OPT_PAGE0_REGS_ONLY	(1 << 1)
+#define ARM_SMMU_OPT_RESV_HW_MSI	(1 << 2)
 	u32				options;
 
 	struct arm_smmu_cmdq		cmdq;
@@ -1934,14 +1935,29 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
 	struct iommu_resv_region *region;
+	struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
+	struct arm_smmu_device *smmu = master->smmu;
 	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	int resv = 0;
 
-	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
-		return;
+	if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) {
 
-	list_add_tail(&region->list, head);
+		resv = iommu_dma_get_msi_resv_regions(dev, head);
+
+		if (resv < 0) {
+			dev_warn(dev, "HW MSI region resv failed: %d\n", resv);
+			return;
+		}
+	}
+
+	if (!resv) {
+		region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+						 prot, IOMMU_RESV_SW_MSI);
+		if (!region)
+			return;
+
+		list_add_tail(&region->list, head);
+	}
 
 	iommu_dma_get_resv_regions(dev, head);
 }
@@ -2667,6 +2683,7 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
 		break;
 	case ACPI_IORT_SMMU_HISILICON_HI161X:
 		smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
+		smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI;
 		break;
 	}
 
-- 
1.9.1

[PATCH v9 3/4] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of HiSilicon
platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.

On these platforms GICv3 ITS translator is presented with the deviceID
by extending the MSI payload data to 64 bits to include the deviceID.
Hence, the PCIe controller on this platforms has to differentiate the
MSI payload against other DMA payload and has to modify the MSI payload.
This basically makes it difficult for this platforms to have a SMMU
translation for MSI.

This patch implements a ACPI table based quirk to reserve the hw msi
regions in the smmu-v3 driver which means these address regions will
not be translated and will be excluded from iova allocations.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/iommu/arm-smmu-v3.c | 27 ++++++++++++++++++++++-----
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index e67ba6c..dd42ae9 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -608,6 +608,7 @@ struct arm_smmu_device {
 
 #define ARM_SMMU_OPT_SKIP_PREFETCH	(1 << 0)
 #define ARM_SMMU_OPT_PAGE0_REGS_ONLY	(1 << 1)
+#define ARM_SMMU_OPT_RESV_HW_MSI	(1 << 2)
 	u32				options;
 
 	struct arm_smmu_cmdq		cmdq;
@@ -1934,14 +1935,29 @@ static void arm_smmu_get_resv_regions(struct device *dev,
 				      struct list_head *head)
 {
 	struct iommu_resv_region *region;
+	struct arm_smmu_master_data *master = dev->iommu_fwspec->iommu_priv;
+	struct arm_smmu_device *smmu = master->smmu;
 	int prot = IOMMU_WRITE | IOMMU_NOEXEC | IOMMU_MMIO;
+	int resv = 0;
 
-	region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
-					 prot, IOMMU_RESV_SW_MSI);
-	if (!region)
-		return;
+	if ((smmu->options & ARM_SMMU_OPT_RESV_HW_MSI)) {
 
-	list_add_tail(&region->list, head);
+		resv = iommu_dma_get_msi_resv_regions(dev, head);
+
+		if (resv < 0) {
+			dev_warn(dev, "HW MSI region resv failed: %d\n", resv);
+			return;
+		}
+	}
+
+	if (!resv) {
+		region = iommu_alloc_resv_region(MSI_IOVA_BASE, MSI_IOVA_LENGTH,
+						 prot, IOMMU_RESV_SW_MSI);
+		if (!region)
+			return;
+
+		list_add_tail(&region->list, head);
+	}
 
 	iommu_dma_get_resv_regions(dev, head);
 }
@@ -2667,6 +2683,7 @@ static void acpi_smmu_get_options(u32 model, struct arm_smmu_device *smmu)
 		break;
 	case ACPI_IORT_SMMU_HISILICON_HI161X:
 		smmu->options |= ARM_SMMU_OPT_SKIP_PREFETCH;
+		smmu->options |= ARM_SMMU_OPT_RESV_HW_MSI;
 		break;
 	}
 
-- 
1.9.1

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.

PCIe controller on these platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI
payload. This basically makes it difficult for this platforms to
have a SMMU translation for MSI. In order to workaround this, ARM
SMMUv3 driver requires a quirk to treat the MSI regions separately.
Such a quirk is currently missing for DT based systems and therefore
we need to blacklist the hip06/hip07 PCIe controllers.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
index a201791..6800747 100644
--- a/drivers/pci/dwc/pcie-hisi.c
+++ b/drivers/pci/dwc/pcie-hisi.c
@@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	struct resource *reg;
 	int ret;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
 	if (!hisi_pcie)
 		return -ENOMEM;
@@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct pci_ecam_ops *ops;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
 	return pci_host_common_probe(pdev, ops);
 }
-- 
1.9.1

[Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameer Kolothum]

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

The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.

PCIe controller on these platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI
payload. This basically makes it difficult for this platforms to
have a SMMU translation for MSI. In order to workaround this, ARM
SMMUv3 driver requires a quirk to treat the MSI regions separately.
Such a quirk is currently missing for DT based systems and therefore
we need to blacklist the hip06/hip07 PCIe controllers.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
---
 drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
index a201791..6800747 100644
--- a/drivers/pci/dwc/pcie-hisi.c
+++ b/drivers/pci/dwc/pcie-hisi.c
@@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	struct resource *reg;
 	int ret;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
 	if (!hisi_pcie)
 		return -ENOMEM;
@@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct pci_ecam_ops *ops;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
 	return pci_host_common_probe(pdev, ops);
 }
-- 
1.9.1

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.

PCIe controller on these platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI
payload. This basically makes it difficult for this platforms to
have a SMMU translation for MSI. In order to workaround this, ARM
SMMUv3 driver requires a quirk to treat the MSI regions separately.
Such a quirk is currently missing for DT based systems and therefore
we need to blacklist the hip06/hip07 PCIe controllers.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
index a201791..6800747 100644
--- a/drivers/pci/dwc/pcie-hisi.c
+++ b/drivers/pci/dwc/pcie-hisi.c
@@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	struct resource *reg;
 	int ret;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
 	if (!hisi_pcie)
 		return -ENOMEM;
@@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct pci_ecam_ops *ops;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
 	return pci_host_common_probe(pdev, ops);
 }
-- 
1.9.1

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameer Kolothum]

The HiSilicon erratum 161010801 describes the limitation of
HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
for MSI transactions.

PCIe controller on these platforms has to differentiate the MSI
payload against other DMA payload and has to modify the MSI
payload. This basically makes it difficult for this platforms to
have a SMMU translation for MSI. In order to workaround this, ARM
SMMUv3 driver requires a quirk to treat the MSI regions separately.
Such a quirk is currently missing for DT based systems and therefore
we need to blacklist the hip06/hip07 PCIe controllers.

Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
---
 drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
index a201791..6800747 100644
--- a/drivers/pci/dwc/pcie-hisi.c
+++ b/drivers/pci/dwc/pcie-hisi.c
@@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
 	struct resource *reg;
 	int ret;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
 	if (!hisi_pcie)
 		return -ENOMEM;
@@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
 	struct device *dev = &pdev->dev;
 	struct pci_ecam_ops *ops;
 
+	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
+			of_property_read_bool(dev->of_node, "iommu-map")) {
+		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
+		return -ENODEV;
+	}
+
 	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
 	return pci_host_common_probe(pdev, ops);
 }
-- 
1.9.1

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 06 October 2017 15:05
> To: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; will.deacon@arm.com; robin.murphy@arm.com;
> joro@8bytes.org; bhelgaas@google.com; Gabriele Paoloni
> Cc: John Garry; iommu@lists.linux-foundation.org; linux-arm-
> kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm; Wangzhou (B);
> Guohanjun (Hanjun Guo); Shameerali Kolothum Thodi
> Subject: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind SMMUv3
> 
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

For this patch
Acked-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
>  	struct resource *reg;
>  	int ret;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> --
> 1.9.1
> 

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 06 October 2017 15:05
> To: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; will.deacon at arm.com; robin.murphy at arm.com;
> joro at 8bytes.org; bhelgaas at google.com; Gabriele Paoloni
> Cc: John Garry; iommu at lists.linux-foundation.org; linux-arm-
> kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> pci at vger.kernel.org; devel at acpica.org; Linuxarm; Wangzhou (B);
> Guohanjun (Hanjun Guo); Shameerali Kolothum Thodi
> Subject: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind SMMUv3
> 
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

For this patch
Acked-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
>  	struct resource *reg;
>  	int ret;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> --
> 1.9.1
> 

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: 06 October 2017 15:05
> To: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; will.deacon@arm.com; robin.murphy@arm.com;
> joro@8bytes.org; bhelgaas@google.com; Gabriele Paoloni
> Cc: John Garry; iommu@lists.linux-foundation.org; linux-arm-
> kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm; Wangzhou (B);
> Guohanjun (Hanjun Guo); Shameerali Kolothum Thodi
> Subject: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind SMMUv3
> 
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

For this patch
Acked-by: Gabriele Paoloni <gabriele.paoloni@huawei.com>

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
>  	struct resource *reg;
>  	int ret;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
> 
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> --
> 1.9.1
> 


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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Zhou Wang]

On 2017/10/6 22:04, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
>

Acked-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Zhou Wang]

On 2017/10/6 22:04, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
>

Acked-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Zhou Wang]

On 2017/10/6 22:04, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
>

Acked-by: Zhou Wang <wangzhou1@hisilicon.com>

Thanks,
Zhou




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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

Please change subject line:

-  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
+  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.

I don't suppose there's a URL for this erratum, is there?

> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.

I don't understand the DT connection here.  If this is a hardware
erratum, I assume the a quirk would be required whether the system
uses DT, ACPI, etc.

> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

I assume this will go via some non-PCI tree.  If I were applying this,
I would look for an ack from Zhou or Gabriele in addition to mine.

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {

Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
have a different type of IOMMU?  I can't tell from reading
Documentation/devicetree/bindings/pci/pci-iommu.txt.

Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
correctly if SMMUv3 is present but not used?

Is it really necessary to ignore the PCIe controller completely?
Could you use the devices below it as long as you disable MSI for
them?  I know there are probably devices that require MSI, so maybe
it's easier to just ignore everything than to respond to reports of
"my device doesn't work because it requires MSI."

> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> -- 
> 1.9.1
> 
> 
> --
> 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 v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

Please change subject line:

-  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
+  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.

I don't suppose there's a URL for this erratum, is there?

> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.

I don't understand the DT connection here.  If this is a hardware
erratum, I assume the a quirk would be required whether the system
uses DT, ACPI, etc.

> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

I assume this will go via some non-PCI tree.  If I were applying this,
I would look for an ack from Zhou or Gabriele in addition to mine.

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {

Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
have a different type of IOMMU?  I can't tell from reading
Documentation/devicetree/bindings/pci/pci-iommu.txt.

Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
correctly if SMMUv3 is present but not used?

Is it really necessary to ignore the PCIe controller completely?
Could you use the devices below it as long as you disable MSI for
them?  I know there are probably devices that require MSI, so maybe
it's easier to just ignore everything than to respond to reports of
"my device doesn't work because it requires MSI."

> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> -- 
> 1.9.1
> 
> 
> --
> 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 v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

Please change subject line:

-  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
+  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.

I don't suppose there's a URL for this erratum, is there?

> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.

I don't understand the DT connection here.  If this is a hardware
erratum, I assume the a quirk would be required whether the system
uses DT, ACPI, etc.

> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

I assume this will go via some non-PCI tree.  If I were applying this,
I would look for an ack from Zhou or Gabriele in addition to mine.

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {

Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
have a different type of IOMMU?  I can't tell from reading
Documentation/devicetree/bindings/pci/pci-iommu.txt.

Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
correctly if SMMUv3 is present but not used?

Is it really necessary to ignore the PCIe controller completely?
Could you use the devices below it as long as you disable MSI for
them?  I know there are probably devices that require MSI, so maybe
it's easier to just ignore everything than to respond to reports of
"my device doesn't work because it requires MSI."

> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> -- 
> 1.9.1
> 
> 
> --
> 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

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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

On Mon, Oct 09, 2017 at 06:54:52PM -0500, Bjorn Helgaas wrote:
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of
> > HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> > for MSI transactions.
> 
> I don't suppose there's a URL for this erratum, is there?
> 
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI
> > payload. This basically makes it difficult for this platforms to
> > have a SMMU translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware
> erratum, I assume the a quirk would be required whether the system
> uses DT, ACPI, etc.
> 
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> I assume this will go via some non-PCI tree.  If I were applying this,
> I would look for an ack from Zhou or Gabriele in addition to mine.

Never mind about this part; I see they already have acked it.  I really
need to learn to read the whole thread before responding :)

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

On Mon, Oct 09, 2017 at 06:54:52PM -0500, Bjorn Helgaas wrote:
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of
> > HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> > for MSI transactions.
> 
> I don't suppose there's a URL for this erratum, is there?
> 
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI
> > payload. This basically makes it difficult for this platforms to
> > have a SMMU translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware
> erratum, I assume the a quirk would be required whether the system
> uses DT, ACPI, etc.
> 
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> 
> I assume this will go via some non-PCI tree.  If I were applying this,
> I would look for an ack from Zhou or Gabriele in addition to mine.

Never mind about this part; I see they already have acked it.  I really
need to learn to read the whole thread before responding :)

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

On Mon, Oct 09, 2017 at 06:54:52PM -0500, Bjorn Helgaas wrote:
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of
> > HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> > for MSI transactions.
> 
> I don't suppose there's a URL for this erratum, is there?
> 
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI
> > payload. This basically makes it difficult for this platforms to
> > have a SMMU translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware
> erratum, I assume the a quirk would be required whether the system
> uses DT, ACPI, etc.
> 
> > Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> 
> I assume this will go via some non-PCI tree.  If I were applying this,
> I would look for an ack from Zhou or Gabriele in addition to mine.

Never mind about this part; I see they already have acked it.  I really
need to learn to read the whole thread before responding :)

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

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

HI Bjorn,

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org]
> Sent: Tuesday, October 10, 2017 12:55 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
> sudeep.holla-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni
> <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org;
> linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org;
> Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Wangzhou (B)
> <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
> <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

Ok.

> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> 
> I don't suppose there's a URL for this erratum, is there?

We don't have anything public at the moment. This is part of the internal
documentation at the moment.

> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware erratum, I
> assume the a quirk would be required whether the system uses DT, ACPI,
> etc.

Yes, this is a hardware erratum and we are almost there to add the ACPI
quirk into the SMMUv3 driver for this.  But we got the feedback that 
either we have to have the DT support or we should blacklist the affected
devices so that from the SMMUv3 driver point of view it will not run into the
quirk unnecessarily[1].

We attempted to provide a DT solution, but it looks like DT requires more
discussions and a more generic approach than ACPI[2]. Hence we are blacklisting
the PCIe for now so that we can have the ACPI support goes through. (Also we 
don't have the DT binding in the mainline which support SMMU on these 
platforms and also DT is not officially supported for these platforms).

> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> 
> I assume this will go via some non-PCI tree.  If I were applying this, I would
> look for an ack from Zhou or Gabriele in addition to mine.
> 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> 
> Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> have a different type of IOMMU?  I can't tell from reading
> Documentation/devicetree/bindings/pci/pci-iommu.txt.

Only if the SMMUv3 driver is loaded and iommu-map binding property present,
the pcie devices will use SMMU translated iova for MSI doorbell addresses.

> Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> correctly if SMMUv3 is present but not used?

Yes. MSI will work if no SMMUv3 is used.

> Is it really necessary to ignore the PCIe controller completely?
> Could you use the devices below it as long as you disable MSI for them?  I
> know there are probably devices that require MSI, so maybe it's easier to
> just ignore everything than to respond to reports of "my device doesn't work
> because it requires MSI."

We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
supported on these platforms.

Thanks,
Shameer

1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
https://www.spinics.net/lists/arm-kernel/msg602873.html
2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
https://www.spinics.net/lists/arm-kernel/msg609431.html

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

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

HI Bjorn,

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas(a)kernel.org]
> Sent: Tuesday, October 10, 2017 12:55 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; will.deacon(a)arm.com; robin.murphy(a)arm.com;
> joro(a)8bytes.org; bhelgaas(a)google.com; Gabriele Paoloni
> <gabriele.paoloni(a)huawei.com>; John Garry <john.garry(a)huawei.com>;
> iommu(a)lists.linux-foundation.org; linux-arm-kernel(a)lists.infradead.org;
> linux-acpi(a)vger.kernel.org; linux-pci(a)vger.kernel.org; devel(a)acpica.org;
> Linuxarm <linuxarm(a)huawei.com>; Wangzhou (B)
> <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

Ok.

> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> 
> I don't suppose there's a URL for this erratum, is there?

We don't have anything public at the moment. This is part of the internal
documentation at the moment.

> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware erratum, I
> assume the a quirk would be required whether the system uses DT, ACPI,
> etc.

Yes, this is a hardware erratum and we are almost there to add the ACPI
quirk into the SMMUv3 driver for this.  But we got the feedback that 
either we have to have the DT support or we should blacklist the affected
devices so that from the SMMUv3 driver point of view it will not run into the
quirk unnecessarily[1].

We attempted to provide a DT solution, but it looks like DT requires more
discussions and a more generic approach than ACPI[2]. Hence we are blacklisting
the PCIe for now so that we can have the ACPI support goes through. (Also we 
don't have the DT binding in the mainline which support SMMU on these 
platforms and also DT is not officially supported for these platforms).

> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi(a)huawei.com>
> 
> I assume this will go via some non-PCI tree.  If I were applying this, I would
> look for an ack from Zhou or Gabriele in addition to mine.
> 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> 
> Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> have a different type of IOMMU?  I can't tell from reading
> Documentation/devicetree/bindings/pci/pci-iommu.txt.

Only if the SMMUv3 driver is loaded and iommu-map binding property present,
the pcie devices will use SMMU translated iova for MSI doorbell addresses.

> Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> correctly if SMMUv3 is present but not used?

Yes. MSI will work if no SMMUv3 is used.

> Is it really necessary to ignore the PCIe controller completely?
> Could you use the devices below it as long as you disable MSI for them?  I
> know there are probably devices that require MSI, so maybe it's easier to
> just ignore everything than to respond to reports of "my device doesn't work
> because it requires MSI."

We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
supported on these platforms.

Thanks,
Shameer

1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
https://www.spinics.net/lists/arm-kernel/msg602873.html
2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
https://www.spinics.net/lists/arm-kernel/msg609431.html

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

HI Bjorn,

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas at kernel.org]
> Sent: Tuesday, October 10, 2017 12:55 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; will.deacon at arm.com; robin.murphy at arm.com;
> joro at 8bytes.org; bhelgaas at google.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; John Garry <john.garry@huawei.com>;
> iommu at lists.linux-foundation.org; linux-arm-kernel at lists.infradead.org;
> linux-acpi at vger.kernel.org; linux-pci at vger.kernel.org; devel at acpica.org;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

Ok.

> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> 
> I don't suppose there's a URL for this erratum, is there?

We don't have anything public at the moment. This is part of the internal
documentation at the moment.

> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware erratum, I
> assume the a quirk would be required whether the system uses DT, ACPI,
> etc.

Yes, this is a hardware erratum and we are almost there to add the ACPI
quirk into the SMMUv3 driver for this.  But we got the feedback that 
either we have to have the DT support or we should blacklist the affected
devices so that from the SMMUv3 driver point of view it will not run into the
quirk unnecessarily[1].

We attempted to provide a DT solution, but it looks like DT requires more
discussions and a more generic approach than ACPI[2]. Hence we are blacklisting
the PCIe for now so that we can have the ACPI support goes through. (Also we 
don't have the DT binding in the mainline which support SMMU on these 
platforms and also DT is not officially supported for these platforms).

> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> 
> I assume this will go via some non-PCI tree.  If I were applying this, I would
> look for an ack from Zhou or Gabriele in addition to mine.
> 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> 
> Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> have a different type of IOMMU?  I can't tell from reading
> Documentation/devicetree/bindings/pci/pci-iommu.txt.

Only if the SMMUv3 driver is loaded and iommu-map binding property present,
the pcie devices will use SMMU translated iova for MSI doorbell addresses.

> Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> correctly if SMMUv3 is present but not used?

Yes. MSI will work if no SMMUv3 is used.

> Is it really necessary to ignore the PCIe controller completely?
> Could you use the devices below it as long as you disable MSI for them?  I
> know there are probably devices that require MSI, so maybe it's easier to
> just ignore everything than to respond to reports of "my device doesn't work
> because it requires MSI."

We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
supported on these platforms.

Thanks,
Shameer

1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
https://www.spinics.net/lists/arm-kernel/msg602873.html
2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
https://www.spinics.net/lists/arm-kernel/msg609431.html

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

HI Bjorn,

> -----Original Message-----
> From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> Sent: Tuesday, October 10, 2017 12:55 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; will.deacon@arm.com; robin.murphy@arm.com;
> joro@8bytes.org; bhelgaas@google.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>; John Garry <john.garry@huawei.com>;
> iommu@lists.linux-foundation.org; linux-arm-kernel@lists.infradead.org;
> linux-acpi@vger.kernel.org; linux-pci@vger.kernel.org; devel@acpica.org;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> Please change subject line:
> 
> -  PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> +  PCI: hisi: Blacklist hip06/hip07 controllers behind SMMUv3

Ok.

> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> 
> I don't suppose there's a URL for this erratum, is there?

We don't have anything public at the moment. This is part of the internal
documentation at the moment.

> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> 
> I don't understand the DT connection here.  If this is a hardware erratum, I
> assume the a quirk would be required whether the system uses DT, ACPI,
> etc.

Yes, this is a hardware erratum and we are almost there to add the ACPI
quirk into the SMMUv3 driver for this.  But we got the feedback that 
either we have to have the DT support or we should blacklist the affected
devices so that from the SMMUv3 driver point of view it will not run into the
quirk unnecessarily[1].

We attempted to provide a DT solution, but it looks like DT requires more
discussions and a more generic approach than ACPI[2]. Hence we are blacklisting
the PCIe for now so that we can have the ACPI support goes through. (Also we 
don't have the DT binding in the mainline which support SMMU on these 
platforms and also DT is not officially supported for these platforms).

> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> 
> I assume this will go via some non-PCI tree.  If I were applying this, I would
> look for an ack from Zhou or Gabriele in addition to mine.
> 
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> 
> Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> have a different type of IOMMU?  I can't tell from reading
> Documentation/devicetree/bindings/pci/pci-iommu.txt.

Only if the SMMUv3 driver is loaded and iommu-map binding property present,
the pcie devices will use SMMU translated iova for MSI doorbell addresses.

> Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> correctly if SMMUv3 is present but not used?

Yes. MSI will work if no SMMUv3 is used.

> Is it really necessary to ignore the PCIe controller completely?
> Could you use the devices below it as long as you disable MSI for them?  I
> know there are probably devices that require MSI, so maybe it's easier to
> just ignore everything than to respond to reports of "my device doesn't work
> because it requires MSI."

We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
supported on these platforms.

Thanks,
Shameer

1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
https://www.spinics.net/lists/arm-kernel/msg602873.html
2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
https://www.spinics.net/lists/arm-kernel/msg609431.html


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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Lorenzo Pieralisi]

On Tue, Oct 10, 2017 at 09:42:30AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > 
> > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> > have a different type of IOMMU?  I can't tell from reading
> > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> 
> Only if the SMMUv3 driver is loaded and iommu-map binding property present,
> the pcie devices will use SMMU translated iova for MSI doorbell addresses.

And the iommu-map property _actually_ points at an OF node with an
SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
is compiled in is not sufficient IIUC.

Lorenzo

> > Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> > correctly if SMMUv3 is present but not used?
> 
> Yes. MSI will work if no SMMUv3 is used.
> 
> > Is it really necessary to ignore the PCIe controller completely?
> > Could you use the devices below it as long as you disable MSI for them?  I
> > know there are probably devices that require MSI, so maybe it's easier to
> > just ignore everything than to respond to reports of "my device doesn't work
> > because it requires MSI."
> 
> We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
> to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
> supported on these platforms.
> 
> Thanks,
> Shameer
> 
> 1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
> https://www.spinics.net/lists/arm-kernel/msg602873.html
> 2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
> https://www.spinics.net/lists/arm-kernel/msg609431.html
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Lorenzo Pieralisi]

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

On Tue, Oct 10, 2017 at 09:42:30AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > 
> > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> > have a different type of IOMMU?  I can't tell from reading
> > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> 
> Only if the SMMUv3 driver is loaded and iommu-map binding property present,
> the pcie devices will use SMMU translated iova for MSI doorbell addresses.

And the iommu-map property _actually_ points at an OF node with an
SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
is compiled in is not sufficient IIUC.

Lorenzo

> > Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> > correctly if SMMUv3 is present but not used?
> 
> Yes. MSI will work if no SMMUv3 is used.
> 
> > Is it really necessary to ignore the PCIe controller completely?
> > Could you use the devices below it as long as you disable MSI for them?  I
> > know there are probably devices that require MSI, so maybe it's easier to
> > just ignore everything than to respond to reports of "my device doesn't work
> > because it requires MSI."
> 
> We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
> to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
> supported on these platforms.
> 
> Thanks,
> Shameer
> 
> 1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
> https://www.spinics.net/lists/arm-kernel/msg602873.html
> 2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
> https://www.spinics.net/lists/arm-kernel/msg609431.html
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel(a)lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Lorenzo Pieralisi]

On Tue, Oct 10, 2017 at 09:42:30AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > 
> > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> > have a different type of IOMMU?  I can't tell from reading
> > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> 
> Only if the SMMUv3 driver is loaded and iommu-map binding property present,
> the pcie devices will use SMMU translated iova for MSI doorbell addresses.

And the iommu-map property _actually_ points at an OF node with an
SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
is compiled in is not sufficient IIUC.

Lorenzo

> > Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> > correctly if SMMUv3 is present but not used?
> 
> Yes. MSI will work if no SMMUv3 is used.
> 
> > Is it really necessary to ignore the PCIe controller completely?
> > Could you use the devices below it as long as you disable MSI for them?  I
> > know there are probably devices that require MSI, so maybe it's easier to
> > just ignore everything than to respond to reports of "my device doesn't work
> > because it requires MSI."
> 
> We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
> to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
> supported on these platforms.
> 
> Thanks,
> Shameer
> 
> 1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
> https://www.spinics.net/lists/arm-kernel/msg602873.html
> 2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
> https://www.spinics.net/lists/arm-kernel/msg609431.html
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Lorenzo Pieralisi]

On Tue, Oct 10, 2017 at 09:42:30AM +0000, Shameerali Kolothum Thodi wrote:

[...]

> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > 
> > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could it
> > have a different type of IOMMU?  I can't tell from reading
> > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> 
> Only if the SMMUv3 driver is loaded and iommu-map binding property present,
> the pcie devices will use SMMU translated iova for MSI doorbell addresses.

And the iommu-map property _actually_ points at an OF node with an
SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
is compiled in is not sufficient IIUC.

Lorenzo

> > Why do you care whether CONFIG_ARM_SMMU_V3 is set?  Does MSI work
> > correctly if SMMUv3 is present but not used?
> 
> Yes. MSI will work if no SMMUv3 is used.
> 
> > Is it really necessary to ignore the PCIe controller completely?
> > Could you use the devices below it as long as you disable MSI for them?  I
> > know there are probably devices that require MSI, so maybe it's easier to
> > just ignore everything than to respond to reports of "my device doesn't work
> > because it requires MSI."
> 
> We are blacklisting MSI for PCIe only if the kernel is using DT and is configured
> to use SMMUv3. Otherwise it is fine. And as I said above DT is not officially
> supported on these platforms.
> 
> Thanks,
> Shameer
> 
> 1. [PATCH v6 3/3] iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
> https://www.spinics.net/lists/arm-kernel/msg602873.html
> 2. [PATCH v8 3/5] iommu/of: Add msi address regions reservation helper
> https://www.spinics.net/lists/arm-kernel/msg609431.html
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Lorenzo

[...]

> > > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could
> it
> > > have a different type of IOMMU?  I can't tell from reading
> > > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> >
> > Only if the SMMUv3 driver is loaded and iommu-map binding property
> present,
> > the pcie devices will use SMMU translated iova for MSI doorbell
> addresses.
> 
> And the iommu-map property _actually_ points at an OF node with an
> SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
> is compiled in is not sufficient IIUC.

The blacklisted controller can only be present in an SoC that supports
SMMUv3 only.

>From our view checking that SMMUv3 is compiled in and also checking that
the DT contains iommu-map is sufficient to decide to blacklist the controller.

Thanks
Gab 

> 
> Lorenzo
> 

[...]

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Lorenzo

[...]

> > > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could
> it
> > > have a different type of IOMMU?  I can't tell from reading
> > > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> >
> > Only if the SMMUv3 driver is loaded and iommu-map binding property
> present,
> > the pcie devices will use SMMU translated iova for MSI doorbell
> addresses.
> 
> And the iommu-map property _actually_ points at an OF node with an
> SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
> is compiled in is not sufficient IIUC.

The blacklisted controller can only be present in an SoC that supports
SMMUv3 only.

>From our view checking that SMMUv3 is compiled in and also checking that
the DT contains iommu-map is sufficient to decide to blacklist the controller.

Thanks
Gab 

> 
> Lorenzo
> 

[...]

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Gabriele Paoloni]

Hi Lorenzo

[...]

> > > Does the presence of "iommu-map" tell you this is an SMMUv3?  Could
> it
> > > have a different type of IOMMU?  I can't tell from reading
> > > Documentation/devicetree/bindings/pci/pci-iommu.txt.
> >
> > Only if the SMMUv3 driver is loaded and iommu-map binding property
> present,
> > the pcie devices will use SMMU translated iova for MSI doorbell
> addresses.
>=20
> And the iommu-map property _actually_ points at an OF node with an
> SMMUv3 compatible string - the sheer fact that the SMMUv3 driver
> is compiled in is not sufficient IIUC.

The blacklisted controller can only be present in an SoC that supports
SMMUv3 only.

>From our view checking that SMMUv3 is compiled in and also checking that
the DT contains iommu-map is sufficient to decide to blacklist the controll=
er.

Thanks
Gab=20

>=20
> Lorenzo
>=20

[...]

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> -- 
> 1.9.1
> 
> 
> --
> 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 v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Bjorn Helgaas]

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	ops = (struct pci_ecam_ops *)of_device_get_match_data(dev);
>  	return pci_host_common_probe(pdev, ops);
>  }
> -- 
> 1.9.1
> 
> 
> --
> 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 v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}

This isn't the right way to solve this problem. I was really hoping you'd
come up with a solution for DT, and I know you've been trying, so I suppose
for now we'll just have to go with the ACPI workaround you have and leave DT
in the balance. I'm not at all happy with that, but I don't think this patch
really improves things.

What I think you should do is remove the relevant smmu/iommu-map entries
from the .dts files that are available for these platforms (i.e. comment
them out with a description as to why).

Will

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

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

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi(a)huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}

This isn't the right way to solve this problem. I was really hoping you'd
come up with a solution for DT, and I know you've been trying, so I suppose
for now we'll just have to go with the ACPI workaround you have and leave DT
in the balance. I'm not at all happy with that, but I don't think this patch
really improves things.

What I think you should do is remove the relevant smmu/iommu-map entries
from the .dts files that are available for these platforms (i.e. comment
them out with a description as to why).

Will

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}

This isn't the right way to solve this problem. I was really hoping you'd
come up with a solution for DT, and I know you've been trying, so I suppose
for now we'll just have to go with the ACPI workaround you have and leave DT
in the balance. I'm not at all happy with that, but I don't think this patch
really improves things.

What I think you should do is remove the relevant smmu/iommu-map entries
from the .dts files that are available for these platforms (i.e. comment
them out with a description as to why).

Will

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> The HiSilicon erratum 161010801 describes the limitation of
> HiSilicon platforms hip06/hip07 to support the SMMUv3 mappings
> for MSI transactions.
> 
> PCIe controller on these platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI
> payload. This basically makes it difficult for this platforms to
> have a SMMU translation for MSI. In order to workaround this, ARM
> SMMUv3 driver requires a quirk to treat the MSI regions separately.
> Such a quirk is currently missing for DT based systems and therefore
> we need to blacklist the hip06/hip07 PCIe controllers.
> 
> Signed-off-by: Shameer Kolothum <shameerali.kolothum.thodi@huawei.com>
> ---
>  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> index a201791..6800747 100644
> --- a/drivers/pci/dwc/pcie-hisi.c
> +++ b/drivers/pci/dwc/pcie-hisi.c
> @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device *pdev)
>  	struct resource *reg;
>  	int ret;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}
> +
>  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
>  	if (!hisi_pcie)
>  		return -ENOMEM;
> @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct platform_device *pdev)
>  	struct device *dev = &pdev->dev;
>  	struct pci_ecam_ops *ops;
>  
> +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> +			of_property_read_bool(dev->of_node, "iommu-map")) {
> +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting PCIe controllers behind SMMUv3\n");
> +		return -ENODEV;
> +	}

This isn't the right way to solve this problem. I was really hoping you'd
come up with a solution for DT, and I know you've been trying, so I suppose
for now we'll just have to go with the ACPI workaround you have and leave DT
in the balance. I'm not at all happy with that, but I don't think this patch
really improves things.

What I think you should do is remove the relevant smmu/iommu-map entries
from the .dts files that are available for these platforms (i.e. comment
them out with a description as to why).

Will

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

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Friday, October 13, 2017 8:22 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
> sudeep.holla-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> Wangzhou (B) <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
> <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> >
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> > +
> >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> >  	if (!hisi_pcie)
> >  		return -ENOMEM;
> > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	struct pci_ecam_ops *ops;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> 
> This isn't the right way to solve this problem. I was really hoping you'd come
> up with a solution for DT, and I know you've been trying, so I suppose for
> now we'll just have to go with the ACPI workaround you have and leave DT in
> the balance. I'm not at all happy with that, but I don't think this patch really
> improves things.

Yes Will, this is to get the ACPI support enabled for now. 

> What I think you should do is remove the relevant smmu/iommu-map
> entries from the .dts files that are available for these platforms (i.e.
> comment them out with a description as to why).

We don't have any smmu/iommu-map entries for these platforms in the 
.dts files [1][2]. We are not aiming for any official DT support for these platforms.
This patch is to enforce the non-support.

Thanks,
Shameer

1. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip07.dtsi
2. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip06.dtsi

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

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



> -----Original Message-----
> From: Will Deacon [mailto:will.deacon(a)arm.com]
> Sent: Friday, October 13, 2017 8:22 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> >
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi(a)huawei.com>
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> > +
> >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> >  	if (!hisi_pcie)
> >  		return -ENOMEM;
> > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	struct pci_ecam_ops *ops;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> 
> This isn't the right way to solve this problem. I was really hoping you'd come
> up with a solution for DT, and I know you've been trying, so I suppose for
> now we'll just have to go with the ACPI workaround you have and leave DT in
> the balance. I'm not at all happy with that, but I don't think this patch really
> improves things.

Yes Will, this is to get the ACPI support enabled for now. 

> What I think you should do is remove the relevant smmu/iommu-map
> entries from the .dts files that are available for these platforms (i.e.
> comment them out with a description as to why).

We don't have any smmu/iommu-map entries for these platforms in the 
.dts files [1][2]. We are not aiming for any official DT support for these platforms.
This patch is to enforce the non-support.

Thanks,
Shameer

1. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip07.dtsi
2. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip06.dtsi

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Friday, October 13, 2017 8:22 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> >
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> > +
> >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> >  	if (!hisi_pcie)
> >  		return -ENOMEM;
> > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	struct pci_ecam_ops *ops;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> 
> This isn't the right way to solve this problem. I was really hoping you'd come
> up with a solution for DT, and I know you've been trying, so I suppose for
> now we'll just have to go with the ACPI workaround you have and leave DT in
> the balance. I'm not at all happy with that, but I don't think this patch really
> improves things.

Yes Will, this is to get the ACPI support enabled for now. 

> What I think you should do is remove the relevant smmu/iommu-map
> entries from the .dts files that are available for these platforms (i.e.
> comment them out with a description as to why).

We don't have any smmu/iommu-map entries for these platforms in the 
.dts files [1][2]. We are not aiming for any official DT support for these platforms.
This patch is to enforce the non-support.

Thanks,
Shameer

1. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip07.dtsi
2. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip06.dtsi

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Friday, October 13, 2017 8:22 PM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > transactions.
> >
> > PCIe controller on these platforms has to differentiate the MSI
> > payload against other DMA payload and has to modify the MSI payload.
> > This basically makes it difficult for this platforms to have a SMMU
> > translation for MSI. In order to workaround this, ARM
> > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > Such a quirk is currently missing for DT based systems and therefore
> > we need to blacklist the hip06/hip07 PCIe controllers.
> >
> > Signed-off-by: Shameer Kolothum
> <shameerali.kolothum.thodi@huawei.com>
> > ---
> >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > index a201791..6800747 100644
> > --- a/drivers/pci/dwc/pcie-hisi.c
> > +++ b/drivers/pci/dwc/pcie-hisi.c
> > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> *pdev)
> >  	struct resource *reg;
> >  	int ret;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> > +
> >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> >  	if (!hisi_pcie)
> >  		return -ENOMEM;
> > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> platform_device *pdev)
> >  	struct device *dev = &pdev->dev;
> >  	struct pci_ecam_ops *ops;
> >
> > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > +			of_property_read_bool(dev->of_node, "iommu-
> map")) {
> > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> PCIe controllers behind SMMUv3\n");
> > +		return -ENODEV;
> > +	}
> 
> This isn't the right way to solve this problem. I was really hoping you'd come
> up with a solution for DT, and I know you've been trying, so I suppose for
> now we'll just have to go with the ACPI workaround you have and leave DT in
> the balance. I'm not at all happy with that, but I don't think this patch really
> improves things.

Yes Will, this is to get the ACPI support enabled for now. 

> What I think you should do is remove the relevant smmu/iommu-map
> entries from the .dts files that are available for these platforms (i.e.
> comment them out with a description as to why).

We don't have any smmu/iommu-map entries for these platforms in the 
.dts files [1][2]. We are not aiming for any official DT support for these platforms.
This patch is to enforce the non-support.

Thanks,
Shameer

1. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip07.dtsi
2. http://elixir.free-electrons.com/linux/v4.14-rc4/source/arch/arm64/boot/dts/hisilicon/hip06.dtsi





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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> 
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon@arm.com]
> > Sent: Friday, October 13, 2017 8:22 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > transactions.
> > >
> > > PCIe controller on these platforms has to differentiate the MSI
> > > payload against other DMA payload and has to modify the MSI payload.
> > > This basically makes it difficult for this platforms to have a SMMU
> > > translation for MSI. In order to workaround this, ARM
> > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > Such a quirk is currently missing for DT based systems and therefore
> > > we need to blacklist the hip06/hip07 PCIe controllers.
> > >
> > > Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@huawei.com>
> > > ---
> > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > > +
> > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > >  	if (!hisi_pcie)
> > >  		return -ENOMEM;
> > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > platform_device *pdev)
> > >  	struct device *dev = &pdev->dev;
> > >  	struct pci_ecam_ops *ops;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > 
> > This isn't the right way to solve this problem. I was really hoping you'd come
> > up with a solution for DT, and I know you've been trying, so I suppose for
> > now we'll just have to go with the ACPI workaround you have and leave DT in
> > the balance. I'm not at all happy with that, but I don't think this patch really
> > improves things.
> 
> Yes Will, this is to get the ACPI support enabled for now. 
> 
> > What I think you should do is remove the relevant smmu/iommu-map
> > entries from the .dts files that are available for these platforms (i.e.
> > comment them out with a description as to why).
> 
> We don't have any smmu/iommu-map entries for these platforms in the 
> .dts files [1][2]. We are not aiming for any official DT support for these platforms.
> This patch is to enforce the non-support.

Understood, but this has dragged on for a while and I don't think this patch
is the right way to enforce things. The best approach might actually be to
add the SMMU to the DTs, but commented out with a comment explaining why
it's not a good idea to enable it.

Will

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

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

On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> 
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon(a)arm.com]
> > Sent: Friday, October 13, 2017 8:22 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> > Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> > sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> > bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> > John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> > linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> > pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
> > Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun(a)huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > transactions.
> > >
> > > PCIe controller on these platforms has to differentiate the MSI
> > > payload against other DMA payload and has to modify the MSI payload.
> > > This basically makes it difficult for this platforms to have a SMMU
> > > translation for MSI. In order to workaround this, ARM
> > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > Such a quirk is currently missing for DT based systems and therefore
> > > we need to blacklist the hip06/hip07 PCIe controllers.
> > >
> > > Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi(a)huawei.com>
> > > ---
> > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > > +
> > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > >  	if (!hisi_pcie)
> > >  		return -ENOMEM;
> > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > platform_device *pdev)
> > >  	struct device *dev = &pdev->dev;
> > >  	struct pci_ecam_ops *ops;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > 
> > This isn't the right way to solve this problem. I was really hoping you'd come
> > up with a solution for DT, and I know you've been trying, so I suppose for
> > now we'll just have to go with the ACPI workaround you have and leave DT in
> > the balance. I'm not at all happy with that, but I don't think this patch really
> > improves things.
> 
> Yes Will, this is to get the ACPI support enabled for now. 
> 
> > What I think you should do is remove the relevant smmu/iommu-map
> > entries from the .dts files that are available for these platforms (i.e.
> > comment them out with a description as to why).
> 
> We don't have any smmu/iommu-map entries for these platforms in the 
> .dts files [1][2]. We are not aiming for any official DT support for these platforms.
> This patch is to enforce the non-support.

Understood, but this has dragged on for a while and I don't think this patch
is the right way to enforce things. The best approach might actually be to
add the SMMU to the DTs, but commented out with a comment explaining why
it's not a good idea to enable it.

Will

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> 
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon at arm.com]
> > Sent: Friday, October 13, 2017 8:22 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> > sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> > bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> > linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> > pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > transactions.
> > >
> > > PCIe controller on these platforms has to differentiate the MSI
> > > payload against other DMA payload and has to modify the MSI payload.
> > > This basically makes it difficult for this platforms to have a SMMU
> > > translation for MSI. In order to workaround this, ARM
> > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > Such a quirk is currently missing for DT based systems and therefore
> > > we need to blacklist the hip06/hip07 PCIe controllers.
> > >
> > > Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@huawei.com>
> > > ---
> > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > > +
> > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > >  	if (!hisi_pcie)
> > >  		return -ENOMEM;
> > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > platform_device *pdev)
> > >  	struct device *dev = &pdev->dev;
> > >  	struct pci_ecam_ops *ops;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > 
> > This isn't the right way to solve this problem. I was really hoping you'd come
> > up with a solution for DT, and I know you've been trying, so I suppose for
> > now we'll just have to go with the ACPI workaround you have and leave DT in
> > the balance. I'm not at all happy with that, but I don't think this patch really
> > improves things.
> 
> Yes Will, this is to get the ACPI support enabled for now. 
> 
> > What I think you should do is remove the relevant smmu/iommu-map
> > entries from the .dts files that are available for these platforms (i.e.
> > comment them out with a description as to why).
> 
> We don't have any smmu/iommu-map entries for these platforms in the 
> .dts files [1][2]. We are not aiming for any official DT support for these platforms.
> This patch is to enforce the non-support.

Understood, but this has dragged on for a while and I don't think this patch
is the right way to enforce things. The best approach might actually be to
add the SMMU to the DTs, but commented out with a comment explaining why
it's not a good idea to enable it.

Will

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> 
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon@arm.com]
> > Sent: Friday, October 13, 2017 8:22 PM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > transactions.
> > >
> > > PCIe controller on these platforms has to differentiate the MSI
> > > payload against other DMA payload and has to modify the MSI payload.
> > > This basically makes it difficult for this platforms to have a SMMU
> > > translation for MSI. In order to workaround this, ARM
> > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > Such a quirk is currently missing for DT based systems and therefore
> > > we need to blacklist the hip06/hip07 PCIe controllers.
> > >
> > > Signed-off-by: Shameer Kolothum
> > <shameerali.kolothum.thodi@huawei.com>
> > > ---
> > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > >  1 file changed, 12 insertions(+)
> > >
> > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > index a201791..6800747 100644
> > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > *pdev)
> > >  	struct resource *reg;
> > >  	int ret;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > > +
> > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > >  	if (!hisi_pcie)
> > >  		return -ENOMEM;
> > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > platform_device *pdev)
> > >  	struct device *dev = &pdev->dev;
> > >  	struct pci_ecam_ops *ops;
> > >
> > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > +			of_property_read_bool(dev->of_node, "iommu-
> > map")) {
> > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > PCIe controllers behind SMMUv3\n");
> > > +		return -ENODEV;
> > > +	}
> > 
> > This isn't the right way to solve this problem. I was really hoping you'd come
> > up with a solution for DT, and I know you've been trying, so I suppose for
> > now we'll just have to go with the ACPI workaround you have and leave DT in
> > the balance. I'm not at all happy with that, but I don't think this patch really
> > improves things.
> 
> Yes Will, this is to get the ACPI support enabled for now. 
> 
> > What I think you should do is remove the relevant smmu/iommu-map
> > entries from the .dts files that are available for these platforms (i.e.
> > comment them out with a description as to why).
> 
> We don't have any smmu/iommu-map entries for these platforms in the 
> .dts files [1][2]. We are not aiming for any official DT support for these platforms.
> This patch is to enforce the non-support.

Understood, but this has dragged on for a while and I don't think this patch
is the right way to enforce things. The best approach might actually be to
add the SMMU to the DTs, but commented out with a comment explaining why
it's not a good idea to enable it.

Will

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

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> Sent: Wednesday, October 18, 2017 11:52 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
> sudeep.holla-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org; Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> Wangzhou (B) <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
> <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon-5wv7dgnIgG8@public.gmane.org]
> > > Sent: Friday, October 13, 2017 8:22 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Cc: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
> > > sudeep.holla-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org; joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org;
> > > bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> > > John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org;
> > > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> > > pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org; Linuxarm
> <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>;
> > > Wangzhou (B) <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
> > > <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind
> > > SMMUv3
> > >
> > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > transactions.
> > > >
> > > > PCIe controller on these platforms has to differentiate the MSI
> > > > payload against other DMA payload and has to modify the MSI payload.
> > > > This basically makes it difficult for this platforms to have a SMMU
> > > > translation for MSI. In order to workaround this, ARM
> > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > Such a quirk is currently missing for DT based systems and therefore
> > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > >
> > > > Signed-off-by: Shameer Kolothum
> > > <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> > > > ---
> > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > index a201791..6800747 100644
> > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > *pdev)
> > > >  	struct resource *reg;
> > > >  	int ret;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > >  	if (!hisi_pcie)
> > > >  		return -ENOMEM;
> > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > platform_device *pdev)
> > > >  	struct device *dev = &pdev->dev;
> > > >  	struct pci_ecam_ops *ops;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > >
> > > This isn't the right way to solve this problem. I was really hoping you'd
> come
> > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > now we'll just have to go with the ACPI workaround you have and leave DT
> in
> > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > improves things.
> >
> > Yes Will, this is to get the ACPI support enabled for now.
> >
> > > What I think you should do is remove the relevant smmu/iommu-map
> > > entries from the .dts files that are available for these platforms (i.e.
> > > comment them out with a description as to why).
> >
> > We don't have any smmu/iommu-map entries for these platforms in the
> > .dts files [1][2]. We are not aiming for any official DT support for these
> platforms.
> > This patch is to enforce the non-support.
> 
> Understood, but this has dragged on for a while and I don't think this patch
> is the right way to enforce things. The best approach might actually be to
> add the SMMU to the DTs, but commented out with a comment explaining why
> it's not a good idea to enable it.

Ok. Just to clarify, you would like to replace this patch with another 
one with smmu entries in dts and commenting/disabling them with explanation.
Or you would like to have that in addition to this one?

Please take a look at below snippet where I have added the smmu dts nodes
and disabled them with comments.

If this looks ok, I can sent it out soon. Please let me know.

Many Thanks,
Shameer

-- >8 --
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..b561ac6 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,20 @@
 			#interrupt-cells = <2>;
 			num-pins = <128>;
 		};
+
+		mbigen_pcie0: intc_pcie0 {
+			msi-parent = <&its_dsa 0x40085>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <10>;
+		};
+
+		mbigen_smmu_pcie_intc: intc_smmu_pcie {
+			msi-parent = <&its_dsa 0x40b0c>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <3>;
+		};
 	};
 
 	mbigen_dsa@c0080000 {
@@ -312,6 +326,27 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip06 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie_intc>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -676,6 +711,29 @@
 				     <637 1>,<638 1>,<639 1>;
 			status = "disabled";
 		};
+
+		pcie0: pcie@a0090000 {
+			compatible = "hisilicon,pcie-almost-ecam";
+			reg = <0 0xb0000000 0 0x2000000>, <0 0xa0090000 0 0x10000>;
+			bus-range = <0  31>;
+			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+			msi-map-mask = <0xffff>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x0 0x10000>;*/
+			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000
+				  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;
+			#interrupt-cells = <1>;
+                        interrupt-map-mask = <0xf800 0 0 7>;
+                        interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+                                         0x0 0 0 2 &mbigen_pcie0 650 4
+                                         0x0 0 0 3 &mbigen_pcie0 650 4
+                                         0x0 0 0 4 &mbigen_pcie0 650 4>;
+			status = "disabled";
+		};
+
 	};
 
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..a483325 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,26 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip07 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -1546,6 +1566,7 @@
 			#size-cells = <2>;
 			device_type = "pci";
 			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x20000 0x10000>;*/
 			ranges = <0x02000000 0 0xa8000000 0 0xa8000000 0 0x77f0000
 				  0x01000000 0 0 0 0xaf7f0000 0 0x10000>;
 			#interrupt-cells = <1>;
-- >8 --

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

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

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon(a)arm.com]
> Sent: Wednesday, October 18, 2017 11:52 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
> Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon(a)arm.com]
> > > Sent: Friday, October 13, 2017 8:22 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> > > Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> > > sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> > > bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> > > John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> > > linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> > > pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm
> <linuxarm(a)huawei.com>;
> > > Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun(a)huawei.com>
> > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind
> > > SMMUv3
> > >
> > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > transactions.
> > > >
> > > > PCIe controller on these platforms has to differentiate the MSI
> > > > payload against other DMA payload and has to modify the MSI payload.
> > > > This basically makes it difficult for this platforms to have a SMMU
> > > > translation for MSI. In order to workaround this, ARM
> > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > Such a quirk is currently missing for DT based systems and therefore
> > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > >
> > > > Signed-off-by: Shameer Kolothum
> > > <shameerali.kolothum.thodi(a)huawei.com>
> > > > ---
> > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > index a201791..6800747 100644
> > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > *pdev)
> > > >  	struct resource *reg;
> > > >  	int ret;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > >  	if (!hisi_pcie)
> > > >  		return -ENOMEM;
> > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > platform_device *pdev)
> > > >  	struct device *dev = &pdev->dev;
> > > >  	struct pci_ecam_ops *ops;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > >
> > > This isn't the right way to solve this problem. I was really hoping you'd
> come
> > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > now we'll just have to go with the ACPI workaround you have and leave DT
> in
> > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > improves things.
> >
> > Yes Will, this is to get the ACPI support enabled for now.
> >
> > > What I think you should do is remove the relevant smmu/iommu-map
> > > entries from the .dts files that are available for these platforms (i.e.
> > > comment them out with a description as to why).
> >
> > We don't have any smmu/iommu-map entries for these platforms in the
> > .dts files [1][2]. We are not aiming for any official DT support for these
> platforms.
> > This patch is to enforce the non-support.
> 
> Understood, but this has dragged on for a while and I don't think this patch
> is the right way to enforce things. The best approach might actually be to
> add the SMMU to the DTs, but commented out with a comment explaining why
> it's not a good idea to enable it.

Ok. Just to clarify, you would like to replace this patch with another 
one with smmu entries in dts and commenting/disabling them with explanation.
Or you would like to have that in addition to this one?

Please take a look at below snippet where I have added the smmu dts nodes
and disabled them with comments.

If this looks ok, I can sent it out soon. Please let me know.

Many Thanks,
Shameer

-- >8 --
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..b561ac6 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,20 @@
 			#interrupt-cells = <2>;
 			num-pins = <128>;
 		};
+
+		mbigen_pcie0: intc_pcie0 {
+			msi-parent = <&its_dsa 0x40085>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <10>;
+		};
+
+		mbigen_smmu_pcie_intc: intc_smmu_pcie {
+			msi-parent = <&its_dsa 0x40b0c>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <3>;
+		};
 	};
 
 	mbigen_dsa(a)c0080000 {
@@ -312,6 +326,27 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip06 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie_intc>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -676,6 +711,29 @@
 				     <637 1>,<638 1>,<639 1>;
 			status = "disabled";
 		};
+
+		pcie0: pcie(a)a0090000 {
+			compatible = "hisilicon,pcie-almost-ecam";
+			reg = <0 0xb0000000 0 0x2000000>, <0 0xa0090000 0 0x10000>;
+			bus-range = <0  31>;
+			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+			msi-map-mask = <0xffff>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x0 0x10000>;*/
+			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000
+				  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;
+			#interrupt-cells = <1>;
+                        interrupt-map-mask = <0xf800 0 0 7>;
+                        interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+                                         0x0 0 0 2 &mbigen_pcie0 650 4
+                                         0x0 0 0 3 &mbigen_pcie0 650 4
+                                         0x0 0 0 4 &mbigen_pcie0 650 4>;
+			status = "disabled";
+		};
+
 	};
 
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..a483325 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,26 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip07 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -1546,6 +1566,7 @@
 			#size-cells = <2>;
 			device_type = "pci";
 			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x20000 0x10000>;*/
 			ranges = <0x02000000 0 0xa8000000 0 0xa8000000 0 0x77f0000
 				  0x01000000 0 0 0 0xaf7f0000 0 0x10000>;
 			#interrupt-cells = <1>;
-- >8 --

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon at arm.com]
> Sent: Wednesday, October 18, 2017 11:52 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon at arm.com]
> > > Sent: Friday, October 13, 2017 8:22 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> > > sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> > > bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > > John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> > > linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> > > pci at vger.kernel.org; devel at acpica.org; Linuxarm
> <linuxarm@huawei.com>;
> > > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun@huawei.com>
> > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind
> > > SMMUv3
> > >
> > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > transactions.
> > > >
> > > > PCIe controller on these platforms has to differentiate the MSI
> > > > payload against other DMA payload and has to modify the MSI payload.
> > > > This basically makes it difficult for this platforms to have a SMMU
> > > > translation for MSI. In order to workaround this, ARM
> > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > Such a quirk is currently missing for DT based systems and therefore
> > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > >
> > > > Signed-off-by: Shameer Kolothum
> > > <shameerali.kolothum.thodi@huawei.com>
> > > > ---
> > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > index a201791..6800747 100644
> > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > *pdev)
> > > >  	struct resource *reg;
> > > >  	int ret;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > >  	if (!hisi_pcie)
> > > >  		return -ENOMEM;
> > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > platform_device *pdev)
> > > >  	struct device *dev = &pdev->dev;
> > > >  	struct pci_ecam_ops *ops;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > >
> > > This isn't the right way to solve this problem. I was really hoping you'd
> come
> > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > now we'll just have to go with the ACPI workaround you have and leave DT
> in
> > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > improves things.
> >
> > Yes Will, this is to get the ACPI support enabled for now.
> >
> > > What I think you should do is remove the relevant smmu/iommu-map
> > > entries from the .dts files that are available for these platforms (i.e.
> > > comment them out with a description as to why).
> >
> > We don't have any smmu/iommu-map entries for these platforms in the
> > .dts files [1][2]. We are not aiming for any official DT support for these
> platforms.
> > This patch is to enforce the non-support.
> 
> Understood, but this has dragged on for a while and I don't think this patch
> is the right way to enforce things. The best approach might actually be to
> add the SMMU to the DTs, but commented out with a comment explaining why
> it's not a good idea to enable it.

Ok. Just to clarify, you would like to replace this patch with another 
one with smmu entries in dts and commenting/disabling them with explanation.
Or you would like to have that in addition to this one?

Please take a look at below snippet where I have added the smmu dts nodes
and disabled them with comments.

If this looks ok, I can sent it out soon. Please let me know.

Many Thanks,
Shameer

-- >8 --
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..b561ac6 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,20 @@
 			#interrupt-cells = <2>;
 			num-pins = <128>;
 		};
+
+		mbigen_pcie0: intc_pcie0 {
+			msi-parent = <&its_dsa 0x40085>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <10>;
+		};
+
+		mbigen_smmu_pcie_intc: intc_smmu_pcie {
+			msi-parent = <&its_dsa 0x40b0c>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <3>;
+		};
 	};
 
 	mbigen_dsa at c0080000 {
@@ -312,6 +326,27 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip06 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie_intc>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -676,6 +711,29 @@
 				     <637 1>,<638 1>,<639 1>;
 			status = "disabled";
 		};
+
+		pcie0: pcie at a0090000 {
+			compatible = "hisilicon,pcie-almost-ecam";
+			reg = <0 0xb0000000 0 0x2000000>, <0 0xa0090000 0 0x10000>;
+			bus-range = <0  31>;
+			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+			msi-map-mask = <0xffff>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x0 0x10000>;*/
+			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000
+				  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;
+			#interrupt-cells = <1>;
+                        interrupt-map-mask = <0xf800 0 0 7>;
+                        interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+                                         0x0 0 0 2 &mbigen_pcie0 650 4
+                                         0x0 0 0 3 &mbigen_pcie0 650 4
+                                         0x0 0 0 4 &mbigen_pcie0 650 4>;
+			status = "disabled";
+		};
+
 	};
 
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..a483325 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,26 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip07 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -1546,6 +1566,7 @@
 			#size-cells = <2>;
 			device_type = "pci";
 			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x20000 0x10000>;*/
 			ranges = <0x02000000 0 0xa8000000 0 0xa8000000 0 0x77f0000
 				  0x01000000 0 0 0 0xaf7f0000 0 0x10000>;
 			#interrupt-cells = <1>;
-- >8 --

RE: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Shameerali Kolothum Thodi]

Hi Will,

> -----Original Message-----
> From: Will Deacon [mailto:will.deacon@arm.com]
> Sent: Wednesday, October 18, 2017 11:52 AM
> To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>
> Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> SMMUv3
> 
> On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> >
> >
> > > -----Original Message-----
> > > From: Will Deacon [mailto:will.deacon@arm.com]
> > > Sent: Friday, October 13, 2017 8:22 PM
> > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > > pci@vger.kernel.org; devel@acpica.org; Linuxarm
> <linuxarm@huawei.com>;
> > > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > > <guohanjun@huawei.com>
> > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> behind
> > > SMMUv3
> > >
> > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > transactions.
> > > >
> > > > PCIe controller on these platforms has to differentiate the MSI
> > > > payload against other DMA payload and has to modify the MSI payload.
> > > > This basically makes it difficult for this platforms to have a SMMU
> > > > translation for MSI. In order to workaround this, ARM
> > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > Such a quirk is currently missing for DT based systems and therefore
> > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > >
> > > > Signed-off-by: Shameer Kolothum
> > > <shameerali.kolothum.thodi@huawei.com>
> > > > ---
> > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > >  1 file changed, 12 insertions(+)
> > > >
> > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > index a201791..6800747 100644
> > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > *pdev)
> > > >  	struct resource *reg;
> > > >  	int ret;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > > > +
> > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > >  	if (!hisi_pcie)
> > > >  		return -ENOMEM;
> > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > platform_device *pdev)
> > > >  	struct device *dev = &pdev->dev;
> > > >  	struct pci_ecam_ops *ops;
> > > >
> > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > map")) {
> > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > PCIe controllers behind SMMUv3\n");
> > > > +		return -ENODEV;
> > > > +	}
> > >
> > > This isn't the right way to solve this problem. I was really hoping you'd
> come
> > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > now we'll just have to go with the ACPI workaround you have and leave DT
> in
> > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > improves things.
> >
> > Yes Will, this is to get the ACPI support enabled for now.
> >
> > > What I think you should do is remove the relevant smmu/iommu-map
> > > entries from the .dts files that are available for these platforms (i.e.
> > > comment them out with a description as to why).
> >
> > We don't have any smmu/iommu-map entries for these platforms in the
> > .dts files [1][2]. We are not aiming for any official DT support for these
> platforms.
> > This patch is to enforce the non-support.
> 
> Understood, but this has dragged on for a while and I don't think this patch
> is the right way to enforce things. The best approach might actually be to
> add the SMMU to the DTs, but commented out with a comment explaining why
> it's not a good idea to enable it.

Ok. Just to clarify, you would like to replace this patch with another 
one with smmu entries in dts and commenting/disabling them with explanation.
Or you would like to have that in addition to this one?

Please take a look at below snippet where I have added the smmu dts nodes
and disabled them with comments.

If this looks ok, I can sent it out soon. Please let me know.

Many Thanks,
Shameer

-- >8 --
diff --git a/arch/arm64/boot/dts/hisilicon/hip06.dtsi b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
index a049b64..b561ac6 100644
--- a/arch/arm64/boot/dts/hisilicon/hip06.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip06.dtsi
@@ -291,6 +291,20 @@
 			#interrupt-cells = <2>;
 			num-pins = <128>;
 		};
+
+		mbigen_pcie0: intc_pcie0 {
+			msi-parent = <&its_dsa 0x40085>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <10>;
+		};
+
+		mbigen_smmu_pcie_intc: intc_smmu_pcie {
+			msi-parent = <&its_dsa 0x40b0c>;
+			interrupt-controller;
+			#interrupt-cells = <2>;
+			num-pins = <3>;
+		};
 	};
 
 	mbigen_dsa@c0080000 {
@@ -312,6 +326,27 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip06 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie_intc>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -676,6 +711,29 @@
 				     <637 1>,<638 1>,<639 1>;
 			status = "disabled";
 		};
+
+		pcie0: pcie@a0090000 {
+			compatible = "hisilicon,pcie-almost-ecam";
+			reg = <0 0xb0000000 0 0x2000000>, <0 0xa0090000 0 0x10000>;
+			bus-range = <0  31>;
+			msi-map = <0x0000 &its_dsa 0x0000 0x2000>;
+			msi-map-mask = <0xffff>;
+			#address-cells = <3>;
+			#size-cells = <2>;
+			device_type = "pci";
+			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x0 0x10000>;*/
+			ranges = <0x02000000 0 0xb2000000 0x0 0xb2000000 0 0x5ff0000
+				  0x01000000 0 0 0 0xb7ff0000 0 0x10000>;
+			#interrupt-cells = <1>;
+                        interrupt-map-mask = <0xf800 0 0 7>;
+                        interrupt-map = <0x0 0 0 1 &mbigen_pcie0 650 4
+                                         0x0 0 0 2 &mbigen_pcie0 650 4
+                                         0x0 0 0 3 &mbigen_pcie0 650 4
+                                         0x0 0 0 4 &mbigen_pcie0 650 4>;
+			status = "disabled";
+		};
+
 	};
 
 };
diff --git a/arch/arm64/boot/dts/hisilicon/hip07.dtsi b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
index 2c01a21..a483325 100644
--- a/arch/arm64/boot/dts/hisilicon/hip07.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip07.dtsi
@@ -1083,6 +1083,26 @@
 		};
 	};
 
+	/** HiSilicon erratum 161010801: Please make sure that
+	 *  the smmu (pcie) node on hip07 is disabled as this will
+	 *  break the PCIe functionality when iommu-map entry
+	 *  is used along with the PCIe node.
+	 */
+	smmu0: smmu_pcie {
+		compatible = "arm,smmu-v3";
+		reg = <0x0 0xa0040000 0x0 0x20000>;
+		interrupt-parent  = <&mbigen_smmu_pcie>;
+		interrupts = <871 1>,
+			<872 1>,
+			<873 1>;
+		interrupt-names = "eventq", "gerror", "cmdq-sync";
+		#iommu-cells = <1>;
+		dma-coherent;
+		smmu-cb-memtype = <0x0 0x1>;
+		hisilicon,broken-prefetch-cmd;
+		status = "disabled";
+	};
+
 	soc {
 		compatible = "simple-bus";
 		#address-cells = <2>;
@@ -1546,6 +1566,7 @@
 			#size-cells = <2>;
 			device_type = "pci";
 			dma-coherent;
+			/*iommu-map = <0x0 &smmu0 0x20000 0x10000>;*/
 			ranges = <0x02000000 0 0xa8000000 0 0xa8000000 0 0x77f0000
 				  0x01000000 0 0 0 0xaf7f0000 0 0x10000>;
 			#interrupt-cells = <1>;
-- >8 --


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

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Wed, Oct 18, 2017 at 12:25:09PM +0000, Shameerali Kolothum Thodi wrote:
> Hi Will,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon@arm.com]
> > Sent: Wednesday, October 18, 2017 11:52 AM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon@arm.com]
> > > > Sent: Friday, October 13, 2017 8:22 PM
> > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > > > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > > > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > > > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > > > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > > > pci@vger.kernel.org; devel@acpica.org; Linuxarm
> > <linuxarm@huawei.com>;
> > > > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > > > <guohanjun@huawei.com>
> > > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> > behind
> > > > SMMUv3
> > > >
> > > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > > transactions.
> > > > >
> > > > > PCIe controller on these platforms has to differentiate the MSI
> > > > > payload against other DMA payload and has to modify the MSI payload.
> > > > > This basically makes it difficult for this platforms to have a SMMU
> > > > > translation for MSI. In order to workaround this, ARM
> > > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > > Such a quirk is currently missing for DT based systems and therefore
> > > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > > >
> > > > > Signed-off-by: Shameer Kolothum
> > > > <shameerali.kolothum.thodi@huawei.com>
> > > > > ---
> > > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > > index a201791..6800747 100644
> > > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > > *pdev)
> > > > >  	struct resource *reg;
> > > > >  	int ret;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > > > +
> > > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > > >  	if (!hisi_pcie)
> > > > >  		return -ENOMEM;
> > > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > > platform_device *pdev)
> > > > >  	struct device *dev = &pdev->dev;
> > > > >  	struct pci_ecam_ops *ops;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > >
> > > > This isn't the right way to solve this problem. I was really hoping you'd
> > come
> > > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > > now we'll just have to go with the ACPI workaround you have and leave DT
> > in
> > > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > > improves things.
> > >
> > > Yes Will, this is to get the ACPI support enabled for now.
> > >
> > > > What I think you should do is remove the relevant smmu/iommu-map
> > > > entries from the .dts files that are available for these platforms (i.e.
> > > > comment them out with a description as to why).
> > >
> > > We don't have any smmu/iommu-map entries for these platforms in the
> > > .dts files [1][2]. We are not aiming for any official DT support for these
> > platforms.
> > > This patch is to enforce the non-support.
> > 
> > Understood, but this has dragged on for a while and I don't think this patch
> > is the right way to enforce things. The best approach might actually be to
> > add the SMMU to the DTs, but commented out with a comment explaining why
> > it's not a good idea to enable it.
> 
> Ok. Just to clarify, you would like to replace this patch with another 
> one with smmu entries in dts and commenting/disabling them with explanation.
> Or you would like to have that in addition to this one?

Yes, I'm saying let's do that instead. My preference is still that we would
have all of this working for DT, but it's clear that isn't going to happen
and so I'm trying to unblock the ACPI bits whilst not having subtle breakage
with DT.

> +	/** HiSilicon erratum 161010801: Please make sure that
> +	 *  the smmu (pcie) node on hip06 is disabled as this will
> +	 *  break the PCIe functionality when iommu-map entry
> +	 *  is used along with the PCIe node.

It would be good to have a better description of what is broken and why,
along with a link to the mailing link discussion.

Will

Re: [Devel] [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

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

On Wed, Oct 18, 2017 at 12:25:09PM +0000, Shameerali Kolothum Thodi wrote:
> Hi Will,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon(a)arm.com]
> > Sent: Wednesday, October 18, 2017 11:52 AM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> > Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> > sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> > bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> > John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> > linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> > pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm <linuxarm(a)huawei.com>;
> > Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun(a)huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon(a)arm.com]
> > > > Sent: Friday, October 13, 2017 8:22 PM
> > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi(a)huawei.com>
> > > > Cc: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> > > > sudeep.holla(a)arm.com; robin.murphy(a)arm.com; joro(a)8bytes.org;
> > > > bhelgaas(a)google.com; Gabriele Paoloni <gabriele.paoloni(a)huawei.com>;
> > > > John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-foundation.org;
> > > > linux-arm-kernel(a)lists.infradead.org; linux-acpi(a)vger.kernel.org; linux-
> > > > pci(a)vger.kernel.org; devel(a)acpica.org; Linuxarm
> > <linuxarm(a)huawei.com>;
> > > > Wangzhou (B) <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> > > > <guohanjun(a)huawei.com>
> > > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> > behind
> > > > SMMUv3
> > > >
> > > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > > transactions.
> > > > >
> > > > > PCIe controller on these platforms has to differentiate the MSI
> > > > > payload against other DMA payload and has to modify the MSI payload.
> > > > > This basically makes it difficult for this platforms to have a SMMU
> > > > > translation for MSI. In order to workaround this, ARM
> > > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > > Such a quirk is currently missing for DT based systems and therefore
> > > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > > >
> > > > > Signed-off-by: Shameer Kolothum
> > > > <shameerali.kolothum.thodi(a)huawei.com>
> > > > > ---
> > > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > > index a201791..6800747 100644
> > > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > > *pdev)
> > > > >  	struct resource *reg;
> > > > >  	int ret;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > > > +
> > > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > > >  	if (!hisi_pcie)
> > > > >  		return -ENOMEM;
> > > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > > platform_device *pdev)
> > > > >  	struct device *dev = &pdev->dev;
> > > > >  	struct pci_ecam_ops *ops;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > >
> > > > This isn't the right way to solve this problem. I was really hoping you'd
> > come
> > > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > > now we'll just have to go with the ACPI workaround you have and leave DT
> > in
> > > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > > improves things.
> > >
> > > Yes Will, this is to get the ACPI support enabled for now.
> > >
> > > > What I think you should do is remove the relevant smmu/iommu-map
> > > > entries from the .dts files that are available for these platforms (i.e.
> > > > comment them out with a description as to why).
> > >
> > > We don't have any smmu/iommu-map entries for these platforms in the
> > > .dts files [1][2]. We are not aiming for any official DT support for these
> > platforms.
> > > This patch is to enforce the non-support.
> > 
> > Understood, but this has dragged on for a while and I don't think this patch
> > is the right way to enforce things. The best approach might actually be to
> > add the SMMU to the DTs, but commented out with a comment explaining why
> > it's not a good idea to enable it.
> 
> Ok. Just to clarify, you would like to replace this patch with another 
> one with smmu entries in dts and commenting/disabling them with explanation.
> Or you would like to have that in addition to this one?

Yes, I'm saying let's do that instead. My preference is still that we would
have all of this working for DT, but it's clear that isn't going to happen
and so I'm trying to unblock the ACPI bits whilst not having subtle breakage
with DT.

> +	/** HiSilicon erratum 161010801: Please make sure that
> +	 *  the smmu (pcie) node on hip06 is disabled as this will
> +	 *  break the PCIe functionality when iommu-map entry
> +	 *  is used along with the PCIe node.

It would be good to have a better description of what is broken and why,
along with a link to the mailing link discussion.

Will

[PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Wed, Oct 18, 2017 at 12:25:09PM +0000, Shameerali Kolothum Thodi wrote:
> Hi Will,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon at arm.com]
> > Sent: Wednesday, October 18, 2017 11:52 AM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> > sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> > bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> > linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> > pci at vger.kernel.org; devel at acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon at arm.com]
> > > > Sent: Friday, October 13, 2017 8:22 PM
> > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > > Cc: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> > > > sudeep.holla at arm.com; robin.murphy at arm.com; joro at 8bytes.org;
> > > > bhelgaas at google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > > > John Garry <john.garry@huawei.com>; iommu at lists.linux-foundation.org;
> > > > linux-arm-kernel at lists.infradead.org; linux-acpi at vger.kernel.org; linux-
> > > > pci at vger.kernel.org; devel at acpica.org; Linuxarm
> > <linuxarm@huawei.com>;
> > > > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > > > <guohanjun@huawei.com>
> > > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> > behind
> > > > SMMUv3
> > > >
> > > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > > transactions.
> > > > >
> > > > > PCIe controller on these platforms has to differentiate the MSI
> > > > > payload against other DMA payload and has to modify the MSI payload.
> > > > > This basically makes it difficult for this platforms to have a SMMU
> > > > > translation for MSI. In order to workaround this, ARM
> > > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > > Such a quirk is currently missing for DT based systems and therefore
> > > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > > >
> > > > > Signed-off-by: Shameer Kolothum
> > > > <shameerali.kolothum.thodi@huawei.com>
> > > > > ---
> > > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > > index a201791..6800747 100644
> > > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > > *pdev)
> > > > >  	struct resource *reg;
> > > > >  	int ret;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > > > +
> > > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > > >  	if (!hisi_pcie)
> > > > >  		return -ENOMEM;
> > > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > > platform_device *pdev)
> > > > >  	struct device *dev = &pdev->dev;
> > > > >  	struct pci_ecam_ops *ops;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > >
> > > > This isn't the right way to solve this problem. I was really hoping you'd
> > come
> > > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > > now we'll just have to go with the ACPI workaround you have and leave DT
> > in
> > > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > > improves things.
> > >
> > > Yes Will, this is to get the ACPI support enabled for now.
> > >
> > > > What I think you should do is remove the relevant smmu/iommu-map
> > > > entries from the .dts files that are available for these platforms (i.e.
> > > > comment them out with a description as to why).
> > >
> > > We don't have any smmu/iommu-map entries for these platforms in the
> > > .dts files [1][2]. We are not aiming for any official DT support for these
> > platforms.
> > > This patch is to enforce the non-support.
> > 
> > Understood, but this has dragged on for a while and I don't think this patch
> > is the right way to enforce things. The best approach might actually be to
> > add the SMMU to the DTs, but commented out with a comment explaining why
> > it's not a good idea to enable it.
> 
> Ok. Just to clarify, you would like to replace this patch with another 
> one with smmu entries in dts and commenting/disabling them with explanation.
> Or you would like to have that in addition to this one?

Yes, I'm saying let's do that instead. My preference is still that we would
have all of this working for DT, but it's clear that isn't going to happen
and so I'm trying to unblock the ACPI bits whilst not having subtle breakage
with DT.

> +	/** HiSilicon erratum 161010801: Please make sure that
> +	 *  the smmu (pcie) node on hip06 is disabled as this will
> +	 *  break the PCIe functionality when iommu-map entry
> +	 *  is used along with the PCIe node.

It would be good to have a better description of what is broken and why,
along with a link to the mailing link discussion.

Will

Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3

[Will Deacon]

On Wed, Oct 18, 2017 at 12:25:09PM +0000, Shameerali Kolothum Thodi wrote:
> Hi Will,
> 
> > -----Original Message-----
> > From: Will Deacon [mailto:will.deacon@arm.com]
> > Sent: Wednesday, October 18, 2017 11:52 AM
> > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > pci@vger.kernel.org; devel@acpica.org; Linuxarm <linuxarm@huawei.com>;
> > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > <guohanjun@huawei.com>
> > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers behind
> > SMMUv3
> > 
> > On Sun, Oct 15, 2017 at 07:46:34AM +0000, Shameerali Kolothum Thodi wrote:
> > >
> > >
> > > > -----Original Message-----
> > > > From: Will Deacon [mailto:will.deacon@arm.com]
> > > > Sent: Friday, October 13, 2017 8:22 PM
> > > > To: Shameerali Kolothum Thodi <shameerali.kolothum.thodi@huawei.com>
> > > > Cc: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> > > > sudeep.holla@arm.com; robin.murphy@arm.com; joro@8bytes.org;
> > > > bhelgaas@google.com; Gabriele Paoloni <gabriele.paoloni@huawei.com>;
> > > > John Garry <john.garry@huawei.com>; iommu@lists.linux-foundation.org;
> > > > linux-arm-kernel@lists.infradead.org; linux-acpi@vger.kernel.org; linux-
> > > > pci@vger.kernel.org; devel@acpica.org; Linuxarm
> > <linuxarm@huawei.com>;
> > > > Wangzhou (B) <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> > > > <guohanjun@huawei.com>
> > > > Subject: Re: [PATCH v9 4/4] PCI: hisi: blacklist hip06/hip07 controllers
> > behind
> > > > SMMUv3
> > > >
> > > > On Fri, Oct 06, 2017 at 03:04:50PM +0100, Shameer Kolothum wrote:
> > > > > The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> > > > > platforms hip06/hip07 to support the SMMUv3 mappings for MSI
> > > > > transactions.
> > > > >
> > > > > PCIe controller on these platforms has to differentiate the MSI
> > > > > payload against other DMA payload and has to modify the MSI payload.
> > > > > This basically makes it difficult for this platforms to have a SMMU
> > > > > translation for MSI. In order to workaround this, ARM
> > > > > SMMUv3 driver requires a quirk to treat the MSI regions separately.
> > > > > Such a quirk is currently missing for DT based systems and therefore
> > > > > we need to blacklist the hip06/hip07 PCIe controllers.
> > > > >
> > > > > Signed-off-by: Shameer Kolothum
> > > > <shameerali.kolothum.thodi@huawei.com>
> > > > > ---
> > > > >  drivers/pci/dwc/pcie-hisi.c | 12 ++++++++++++
> > > > >  1 file changed, 12 insertions(+)
> > > > >
> > > > > diff --git a/drivers/pci/dwc/pcie-hisi.c b/drivers/pci/dwc/pcie-hisi.c
> > > > > index a201791..6800747 100644
> > > > > --- a/drivers/pci/dwc/pcie-hisi.c
> > > > > +++ b/drivers/pci/dwc/pcie-hisi.c
> > > > > @@ -270,6 +270,12 @@ static int hisi_pcie_probe(struct platform_device
> > > > *pdev)
> > > > >  	struct resource *reg;
> > > > >  	int ret;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > > > +
> > > > >  	hisi_pcie = devm_kzalloc(dev, sizeof(*hisi_pcie), GFP_KERNEL);
> > > > >  	if (!hisi_pcie)
> > > > >  		return -ENOMEM;
> > > > > @@ -340,6 +346,12 @@ static int hisi_pcie_almost_ecam_probe(struct
> > > > platform_device *pdev)
> > > > >  	struct device *dev = &pdev->dev;
> > > > >  	struct pci_ecam_ops *ops;
> > > > >
> > > > > +	if ((IS_BUILTIN(CONFIG_ARM_SMMU_V3)) &&
> > > > > +			of_property_read_bool(dev->of_node, "iommu-
> > > > map")) {
> > > > > +		dev_warn(dev, "HiSilicon erratum 161010801: blacklisting
> > > > PCIe controllers behind SMMUv3\n");
> > > > > +		return -ENODEV;
> > > > > +	}
> > > >
> > > > This isn't the right way to solve this problem. I was really hoping you'd
> > come
> > > > up with a solution for DT, and I know you've been trying, so I suppose for
> > > > now we'll just have to go with the ACPI workaround you have and leave DT
> > in
> > > > the balance. I'm not at all happy with that, but I don't think this patch really
> > > > improves things.
> > >
> > > Yes Will, this is to get the ACPI support enabled for now.
> > >
> > > > What I think you should do is remove the relevant smmu/iommu-map
> > > > entries from the .dts files that are available for these platforms (i.e.
> > > > comment them out with a description as to why).
> > >
> > > We don't have any smmu/iommu-map entries for these platforms in the
> > > .dts files [1][2]. We are not aiming for any official DT support for these
> > platforms.
> > > This patch is to enforce the non-support.
> > 
> > Understood, but this has dragged on for a while and I don't think this patch
> > is the right way to enforce things. The best approach might actually be to
> > add the SMMU to the DTs, but commented out with a comment explaining why
> > it's not a good idea to enable it.
> 
> Ok. Just to clarify, you would like to replace this patch with another 
> one with smmu entries in dts and commenting/disabling them with explanation.
> Or you would like to have that in addition to this one?

Yes, I'm saying let's do that instead. My preference is still that we would
have all of this working for DT, but it's clear that isn't going to happen
and so I'm trying to unblock the ACPI bits whilst not having subtle breakage
with DT.

> +	/** HiSilicon erratum 161010801: Please make sure that
> +	 *  the smmu (pcie) node on hip06 is disabled as this will
> +	 *  break the PCIe functionality when iommu-map entry
> +	 *  is used along with the PCIe node.

It would be good to have a better description of what is broken and why,
along with a link to the mailing link discussion.

Will

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

RE: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Will,

Any further comments on this series, please? 

We do have the ack from all relevant people for the "[PATCH v9 4/4] PCI: hisi: blacklist
hip06/hip07 controllers behind SMMUv3" now. 

Really appreciate if you can take a look and let us know.

Many thanks,
Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Friday, October 06, 2017 3:05 PM
> To: lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org; marc.zyngier-5wv7dgnIgG8@public.gmane.org;
> sudeep.holla-5wv7dgnIgG8@public.gmane.org; will.deacon-5wv7dgnIgG8@public.gmane.org; robin.murphy-5wv7dgnIgG8@public.gmane.org;
> joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org; bhelgaas-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org; Gabriele Paoloni
> <gabriele.paoloni-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Cc: John Garry <john.garry-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; iommu-cunTk1MwBs/ROKNJybVBZg@public.gmane.org
> foundation.org; linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; linux-
> acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; devel-E0kO6a4B6psdnm+yROfE0A@public.gmane.org;
> Linuxarm <linuxarm-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Wangzhou (B)
> <wangzhou1-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org>; Guohanjun (Hanjun Guo)
> <guohanjun-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
> Subject: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI and DT based quirk to reserve the hw msi
> regions in the smmu-v3 driver which means these address regions will
> not be translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve the
>    associated ITS base address from a device IORT node.
> 2. Added a generic helper function to of iommu code to retrieve the
>    associated msi controller base address from for a PCI RC
>    msi-mapping and also platform device msi-parent.
> 3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
>    platforms when SMMUv3 is enabled as there is no DT based solution
>    for this as of now.
> 
> Changelog:
> 
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
>  translater region only.
> -Removed the DT support for MSI reservation and blacklisted
>  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
>  enabled.
> 
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
>  -Modified to use DT compatible string for errata.
>  -Changed logic to retrieve the msi-parent for DT case.
> 
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
>  - added bt binding
>  - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
> 
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
>   is not applicable. Provided a generic function in iommu code and added
>   back the quirk implementation in SMMU v3 driver(patch#3)
> 
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
>   HW topologies are handled while reserving ITS regions(patch #1).
> 
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
>   iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
> 
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
>   iort helper function.
> 
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> 
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
> 
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed  the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor
> specific CSRT table.
> 
> 
> Shameer Kolothum (4):
>   ACPI/IORT: Add msi address regions reservation helper
>   iommu/dma: Add a helper function to reserve HW MSI address regions for
>     IOMMU drivers
>   iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
>   PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> 
>  drivers/acpi/arm64/iort.c        | 97
> ++++++++++++++++++++++++++++++++++++++--
>  drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
>  drivers/iommu/dma-iommu.c        | 20 +++++++++
>  drivers/irqchip/irq-gic-v3-its.c |  3 +-
>  drivers/pci/dwc/pcie-hisi.c      | 12 +++++
>  include/linux/acpi_iort.h        |  7 ++-
>  include/linux/dma-iommu.h        |  7 +++
>  7 files changed, 163 insertions(+), 10 deletions(-)
> 
> --
> 1.9.1
> 

Re: [Devel] [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

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

Hi Will,

Any further comments on this series, please? 

We do have the ack from all relevant people for the "[PATCH v9 4/4] PCI: hisi: blacklist
hip06/hip07 controllers behind SMMUv3" now. 

Really appreciate if you can take a look and let us know.

Many thanks,
Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Friday, October 06, 2017 3:05 PM
> To: lorenzo.pieralisi(a)arm.com; marc.zyngier(a)arm.com;
> sudeep.holla(a)arm.com; will.deacon(a)arm.com; robin.murphy(a)arm.com;
> joro(a)8bytes.org; bhelgaas(a)google.com; Gabriele Paoloni
> <gabriele.paoloni(a)huawei.com>
> Cc: John Garry <john.garry(a)huawei.com>; iommu(a)lists.linux-
> foundation.org; linux-arm-kernel(a)lists.infradead.org; linux-
> acpi(a)vger.kernel.org; linux-pci(a)vger.kernel.org; devel(a)acpica.org;
> Linuxarm <linuxarm(a)huawei.com>; Wangzhou (B)
> <wangzhou1(a)hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun(a)huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi(a)huawei.com>
> Subject: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI and DT based quirk to reserve the hw msi
> regions in the smmu-v3 driver which means these address regions will
> not be translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve the
>    associated ITS base address from a device IORT node.
> 2. Added a generic helper function to of iommu code to retrieve the
>    associated msi controller base address from for a PCI RC
>    msi-mapping and also platform device msi-parent.
> 3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
>    platforms when SMMUv3 is enabled as there is no DT based solution
>    for this as of now.
> 
> Changelog:
> 
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
>  translater region only.
> -Removed the DT support for MSI reservation and blacklisted
>  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
>  enabled.
> 
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
>  -Modified to use DT compatible string for errata.
>  -Changed logic to retrieve the msi-parent for DT case.
> 
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
>  - added bt binding
>  - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
> 
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
>   is not applicable. Provided a generic function in iommu code and added
>   back the quirk implementation in SMMU v3 driver(patch#3)
> 
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
>   HW topologies are handled while reserving ITS regions(patch #1).
> 
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
>   iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
> 
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
>   iort helper function.
> 
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> 
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
> 
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed  the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor
> specific CSRT table.
> 
> 
> Shameer Kolothum (4):
>   ACPI/IORT: Add msi address regions reservation helper
>   iommu/dma: Add a helper function to reserve HW MSI address regions for
>     IOMMU drivers
>   iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
>   PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> 
>  drivers/acpi/arm64/iort.c        | 97
> ++++++++++++++++++++++++++++++++++++++--
>  drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
>  drivers/iommu/dma-iommu.c        | 20 +++++++++
>  drivers/irqchip/irq-gic-v3-its.c |  3 +-
>  drivers/pci/dwc/pcie-hisi.c      | 12 +++++
>  include/linux/acpi_iort.h        |  7 ++-
>  include/linux/dma-iommu.h        |  7 +++
>  7 files changed, 163 insertions(+), 10 deletions(-)
> 
> --
> 1.9.1
> 

[PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Will,

Any further comments on this series, please? 

We do have the ack from all relevant people for the "[PATCH v9 4/4] PCI: hisi: blacklist
hip06/hip07 controllers behind SMMUv3" now. 

Really appreciate if you can take a look and let us know.

Many thanks,
Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Friday, October 06, 2017 3:05 PM
> To: lorenzo.pieralisi at arm.com; marc.zyngier at arm.com;
> sudeep.holla at arm.com; will.deacon at arm.com; robin.murphy at arm.com;
> joro at 8bytes.org; bhelgaas at google.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>
> Cc: John Garry <john.garry@huawei.com>; iommu at lists.linux-
> foundation.org; linux-arm-kernel at lists.infradead.org; linux-
> acpi at vger.kernel.org; linux-pci at vger.kernel.org; devel at acpica.org;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI and DT based quirk to reserve the hw msi
> regions in the smmu-v3 driver which means these address regions will
> not be translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve the
>    associated ITS base address from a device IORT node.
> 2. Added a generic helper function to of iommu code to retrieve the
>    associated msi controller base address from for a PCI RC
>    msi-mapping and also platform device msi-parent.
> 3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
>    platforms when SMMUv3 is enabled as there is no DT based solution
>    for this as of now.
> 
> Changelog:
> 
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
>  translater region only.
> -Removed the DT support for MSI reservation and blacklisted
>  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
>  enabled.
> 
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
>  -Modified to use DT compatible string for errata.
>  -Changed logic to retrieve the msi-parent for DT case.
> 
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
>  - added bt binding
>  - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
> 
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
>   is not applicable. Provided a generic function in iommu code and added
>   back the quirk implementation in SMMU v3 driver(patch#3)
> 
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
>   HW topologies are handled while reserving ITS regions(patch #1).
> 
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
>   iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
> 
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
>   iort helper function.
> 
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> 
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
> 
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed  the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor
> specific CSRT table.
> 
> 
> Shameer Kolothum (4):
>   ACPI/IORT: Add msi address regions reservation helper
>   iommu/dma: Add a helper function to reserve HW MSI address regions for
>     IOMMU drivers
>   iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
>   PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> 
>  drivers/acpi/arm64/iort.c        | 97
> ++++++++++++++++++++++++++++++++++++++--
>  drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
>  drivers/iommu/dma-iommu.c        | 20 +++++++++
>  drivers/irqchip/irq-gic-v3-its.c |  3 +-
>  drivers/pci/dwc/pcie-hisi.c      | 12 +++++
>  include/linux/acpi_iort.h        |  7 ++-
>  include/linux/dma-iommu.h        |  7 +++
>  7 files changed, 163 insertions(+), 10 deletions(-)
> 
> --
> 1.9.1
> 

RE: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon 161010801 erratum(reserve HW MSI)

[Shameerali Kolothum Thodi]

Hi Will,

Any further comments on this series, please? 

We do have the ack from all relevant people for the "[PATCH v9 4/4] PCI: hisi: blacklist
hip06/hip07 controllers behind SMMUv3" now. 

Really appreciate if you can take a look and let us know.

Many thanks,
Shameer

> -----Original Message-----
> From: Shameerali Kolothum Thodi
> Sent: Friday, October 06, 2017 3:05 PM
> To: lorenzo.pieralisi@arm.com; marc.zyngier@arm.com;
> sudeep.holla@arm.com; will.deacon@arm.com; robin.murphy@arm.com;
> joro@8bytes.org; bhelgaas@google.com; Gabriele Paoloni
> <gabriele.paoloni@huawei.com>
> Cc: John Garry <john.garry@huawei.com>; iommu@lists.linux-
> foundation.org; linux-arm-kernel@lists.infradead.org; linux-
> acpi@vger.kernel.org; linux-pci@vger.kernel.org; devel@acpica.org;
> Linuxarm <linuxarm@huawei.com>; Wangzhou (B)
> <wangzhou1@hisilicon.com>; Guohanjun (Hanjun Guo)
> <guohanjun@huawei.com>; Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>
> Subject: [PATCH v9 0/4] iommu/smmu-v3: Workaround for hisilicon
> 161010801 erratum(reserve HW MSI)
> 
> On certain HiSilicon platforms (hip06/hip07) the GIC ITS and PCIe RC
> deviates from the standard implementation and this breaks PCIe MSI
> functionality when SMMU is enabled.
> 
> The HiSilicon erratum 161010801 describes this limitation of certain
> HiSilicon platforms to support the SMMU mappings for MSI transactions.
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64 bits to include the deviceID.
> Hence, the PCIe controller on this platforms has to differentiate the MSI
> payload against other DMA payload and has to modify the MSI payload.
> This basically makes it difficult for this platforms to have a SMMU
> translation for MSI.
> 
> This patch implements an ACPI and DT based quirk to reserve the hw msi
> regions in the smmu-v3 driver which means these address regions will
> not be translated and will be excluded from iova allocations.
> 
> To implement this quirk, the following changes are incorporated:
> 1. Added a generic helper function to IORT code to retrieve the
>    associated ITS base address from a device IORT node.
> 2. Added a generic helper function to of iommu code to retrieve the
>    associated msi controller base address from for a PCI RC
>    msi-mapping and also platform device msi-parent.
> 3. Blacklisted HiSilicon PCIe controllers on DT based hip06/hip07
>    platforms when SMMUv3 is enabled as there is no DT based solution
>    for this as of now.
> 
> Changelog:
> 
> v8 --> v9
> -Thanks to Marc, fixed IORT helper function to reserve the ITS
>  translater region only.
> -Removed the DT support for MSI reservation and blacklisted
>  HiSilicon PCIe controllers on DT based systems when SMMUv3 is
>  enabled.
> 
> v7 --> v8
> Addressed comments from Rob and Lorenzo:
>  -Modified to use DT compatible string for errata.
>  -Changed logic to retrieve the msi-parent for DT case.
> 
> v6 --> v7
> Addressed request from Will to add DT support for the erratum:
>  - added bt binding
>  - add of_iommu_msi_get_resv_regions()
> New arm64 silicon errata entry
> Rename iort_iommu_{its->msi}_get_resv_regions
> 
> v5 --> v6
> Addressed comments from Robin and Lorenzo:
> -No change to patch#1 .
> -Reverted v5 patch#2 as this might break the platforms where this quirk
>   is not applicable. Provided a generic function in iommu code and added
>   back the quirk implementation in SMMU v3 driver(patch#3)
> 
> v4 --> v5
> Addressed comments from Robin and Lorenzo:
> -Added a comment to make it clear that, for now, only straightforward
>   HW topologies are handled while reserving ITS regions(patch #1).
> 
> v3 --> v4
> Rebased on 4.13-rc1.
> Addressed comments from Robin, Will and Lorenzo:
> -As suggested by Robin, moved the ITS msi reservation into
>   iommu_dma_get_resv_regions().
> -Added its_count != resv region failure case(patch #1).
> 
> v2 --> v3
> Addressed comments from Lorenzo and Robin:
> -Removed dev_is_pci() check in smmuV3 driver.
> -Don't treat device not having an ITS mapping as an error in
>   iort helper function.
> 
> v1 --> v2
> -patch 2/2: Invoke iort helper fn based on fwnode type(acpi).
> 
> RFCv2 -->PATCH
> -Incorporated Lorenzo's review comments.
> 
> RFC v1 --> RFC v2
> Based on Robin's review comments,
> -Removed  the generic erratum framework.
> -Using IORT/MADT tables to retrieve the ITS base addr instead  of vendor
> specific CSRT table.
> 
> 
> Shameer Kolothum (4):
>   ACPI/IORT: Add msi address regions reservation helper
>   iommu/dma: Add a helper function to reserve HW MSI address regions for
>     IOMMU drivers
>   iommu/arm-smmu-v3:Enable ACPI based HiSilicon erratum 161010801
>   PCI: hisi: blacklist hip06/hip07 controllers behind SMMUv3
> 
>  drivers/acpi/arm64/iort.c        | 97
> ++++++++++++++++++++++++++++++++++++++--
>  drivers/iommu/arm-smmu-v3.c      | 27 ++++++++---
>  drivers/iommu/dma-iommu.c        | 20 +++++++++
>  drivers/irqchip/irq-gic-v3-its.c |  3 +-
>  drivers/pci/dwc/pcie-hisi.c      | 12 +++++
>  include/linux/acpi_iort.h        |  7 ++-
>  include/linux/dma-iommu.h        |  7 +++
>  7 files changed, 163 insertions(+), 10 deletions(-)
> 
> --
> 1.9.1
> 


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