Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Greg Kroah-Hartman 
On Wed, Oct 30, 2019 at 08:45:32PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 08:26:40PM +0100, Greg Kroah-Hartman wrote:
> > Looks good!  You can apply patch 2/2 as well if you want to take that
> > through your tree too.
> 
> I can do that, I'll just need a formal ACK from you.

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

Re: [PATCH v4 2/2] usb: core: Remove redundant vmap checks

2019-10-30 Thread Greg Kroah-Hartman 
On Tue, Oct 29, 2019 at 02:34:23PM -0700, Kees Cook wrote:
> Now that the vmap area checks are being performed in the DMA
> infrastructure directly, there is no need to repeat them in USB.
> 
> Signed-off-by: Kees Cook 
> ---
>  drivers/usb/core/hcd.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)

Acked-by: Greg Kroah-Hartman 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[PATCH v4 3/6] iommu/arm-smmu: Add global/context fault implementation hooks

2019-10-30 Thread Krishna Reddy 
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.

Signed-off-by: Krishna Reddy 
---
 drivers/iommu/arm-smmu-nvidia.c | 100 
 drivers/iommu/arm-smmu.c|  11 -
 drivers/iommu/arm-smmu.h|   3 ++
 3 files changed, 112 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
index 05d66ac..0ba7abc 100644
--- a/drivers/iommu/arm-smmu-nvidia.c
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -117,6 +117,104 @@ static int nsmmu_reset(struct arm_smmu_device *smmu)
return 0;
 }
 
+static struct arm_smmu_domain *to_smmu_domain(struct iommu_domain *dom)
+{
+   return container_of(dom, struct arm_smmu_domain, domain);
+}
+
+static irqreturn_t nsmmu_global_fault_inst(int irq,
+  struct arm_smmu_device *smmu,
+  int inst)
+{
+   u32 gfsr, gfsynr0, gfsynr1, gfsynr2;
+
+   gfsr = readl_relaxed(nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+   gfsynr0 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+   ARM_SMMU_GR0_sGFSYNR0);
+   gfsynr1 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+   ARM_SMMU_GR0_sGFSYNR1);
+   gfsynr2 = readl_relaxed(nsmmu_page(smmu, inst, 0) +
+   ARM_SMMU_GR0_sGFSYNR2);
+
+   if (!gfsr)
+   return IRQ_NONE;
+
+   dev_err_ratelimited(smmu->dev,
+   "Unexpected global fault, this could be serious\n");
+   dev_err_ratelimited(smmu->dev,
+   "\tGFSR 0x%08x, GFSYNR0 0x%08x, GFSYNR1 0x%08x, GFSYNR2 
0x%08x\n",
+   gfsr, gfsynr0, gfsynr1, gfsynr2);
+
+   writel_relaxed(gfsr, nsmmu_page(smmu, inst, 0) + ARM_SMMU_GR0_sGFSR);
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_global_fault(int irq, void *dev)
+{
+   int inst;
+   irqreturn_t irq_ret = IRQ_NONE;
+   struct arm_smmu_device *smmu = dev;
+
+   for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+   irq_ret = nsmmu_global_fault_inst(irq, smmu, inst);
+   if (irq_ret == IRQ_HANDLED)
+   return irq_ret;
+   }
+
+   return irq_ret;
+}
+
+static irqreturn_t nsmmu_context_fault_bank(int irq,
+   struct arm_smmu_device *smmu,
+   int idx, int inst)
+{
+   u32 fsr, fsynr, cbfrsynra;
+   unsigned long iova;
+
+   fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
+   if (!(fsr & FSR_FAULT))
+   return IRQ_NONE;
+
+   fsynr = readl_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ ARM_SMMU_CB_FSYNR0);
+   iova = readq_relaxed(nsmmu_page(smmu, inst, smmu->numpage + idx) +
+ARM_SMMU_CB_FAR);
+   cbfrsynra = readl_relaxed(nsmmu_page(smmu, inst, 1) +
+ ARM_SMMU_GR1_CBFRSYNRA(idx));
+
+   dev_err_ratelimited(smmu->dev,
+   "Unhandled context fault: fsr=0x%x, iova=0x%08lx, fsynr=0x%x, 
cbfrsynra=0x%x, cb=%d\n",
+   fsr, iova, fsynr, cbfrsynra, idx);
+
+   writel_relaxed(fsr, nsmmu_page(smmu, inst, smmu->numpage + idx) +
+   ARM_SMMU_CB_FSR);
+   return IRQ_HANDLED;
+}
+
+static irqreturn_t nsmmu_context_fault(int irq, void *dev)
+{
+   int inst, idx;
+   irqreturn_t irq_ret = IRQ_NONE;
+   struct iommu_domain *domain = dev;
+   struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
+   struct arm_smmu_device *smmu = smmu_domain->smmu;
+
+   for (inst = 0; inst < to_nvidia_smmu(smmu)->num_inst; inst++) {
+   /* Interrupt line shared between all context faults.
+* Check for faults across all contexts.
+*/
+   for (idx = 0; idx < smmu->num_context_banks; idx++) {
+   irq_ret = nsmmu_context_fault_bank(irq, smmu,
+  idx, inst);
+
+   if (irq_ret == IRQ_HANDLED)
+   return irq_ret;
+   }
+   }
+
+   return irq_ret;
+}
+
 static const struct arm_smmu_impl nvidia_smmu_impl = {
.read_reg = nsmmu_read_reg,
.write_reg = nsmmu_write_reg,
@@ -124,6 +222,8 @@ static const struct arm_smmu_impl nvidia_smmu_impl = {
.write_reg64 = nsmmu_write_reg64,
.reset = nsmmu_reset,
.tlb_sync = nsmmu_tlb_sync,
+   .global_fault = nsmmu_global_fault,
+   .context_fault = nsmmu_context_fault,
 };
 
 struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device *smmu)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 080af03..829fb4c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -651,6 +651,7

[PATCH v4 5/6] arm64: tegra: Add DT node for T194 SMMU

2019-10-30 Thread Krishna Reddy 
Add DT node for T194 SMMU to enable SMMU support.

Signed-off-by: Krishna Reddy 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77 
 1 file changed, 77 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 1e0b54b..6f81e90 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1436,6 +1436,83 @@
  0x8200 0x0  0x4000 0x1f 0x4000 0x0 
0xc000>; /* non-prefetchable memory (3GB) */
};
 
+   smmu: iommu@1200 {
+   compatible = "arm,mmu-500","nvidia,tegra194-smmu";
+   reg = <0 0x1200 0 0x80>,
+ <0 0x1100 0 0x80>,
+ <0 0x1000 0 0x80>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   stream-match-mask = <0x7f80>;
+   #global-interrupts = <3>;
+   #iommu-cells = <1>;
+   };
+
sysram@4000 {
compatible = "nvidia,tegra194-sysram", "mmio-sram";
reg = <0x0 0x4000 0x0 0x5>;
-- 
2.7.4

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

[PATCH v4 6/6] arm64: tegra: enable SMMU for SDHCI and EQOS on T194

2019-10-30 Thread Krishna Reddy 
Enable SMMU translations for SDHCI and EQOS transactions on T194.

Signed-off-by: Krishna Reddy 
---
 arch/arm64/boot/dts/nvidia/tegra194.dtsi | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 6f81e90..bf8ed7a 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -3,6 +3,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -51,6 +52,7 @@
clock-names = "master_bus", "slave_bus", "rx", "tx", 
"ptp_ref";
resets = <&bpmp TEGRA194_RESET_EQOS>;
reset-names = "eqos";
+   iommus = <&smmu TEGRA186_SID_EQOS>;
status = "disabled";
 
snps,write-requests = <1>;
@@ -413,6 +415,7 @@
clock-names = "sdhci";
resets = <&bpmp TEGRA194_RESET_SDMMC1>;
reset-names = "sdhci";
+   iommus = <&smmu TEGRA186_SID_SDMMC1>;
nvidia,pad-autocal-pull-up-offset-3v3-timeout =
<0x07>;
nvidia,pad-autocal-pull-down-offset-3v3-timeout =
@@ -435,6 +438,7 @@
clock-names = "sdhci";
resets = <&bpmp TEGRA194_RESET_SDMMC3>;
reset-names = "sdhci";
+   iommus = <&smmu TEGRA186_SID_SDMMC3>;
nvidia,pad-autocal-pull-up-offset-1v8 = <0x00>;
nvidia,pad-autocal-pull-down-offset-1v8 = <0x7a>;
nvidia,pad-autocal-pull-up-offset-3v3-timeout = <0x07>;
@@ -462,6 +466,7 @@
  <&bpmp TEGRA194_CLK_PLLC4>;
resets = <&bpmp TEGRA194_RESET_SDMMC4>;
reset-names = "sdhci";
+   iommus = <&smmu TEGRA186_SID_SDMMC4>;
nvidia,pad-autocal-pull-up-offset-hs400 = <0x00>;
nvidia,pad-autocal-pull-down-offset-hs400 = <0x00>;
nvidia,pad-autocal-pull-up-offset-1v8-timeout = <0x0a>;
-- 
2.7.4

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

[PATCH v4 2/6] dt-bindings: arm-smmu: Add binding for Tegra194 SMMU

2019-10-30 Thread Krishna Reddy 
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.

Signed-off-by: Krishna Reddy 
---
 Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt 
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 3133f3b..1d72fac 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -31,6 +31,10 @@ conditions.
   as below, SoC-specific compatibles:
   "qcom,sdm845-smmu-500", "arm,mmu-500"
 
+  NVIDIA SoCs that use more than one ARM MMU-500 together
+  needs following SoC-specific compatibles along with 
"arm,mmu-500":
+  "nvidia,tegra194-smmu"
+
 - reg   : Base address and size of the SMMU.
 
 - #global-interrupts : The number of global interrupts exposed by the
-- 
2.7.4

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

[PATCH v4 0/6] Nvidia Arm SMMUv2 Implementation

2019-10-30 Thread Krishna Reddy 
Changes in v4:
Rebased on top of 
https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/ 
for-joerg/arm-smmu/updates.
Updated arm-smmu-nvidia.c to use the tlb_sync implementation hook.
Dropped patch that updates arm_smmu_flush_ops for override as it is no longer 
necessary.

v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588

Krishna Reddy (6):
  iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
  dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
  iommu/arm-smmu: Add global/context fault implementation hooks
  arm64: tegra: Add Memory controller DT node on T194
  arm64: tegra: Add DT node for T194 SMMU
  arm64: tegra: enable SMMU for SDHCI and EQOS on T194

 .../devicetree/bindings/iommu/arm,smmu.txt |   4 +
 MAINTAINERS|   2 +
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi |   4 +
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   |  88 +++
 drivers/iommu/Makefile |   2 +-
 drivers/iommu/arm-smmu-impl.c  |   3 +
 drivers/iommu/arm-smmu-nvidia.c| 261 +
 drivers/iommu/arm-smmu.c   |  11 +-
 drivers/iommu/arm-smmu.h   |   4 +
 9 files changed, 376 insertions(+), 3 deletions(-)
 create mode 100644 drivers/iommu/arm-smmu-nvidia.c

-- 
2.7.4

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

[PATCH v4 4/6] arm64: tegra: Add Memory controller DT node on T194

2019-10-30 Thread Krishna Reddy 
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.

Signed-off-by: Krishna Reddy 
---
 arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4 
 arch/arm64/boot/dts/nvidia/tegra194.dtsi   | 6 ++
 2 files changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
index 4c38426..82a02490 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi
@@ -47,6 +47,10 @@
};
};
 
+   memory-controller@2c0 {
+   status = "okay";
+   };
+
serial@311 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi 
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54..1e0b54b 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -163,6 +163,12 @@
};
};
 
+   memory-controller@2c0 {
+   compatible = "nvidia,tegra186-mc";
+   reg = <0x02c0 0xb>;
+   status = "disabled";
+   };
+
uarta: serial@310 {
compatible = "nvidia,tegra194-uart", 
"nvidia,tegra20-uart";
reg = <0x0310 0x40>;
-- 
2.7.4

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

[PATCH v4 1/6] iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage

2019-10-30 Thread Krishna Reddy 
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.

Signed-off-by: Krishna Reddy 
---
 MAINTAINERS |   2 +
 drivers/iommu/Makefile  |   2 +-
 drivers/iommu/arm-smmu-impl.c   |   3 +
 drivers/iommu/arm-smmu-nvidia.c | 161 
 drivers/iommu/arm-smmu.h|   1 +
 5 files changed, 168 insertions(+), 1 deletion(-)
 create mode 100644 drivers/iommu/arm-smmu-nvidia.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 296de2b..0519024 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15972,9 +15972,11 @@ F: drivers/i2c/busses/i2c-tegra.c
 
 TEGRA IOMMU DRIVERS
 M: Thierry Reding 
+R: Krishna Reddy 
 L: linux-te...@vger.kernel.org
 S: Supported
 F: drivers/iommu/tegra*
+F: drivers/iommu/arm-smmu-nvidia.c
 
 TEGRA KBC DRIVER
 M: Laxman Dewangan 
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 4f405f9..7baeade 100644
--- a/drivers/iommu/Makefile
+++ b/drivers/iommu/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o
 obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o amd_iommu_quirks.o
 obj-$(CONFIG_AMD_IOMMU_DEBUGFS) += amd_iommu_debugfs.o
 obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o
-obj-$(CONFIG_ARM_SMMU) += arm-smmu.o arm-smmu-impl.o
+obj-$(CONFIG_ARM_SMMU) += arm-smmu.o arm-smmu-impl.o arm-smmu-nvidia.o
 obj-$(CONFIG_ARM_SMMU_V3) += arm-smmu-v3.o
 obj-$(CONFIG_DMAR_TABLE) += dmar.o
 obj-$(CONFIG_INTEL_IOMMU) += intel-iommu.o intel-pasid.o
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 5c87a38..1a19687 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -158,6 +158,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct 
arm_smmu_device *smmu)
 */
switch (smmu->model) {
case ARM_MMU500:
+   if (of_device_is_compatible(smmu->dev->of_node,
+   "nvidia,tegra194-smmu"))
+   return nvidia_smmu_impl_init(smmu);
smmu->impl = &arm_mmu500_impl;
break;
case CAVIUM_SMMUV2:
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu/arm-smmu-nvidia.c
new file mode 100644
index 000..05d66ac
--- /dev/null
+++ b/drivers/iommu/arm-smmu-nvidia.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Nvidia ARM SMMU v2 implementation quirks
+// Copyright (C) 2019 NVIDIA CORPORATION.  All rights reserved.
+
+#define pr_fmt(fmt) "nvidia-smmu: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "arm-smmu.h"
+
+/* Tegra194 has three ARM MMU-500 Instances.
+ * Two of them are used together for Interleaved IOVA accesses and
+ * used by Non-Isochronous Hw devices for SMMU translations.
+ * Third one is used for SMMU translations from Isochronous HW devices.
+ * It is possible to use this Implementation to program either
+ * all three or two of the instances identically as desired through
+ * DT node.
+ *
+ * Programming all the three instances identically comes with redundant tlb
+ * invalidations as all three never need to be tlb invalidated for a HW device.
+ *
+ * When Linux Kernel supports multiple SMMU devices, The SMMU device used for
+ * Isochornous HW devices should be added as a separate ARM MMU-500 device
+ * in DT and be programmed independently for efficient tlb invalidates.
+ *
+ */
+#define MAX_SMMU_INSTANCES 3
+
+#define TLB_LOOP_TIMEOUT   100 /* 1s! */
+#define TLB_SPIN_COUNT 10
+
+struct nvidia_smmu {
+   struct arm_smmu_device  smmu;
+   unsigned intnum_inst;
+   void __iomem*bases[MAX_SMMU_INSTANCES];
+};
+
+#define to_nvidia_smmu(s) container_of(s, struct nvidia_smmu, smmu)
+
+#define nsmmu_page(smmu, inst, page) \
+   (((inst) ? to_nvidia_smmu(smmu)->bases[(inst)] : smmu->base) + \
+   ((page) << smmu->pgshift))
+
+static u32 nsmmu_read_reg(struct arm_smmu_device *smmu,
+ int page, int offset)
+{
+   return readl_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg(struct arm_smmu_device *smmu,
+   int page, int offset, u32 val)
+{
+   unsigned int i;
+
+   for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+   writel_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}
+
+static u64 nsmmu_read_reg64(struct arm_smmu_device *smmu,
+   int page, int offset)
+{
+   return readq_relaxed(nsmmu_page(smmu, 0, page) + offset);
+}
+
+static void nsmmu_write_reg64(struct arm_smmu_device *smmu,
+ int page, int offset, u64 val)
+{
+   unsigned int i;
+
+   for (i = 0; i < to_nvidia_smmu(smmu)->num_inst; i++)
+   writeq_relaxed(val, nsmmu_page(smmu, i, page) + offset);
+}

Re: [PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"

2019-10-30 Thread Jordan Crouse 
On Wed, Oct 30, 2019 at 02:51:11PM +, Will Deacon wrote:
> This reverts commit addb672f200f4e99368270da205320b83efe01a0.
> 
> Let's get the SMMU driver building as a module, which means putting
> back some dead code that we used to carry.
> 
> Signed-off-by: Will Deacon 
> ---
>  drivers/iommu/arm-smmu.c | 32 +++-
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> index 7c503a6bc585..53bbe0663b9e 100644
> --- a/drivers/iommu/arm-smmu.c
> +++ b/drivers/iommu/arm-smmu.c
> @@ -27,8 +27,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -59,10 +58,6 @@
>  #define MSI_IOVA_LENGTH  0x10
>  
>  static int force_stage;
> -/*
> - * not really modular, but the easiest way to keep compat with existing
> - * bootargs behaviour is to continue using module_param() here.
> - */
>  module_param(force_stage, int, S_IRUGO);
>  MODULE_PARM_DESC(force_stage,
>   "Force SMMU mappings to be installed at a particular stage of 
> translation. A value of '1' or '2' forces the corresponding stage. All other 
> values are ignored (i.e. no stage is forced). Note that selecting a specific 
> stage will disable support for nested translation.");
> @@ -1878,6 +1873,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
>   { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
>   { },
>  };
> +MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
>  
>  #ifdef CONFIG_ACPI
>  static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
> @@ -2165,12 +2161,12 @@ static int arm_smmu_legacy_bus_init(void)
>  }
>  device_initcall_sync(arm_smmu_legacy_bus_init);
>  
> -static void arm_smmu_device_shutdown(struct platform_device *pdev)
> +static int arm_smmu_device_remove(struct platform_device *pdev)
>  {
>   struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
>  
>   if (!smmu)
> - return;
> + return -ENODEV;
>  
>   if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
>   dev_err(&pdev->dev, "removing device with active domains!\n");
> @@ -2186,6 +2182,12 @@ static void arm_smmu_device_shutdown(struct 
> platform_device *pdev)
>   clk_bulk_disable(smmu->num_clks, smmu->clks);
>  
>   clk_bulk_unprepare(smmu->num_clks, smmu->clks);
> + return 0;
> +}
> +
> +static void arm_smmu_device_shutdown(struct platform_device *pdev)
> +{
> + arm_smmu_device_remove(pdev);
>  }
>  
>  static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
> @@ -2235,12 +2237,16 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
>  
>  static struct platform_driver arm_smmu_driver = {
>   .driver = {
> - .name   = "arm-smmu",
> - .of_match_table = of_match_ptr(arm_smmu_of_match),
> - .pm = &arm_smmu_pm_ops,
> - .suppress_bind_attrs= true,
> + .name   = "arm-smmu",
> + .of_match_table = of_match_ptr(arm_smmu_of_match),
> + .pm = &arm_smmu_pm_ops,
>   },
>   .probe  = arm_smmu_device_probe,
> + .remove = arm_smmu_device_remove,
>   .shutdown = arm_smmu_device_shutdown,
>  };
> -builtin_platform_driver(arm_smmu_driver);
> +module_platform_driver(arm_smmu_driver);

I know this is a revert, but wouldn't you still want to be at device_init()
level for built in drivers? It always preferable to not defer if given the
choice to do so and device_init() is the right level for this driver IMO.

Jordan

-- 
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH RFC 1/5] dma/direct: turn ARCH_ZONE_DMA_BITS into a variable

2019-10-30 Thread Christoph Hellwig 
On Mon, Oct 14, 2019 at 08:31:03PM +0200, Nicolas Saenz Julienne wrote:
> Some architectures, notably ARM, are interested in tweaking this
> depending on their runtime DMA addressing limitations.
> 
> Signed-off-by: Nicolas Saenz Julienne 

Do you want me to pick this up for the 5.5 dma-mapping tree, or do you
want me to wait for the rest to settle?
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 1/2] dma-direct: check for overflows on 32 bit DMA addresses

2019-10-30 Thread Christoph Hellwig 
On Fri, Oct 18, 2019 at 01:00:43PM +0200, Nicolas Saenz Julienne wrote:
> +#ifndef CONFIG_ARCH_DMA_ADDR_T_64BIT
> + /* Check if DMA address overflowed */
> + if (min(addr, addr + size - 1) <
> + __phys_to_dma(dev, (phys_addr_t)(min_low_pfn << PAGE_SHIFT)))
> + return false;
> +#endif

Would be nice to use IS_ENABLED and PFN_PHYS here, and I also think we
need to use phys_to_dma to take care of the encryption bit.  If you then
also introduce an end variable we can make the whole thing actually look
nice:

static inline bool dma_capable(struct device *dev, dma_addr_t addr, size_t size)
{
dma_addr_t end = addr + size - 1;

if (!dev->dma_mask)
return false;

if (!IS_ENABLED(CONFIG_ARCH_DMA_ADDR_T_64BIT) &&
min(addr, end) < phys_to_dma(dev, PFN_PHYS(min_low_pfn)))
return false;

return end <= min_not_zero(*dev->dma_mask, dev->bus_dma_mask);
}

Otherwise this looks sensible to me.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules

2019-10-30 Thread Bjorn Helgaas 
On Wed, Oct 30, 2019 at 02:51:08PM +, Will Deacon wrote:
> Building drivers for ATS-aware IOMMUs as modules requires access to
> pci_ats_disabled(). Export it as a GPL symbol to get things working.
> 
> Signed-off-by: Will Deacon 

Acked-by: Bjorn Helgaas 

> ---
>  drivers/pci/pci.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> index a97e2571a527..4fbe5b576dd8 100644
> --- a/drivers/pci/pci.c
> +++ b/drivers/pci/pci.c
> @@ -123,6 +123,7 @@ bool pci_ats_disabled(void)
>  {
>   return pcie_ats_disabled;
>  }
> +EXPORT_SYMBOL_GPL(pci_ats_disabled);
>  
>  /* Disable bridge_d3 for all PCIe ports */
>  static bool pci_bridge_d3_disable;
> -- 
> 2.24.0.rc0.303.g954a862665-goog
> 
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Christoph Hellwig 
On Wed, Oct 30, 2019 at 08:26:40PM +0100, Greg Kroah-Hartman wrote:
> Looks good!  You can apply patch 2/2 as well if you want to take that
> through your tree too.

I can do that, I'll just need a formal ACK from you.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module

2019-10-30 Thread Joerg Roedel 
Hi Will,

On Wed, Oct 30, 2019 at 02:51:10PM +, Will Deacon wrote:
> By removing the redundant call to 'pci_request_acs()' we can allow the
> ARM SMMUv3 driver to be built as a module.
> 
> Signed-off-by: Will Deacon 
> ---
>  drivers/iommu/Kconfig   | 2 +-
>  drivers/iommu/arm-smmu-v3.c | 1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index e3842eabcfdd..7583d47fc4d5 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -388,7 +388,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
> config.
>  
>  config ARM_SMMU_V3
> - bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
> + tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
>   depends on ARM64
>   select IOMMU_API
>   select IOMMU_IO_PGTABLE_LPAEa

Sorry for the stupid question, but what prevents the iommu module from
being unloaded when there are active users? There are no symbol
dependencies to endpoint device drivers, because the interface is only
exposed through the iommu-api, right? Is some sort of manual module
reference counting needed?


Joerg

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

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Greg Kroah-Hartman 
On Wed, Oct 30, 2019 at 07:09:21PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> > > As we've seen from USB and other areas[1], we need to always do runtime
> > > checks for DMA operating on memory regions that might be remapped. This
> > > adds vmap checks (similar to those already in USB but missing in other
> > > places) into dma_map_single() so all callers benefit from the checking.
> > > 
> > > [1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
> > > 
> > > Suggested-by: Laura Abbott 
> > > Signed-off-by: Kees Cook 
> > > ---
> > >  include/linux/dma-mapping.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > > index 4a1c4fca475a..54de3c496407 100644
> > > --- a/include/linux/dma-mapping.h
> > > +++ b/include/linux/dma-mapping.h
> > > @@ -583,6 +583,12 @@ static inline unsigned long 
> > > dma_get_merge_boundary(struct device *dev)
> > >  static inline dma_addr_t dma_map_single_attrs(struct device *dev, void 
> > > *ptr,
> > >   size_t size, enum dma_data_direction dir, unsigned long attrs)
> > >  {
> > > + /* DMA must never operate on areas that might be remapped. */
> > > + if (dev_WARN_ONCE(dev, is_vmalloc_addr(ptr),
> > > +   "wanted %zu bytes mapped in vmalloc\n", size)) {
> > > + return DMA_MAPPING_ERROR;
> > > + }
> > 
> > That's a very odd error string, I know if I saw it for the first time, I
> > would have no idea what it meant.  The USB message at least gives you a
> > bit more context as to what went wrong and how to fix it.
> > 
> > How about something like "Memory is not DMA capabable, please fix the
> > allocation of it to be correct", or "non-dma-able memory was attempted
> > to be mapped, but this is impossible to to" or something else.
> 
> I've fixed the message to "rejecting DMA map of vmalloc memory" and
> applied the patch.

Looks good!  You can apply patch 2/2 as well if you want to take that
through your tree too.

thanks,

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

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Kees Cook 
On Wed, Oct 30, 2019 at 07:09:21PM +0100, Christoph Hellwig wrote:
> On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> > > As we've seen from USB and other areas[1], we need to always do runtime
> > > checks for DMA operating on memory regions that might be remapped. This
> > > adds vmap checks (similar to those already in USB but missing in other
> > > places) into dma_map_single() so all callers benefit from the checking.
> > > 
> > > [1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
> > > 
> > > Suggested-by: Laura Abbott 
> > > Signed-off-by: Kees Cook 
> > > ---
> > >  include/linux/dma-mapping.h | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > > index 4a1c4fca475a..54de3c496407 100644
> > > --- a/include/linux/dma-mapping.h
> > > +++ b/include/linux/dma-mapping.h
> > > @@ -583,6 +583,12 @@ static inline unsigned long 
> > > dma_get_merge_boundary(struct device *dev)
> > >  static inline dma_addr_t dma_map_single_attrs(struct device *dev, void 
> > > *ptr,
> > >   size_t size, enum dma_data_direction dir, unsigned long attrs)
> > >  {
> > > + /* DMA must never operate on areas that might be remapped. */
> > > + if (dev_WARN_ONCE(dev, is_vmalloc_addr(ptr),
> > > +   "wanted %zu bytes mapped in vmalloc\n", size)) {
> > > + return DMA_MAPPING_ERROR;
> > > + }
> > 
> > That's a very odd error string, I know if I saw it for the first time, I
> > would have no idea what it meant.  The USB message at least gives you a
> > bit more context as to what went wrong and how to fix it.
> > 
> > How about something like "Memory is not DMA capabable, please fix the
> > allocation of it to be correct", or "non-dma-able memory was attempted
> > to be mapped, but this is impossible to to" or something else.
> 
> I've fixed the message to "rejecting DMA map of vmalloc memory" and
> applied the patch.

Great; thank you!

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

Re: [PATCH] dma/coherent: remove unused dma_get_device_base()

2019-10-30 Thread Christoph Hellwig 
So it turns out the user now showed up, so I'm skipping this patch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH] dma-mapping: fix handling of dma-ranges for reserved memory (again)

2019-10-30 Thread Christoph Hellwig 
Thanks,

applied to the dma-mapping for-next tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH V2] kernel: dma: contigous: Make CMA parameters __initdata/__initconst

2019-10-30 Thread Christoph Hellwig 
Applied to the dma-mapping for-next branch after fixing up the commit
message and an overly long line.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Christoph Hellwig 
On Wed, Oct 30, 2019 at 10:18:49AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> > As we've seen from USB and other areas[1], we need to always do runtime
> > checks for DMA operating on memory regions that might be remapped. This
> > adds vmap checks (similar to those already in USB but missing in other
> > places) into dma_map_single() so all callers benefit from the checking.
> > 
> > [1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
> > 
> > Suggested-by: Laura Abbott 
> > Signed-off-by: Kees Cook 
> > ---
> >  include/linux/dma-mapping.h | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> > index 4a1c4fca475a..54de3c496407 100644
> > --- a/include/linux/dma-mapping.h
> > +++ b/include/linux/dma-mapping.h
> > @@ -583,6 +583,12 @@ static inline unsigned long 
> > dma_get_merge_boundary(struct device *dev)
> >  static inline dma_addr_t dma_map_single_attrs(struct device *dev, void 
> > *ptr,
> > size_t size, enum dma_data_direction dir, unsigned long attrs)
> >  {
> > +   /* DMA must never operate on areas that might be remapped. */
> > +   if (dev_WARN_ONCE(dev, is_vmalloc_addr(ptr),
> > + "wanted %zu bytes mapped in vmalloc\n", size)) {
> > +   return DMA_MAPPING_ERROR;
> > +   }
> 
> That's a very odd error string, I know if I saw it for the first time, I
> would have no idea what it meant.  The USB message at least gives you a
> bit more context as to what went wrong and how to fix it.
> 
> How about something like "Memory is not DMA capabable, please fix the
> allocation of it to be correct", or "non-dma-able memory was attempted
> to be mapped, but this is impossible to to" or something else.

I've fixed the message to "rejecting DMA map of vmalloc memory" and
applied the patch.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

2019-10-30 Thread Will Deacon 
Hi Robin,

On Wed, Oct 30, 2019 at 03:35:55PM +, Robin Murphy wrote:
> On 30/10/2019 14:51, Will Deacon wrote:
> > As part of the work to enable a "Generic Kernel Image" across multiple
> > Android devices, there is a need to seperate shared, core kernel code
> > from modular driver code that may not be needed by all SoCs. This means
> > building IOMMU drivers as modules.
> > 
> > It turns out that most of the groundwork has already been done to enable
> > the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig;
> > with a few symbols exported from the IOMMU/PCI core, everything builds
> > nicely out of the box. The one exception is support for the legacy SMMU
> > DT binding, which is not in widespread use and has never worked with
> > modules, so we can simply remove that when building as a module rather
> > than try to paper over it with even more hacks.
> > 
> > Obviously you need to be careful about using IOMMU drivers as modules,
> > since late loading of the driver for an IOMMU serving active DMA masters
> > is going to end badly in many cases. On Android, we're using device links
> > to ensure that the IOMMU probes first.
> 
> Out of curiosity, which device links are those? Clearly not the RPM links
> created by the IOMMU drivers themselves... Is this some special Android
> magic, or is there actually a chance of replacing all the
> of_iommu_configure() machinery with something more generic?

I'll admit that I haven't used them personally yet, but I'm referring to
this series from Saravana [CC'd]:

https://lore.kernel.org/linux-acpi/20190904211126.47518-1-sarava...@google.com/

which is currently sitting in linux-next now that we're upstreaming the
"special Android magic" ;)

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

Re: [PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

2019-10-30 Thread Robin Murphy 

On 30/10/2019 14:51, Will Deacon wrote:

Hi all,

As part of the work to enable a "Generic Kernel Image" across multiple
Android devices, there is a need to seperate shared, core kernel code
from modular driver code that may not be needed by all SoCs. This means
building IOMMU drivers as modules.

It turns out that most of the groundwork has already been done to enable
the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig;
with a few symbols exported from the IOMMU/PCI core, everything builds
nicely out of the box. The one exception is support for the legacy SMMU
DT binding, which is not in widespread use and has never worked with
modules, so we can simply remove that when building as a module rather
than try to paper over it with even more hacks.

Obviously you need to be careful about using IOMMU drivers as modules,
since late loading of the driver for an IOMMU serving active DMA masters
is going to end badly in many cases. On Android, we're using device links
to ensure that the IOMMU probes first.


Out of curiosity, which device links are those? Clearly not the RPM 
links created by the IOMMU drivers themselves... Is this some special 
Android magic, or is there actually a chance of replacing all the 
of_iommu_configure() machinery with something more generic?


Robin.



Comments welcome,

Will

Cc: Robin Murphy 
Cc: Joerg Roedel 
Cc: Bjorn Helgaas 
Cc: Lorenzo Pieralisi 

--->8

Will Deacon (7):
   drivers/iommu: Export core IOMMU API symbols to permit modular drivers
   iommu/of: Request ACS from the PCI core when configuring IOMMU linkage
   PCI: Export pci_ats_disabled() as a GPL symbol to modules
   Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"
   iommu/arm-smmu-v3: Allow building as a module
   Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"
   iommu/arm-smmu: Allow building as a module

  drivers/iommu/Kconfig | 16 ++-
  drivers/iommu/arm-smmu-impl.c |  6 +++
  drivers/iommu/arm-smmu-v3.c   | 26 +++
  drivers/iommu/arm-smmu.c  | 86 +--
  drivers/iommu/iommu-sysfs.c   |  5 ++
  drivers/iommu/iommu.c |  8 
  drivers/iommu/of_iommu.c  |  1 +
  drivers/pci/pci.c |  1 +
  8 files changed, 102 insertions(+), 47 deletions(-)


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

Re: [PATCH 7/7] iommu/arm-smmu: Allow building as a module

2019-10-30 Thread Robin Murphy 

On 30/10/2019 15:22, Rob Herring wrote:

On Wed, Oct 30, 2019 at 02:51:12PM +, Will Deacon wrote:

By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.

Signed-off-by: Will Deacon 
---
  drivers/iommu/Kconfig | 14 -
  drivers/iommu/arm-smmu-impl.c |  6 
  drivers/iommu/arm-smmu.c  | 54 +--
  3 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7583d47fc4d5..02703f51e533 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -350,7 +350,7 @@ config SPAPR_TCE_IOMMU
  
  # ARM IOMMU support

  config ARM_SMMU
-   bool "ARM Ltd. System MMU (SMMU) Support"
+   tristate "ARM Ltd. System MMU (SMMU) Support"
depends on (ARM64 || ARM) && MMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
@@ -362,6 +362,18 @@ config ARM_SMMU
  Say Y here if your SoC includes an IOMMU device implementing
  the ARM SMMU architecture.
  
+config ARM_SMMU_LEGACY_DT_BINDINGS

+   bool "Support the legacy \"mmu-masters\" devicetree bindings"


Can't we just remove this now? The only user is Seattle. Is anyone still
using Seattle AND DT? There's been no real dts change since Feb '16.
There's a bit of clean-up needed in the Seattle dts files, so I'd like
to remove them if there's not users.

If there are users, can't we just make them move to the new binding?
Yes compatibility, but that really depends on the users caring.


Apparently it's also in the wild on Cavium ThunderX/OcteonTX machines as 
well :(



I though Calxeda was using this too, but I guess we didn't get that
finished. We should probably remove that secure mode flag as well.


FWIW the secure quirk still comes in useful every now and then when 
people prototype stuff on 32-bit VExpress, where it turns out an SMMU is 
about the only thing which cares whether you're running Linux in Secure 
mode or not.


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

Re: [PATCH 7/7] iommu/arm-smmu: Allow building as a module

2019-10-30 Thread Will Deacon 
Hi Rob,

On Wed, Oct 30, 2019 at 10:22:12AM -0500, Rob Herring wrote:
> On Wed, Oct 30, 2019 at 02:51:12PM +, Will Deacon wrote:
> > By conditionally dropping support for the legacy binding and exporting
> > the newly introduced 'arm_smmu_impl_init()' function we can allow the
> > ARM SMMU driver to be built as a module.
> > 
> > Signed-off-by: Will Deacon 
> > ---
> >  drivers/iommu/Kconfig | 14 -
> >  drivers/iommu/arm-smmu-impl.c |  6 
> >  drivers/iommu/arm-smmu.c  | 54 +--
> >  3 files changed, 51 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> > index 7583d47fc4d5..02703f51e533 100644
> > --- a/drivers/iommu/Kconfig
> > +++ b/drivers/iommu/Kconfig
> > @@ -350,7 +350,7 @@ config SPAPR_TCE_IOMMU
> >  
> >  # ARM IOMMU support
> >  config ARM_SMMU
> > -   bool "ARM Ltd. System MMU (SMMU) Support"
> > +   tristate "ARM Ltd. System MMU (SMMU) Support"
> > depends on (ARM64 || ARM) && MMU
> > select IOMMU_API
> > select IOMMU_IO_PGTABLE_LPAE
> > @@ -362,6 +362,18 @@ config ARM_SMMU
> >   Say Y here if your SoC includes an IOMMU device implementing
> >   the ARM SMMU architecture.
> >  
> > +config ARM_SMMU_LEGACY_DT_BINDINGS
> > +   bool "Support the legacy \"mmu-masters\" devicetree bindings"
> 
> Can't we just remove this now? The only user is Seattle. Is anyone still 
> using Seattle AND DT? There's been no real dts change since Feb '16.
> There's a bit of clean-up needed in the Seattle dts files, so I'd like 
> to remove them if there's not users.
> 
> If there are users, can't we just make them move to the new binding? 
> Yes compatibility, but that really depends on the users caring.
> 
> I though Calxeda was using this too, but I guess we didn't get that 
> finished. We should probably remove that secure mode flag as well.

There was a recent mail from somebody using TX1 with this binding, although
it didn't actually appear to be working (but I'm not sure how much of that
is the bindings fault):

http://lists.infradead.org/pipermail/linux-arm-kernel/2019-October/683992.html

However, I agree with you, which is why the new Kconfig option actually
disables the legacy bindings by default in the hope that we can remove it
in a few releases time, with an easy "get things sorta working" option in
the meantime.

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

Re: [PATCH 7/7] iommu/arm-smmu: Allow building as a module

2019-10-30 Thread Rob Herring 
On Wed, Oct 30, 2019 at 02:51:12PM +, Will Deacon wrote:
> By conditionally dropping support for the legacy binding and exporting
> the newly introduced 'arm_smmu_impl_init()' function we can allow the
> ARM SMMU driver to be built as a module.
> 
> Signed-off-by: Will Deacon 
> ---
>  drivers/iommu/Kconfig | 14 -
>  drivers/iommu/arm-smmu-impl.c |  6 
>  drivers/iommu/arm-smmu.c  | 54 +--
>  3 files changed, 51 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
> index 7583d47fc4d5..02703f51e533 100644
> --- a/drivers/iommu/Kconfig
> +++ b/drivers/iommu/Kconfig
> @@ -350,7 +350,7 @@ config SPAPR_TCE_IOMMU
>  
>  # ARM IOMMU support
>  config ARM_SMMU
> - bool "ARM Ltd. System MMU (SMMU) Support"
> + tristate "ARM Ltd. System MMU (SMMU) Support"
>   depends on (ARM64 || ARM) && MMU
>   select IOMMU_API
>   select IOMMU_IO_PGTABLE_LPAE
> @@ -362,6 +362,18 @@ config ARM_SMMU
> Say Y here if your SoC includes an IOMMU device implementing
> the ARM SMMU architecture.
>  
> +config ARM_SMMU_LEGACY_DT_BINDINGS
> + bool "Support the legacy \"mmu-masters\" devicetree bindings"

Can't we just remove this now? The only user is Seattle. Is anyone still 
using Seattle AND DT? There's been no real dts change since Feb '16.
There's a bit of clean-up needed in the Seattle dts files, so I'd like 
to remove them if there's not users.

If there are users, can't we just make them move to the new binding? 
Yes compatibility, but that really depends on the users caring.

I though Calxeda was using this too, but I guess we didn't get that 
finished. We should probably remove that secure mode flag as well.

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

[PATCH 6/7] Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"

2019-10-30 Thread Will Deacon 
This reverts commit addb672f200f4e99368270da205320b83efe01a0.

Let's get the SMMU driver building as a module, which means putting
back some dead code that we used to carry.

Signed-off-by: Will Deacon 
---
 drivers/iommu/arm-smmu.c | 32 +++-
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 7c503a6bc585..53bbe0663b9e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -27,8 +27,7 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -59,10 +58,6 @@
 #define MSI_IOVA_LENGTH0x10
 
 static int force_stage;
-/*
- * not really modular, but the easiest way to keep compat with existing
- * bootargs behaviour is to continue using module_param() here.
- */
 module_param(force_stage, int, S_IRUGO);
 MODULE_PARM_DESC(force_stage,
"Force SMMU mappings to be installed at a particular stage of 
translation. A value of '1' or '2' forces the corresponding stage. All other 
values are ignored (i.e. no stage is forced). Note that selecting a specific 
stage will disable support for nested translation.");
@@ -1878,6 +1873,7 @@ static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
{ },
 };
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
 
 #ifdef CONFIG_ACPI
 static int acpi_smmu_get_data(u32 model, struct arm_smmu_device *smmu)
@@ -2165,12 +2161,12 @@ static int arm_smmu_legacy_bus_init(void)
 }
 device_initcall_sync(arm_smmu_legacy_bus_init);
 
-static void arm_smmu_device_shutdown(struct platform_device *pdev)
+static int arm_smmu_device_remove(struct platform_device *pdev)
 {
struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
 
if (!smmu)
-   return;
+   return -ENODEV;
 
if (!bitmap_empty(smmu->context_map, ARM_SMMU_MAX_CBS))
dev_err(&pdev->dev, "removing device with active domains!\n");
@@ -2186,6 +2182,12 @@ static void arm_smmu_device_shutdown(struct 
platform_device *pdev)
clk_bulk_disable(smmu->num_clks, smmu->clks);
 
clk_bulk_unprepare(smmu->num_clks, smmu->clks);
+   return 0;
+}
+
+static void arm_smmu_device_shutdown(struct platform_device *pdev)
+{
+   arm_smmu_device_remove(pdev);
 }
 
 static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
@@ -2235,12 +2237,16 @@ static const struct dev_pm_ops arm_smmu_pm_ops = {
 
 static struct platform_driver arm_smmu_driver = {
.driver = {
-   .name   = "arm-smmu",
-   .of_match_table = of_match_ptr(arm_smmu_of_match),
-   .pm = &arm_smmu_pm_ops,
-   .suppress_bind_attrs= true,
+   .name   = "arm-smmu",
+   .of_match_table = of_match_ptr(arm_smmu_of_match),
+   .pm = &arm_smmu_pm_ops,
},
.probe  = arm_smmu_device_probe,
+   .remove = arm_smmu_device_remove,
.shutdown = arm_smmu_device_shutdown,
 };
-builtin_platform_driver(arm_smmu_driver);
+module_platform_driver(arm_smmu_driver);
+
+MODULE_DESCRIPTION("IOMMU API for ARM architected SMMU implementations");
+MODULE_AUTHOR("Will Deacon ");
+MODULE_LICENSE("GPL v2");
-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 5/7] iommu/arm-smmu-v3: Allow building as a module

2019-10-30 Thread Will Deacon 
By removing the redundant call to 'pci_request_acs()' we can allow the
ARM SMMUv3 driver to be built as a module.

Signed-off-by: Will Deacon 
---
 drivers/iommu/Kconfig   | 2 +-
 drivers/iommu/arm-smmu-v3.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index e3842eabcfdd..7583d47fc4d5 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -388,7 +388,7 @@ config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
  config.
 
 config ARM_SMMU_V3
-   bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
+   tristate "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
depends on ARM64
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 2ad8e2ca0583..56ce4ba2fcbe 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -3657,7 +3657,6 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
 
 #ifdef CONFIG_PCI
if (pci_bus_type.iommu_ops != &arm_smmu_ops) {
-   pci_request_acs();
ret = bus_set_iommu(&pci_bus_type, &arm_smmu_ops);
if (ret)
return ret;
-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 7/7] iommu/arm-smmu: Allow building as a module

2019-10-30 Thread Will Deacon 
By conditionally dropping support for the legacy binding and exporting
the newly introduced 'arm_smmu_impl_init()' function we can allow the
ARM SMMU driver to be built as a module.

Signed-off-by: Will Deacon 
---
 drivers/iommu/Kconfig | 14 -
 drivers/iommu/arm-smmu-impl.c |  6 
 drivers/iommu/arm-smmu.c  | 54 +--
 3 files changed, 51 insertions(+), 23 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 7583d47fc4d5..02703f51e533 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -350,7 +350,7 @@ config SPAPR_TCE_IOMMU
 
 # ARM IOMMU support
 config ARM_SMMU
-   bool "ARM Ltd. System MMU (SMMU) Support"
+   tristate "ARM Ltd. System MMU (SMMU) Support"
depends on (ARM64 || ARM) && MMU
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
@@ -362,6 +362,18 @@ config ARM_SMMU
  Say Y here if your SoC includes an IOMMU device implementing
  the ARM SMMU architecture.
 
+config ARM_SMMU_LEGACY_DT_BINDINGS
+   bool "Support the legacy \"mmu-masters\" devicetree bindings"
+   depends on ARM_SMMU=y && OF
+   help
+ Support for the badly designed and deprecated \"mmu-masters\"
+ devicetree bindings. This allows some DMA masters to attach
+ to the SMMU but does not provide any support via the DMA API.
+ If you're lucky, you might be able to get VFIO up and running.
+
+ If you say Y here then you'll make me very sad. Instead, say N
+ and move your firmware to the utopian future that was 2016.
+
 config ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT
bool "Default to disabling bypass on ARM SMMU v1 and v2"
depends on ARM_SMMU
diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
index 5c87a38620c4..2f82d40317d6 100644
--- a/drivers/iommu/arm-smmu-impl.c
+++ b/drivers/iommu/arm-smmu-impl.c
@@ -5,6 +5,7 @@
 #define pr_fmt(fmt) "arm-smmu: " fmt
 
 #include 
+#include 
 #include 
 
 #include "arm-smmu.h"
@@ -172,3 +173,8 @@ struct arm_smmu_device *arm_smmu_impl_init(struct 
arm_smmu_device *smmu)
 
return smmu;
 }
+EXPORT_SYMBOL_GPL(arm_smmu_impl_init);
+
+MODULE_DESCRIPTION("IOMMU quirks for ARM architected SMMU implementations");
+MODULE_AUTHOR("Robin Murphy ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 53bbe0663b9e..9ef14830546d 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -125,6 +125,12 @@ static struct arm_smmu_domain *to_smmu_domain(struct 
iommu_domain *dom)
return container_of(dom, struct arm_smmu_domain, domain);
 }
 
+static struct platform_driver arm_smmu_driver;
+static struct iommu_ops arm_smmu_ops;
+
+#ifdef CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS
+static void arm_smmu_bus_init(void);
+
 static struct device_node *dev_get_dev_node(struct device *dev)
 {
if (dev_is_pci(dev)) {
@@ -160,9 +166,6 @@ static int __find_legacy_master_phandle(struct device *dev, 
void *data)
return err == -ENOENT ? 0 : err;
 }
 
-static struct platform_driver arm_smmu_driver;
-static struct iommu_ops arm_smmu_ops;
-
 static int arm_smmu_register_legacy_master(struct device *dev,
   struct arm_smmu_device **smmu)
 {
@@ -214,6 +217,27 @@ static int arm_smmu_register_legacy_master(struct device 
*dev,
return err;
 }
 
+/*
+ * With the legacy DT binding in play, we have no guarantees about
+ * probe order, but then we're also not doing default domains, so we can
+ * delay setting bus ops until we're sure every possible SMMU is ready,
+ * and that way ensure that no add_device() calls get missed.
+ */
+static int arm_smmu_legacy_bus_init(void)
+{
+   if (using_legacy_binding)
+   arm_smmu_bus_init();
+   return 0;
+}
+device_initcall_sync(arm_smmu_legacy_bus_init);
+#else
+static int arm_smmu_register_legacy_master(struct device *dev,
+  struct arm_smmu_device **smmu)
+{
+   return -ENODEV;
+}
+#endif /* CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS */
+
 static int __arm_smmu_alloc_bitmap(unsigned long *map, int start, int end)
 {
int idx;
@@ -1960,8 +1984,10 @@ static int arm_smmu_device_dt_probe(struct 
platform_device *pdev,
 
legacy_binding = of_find_property(dev->of_node, "mmu-masters", NULL);
if (legacy_binding && !using_generic_binding) {
-   if (!using_legacy_binding)
-   pr_notice("deprecated \"mmu-masters\" DT property in 
use; DMA API support unavailable\n");
+   if (!using_legacy_binding) {
+   pr_notice("deprecated \"mmu-masters\" DT property in 
use; %s support unavailable\n",
+ 
IS_ENABLED(CONFIG_ARM_SMMU_LEGACY_DT_BINDINGS) ? "DMA API" : "SMMU");
+   }
using_legacy_binding = true;
} else if (!legacy_binding && !using_legacy_binding) {

[PATCH 0/7] iommu: Permit modular builds of ARM SMMU[v3] drivers

2019-10-30 Thread Will Deacon 
Hi all,

As part of the work to enable a "Generic Kernel Image" across multiple
Android devices, there is a need to seperate shared, core kernel code
from modular driver code that may not be needed by all SoCs. This means
building IOMMU drivers as modules.

It turns out that most of the groundwork has already been done to enable
the ARM SMMU drivers to be 'tristate' options in drivers/iommu/Kconfig;
with a few symbols exported from the IOMMU/PCI core, everything builds
nicely out of the box. The one exception is support for the legacy SMMU
DT binding, which is not in widespread use and has never worked with
modules, so we can simply remove that when building as a module rather
than try to paper over it with even more hacks.

Obviously you need to be careful about using IOMMU drivers as modules,
since late loading of the driver for an IOMMU serving active DMA masters
is going to end badly in many cases. On Android, we're using device links
to ensure that the IOMMU probes first.

Comments welcome,

Will

Cc: Robin Murphy 
Cc: Joerg Roedel 
Cc: Bjorn Helgaas 
Cc: Lorenzo Pieralisi 

--->8

Will Deacon (7):
  drivers/iommu: Export core IOMMU API symbols to permit modular drivers
  iommu/of: Request ACS from the PCI core when configuring IOMMU linkage
  PCI: Export pci_ats_disabled() as a GPL symbol to modules
  Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"
  iommu/arm-smmu-v3: Allow building as a module
  Revert "iommu/arm-smmu: Make arm-smmu explicitly non-modular"
  iommu/arm-smmu: Allow building as a module

 drivers/iommu/Kconfig | 16 ++-
 drivers/iommu/arm-smmu-impl.c |  6 +++
 drivers/iommu/arm-smmu-v3.c   | 26 +++
 drivers/iommu/arm-smmu.c  | 86 +--
 drivers/iommu/iommu-sysfs.c   |  5 ++
 drivers/iommu/iommu.c |  8 
 drivers/iommu/of_iommu.c  |  1 +
 drivers/pci/pci.c |  1 +
 8 files changed, 102 insertions(+), 47 deletions(-)

-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 2/7] iommu/of: Request ACS from the PCI core when configuring IOMMU linkage

2019-10-30 Thread Will Deacon 
To avoid having to export 'pci_request_acs()' to modular IOMMU drivers,
move the call into the 'of_dma_configure()' path in a similar manner to
the way in which ACS is configured when probing via ACPI/IORT.

Signed-off-by: Will Deacon 
---
 drivers/iommu/of_iommu.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 614a93aa5305..78faa9f73a91 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -177,6 +177,7 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
.np = master_np,
};
 
+   pci_request_acs();
err = pci_for_each_dma_alias(to_pci_dev(dev),
 of_pci_iommu_init, &info);
} else if (dev_is_fsl_mc(dev)) {
-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 4/7] Revert "iommu/arm-smmu: Make arm-smmu-v3 explicitly non-modular"

2019-10-30 Thread Will Deacon 
This reverts commit c07b6426df922d21a13a959cf785d46e9c531941.

Let's get the SMMUv3 driver building as a module, which means putting
back some dead code that we used to carry.

Signed-off-by: Will Deacon 
---
 drivers/iommu/arm-smmu-v3.c | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 8da93e730d6f..2ad8e2ca0583 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -21,8 +21,7 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
 #include 
 #include 
 #include 
@@ -384,10 +383,6 @@
 #define MSI_IOVA_BASE  0x800
 #define MSI_IOVA_LENGTH0x10
 
-/*
- * not really modular, but the easiest way to keep compat with existing
- * bootargs behaviour is to continue using module_param_named here.
- */
 static bool disable_bypass = 1;
 module_param_named(disable_bypass, disable_bypass, bool, S_IRUGO);
 MODULE_PARM_DESC(disable_bypass,
@@ -3683,25 +3678,37 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
return 0;
 }
 
-static void arm_smmu_device_shutdown(struct platform_device *pdev)
+static int arm_smmu_device_remove(struct platform_device *pdev)
 {
struct arm_smmu_device *smmu = platform_get_drvdata(pdev);
 
arm_smmu_device_disable(smmu);
+
+   return 0;
+}
+
+static void arm_smmu_device_shutdown(struct platform_device *pdev)
+{
+   arm_smmu_device_remove(pdev);
 }
 
 static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v3", },
{ },
 };
+MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
 
 static struct platform_driver arm_smmu_driver = {
.driver = {
.name   = "arm-smmu-v3",
.of_match_table = of_match_ptr(arm_smmu_of_match),
-   .suppress_bind_attrs = true,
},
.probe  = arm_smmu_device_probe,
+   .remove = arm_smmu_device_remove,
.shutdown = arm_smmu_device_shutdown,
 };
-builtin_platform_driver(arm_smmu_driver);
+module_platform_driver(arm_smmu_driver);
+
+MODULE_DESCRIPTION("IOMMU API for ARM architected SMMUv3 implementations");
+MODULE_AUTHOR("Will Deacon ");
+MODULE_LICENSE("GPL v2");
-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 3/7] PCI: Export pci_ats_disabled() as a GPL symbol to modules

2019-10-30 Thread Will Deacon 
Building drivers for ATS-aware IOMMUs as modules requires access to
pci_ats_disabled(). Export it as a GPL symbol to get things working.

Signed-off-by: Will Deacon 
---
 drivers/pci/pci.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index a97e2571a527..4fbe5b576dd8 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -123,6 +123,7 @@ bool pci_ats_disabled(void)
 {
return pcie_ats_disabled;
 }
+EXPORT_SYMBOL_GPL(pci_ats_disabled);
 
 /* Disable bridge_d3 for all PCIe ports */
 static bool pci_bridge_d3_disable;
-- 
2.24.0.rc0.303.g954a862665-goog

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

[PATCH 1/7] drivers/iommu: Export core IOMMU API symbols to permit modular drivers

2019-10-30 Thread Will Deacon 
Building IOMMU drivers as modules requires that the core IOMMU API
symbols are exported as GPL symbols.

Signed-off-by: Will Deacon 
---
 drivers/iommu/iommu-sysfs.c | 5 +
 drivers/iommu/iommu.c   | 8 
 2 files changed, 13 insertions(+)

diff --git a/drivers/iommu/iommu-sysfs.c b/drivers/iommu/iommu-sysfs.c
index e436ff813e7e..99869217fbec 100644
--- a/drivers/iommu/iommu-sysfs.c
+++ b/drivers/iommu/iommu-sysfs.c
@@ -87,6 +87,7 @@ int iommu_device_sysfs_add(struct iommu_device *iommu,
put_device(iommu->dev);
return ret;
 }
+EXPORT_SYMBOL_GPL(iommu_device_sysfs_add);
 
 void iommu_device_sysfs_remove(struct iommu_device *iommu)
 {
@@ -94,6 +95,8 @@ void iommu_device_sysfs_remove(struct iommu_device *iommu)
device_unregister(iommu->dev);
iommu->dev = NULL;
 }
+EXPORT_SYMBOL_GPL(iommu_device_sysfs_remove);
+
 /*
  * IOMMU drivers can indicate a device is managed by a given IOMMU using
  * this interface.  A link to the device will be created in the "devices"
@@ -119,6 +122,7 @@ int iommu_device_link(struct iommu_device *iommu, struct 
device *link)
 
return ret;
 }
+EXPORT_SYMBOL_GPL(iommu_device_link);
 
 void iommu_device_unlink(struct iommu_device *iommu, struct device *link)
 {
@@ -128,3 +132,4 @@ void iommu_device_unlink(struct iommu_device *iommu, struct 
device *link)
sysfs_remove_link(&link->kobj, "iommu");
sysfs_remove_link_from_group(&iommu->dev->kobj, "devices", 
dev_name(link));
 }
+EXPORT_SYMBOL_GPL(iommu_device_unlink);
diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index d658c7c6a2ab..c1aadb570145 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -141,6 +141,7 @@ int iommu_device_register(struct iommu_device *iommu)
spin_unlock(&iommu_device_lock);
return 0;
 }
+EXPORT_SYMBOL_GPL(iommu_device_register);
 
 void iommu_device_unregister(struct iommu_device *iommu)
 {
@@ -148,6 +149,7 @@ void iommu_device_unregister(struct iommu_device *iommu)
list_del(&iommu->list);
spin_unlock(&iommu_device_lock);
 }
+EXPORT_SYMBOL_GPL(iommu_device_unregister);
 
 static struct iommu_param *iommu_get_dev_param(struct device *dev)
 {
@@ -886,6 +888,7 @@ struct iommu_group *iommu_group_ref_get(struct iommu_group 
*group)
kobject_get(group->devices_kobj);
return group;
 }
+EXPORT_SYMBOL_GPL(iommu_group_ref_get);
 
 /**
  * iommu_group_put - Decrement group reference
@@ -1259,6 +1262,7 @@ struct iommu_group *generic_device_group(struct device 
*dev)
 {
return iommu_group_alloc();
 }
+EXPORT_SYMBOL_GPL(generic_device_group);
 
 /*
  * Use standard PCI bus topology, isolation features, and DMA alias quirks
@@ -1326,6 +1330,7 @@ struct iommu_group *pci_device_group(struct device *dev)
/* No shared group found, allocate new */
return iommu_group_alloc();
 }
+EXPORT_SYMBOL_GPL(pci_device_group);
 
 /* Get the IOMMU group for device on fsl-mc bus */
 struct iommu_group *fsl_mc_device_group(struct device *dev)
@@ -1338,6 +1343,7 @@ struct iommu_group *fsl_mc_device_group(struct device 
*dev)
group = iommu_group_alloc();
return group;
 }
+EXPORT_SYMBOL_GPL(fsl_mc_device_group);
 
 /**
  * iommu_group_get_for_dev - Find or create the IOMMU group for a device
@@ -1406,6 +1412,7 @@ struct iommu_group *iommu_group_get_for_dev(struct device 
*dev)
 
return group;
 }
+EXPORT_SYMBOL(iommu_group_get_for_dev);
 
 struct iommu_domain *iommu_group_default_domain(struct iommu_group *group)
 {
@@ -2185,6 +2192,7 @@ struct iommu_resv_region 
*iommu_alloc_resv_region(phys_addr_t start,
region->type = type;
return region;
 }
+EXPORT_SYMBOL_GPL(iommu_alloc_resv_region);
 
 static int
 request_default_domain_for_dev(struct device *dev, unsigned long type)
-- 
2.24.0.rc0.303.g954a862665-goog

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

Re: [git pull] IOMMU Fixes for Linux v5.4-rc5

2019-10-30 Thread pr-tracker-bot 
The pull request you sent on Wed, 30 Oct 2019 14:02:57 +0100:

> git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
> tags/iommu-fixes-v5.4-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/32e72ec0613e164ce9608d865396fb2da278

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

[git pull] IOMMU Fixes for Linux v5.4-rc5

2019-10-30 Thread Joerg Roedel 
Hi Linus,

The following changes since commit d6d5df1db6e9d7f8f76d2911707f7d5877251b02:

  Linux 5.4-rc5 (2019-10-27 13:19:19 -0400)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git 
tags/iommu-fixes-v5.4-rc5

for you to fetch changes up to 160c63f909ffbc797c0bbe23310ac1eaf2349d2f:

  iommu/vt-d: Fix panic after kexec -p for kdump (2019-10-30 10:30:22 +0100)


IOMMU Fixes for Linux v5.4-rc5

Including:

- Follow-on fix for Renesas IPMMU to get rid of a redundant
  error message.

- Quirk for AMD IOMMU to make it work on another Acer Laptop
  model with a broken IVRS ACPI table.

- Fix for a panic at kdump in the Intel IOMMU driver.


John Donnelly (1):
  iommu/vt-d: Fix panic after kexec -p for kdump

Takashi Iwai (1):
  iommu/amd: Apply the same IVRS IOAPIC workaround to Acer Aspire A315-41

YueHaibing (1):
  iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure

 drivers/iommu/amd_iommu_quirks.c | 13 +
 drivers/iommu/intel-iommu.c  |  2 +-
 drivers/iommu/ipmmu-vmsa.c   |  4 +---
 3 files changed, 15 insertions(+), 4 deletions(-)

Please pull.

Thanks,

Joerg


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

Re: [BUG] dma-ranges, reserved memory regions, dma_alloc_coherent: possible bug?

2019-10-30 Thread Vladimir Murzin 
On 10/29/19 4:52 PM, Daniele Alessandrelli wrote:
> On Tue, Oct 29, 2019 at 9:43 AM Daniele Alessandrelli
>  wrote:
>>
>> On Mon, Oct 28, 2019 at 10:59 AM Vladimir Murzin
>>  wrote:
>>>
>>> @Daniele, it'd be handy to know if that fix issue for you...
>>>
>>
>> Apologies, I've been traveling for the last few days and haven't
>> managed to try it yet.
>>
>> I'll do it later today though and let you know.
> 
> Hi Vladimir,
> 
> I can confirm that your patch fixes the issue I was having. Thanks!

Great thanks!

Christoph, I've just sent it as a proper patch, please consider to apply.

Cheers
Vladimir

> 
> Regards,
> Daniele
> 

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

[PATCH] dma-mapping: fix handling of dma-ranges for reserved memory (again)

2019-10-30 Thread Vladimir Murzin 
Daniele reported that issue previously fixed in c41f9ea998f3
("drivers: dma-coherent: Account dma_pfn_offset when used with device
tree") reappear shortly after 43fc509c3efb ("dma-coherent: introduce
interface for default DMA pool") where fix was accidentally dropped.

Lets put fix back in place and respect dma-ranges for reserved memory.

Fixes: 43fc509c3efb ("dma-coherent: introduce interface for default DMA pool")

Reported-by: Daniele Alessandrelli 
Tested-by: Daniele Alessandrelli 
Tested-by: Alexandre Torgue 
Signed-off-by: Vladimir Murzin 
---
 arch/arm/mm/dma-mapping-nommu.c |  2 +-
 include/linux/dma-mapping.h |  4 ++--
 kernel/dma/coherent.c   | 16 +---
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mm/dma-mapping-nommu.c b/arch/arm/mm/dma-mapping-nommu.c
index db92478..287ef89 100644
--- a/arch/arm/mm/dma-mapping-nommu.c
+++ b/arch/arm/mm/dma-mapping-nommu.c
@@ -35,7 +35,7 @@ static void *arm_nommu_dma_alloc(struct device *dev, size_t 
size,
 unsigned long attrs)
 
 {
-   void *ret = dma_alloc_from_global_coherent(size, dma_handle);
+   void *ret = dma_alloc_from_global_coherent(dev, size, dma_handle);
 
/*
 * dma_alloc_from_global_coherent() may fail because:
diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
index 4a1c4fc..10918c5 100644
--- a/include/linux/dma-mapping.h
+++ b/include/linux/dma-mapping.h
@@ -162,7 +162,7 @@ int dma_release_from_dev_coherent(struct device *dev, int 
order, void *vaddr);
 int dma_mmap_from_dev_coherent(struct device *dev, struct vm_area_struct *vma,
void *cpu_addr, size_t size, int *ret);
 
-void *dma_alloc_from_global_coherent(ssize_t size, dma_addr_t *dma_handle);
+void *dma_alloc_from_global_coherent(struct device *dev, ssize_t size, 
dma_addr_t *dma_handle);
 int dma_release_from_global_coherent(int order, void *vaddr);
 int dma_mmap_from_global_coherent(struct vm_area_struct *vma, void *cpu_addr,
  size_t size, int *ret);
@@ -172,7 +172,7 @@ int dma_mmap_from_global_coherent(struct vm_area_struct 
*vma, void *cpu_addr,
 #define dma_release_from_dev_coherent(dev, order, vaddr) (0)
 #define dma_mmap_from_dev_coherent(dev, vma, vaddr, order, ret) (0)
 
-static inline void *dma_alloc_from_global_coherent(ssize_t size,
+static inline void *dma_alloc_from_global_coherent(struct device *dev, ssize_t 
size,
   dma_addr_t *dma_handle)
 {
return NULL;
diff --git a/kernel/dma/coherent.c b/kernel/dma/coherent.c
index 545e386..551b0eb 100644
--- a/kernel/dma/coherent.c
+++ b/kernel/dma/coherent.c
@@ -123,8 +123,9 @@ int dma_declare_coherent_memory(struct device *dev, 
phys_addr_t phys_addr,
return ret;
 }
 
-static void *__dma_alloc_from_coherent(struct dma_coherent_mem *mem,
-   ssize_t size, dma_addr_t *dma_handle)
+static void *__dma_alloc_from_coherent(struct device *dev,
+  struct dma_coherent_mem *mem,
+  ssize_t size, dma_addr_t *dma_handle)
 {
int order = get_order(size);
unsigned long flags;
@@ -143,7 +144,7 @@ static void *__dma_alloc_from_coherent(struct 
dma_coherent_mem *mem,
/*
 * Memory was found in the coherent area.
 */
-   *dma_handle = mem->device_base + (pageno << PAGE_SHIFT);
+   *dma_handle = dma_get_device_base(dev, mem) + (pageno << PAGE_SHIFT);
ret = mem->virt_base + (pageno << PAGE_SHIFT);
spin_unlock_irqrestore(&mem->spinlock, flags);
memset(ret, 0, size);
@@ -175,17 +176,18 @@ int dma_alloc_from_dev_coherent(struct device *dev, 
ssize_t size,
if (!mem)
return 0;
 
-   *ret = __dma_alloc_from_coherent(mem, size, dma_handle);
+   *ret = __dma_alloc_from_coherent(dev, mem, size, dma_handle);
return 1;
 }
 
-void *dma_alloc_from_global_coherent(ssize_t size, dma_addr_t *dma_handle)
+void *dma_alloc_from_global_coherent(struct device *dev, ssize_t size,
+dma_addr_t *dma_handle)
 {
if (!dma_coherent_default_memory)
return NULL;
 
-   return __dma_alloc_from_coherent(dma_coherent_default_memory, size,
-   dma_handle);
+   return __dma_alloc_from_coherent(dev, dma_coherent_default_memory, size,
+dma_handle);
 }
 
 static int __dma_release_from_coherent(struct dma_coherent_mem *mem,
-- 
2.7.4

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

Re: [PATCH v2 1/3] dma-mapping: introduce new dma unmap and sync api variants

2019-10-30 Thread kbuild test robot 
Hi Laurentiu,

I love your patch! Yet something to improve:

[auto build test ERROR on net-next/master]
[also build test ERROR on v5.4-rc5 next-20191029]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]

url:
https://github.com/0day-ci/linux/commits/Laurentiu-Tudor/dma-mapping-introduce-new-dma-unmap-and-sync-variants/20191027-173418
base:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
503a64635d5ef7351657c78ad77f8b5ff658d5fc
config: um-x86_64_defconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um SUBARCH=x86_64

If you fix the issue, kindly add following tag
Reported-by: kbuild test robot 

All errors (new ones prefixed by >>):

   In file included from include/linux/skbuff.h:31:0,
from include/net/net_namespace.h:38,
from include/linux/inet.h:42,
from include/linux/sunrpc/msg_prot.h:204,
from include/linux/sunrpc/auth.h:16,
from include/linux/nfs_fs.h:31,
from init/do_mounts.c:23:
   include/linux/dma-mapping.h: In function 'dma_sync_single_for_cpu_desc':
   include/linux/dma-mapping.h:539:1: warning: no return statement in function 
returning non-void [-Wreturn-type]
}
^
   include/linux/dma-mapping.h: In function 'dma_unmap_single_attrs_desc':
>> include/linux/dma-mapping.h:638:34: error: implicit declaration of function 
>> 'get_dma_ops'; did you mean 'get_mm_rss'? 
>> [-Werror=implicit-function-declaration]
 const struct dma_map_ops *ops = get_dma_ops(dev);
 ^~~
 get_mm_rss
   include/linux/dma-mapping.h:638:34: warning: initialization makes pointer 
from integer without a cast [-Wint-conversion]
   cc1: some warnings being treated as errors

vim +638 include/linux/dma-mapping.h

   534  
   535  static inline void *
   536  dma_sync_single_for_cpu_desc(struct device *dev, dma_addr_t addr, 
size_t size,
   537   enum dma_data_direction dir)
   538  {
 > 539  }
   540  static inline void dma_sync_single_for_device(struct device *dev,
   541  dma_addr_t addr, size_t size, enum dma_data_direction 
dir)
   542  {
   543  }
   544  static inline void dma_sync_sg_for_cpu(struct device *dev,
   545  struct scatterlist *sg, int nelems, enum 
dma_data_direction dir)
   546  {
   547  }
   548  static inline void dma_sync_sg_for_device(struct device *dev,
   549  struct scatterlist *sg, int nelems, enum 
dma_data_direction dir)
   550  {
   551  }
   552  static inline int dma_mapping_error(struct device *dev, dma_addr_t 
dma_addr)
   553  {
   554  return -ENOMEM;
   555  }
   556  static inline void *dma_alloc_attrs(struct device *dev, size_t size,
   557  dma_addr_t *dma_handle, gfp_t flag, unsigned long attrs)
   558  {
   559  return NULL;
   560  }
   561  static void dma_free_attrs(struct device *dev, size_t size, void 
*cpu_addr,
   562  dma_addr_t dma_handle, unsigned long attrs)
   563  {
   564  }
   565  static inline void *dmam_alloc_attrs(struct device *dev, size_t size,
   566  dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
   567  {
   568  return NULL;
   569  }
   570  static inline void dmam_free_coherent(struct device *dev, size_t size,
   571  void *vaddr, dma_addr_t dma_handle)
   572  {
   573  }
   574  static inline void dma_cache_sync(struct device *dev, void *vaddr, 
size_t size,
   575  enum dma_data_direction dir)
   576  {
   577  }
   578  static inline int dma_get_sgtable_attrs(struct device *dev,
   579  struct sg_table *sgt, void *cpu_addr, dma_addr_t 
dma_addr,
   580  size_t size, unsigned long attrs)
   581  {
   582  return -ENXIO;
   583  }
   584  static inline int dma_mmap_attrs(struct device *dev, struct 
vm_area_struct *vma,
   585  void *cpu_addr, dma_addr_t dma_addr, size_t size,
   586  unsigned long attrs)
   587  {
   588  return -ENXIO;
   589  }
   590  static inline bool dma_can_mmap(struct device *dev)
   591  {
   592  return false;
   593  }
   594  static inline int dma_supported(struct device *dev, u64 mask)
   595  {
   596  return 0;
   597  }
   598  static inline int dma_set_mask(struct device *dev, u64 mask)
   599  {
   600  return -EIO;
   601  }
   602  static inline int dma_set_coherent_mask(struct device *dev, u64 mask)
   603  {
   604  return -EIO;
   605  }
   606  static inline u64 dma_get_required_mask(struct device *dev)

Re: [PATCH] iommu/virtio: Remove unused variable

2019-10-30 Thread Joerg Roedel 
On Fri, Oct 25, 2019 at 01:13:40PM -0300, Cristiane Naves wrote:
> Remove the variable of return. Issue found by
> coccicheck(scripts/coccinelle/misc/returnvar.cocci)
> 
> Signed-off-by: Cristiane Naves 
> ---
>  drivers/iommu/virtio-iommu.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

Applied for v5.5, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [PATCH v2 0/2] AMD IOMMU Changes for NTB

2019-10-30 Thread Joerg Roedel 
On Tue, Oct 22, 2019 at 04:01:19PM -0600, Logan Gunthorpe wrote:
> Logan Gunthorpe (2):
>   iommu/amd: Support multiple PCI DMA aliases in device table
>   iommu/amd: Support multiple PCI DMA aliases in IRQ Remapping
> 
>  drivers/iommu/amd_iommu.c   | 170 +---
>  drivers/iommu/amd_iommu_types.h |   2 +-
>  2 files changed, 92 insertions(+), 80 deletions(-)

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

Re: [PATCH] iommu/amd: Apply the same IVRS IOAPIC workaround to Acer Aspire A315-41

2019-10-30 Thread Joerg Roedel 
On Mon, Oct 21, 2019 at 05:17:21PM +0200, Takashi Iwai wrote:
> Acer Aspire A315-41 requires the very same workaround as the existing
> quirk for Dell Latitude 5495.  Add the new entry for that.
> 
> BugLink: https://bugzilla.suse.com/show_bug.cgi?id=1137799
> Signed-off-by: Takashi Iwai 
> ---
>  drivers/iommu/amd_iommu_quirks.c | 13 +
>  1 file changed, 13 insertions(+)

Applied for v5.4, thanks Takashi.

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

Re: [PATCH v4 1/2] dma-mapping: Add vmap checks to dma_map_single()

2019-10-30 Thread Greg Kroah-Hartman 
On Tue, Oct 29, 2019 at 02:34:22PM -0700, Kees Cook wrote:
> As we've seen from USB and other areas[1], we need to always do runtime
> checks for DMA operating on memory regions that might be remapped. This
> adds vmap checks (similar to those already in USB but missing in other
> places) into dma_map_single() so all callers benefit from the checking.
> 
> [1] https://git.kernel.org/linus/3840c5b78803b2b6cc1ff820100a74a092c40cbb
> 
> Suggested-by: Laura Abbott 
> Signed-off-by: Kees Cook 
> ---
>  include/linux/dma-mapping.h | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/include/linux/dma-mapping.h b/include/linux/dma-mapping.h
> index 4a1c4fca475a..54de3c496407 100644
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -583,6 +583,12 @@ static inline unsigned long 
> dma_get_merge_boundary(struct device *dev)
>  static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
>   size_t size, enum dma_data_direction dir, unsigned long attrs)
>  {
> + /* DMA must never operate on areas that might be remapped. */
> + if (dev_WARN_ONCE(dev, is_vmalloc_addr(ptr),
> +   "wanted %zu bytes mapped in vmalloc\n", size)) {
> + return DMA_MAPPING_ERROR;
> + }

That's a very odd error string, I know if I saw it for the first time, I
would have no idea what it meant.  The USB message at least gives you a
bit more context as to what went wrong and how to fix it.

How about something like "Memory is not DMA capabable, please fix the
allocation of it to be correct", or "non-dma-able memory was attempted
to be mapped, but this is impossible to to" or something else.

thanks,

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

Re: [PATCH -next] iommu/ipmmu-vmsa: Remove dev_err() on platform_get_irq() failure

2019-10-30 Thread Joerg Roedel 
On Wed, Oct 23, 2019 at 09:59:41PM +0800, YueHaibing wrote:
> platform_get_irq() will call dev_err() itself on failure,
> so there is no need for the driver to also do this.
> This is detected by coccinelle.
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/iommu/ipmmu-vmsa.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

Applied for v5.4, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu