Re: [PATCH] iommu/vt-d: Avoid write-tearing on PTE clear

2016-06-03 Thread Nadav Amit
Ping?

Nadav Amit  wrote:

> When a PTE is cleared, the write may be teared or perform by multiple
> writes. In addition, in 32-bit kernel, writes are currently performed
> using a single 64-bit write, which does not guarantee order.
> 
> The byte-code right now does not seem to cause a problem, but it may
> still occur in theory.
> 
> Avoid this scenario by using WRITE_ONCE, and order the writes on
> 32-bit kernels.
> 
> Signed-off-by: Nadav Amit 
> ---
> drivers/iommu/intel-iommu.c | 19 ++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
> index e1852e8..4f488a5 100644
> --- a/drivers/iommu/intel-iommu.c
> +++ b/drivers/iommu/intel-iommu.c
> @@ -326,9 +326,26 @@ struct dma_pte {
>   u64 val;
> };
> 
> +#ifndef CONFIG_64BIT
> +union split_dma_pte {
> + struct {
> + u32 val_low;
> + u32 val_high;
> + };
> + u64 val;
> +};
> +#endif
> +
> static inline void dma_clear_pte(struct dma_pte *pte)
> {
> - pte->val = 0;
> +#ifdef CONFIG_64BIT
> + WRITE_ONCE(pte->val, 0);
> +#else
> + union split_dma_pte *sdma_pte = (union split_dma_pte *)pte;
> +
> + WRITE_ONCE(sdma_pte->val_low, 0);
> + sdma_pte->val_high = 0;
> +#endif
> }
> 
> static inline u64 dma_pte_addr(struct dma_pte *pte)
> -- 
> 2.7.4


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


[PATCH v2 6/7] iommu/arm-smmu: Finish off SMMUv3 default domain support

2016-06-03 Thread Robin Murphy
The driver's current reliance on attaching/detaching an entire group
for the first device it sees is at odds with the IOMMU core's initial
construction of a group by adding each device and attaching it to the
default domain in turn. As it turns out, we can happily do away with the
whole palaver by simply letting each device be in charge of its own
stream ID/stream table entry, and reducing the problem of tracking
duplicate IDs and domains down to "Is the STE already associated with
the appropriate context?", which is easily done by just looking at the
stream table itself.

With an of_xlate() callback in place, devices attached to default
domains will now get appropriate DMA ops installed, so make sure we
enable translation again to stop them getting horribly confused - this
reverts the SMMUv3 portion of cbf8277ef456 ("iommu/arm-smmu: Treat
IOMMU_DOMAIN_DMA as bypass for now")

Signed-off-by: Robin Murphy 
---

v2: New.

 drivers/iommu/arm-smmu-v3.c | 183 +---
 1 file changed, 38 insertions(+), 145 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 7631639cc209..28dcc5ca237e 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -607,15 +607,6 @@ struct arm_smmu_device {
struct arm_smmu_strtab_cfg  strtab_cfg;
 };
 
-/* SMMU private data for an IOMMU group */
-struct arm_smmu_group {
-   struct arm_smmu_device  *smmu;
-   struct arm_smmu_domain  *domain;
-   int num_sids;
-   u32 *sids;
-   struct arm_smmu_strtab_ent  ste;
-};
-
 /* SMMU private data for an IOMMU domain */
 enum arm_smmu_domain_stage {
ARM_SMMU_DOMAIN_S1 = 0,
@@ -642,6 +633,8 @@ struct arm_smmu_domain {
 /* SMMU private data for each master */
 struct arm_smmu_master_data {
struct arm_smmu_device  *smmu;
+
+   struct arm_smmu_strtab_ent  ste;
u32 sid;
 };
 
@@ -1020,9 +1013,15 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
 * 1. Update Config, return (init time STEs aren't live)
 * 2. Write everything apart from dword 0, sync, write dword 0, sync
 * 3. Update Config, sync
+*
+* Note that with the departure of the explicit detach callback from
+* the API, we may be doing 3 & 2 back-to-back in the same call.
 */
u64 val = le64_to_cpu(dst[0]);
bool ste_live = false;
+   bool ste_ok = false;
+   dma_addr_t s1ctxptr = ste->s1_cfg ? ste->s1_cfg->cdptr_dma : 0;
+   u16 vmid = ste->s2_cfg ? ste->s2_cfg->vmid : 0;
struct arm_smmu_cmdq_ent prefetch_cmd = {
.opcode = CMDQ_OP_PREFETCH_CFG,
.prefetch   = {
@@ -1035,17 +1034,27 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
 
cfg = val & STRTAB_STE_0_CFG_MASK << STRTAB_STE_0_CFG_SHIFT;
switch (cfg) {
+   case STRTAB_STE_0_CFG_ABORT:
case STRTAB_STE_0_CFG_BYPASS:
+   ste_ok = ste->bypass;
break;
case STRTAB_STE_0_CFG_S1_TRANS:
case STRTAB_STE_0_CFG_S2_TRANS:
ste_live = true;
+   ste_ok = ((val & STRTAB_STE_0_S1CTXPTR_MASK <<
+  STRTAB_STE_0_S1CTXPTR_SHIFT) == s1ctxptr) &&
+((le64_to_cpu(dst[2]) &
+ STRTAB_STE_2_S2VMID_MASK) == vmid);
break;
default:
BUG(); /* STE corruption */
}
}
 
+   /* No point rewriting things to the exact same state... */
+   if (ste_ok)
+   return;
+
/* Nuke the existing Config, as we're going to rewrite it */
val &= ~(STRTAB_STE_0_CFG_MASK << STRTAB_STE_0_CFG_SHIFT);
 
@@ -1054,7 +1063,7 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
else
val &= ~STRTAB_STE_0_V;
 
-   if (ste->bypass) {
+   if (ste_live || ste->bypass) {
val |= disable_bypass ? STRTAB_STE_0_CFG_ABORT
  : STRTAB_STE_0_CFG_BYPASS;
dst[0] = cpu_to_le64(val);
@@ -1063,11 +1072,11 @@ static void arm_smmu_write_strtab_ent(struct 
arm_smmu_device *smmu, u32 sid,
dst[2] = 0; /* Nuke the VMID */
if (ste_live)
arm_smmu_sync_ste_for_sid(smmu, sid);
-   return;
+   if (ste->bypass)
+   return;
}
 
if (ste->s1_cfg) {
-   BUG_ON(ste_live);
dst[1] = cpu_to_le64(
 STRTAB_STE_1_S1C_CACHE_WBRA
 << STRTAB_STE_1_S1CIR_SHIFT |

[PATCH v2 7/7] iommu/arm-smmu: Support non-PCI devices with SMMUv3

2016-06-03 Thread Robin Murphy
With the device <-> stream ID relationship suitably abstracted and
of_xlate() hooked up, we no longer have any PCI-specifics in play,
so adding support for the simpler kinds of platform device (a single
unique stream ID each) becomes trivial; let's do it!

Signed-off-by: Robin Murphy 
---

v2: New. Consider this one "extra bonus material" as I'm not sure there
are even any suitable devices on our model to test it with (it
_should_ be OK, given that I know the basic infrastructure on either
side works...)

 drivers/iommu/Kconfig   |  2 +-
 drivers/iommu/arm-smmu-v3.c | 36 ++--
 2 files changed, 31 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index ad0860383cb3..d1c66afefeed 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -308,7 +308,7 @@ config ARM_SMMU
 
 config ARM_SMMU_V3
bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
-   depends on ARM64 && PCI
+   depends on ARM64
select IOMMU_API
select IOMMU_IO_PGTABLE_LPAE
select GENERIC_MSI_IRQ_DOMAIN
diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 28dcc5ca237e..6379f0ab24fc 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -35,6 +35,8 @@
 #include 
 #include 
 
+#include 
+
 #include "io-pgtable.h"
 
 /* MMIO registers */
@@ -1773,6 +1775,22 @@ static void arm_smmu_remove_device(struct device *dev)
iommu_group_remove_device(dev);
 }
 
+static struct iommu_group *arm_smmu_device_group(struct device *dev)
+{
+   struct iommu_group *group;
+
+   /*
+* We've currently no means of grouping non-PCI masters, so
+* there'd better not be any non-unique stream IDs in the DT...
+*/
+   if (dev_is_pci(dev))
+   group = pci_device_group(dev);
+   else
+   group = generic_device_group(dev);
+
+   return group;
+}
+
 static int arm_smmu_domain_get_attr(struct iommu_domain *domain,
enum iommu_attr attr, void *data)
 {
@@ -1821,10 +1839,6 @@ static int arm_smmu_of_xlate(struct device *dev, struct 
of_phandle_args *args)
 {
struct arm_smmu_master_data *data;
 
-   /* We only support PCI, for now */
-   if (!dev_is_pci(dev))
-   return -ENODEV;
-
if (dev->archdata.iommu)
return -EEXIST;
 
@@ -1855,7 +1869,7 @@ static struct iommu_ops arm_smmu_ops = {
.iova_to_phys   = arm_smmu_iova_to_phys,
.add_device = arm_smmu_add_device,
.remove_device  = arm_smmu_remove_device,
-   .device_group   = pci_device_group,
+   .device_group   = arm_smmu_device_group,
.domain_get_attr= arm_smmu_domain_get_attr,
.domain_set_attr= arm_smmu_domain_set_attr,
.of_xlate   = arm_smmu_of_xlate,
@@ -2598,7 +2612,17 @@ static int __init arm_smmu_init(void)
if (ret)
return ret;
 
-   return bus_set_iommu(_bus_type, _smmu_ops);
+#ifdef CONFIG_PCI
+   ret = bus_set_iommu(_bus_type, _smmu_ops);
+   if (ret)
+   return ret;
+#endif
+#ifdef CONFIG_ARM_AMBA
+   ret = bus_set_iommu(_bustype, _smmu_ops);
+   if (ret)
+   return ret;
+#endif
+   return bus_set_iommu(_bus_type, _smmu_ops);
 }
 
 static void __exit arm_smmu_exit(void)
-- 
2.8.1.dirty

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


[PATCH v2 5/7] iommu/arm-smmu: Implement of_xlate() for SMMUv3

2016-06-03 Thread Robin Murphy
Now that we can properly describe the mapping between PCI RIDs and
stream IDs via "iommu-map", and have it fed it to the driver
automatically via of_xlate(), rework the SMMUv3 driver to benefit from
that. Initially, this just gets rid of the misuse of the "iommus"
binding without changing the driver's existing level of functionality,
but does at least pave the way to extending it more easily in future.

Signed-off-by: Robin Murphy 
---

v2: New.

 drivers/iommu/arm-smmu-v3.c | 119 +++-
 1 file changed, 73 insertions(+), 46 deletions(-)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 94b68213c50d..7631639cc209 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -638,6 +639,12 @@ struct arm_smmu_domain {
struct iommu_domain domain;
 };
 
+/* SMMU private data for each master */
+struct arm_smmu_master_data {
+   struct arm_smmu_device  *smmu;
+   u32 sid;
+};
+
 struct arm_smmu_option_prop {
u32 opt;
const char *prop;
@@ -1754,40 +1761,19 @@ arm_smmu_iova_to_phys(struct iommu_domain *domain, 
dma_addr_t iova)
return ret;
 }
 
-static int __arm_smmu_get_pci_sid(struct pci_dev *pdev, u16 alias, void *sidp)
-{
-   *(u32 *)sidp = alias;
-   return 0; /* Continue walking */
-}
-
 static void __arm_smmu_release_pci_iommudata(void *data)
 {
kfree(data);
 }
 
-static struct arm_smmu_device *arm_smmu_get_for_pci_dev(struct pci_dev *pdev)
+static struct arm_smmu_device *arm_smmu_get_by_node(struct device_node *np)
 {
-   struct device_node *of_node;
-   struct platform_device *smmu_pdev;
-   struct arm_smmu_device *smmu = NULL;
-   struct pci_bus *bus = pdev->bus;
+   struct platform_device *smmu_pdev = of_find_device_by_node(np);
 
-   /* Walk up to the root bus */
-   while (!pci_is_root_bus(bus))
-   bus = bus->parent;
-
-   /* Follow the "iommus" phandle from the host controller */
-   of_node = of_parse_phandle(bus->bridge->parent->of_node, "iommus", 0);
-   if (!of_node)
+   if (!smmu_pdev)
return NULL;
 
-   /* See if we can find an SMMU corresponding to the phandle */
-   smmu_pdev = of_find_device_by_node(of_node);
-   if (smmu_pdev)
-   smmu = platform_get_drvdata(smmu_pdev);
-
-   of_node_put(of_node);
-   return smmu;
+   return platform_get_drvdata(smmu_pdev);
 }
 
 static bool arm_smmu_sid_in_range(struct arm_smmu_device *smmu, u32 sid)
@@ -1804,23 +1790,41 @@ static int arm_smmu_add_device(struct device *dev)
 {
int i, ret;
u32 sid, *sids;
-   struct pci_dev *pdev;
struct iommu_group *group;
+   struct device_node *np;
struct arm_smmu_group *smmu_group;
-   struct arm_smmu_device *smmu;
+   struct arm_smmu_device *smmu = NULL;
+   struct arm_smmu_master_data *data = dev->archdata.iommu;
 
-   /* We only support PCI, for now */
-   if (!dev_is_pci(dev))
+   if (!data)
return -ENODEV;
 
-   pdev = to_pci_dev(dev);
+   np = (struct device_node *)data->smmu;
+   smmu = data->smmu = arm_smmu_get_by_node(np);
+   of_node_put(np);
+   if (!smmu)
+   return -ENODEV;
+
+   sid = data->sid;
+
+   /* Check the SID is in range of the SMMU and our stream table */
+   if (!arm_smmu_sid_in_range(smmu, sid))
+   return -ERANGE;
+
+   /* Ensure l2 strtab is initialised */
+   if (smmu->features & ARM_SMMU_FEAT_2_LVL_STRTAB) {
+   ret = arm_smmu_init_l2_strtab(smmu, sid);
+   if (ret)
+   return ret;
+   }
+
group = iommu_group_get_for_dev(dev);
if (IS_ERR(group))
return PTR_ERR(group);
 
smmu_group = iommu_group_get_iommudata(group);
if (!smmu_group) {
-   smmu = arm_smmu_get_for_pci_dev(pdev);
+   smmu = arm_smmu_get_by_node(np);
if (!smmu) {
ret = -ENOENT;
goto out_remove_dev;
@@ -1840,27 +1844,12 @@ static int arm_smmu_add_device(struct device *dev)
smmu = smmu_group->smmu;
}
 
-   /* Assume SID == RID until firmware tells us otherwise */
-   pci_for_each_dma_alias(pdev, __arm_smmu_get_pci_sid, );
for (i = 0; i < smmu_group->num_sids; ++i) {
/* If we already know about this SID, then we're done */
if (smmu_group->sids[i] == sid)
goto out_put_group;
}
 
-   /* Check the SID is in range of the SMMU and our stream table */
-   if (!arm_smmu_sid_in_range(smmu, sid)) {
-   ret = -ERANGE;
-   goto out_remove_dev;
-   }
-
-   /* Ensure l2 

[PATCH v2 4/7] iommu/of: Handle iommu-map property for PCI

2016-06-03 Thread Robin Murphy
Now that we have a way to pick up the RID translation and target IOMMU,
hook up of_iommu_configure() to bring PCI devices into the of_xlate
mechanism and allow them IOMMU-backed DMA ops without the need for
driver-specific handling.

CC: Rob Herring 
CC: Frank Rowand 
Signed-off-by: Robin Murphy 
---

v2: Skip disabled IOMMUs.

 drivers/iommu/of_iommu.c | 44 +---
 1 file changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 662f9a600f4f..5716131199b3 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static const struct of_device_id __iommu_of_table_sentinel
@@ -134,20 +135,49 @@ const struct iommu_ops *of_iommu_get_ops(struct 
device_node *np)
return ops;
 }
 
+static int __get_pci_rid(struct pci_dev *pdev, u16 alias, void *data)
+{
+   struct of_phandle_args *iommu_spec = data;
+
+   iommu_spec->args[0] = alias;
+   return iommu_spec->np == pdev->bus->dev.of_node;
+}
+
 const struct iommu_ops *of_iommu_configure(struct device *dev,
   struct device_node *master_np)
 {
struct of_phandle_args iommu_spec;
-   struct device_node *np;
+   struct device_node *np = NULL;
const struct iommu_ops *ops = NULL;
int idx;
 
-   /*
-* We can't do much for PCI devices without knowing how
-* device IDs are wired up from the PCI bus to the IOMMU.
-*/
-   if (dev_is_pci(dev))
-   return NULL;
+   if (dev_is_pci(dev)) {
+   /*
+* Start by tracing the RID alias down the PCI topology as
+* far as the host bridge whose OF node we have...
+*/
+   iommu_spec.np = master_np;
+   pci_for_each_dma_alias(to_pci_dev(dev), __get_pci_rid,
+  _spec);
+   /*
+* ...then find out what that becomes once it escapes the PCI
+* bus into the system beyond, and which IOMMU it ends up at.
+*/
+   if (of_pci_map_rid(master_np, "iommu-map", iommu_spec.args[0],
+  , iommu_spec.args) ||
+   !of_device_is_available(np))
+   return NULL;
+
+   /* We're not attempting to handle multi-alias devices yet */
+   iommu_spec.np = np;
+   iommu_spec.args_count = 1;
+   ops = of_iommu_get_ops(np);
+   if (!ops || !ops->of_xlate || ops->of_xlate(dev, _spec))
+   ops = NULL;
+
+   of_node_put(np);
+   return ops;
+   }
 
/*
 * We don't currently walk up the tree looking for a parent IOMMU.
-- 
2.8.1.dirty

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


[PATCH v2 3/7] of/irq: Break out msi-map lookup (again)

2016-06-03 Thread Robin Murphy
The PCI msi-map code is already doing double-duty translating IDs and
retrieving MSI parents, which unsurprisingly is the same functionality
we need for the identically-formatted PCI iommu-map property. Drag the
core parsing routine up yet another layer into the general OF-PCI code,
and further generalise it for either kind of lookup in either flavour
of map property.

CC: Rob Herring 
CC: Frank Rowand 
CC: Marc Zyngier 
Signed-off-by: Robin Murphy 
---

v2: No change.

 drivers/of/irq.c   |  70 ++---
 drivers/of/of_pci.c| 102 +
 include/linux/of_pci.h |   8 
 3 files changed, 114 insertions(+), 66 deletions(-)

diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index e7bfc175b8e1..0c9118d849ee 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -586,13 +587,7 @@ static u32 __of_msi_map_rid(struct device *dev, struct 
device_node **np,
u32 rid_in)
 {
struct device *parent_dev;
-   struct device_node *msi_controller_node;
-   struct device_node *msi_np = *np;
-   u32 map_mask, masked_rid, rid_base, msi_base, rid_len, phandle;
-   int msi_map_len;
-   bool matched;
u32 rid_out = rid_in;
-   const __be32 *msi_map = NULL;
 
/*
 * Walk up the device parent links looking for one with a
@@ -602,71 +597,14 @@ static u32 __of_msi_map_rid(struct device *dev, struct 
device_node **np,
if (!parent_dev->of_node)
continue;
 
-   msi_map = of_get_property(parent_dev->of_node,
- "msi-map", _map_len);
-   if (!msi_map)
+   if (!of_property_read_bool(parent_dev->of_node, "msi-map"))
continue;
 
-   if (msi_map_len % (4 * sizeof(__be32))) {
-   dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
-   msi_map_len);
-   return rid_out;
-   }
/* We have a good parent_dev and msi_map, let's use them. */
+   of_pci_map_rid(parent_dev->of_node, "msi-map", rid_in, np,
+  _out);
break;
}
-   if (!msi_map)
-   return rid_out;
-
-   /* The default is to select all bits. */
-   map_mask = 0x;
-
-   /*
-* Can be overridden by "msi-map-mask" property.  If
-* of_property_read_u32() fails, the default is used.
-*/
-   of_property_read_u32(parent_dev->of_node, "msi-map-mask", _mask);
-
-   masked_rid = map_mask & rid_in;
-   matched = false;
-   while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
-   rid_base = be32_to_cpup(msi_map + 0);
-   phandle = be32_to_cpup(msi_map + 1);
-   msi_base = be32_to_cpup(msi_map + 2);
-   rid_len = be32_to_cpup(msi_map + 3);
-
-   if (rid_base & ~map_mask) {
-   dev_err(parent_dev,
-   "Invalid msi-map translation - msi-map-mask 
(0x%x) ignores rid-base (0x%x)\n",
-   map_mask, rid_base);
-   return rid_out;
-   }
-
-   msi_controller_node = of_find_node_by_phandle(phandle);
-
-   matched = (masked_rid >= rid_base &&
-  masked_rid < rid_base + rid_len);
-   if (msi_np)
-   matched &= msi_np == msi_controller_node;
-
-   if (matched && !msi_np) {
-   *np = msi_np = msi_controller_node;
-   break;
-   }
-
-   of_node_put(msi_controller_node);
-   msi_map_len -= 4 * sizeof(__be32);
-   msi_map += 4;
-   }
-   if (!matched)
-   return rid_out;
-
-   rid_out = masked_rid - rid_base + msi_base;
-   dev_dbg(dev,
-   "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base: 
%08x, length: %08x, rid: %08x -> %08x\n",
-   dev_name(parent_dev), map_mask, rid_base, msi_base,
-   rid_len, rid_in, rid_out);
-
return rid_out;
 }
 
diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
index 13f4fed38048..20bf5a0c57fd 100644
--- a/drivers/of/of_pci.c
+++ b/drivers/of/of_pci.c
@@ -306,3 +306,105 @@ struct msi_controller 
*of_pci_find_msi_chip_by_node(struct device_node *of_node)
 EXPORT_SYMBOL_GPL(of_pci_find_msi_chip_by_node);
 
 #endif /* CONFIG_PCI_MSI */
+
+#define MASK_NAME_LEN  32  /* Safely longer than "iommu-map-mask" */
+
+/**
+ * of_pci_map_rid - Translate a requester ID through a downstream mapping.
+ * @np: root complex device node.
+ * @map_name: property name of 

[PATCH v2 1/7] iommu/of: Respect disabled IOMMUs

2016-06-03 Thread Robin Murphy
If an IOMMU node is present in the DT but marked as disabled, we should
avoid trying to do anything with it. We currently sort-of get away with
this by virtue of a disabled device probably not having called
of_iommu_set_ops(), but that is hardly safe to rely upon in general, and
either way we don't want to treat it as an error condition with the
resulting "Failed to initialise IOMMU" message.

Signed-off-by: Robin Murphy 
---

v2: New.

 drivers/iommu/of_iommu.c | 29 +++--
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index af499aea0a1a..662f9a600f4f 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -140,7 +140,7 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
struct of_phandle_args iommu_spec;
struct device_node *np;
const struct iommu_ops *ops = NULL;
-   int idx = 0;
+   int idx;
 
/*
 * We can't do much for PCI devices without knowing how
@@ -154,24 +154,25 @@ const struct iommu_ops *of_iommu_configure(struct device 
*dev,
 * See the `Notes:' section of
 * Documentation/devicetree/bindings/iommu/iommu.txt
 */
-   while (!of_parse_phandle_with_args(master_np, "iommus",
-  "#iommu-cells", idx,
-  _spec)) {
+   for (idx = 0;
+!of_parse_phandle_with_args(master_np, "iommus", "#iommu-cells",
+idx, _spec);
+of_node_put(np), idx++) {
np = iommu_spec.np;
+   if (!of_device_is_available(np))
+   continue;
+
ops = of_iommu_get_ops(np);
+   if (!ops || !ops->of_xlate)
+   continue;
 
-   if (!ops || !ops->of_xlate || ops->of_xlate(dev, _spec))
-   goto err_put_node;
-
-   of_node_put(np);
-   idx++;
+   if (ops->of_xlate(dev, _spec)) {
+   of_node_put(np);
+   return NULL;
+   }
}
 
return ops;
-
-err_put_node:
-   of_node_put(np);
-   return NULL;
 }
 
 void __init of_iommu_init(void)
@@ -182,7 +183,7 @@ void __init of_iommu_init(void)
for_each_matching_node_and_match(np, matches, ) {
const of_iommu_init_fn init_fn = match->data;
 
-   if (init_fn(np))
+   if (of_device_is_available(np) && init_fn(np))
pr_err("Failed to initialise IOMMU %s\n",
of_node_full_name(np));
}
-- 
2.8.1.dirty

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


[PATCH v2 0/7] Generic DT bindings for PCI IOMMUs and ARM SMMUv3

2016-06-03 Thread Robin Murphy
Hi all,

Compared to v1[1] this is more or less a repost of the core parts, although
patch 1 is new. I still need to take the horrible SMMUv2 code out back and
shoot it (there turned out to be some subtle nasties in v1), so in the
meantime I picked up the SMMUv3 ticket to fill in as it was rather more
straightforward. I'll be reworking SMMUv2 on top of these patches (modulo
any feedback) to post in another week or so.

Note that patch 6 might not be plausible to queue just yet as it ends up
looking like a regression due to deficiencies elsewhere - the virtio block
device on the SMMUv3 Fast Model blows up because virtio doesn't use the DMA
API appropriately on a host (although hacking vring_use_dma_api() suffices),
and MSIs are still an open problem - I could really do with focusing on that
with Eric, so it'd be nice to get as much of this out of the way as I can :)

Branch at git://linux-arm.org/linux-rm iommu/generic-v2

Robin.

[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/12454

Mark Rutland (1):
  Docs: dt: add PCI IOMMU map bindings

Robin Murphy (6):
  iommu/of: Respect disabled IOMMUs
  of/irq: Break out msi-map lookup (again)
  iommu/of: Handle iommu-map property for PCI
  iommu/arm-smmu: Implement of_xlate() for SMMUv3
  iommu/arm-smmu: Finish off SMMUv3 default domain support
  iommu/arm-smmu: Support non-PCI devices with SMMUv3

 .../devicetree/bindings/pci/pci-iommu.txt  | 171 
 drivers/iommu/Kconfig  |   2 +-
 drivers/iommu/arm-smmu-v3.c| 300 +
 drivers/iommu/of_iommu.c   |  73 +++--
 drivers/of/irq.c   |  70 +
 drivers/of/of_pci.c| 102 +++
 include/linux/of_pci.h |   8 +
 7 files changed, 460 insertions(+), 266 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt

-- 
2.8.1.dirty

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


[PATCH v2 2/7] Docs: dt: add PCI IOMMU map bindings

2016-06-03 Thread Robin Murphy
From: Mark Rutland 

The existing IOMMU bindings are able to specify the relationship between
masters and IOMMUs, but they are insufficient for describing the general
case of hotpluggable busses such as PCI where the set of masters is not
known until runtime, and the relationship between masters and IOMMUs is
a property of the integration of the system.

This patch adds a generic binding for mapping PCI devices to IOMMUs,
using a new iommu-map property (specific to PCI*) which may be used to
map devices (identified by their Requester ID) to sideband data for the
IOMMU which they master through.

Acked-by: Rob Herring 
Signed-off-by: Mark Rutland 
---

v2: +Rob's ack.

 .../devicetree/bindings/pci/pci-iommu.txt  | 171 +
 1 file changed, 171 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/pci/pci-iommu.txt

diff --git a/Documentation/devicetree/bindings/pci/pci-iommu.txt 
b/Documentation/devicetree/bindings/pci/pci-iommu.txt
new file mode 100644
index ..56c829621b9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-iommu.txt
@@ -0,0 +1,171 @@
+This document describes the generic device tree binding for describing the
+relationship between PCI(e) devices and IOMMU(s).
+
+Each PCI(e) device under a root complex is uniquely identified by its Requester
+ID (AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
+Function number.
+
+For the purpose of this document, when treated as a numeric value, a RID is
+formatted such that:
+
+* Bits [15:8] are the Bus number.
+* Bits [7:3] are the Device number.
+* Bits [2:0] are the Function number.
+* Any other bits required for padding must be zero.
+
+IOMMUs may distinguish PCI devices through sideband data derived from the
+Requester ID. While a given PCI device can only master through one IOMMU, a
+root complex may split masters across a set of IOMMUs (e.g. with one IOMMU per
+bus).
+
+The generic 'iommus' property is insufficient to describe this relationship,
+and a mechanism is required to map from a PCI device to its IOMMU and sideband
+data.
+
+For generic IOMMU bindings, see
+Documentation/devicetree/bindings/iommu/iommu.txt.
+
+
+PCI root complex
+
+
+Optional properties
+---
+
+- iommu-map: Maps a Requester ID to an IOMMU and associated iommu-specifier
+  data.
+
+  The property is an arbitrary number of tuples of
+  (rid-base,iommu,iommu-base,length).
+
+  Any RID r in the interval [rid-base, rid-base + length) is associated with
+  the listed IOMMU, with the iommu-specifier (r - rid-base + iommu-base).
+
+- iommu-map-mask: A mask to be applied to each Requester ID prior to being
+  mapped to an iommu-specifier per the iommu-map property.
+
+
+Example (1)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID,
+* identity-mapped.
+*/
+   iommu-map = <0x0  0x0 0x1>;
+   };
+};
+
+
+Example (2)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID with the
+* function bits masked out.
+*/
+   iommu-map = <0x0  0x0 0x1>;
+   iommu-map-mask = <0xfff8>;
+   };
+};
+
+
+Example (3)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = "vendor,some-iommu";
+   #iommu-cells = <1>;
+   };
+
+   pci: pci@f {
+   reg = <0xf 0x1>;
+   compatible = "vendor,pcie-root-complex";
+   device_type = "pci";
+
+   /*
+* The sideband data provided to the IOMMU is the RID,
+* but the high bits of the bus number are flipped.
+*/
+   iommu-map = <0x  0x8000 0x8000>,
+   <0x8000  0x 0x8000>;
+   };
+};
+
+
+Example (4)
+===
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   iommu_a: iommu@a {
+   reg = <0xa 0x1>;
+   compatible = 

Re: [PATCH v2 3/3] iommu: convert DT component matching to component_match_add_release()

2016-06-03 Thread Matthias Brugger



On 03/06/16 16:21, Russell King wrote:

Convert DT component matching to use component_match_add_release().

Signed-off-by: Russell King 



Reviewed-by: Matthias Brugger 


---
  drivers/iommu/mtk_iommu.c | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3043d8754e3..71cf62af4e24 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -24,6 +24,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -552,11 +553,6 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
*data)
return 0;
  }

-static int compare_of(struct device *dev, void *data)
-{
-   return dev->of_node == data;
-}
-
  static int mtk_iommu_bind(struct device *dev)
  {
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -630,17 +626,19 @@ static int mtk_iommu_probe(struct platform_device *pdev)
continue;

plarbdev = of_find_device_by_node(larbnode);
-   of_node_put(larbnode);
if (!plarbdev) {
plarbdev = of_platform_device_create(
larbnode, NULL,
platform_bus_type.dev_root);
-   if (!plarbdev)
+   if (!plarbdev) {
+   of_node_put(larbnode);
return -EPROBE_DEFER;
+   }
}
data->smi_imu.larb_imu[i].dev = >dev;

-   component_match_add(dev, , compare_of, larbnode);
+   component_match_add_of(dev, , larbnode);
+   of_node_put(larbnode);
}

platform_set_drvdata(pdev, data);


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


[PATCH v2 3/3] iommu: convert DT component matching to component_match_add_release()

2016-06-03 Thread Russell King
Convert DT component matching to use component_match_add_release().

Signed-off-by: Russell King 
---
 drivers/iommu/mtk_iommu.c | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3043d8754e3..71cf62af4e24 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -552,11 +553,6 @@ static int mtk_iommu_hw_init(const struct mtk_iommu_data 
*data)
return 0;
 }
 
-static int compare_of(struct device *dev, void *data)
-{
-   return dev->of_node == data;
-}
-
 static int mtk_iommu_bind(struct device *dev)
 {
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -630,17 +626,19 @@ static int mtk_iommu_probe(struct platform_device *pdev)
continue;
 
plarbdev = of_find_device_by_node(larbnode);
-   of_node_put(larbnode);
if (!plarbdev) {
plarbdev = of_platform_device_create(
larbnode, NULL,
platform_bus_type.dev_root);
-   if (!plarbdev)
+   if (!plarbdev) {
+   of_node_put(larbnode);
return -EPROBE_DEFER;
+   }
}
data->smi_imu.larb_imu[i].dev = >dev;
 
-   component_match_add(dev, , compare_of, larbnode);
+   component_match_add_of(dev, , larbnode);
+   of_node_put(larbnode);
}
 
platform_set_drvdata(pdev, data);
-- 
2.1.0

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


Re: [PATCH] iommu: convert DT component matching to component_match_add_release()

2016-06-03 Thread Matthias Brugger



On 03/06/16 09:58, Russell King wrote:

Convert DT component matching to use component_match_add_release().

Signed-off-by: Russell King 
---


Reviewed-by: Matthias Brugger 


  drivers/iommu/mtk_iommu.c | 13 ++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3043d8754e3..c036df1c49ca 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -557,6 +557,11 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
  }

+static void release_of(struct device *dev, void *data)
+{
+   of_node_put(data);
+}
+
  static int mtk_iommu_bind(struct device *dev)
  {
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -630,17 +635,19 @@ static int mtk_iommu_probe(struct platform_device *pdev)
continue;

plarbdev = of_find_device_by_node(larbnode);
-   of_node_put(larbnode);
if (!plarbdev) {
plarbdev = of_platform_device_create(
larbnode, NULL,
platform_bus_type.dev_root);
-   if (!plarbdev)
+   if (!plarbdev) {
+   of_node_put(larbnode);
return -EPROBE_DEFER;
+   }
}
data->smi_imu.larb_imu[i].dev = >dev;

-   component_match_add(dev, , compare_of, larbnode);
+   component_match_add_release(dev, , release_of,
+   compare_of, larbnode);
}

platform_set_drvdata(pdev, data);


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


[PATCH] iommu: convert DT component matching to component_match_add_release()

2016-06-03 Thread Russell King
Convert DT component matching to use component_match_add_release().

Signed-off-by: Russell King 
---
 drivers/iommu/mtk_iommu.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/iommu/mtk_iommu.c b/drivers/iommu/mtk_iommu.c
index c3043d8754e3..c036df1c49ca 100644
--- a/drivers/iommu/mtk_iommu.c
+++ b/drivers/iommu/mtk_iommu.c
@@ -557,6 +557,11 @@ static int compare_of(struct device *dev, void *data)
return dev->of_node == data;
 }
 
+static void release_of(struct device *dev, void *data)
+{
+   of_node_put(data);
+}
+
 static int mtk_iommu_bind(struct device *dev)
 {
struct mtk_iommu_data *data = dev_get_drvdata(dev);
@@ -630,17 +635,19 @@ static int mtk_iommu_probe(struct platform_device *pdev)
continue;
 
plarbdev = of_find_device_by_node(larbnode);
-   of_node_put(larbnode);
if (!plarbdev) {
plarbdev = of_platform_device_create(
larbnode, NULL,
platform_bus_type.dev_root);
-   if (!plarbdev)
+   if (!plarbdev) {
+   of_node_put(larbnode);
return -EPROBE_DEFER;
+   }
}
data->smi_imu.larb_imu[i].dev = >dev;
 
-   component_match_add(dev, , compare_of, larbnode);
+   component_match_add_release(dev, , release_of,
+   compare_of, larbnode);
}
 
platform_set_drvdata(pdev, data);
-- 
2.1.0

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


[PATCH] iommu/arm-smmu: wire up map_sg for arm-smmu-v3

2016-06-03 Thread Will Deacon
From: Jean-Philippe Brucker 

The map_sg callback is missing from arm_smmu_ops, but is required by
iommu.h. Similarly to most other IOMMU drivers, connect it to
default_iommu_map_sg.

Cc: 
Signed-off-by: Jean-Philippe Brucker 
Signed-off-by: Will Deacon 
---

Joerg -- this is the only fix I have queued, so could you pick it up
directly, please?

 drivers/iommu/arm-smmu-v3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
index 94b68213c50d..5f6b3bcab078 100644
--- a/drivers/iommu/arm-smmu-v3.c
+++ b/drivers/iommu/arm-smmu-v3.c
@@ -1941,6 +1941,7 @@ static struct iommu_ops arm_smmu_ops = {
.attach_dev = arm_smmu_attach_dev,
.map= arm_smmu_map,
.unmap  = arm_smmu_unmap,
+   .map_sg = default_iommu_map_sg,
.iova_to_phys   = arm_smmu_iova_to_phys,
.add_device = arm_smmu_add_device,
.remove_device  = arm_smmu_remove_device,
-- 
2.1.4

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


Re: [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

2016-06-03 Thread Geert Uytterhoeven
Hi Magnus,

On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm  wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V3
>
> [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for 
> context
> [PATCH v3 03/06] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v3 04/06] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v3 05/06] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v3 06/06] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
>
> These patches update the IPMMU driver with a couple of changes
> to support build on multiple architectures. In the process of
> doing so the interrupt code gets reworked and the foundation
> for supporting multiple contexts are added.
>
> In this version of the series the patch order has been reworked
> to make simplify review. Thanks to Laurent for his suggestions!
>
> The 32-bit ARM logic has intentionally been changed as little as possible
> to avoid breakage. Once CONFIG_IOMMU_DMA can be used it may be good time
> to revisit the init ordering for the 32-bit SoCs. There is room for
> improvement for sure like Robin Murphy kindly pointed out.
>
> Changes since V2:
>  - Got rid of patch 3 from the V2 however patch 1, 2 and 4 are kept.
>  - V3 patch 3, 4 and 5 come from
>[PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update
>  - Patch 5 has been reworked to include patch 3 of the V1 of this series
>
> Changes since V1:
>  - Got rid of patch 2 and 3 from initial series
>  - Updated bitmap code locking and also used lighter bitop functions
>  - Updated the Kconfig bits to apply on top of ARCH_RENESAS
>
> Signed-off-by: Magnus Damm 

Thanks for your series!

For your convenience, I've queued it up in topic/ipmmu-multi-arch-v3 at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git, and
will include it in next renesas-drivers release.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v3 10/45] cris: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Jesper Nilsson
On Thu, Jun 02, 2016 at 05:39:12PM +0200, Krzysztof Kozlowski wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.

Acked-by: Jesper Nilsson 

> Signed-off-by: Krzysztof Kozlowski 

/^JN - Jesper Nilsson
-- 
   Jesper Nilsson -- jesper.nils...@axis.com
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v3 01/45] powerpc: dma-mapping: Don't hard-code the value of DMA_ATTR_WEAK_ORDERING

2016-06-03 Thread Krzysztof Kozlowski
On 06/02/2016 05:39 PM, Krzysztof Kozlowski wrote:
> Hard-coded value of DMA_ATTR_WEAK_ORDERING is then compared with the
> symbol.  This will stop matching if the value of symbol is changed (when
> switching DMA attributes to unsigned long).
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  arch/powerpc/platforms/cell/iommu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/powerpc/platforms/cell/iommu.c 
> b/arch/powerpc/platforms/cell/iommu.c
> index 14a582b21274..0c2794d2b6c0 100644
> --- a/arch/powerpc/platforms/cell/iommu.c
> +++ b/arch/powerpc/platforms/cell/iommu.c
> @@ -1162,7 +1162,7 @@ static int __init setup_iommu_fixed(char *str)
>   pciep = of_find_node_by_type(NULL, "pcie-endpoint");
>  
>   if (strcmp(str, "weak") == 0 || (pciep && strcmp(str, "strong") != 0))
> - iommu_fixed_is_weak = 1;
> + iommu_fixed_is_weak = DMA_ATTR_WEAK_ORDERING;

After some more thoughts given to this, I think my fix is not correct.
The 'iommu_fixed_is_weak' stores the bool and it is used to compare with
result of test_bit().

Please ignore this patch.

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


Re: [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Krzysztof Kozlowski
On 06/03/2016 09:17 AM, Geert Uytterhoeven wrote:
> Hi Krzysztof,
> 
> On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
>  wrote:
>> --- a/include/linux/dma-mapping.h
>> +++ b/include/linux/dma-mapping.h
>> @@ -5,13 +5,25 @@
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER (1UL << 1)
> 
> Any particular reason they start at 2, not 1?

No reason. I'll fix this in next version (and trim Cc-list). Anyway the
values of constants won't match old ones but that should not be problem
(unless they are hard-coded somewhere).

Best regards,
Krzysztof


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


Re: [RFC v3 29/45] m68k: dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Geert Uytterhoeven
On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
 wrote:
> Split out subsystem specific changes for easier reviews. This will be
> squashed with main commit.
>
> Signed-off-by: Krzysztof Kozlowski 

Looks good.

Acked-by: Geert Uytterhoeven 

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu


Re: [RFC v3 02/45] dma-mapping: Use unsigned long for dma_attrs

2016-06-03 Thread Geert Uytterhoeven
Hi Krzysztof,

On Thu, Jun 2, 2016 at 5:39 PM, Krzysztof Kozlowski
 wrote:
> --- a/include/linux/dma-mapping.h
> +++ b/include/linux/dma-mapping.h
> @@ -5,13 +5,25 @@

> +/**
> + * List of possible attributes associated with a DMA mapping. The semantics
> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
> + */
> +#define DMA_ATTR_WRITE_BARRIER (1UL << 1)

Any particular reason they start at 2, not 1?

> +#define DMA_ATTR_WEAK_ORDERING (1UL << 2)
> +#define DMA_ATTR_WRITE_COMBINE (1UL << 3)
> +#define DMA_ATTR_NON_CONSISTENT(1UL << 4)
> +#define DMA_ATTR_NO_KERNEL_MAPPING (1UL << 5)
> +#define DMA_ATTR_SKIP_CPU_SYNC (1UL << 6)
> +#define DMA_ATTR_FORCE_CONTIGUOUS  (1UL << 7)
> +#define DMA_ATTR_ALLOC_SINGLE_PAGES(1UL << 8)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu