* [PATCH 0/5] iommu/arm-smmu: updates for 3.15 @ 2014-02-21 17:16 Will Deacon 2014-02-21 17:16 ` [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Will Deacon ` (4 more replies) 0 siblings, 5 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel Hello, These are the arm-smmu updates I have queued for 3.15 and plan to send to Joerg sometime next week. The main parts are for accessing the buggy Calxeda SMMU, which is wired as secure despite being non-secure. Unfortunately, the apparent demise of Calxeda means that Andreas is no longer working on this, so I had to extract what I could from a larger patchset (which wasn't yet ready for merging). On my side, there's some cosmetic changes after Joerg fixed some locks to use spin_lock_irq{save,restore} and also an optimisation to restrict the scope of our barrier when publishing page tables (now that ARM64 can accept the option). Feedback welcome, Will Andreas Herrmann (3): iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS iommu/arm-smmu: support buggy implementations with secure cfg accesses documentation/iommu: update description of ARM System MMU binding Will Deacon (2): iommu/arm-smmu: clean up use of `flags' in page table handling code iommu/arm-smmu: provide option to dsb macro when publishing tables .../devicetree/bindings/iommu/arm,smmu.txt | 6 ++ drivers/iommu/arm-smmu.c | 100 ++++++++++++++------- 2 files changed, 75 insertions(+), 31 deletions(-) -- 1.8.2.2 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon @ 2014-02-21 17:16 ` Will Deacon 2014-02-21 17:16 ` [PATCH 2/5] iommu/arm-smmu: support buggy implementations with secure cfg accesses Will Deacon ` (3 subsequent siblings) 4 siblings, 0 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel From: Andreas Herrmann <andreas.herrmann@calxeda.com> The DT parsing code that determines stream IDs uses of_parse_phandle_with_args and thus MAX_MASTER_STREAMIDS is always bound by MAX_PHANDLE_ARGS. Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- drivers/iommu/arm-smmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 1d9ab39af29f..a3ce60887efa 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -48,7 +48,7 @@ #include <asm/pgalloc.h> /* Maximum number of stream IDs assigned to a single device */ -#define MAX_MASTER_STREAMIDS 8 +#define MAX_MASTER_STREAMIDS MAX_PHANDLE_ARGS /* Maximum number of context banks per SMMU */ #define ARM_SMMU_MAX_CBS 128 -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/5] iommu/arm-smmu: support buggy implementations with secure cfg accesses 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon 2014-02-21 17:16 ` [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Will Deacon @ 2014-02-21 17:16 ` Will Deacon 2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon ` (2 subsequent siblings) 4 siblings, 0 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel From: Andreas Herrmann <andreas.herrmann@calxeda.com> In such a case we have to use secure aliases of some non-secure registers. This handling is switched on by DT property "calxeda,smmu-secure-config-access" for an SMMU node. Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com> [will: merged with driver option handling patch] Signed-off-by: Will Deacon <will.deacon@arm.com> --- drivers/iommu/arm-smmu.c | 58 +++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 48 insertions(+), 10 deletions(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index a3ce60887efa..e04fdcb4b9ba 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -60,6 +60,16 @@ #define ARM_SMMU_GR0(smmu) ((smmu)->base) #define ARM_SMMU_GR1(smmu) ((smmu)->base + (smmu)->pagesize) +/* + * SMMU global address space with conditional offset to access secure + * aliases of non-secure registers (e.g. nsCR0: 0x400, nsGFSR: 0x448, + * nsGFSYNR0: 0x450) + */ +#define ARM_SMMU_GR0_NS(smmu) \ + ((smmu)->base + \ + ((smmu->options & ARM_SMMU_OPT_SECURE_CFG_ACCESS) \ + ? 0x400 : 0)) + /* Page table bits */ #define ARM_SMMU_PTE_XN (((pteval_t)3) << 53) #define ARM_SMMU_PTE_CONT (((pteval_t)1) << 52) @@ -351,6 +361,9 @@ struct arm_smmu_device { #define ARM_SMMU_FEAT_TRANS_S2 (1 << 3) #define ARM_SMMU_FEAT_TRANS_NESTED (1 << 4) u32 features; + +#define ARM_SMMU_OPT_SECURE_CFG_ACCESS (1 << 0) + u32 options; int version; u32 num_context_banks; @@ -401,6 +414,29 @@ struct arm_smmu_domain { static DEFINE_SPINLOCK(arm_smmu_devices_lock); static LIST_HEAD(arm_smmu_devices); +struct arm_smmu_option_prop { + u32 opt; + const char *prop; +}; + +static struct arm_smmu_option_prop arm_smmu_options [] = { + { ARM_SMMU_OPT_SECURE_CFG_ACCESS, "calxeda,smmu-secure-config-access" }, + { 0, NULL}, +}; + +static void parse_driver_options(struct arm_smmu_device *smmu) +{ + int i = 0; + do { + if (of_property_read_bool(smmu->dev->of_node, + arm_smmu_options[i].prop)) { + smmu->options |= arm_smmu_options[i].opt; + dev_notice(smmu->dev, "option %s\n", + arm_smmu_options[i].prop); + } + } while (arm_smmu_options[++i].opt); +} + static struct arm_smmu_master *find_smmu_master(struct arm_smmu_device *smmu, struct device_node *dev_node) { @@ -614,16 +650,16 @@ static irqreturn_t arm_smmu_global_fault(int irq, void *dev) { u32 gfsr, gfsynr0, gfsynr1, gfsynr2; struct arm_smmu_device *smmu = dev; - void __iomem *gr0_base = ARM_SMMU_GR0(smmu); + void __iomem *gr0_base = ARM_SMMU_GR0_NS(smmu); gfsr = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR); - if (!gfsr) - return IRQ_NONE; - gfsynr0 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR0); gfsynr1 = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSYNR1); gfsynr2 = readl_relaxed(gr0_base + 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, @@ -1597,9 +1633,9 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu) int i = 0; u32 reg; - /* Clear Global FSR */ - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sGFSR); - writel(reg, gr0_base + ARM_SMMU_GR0_sGFSR); + /* clear global FSR */ + reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR); + writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sGFSR); /* Mark all SMRn as invalid and all S2CRn as bypass */ for (i = 0; i < smmu->num_mapping_groups; ++i) { @@ -1619,7 +1655,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu) writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH); writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH); - reg = readl_relaxed(gr0_base + ARM_SMMU_GR0_sCR0); + reg = readl_relaxed(ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); /* Enable fault reporting */ reg |= (sCR0_GFRE | sCR0_GFIE | sCR0_GCFGFRE | sCR0_GCFGFIE); @@ -1638,7 +1674,7 @@ static void arm_smmu_device_reset(struct arm_smmu_device *smmu) /* Push the button */ arm_smmu_tlb_sync(smmu); - writel_relaxed(reg, gr0_base + ARM_SMMU_GR0_sCR0); + writel(reg, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); } static int arm_smmu_id_size_to_bits(int size) @@ -1885,6 +1921,8 @@ static int arm_smmu_device_dt_probe(struct platform_device *pdev) if (err) goto out_put_parent; + parse_driver_options(smmu); + if (smmu->version > 1 && smmu->num_context_banks != smmu->num_context_irqs) { dev_err(dev, @@ -1969,7 +2007,7 @@ static int arm_smmu_device_remove(struct platform_device *pdev) free_irq(smmu->irqs[i], smmu); /* Turn the thing off */ - writel_relaxed(sCR0_CLIENTPD, ARM_SMMU_GR0(smmu) + ARM_SMMU_GR0_sCR0); + writel(sCR0_CLIENTPD,ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0); return 0; } -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon 2014-02-21 17:16 ` [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Will Deacon 2014-02-21 17:16 ` [PATCH 2/5] iommu/arm-smmu: support buggy implementations with secure cfg accesses Will Deacon @ 2014-02-21 17:16 ` Will Deacon 2014-02-21 18:57 ` Sergei Shtylyov 2014-02-28 16:17 ` Timur Tabi 2014-02-21 17:16 ` [PATCH 4/5] iommu/arm-smmu: clean up use of `flags' in page table handling code Will Deacon 2014-02-21 17:16 ` [PATCH 5/5] iommu/arm-smmu: provide option to dsb macro when publishing tables Will Deacon 4 siblings, 2 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel From: Andreas Herrmann <andreas.herrmann@calxeda.com> This patch adds descriptions for new properties of the device tree binding for the ARM SMMU architecture. These properties control arm-smmu driver options. Cc: Grant Likely <grant.likely@linaro.org> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com> [will: removed device isolation property, as this has been dropped] Signed-off-by: Will Deacon <will.deacon@arm.com> --- Documentation/devicetree/bindings/iommu/arm,smmu.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt index e34c6cdd8ba8..d6d2f6dd437a 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt @@ -48,6 +48,12 @@ conditions. from the mmu-masters towards memory) node for this SMMU. +- calxeda,smmu-secure-config-access : Enable proper handling of buggy + implementations that always use secure access to + SMMU configuration registers. In this case non-secure + aliases of secure registers have to be used during + SMMU configuration. + Example: smmu { -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon @ 2014-02-21 18:57 ` Sergei Shtylyov 2014-02-28 16:17 ` Timur Tabi 1 sibling, 0 replies; 12+ messages in thread From: Sergei Shtylyov @ 2014-02-21 18:57 UTC (permalink / raw) To: linux-arm-kernel Hello. On 02/21/2014 08:16 PM, Will Deacon wrote: > From: Andreas Herrmann <andreas.herrmann@calxeda.com> > This patch adds descriptions for new properties of the device tree > binding for the ARM SMMU architecture. These properties control > arm-smmu driver options. > Cc: Grant Likely <grant.likely@linaro.org> > Acked-by: Rob Herring <robh@kernel.org> > Signed-off-by: Andreas Herrmann <andreas.herrmann@calxeda.com> > [will: removed device isolation property, as this has been dropped] > Signed-off-by: Will Deacon <will.deacon@arm.com> > --- > Documentation/devicetree/bindings/iommu/arm,smmu.txt | 6 ++++++ > 1 file changed, 6 insertions(+) > diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > index e34c6cdd8ba8..d6d2f6dd437a 100644 > --- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt > +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt > @@ -48,6 +48,12 @@ conditions. > from the mmu-masters towards memory) node for this > SMMU. > > +- calxeda,smmu-secure-config-access : Enable proper handling of buggy > + implementations that always use secure access to > + SMMU configuration registers. In this case non-secure > + aliases of secure registers have to be used during > + SMMU configuration. Could you indent the text uniformly, in this case probably with spaces only (looking at the above property)? WBR, Sergei ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon 2014-02-21 18:57 ` Sergei Shtylyov @ 2014-02-28 16:17 ` Timur Tabi 2014-02-28 16:21 ` Will Deacon 1 sibling, 1 reply; 12+ messages in thread From: Timur Tabi @ 2014-02-28 16:17 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 21, 2014 at 11:16 AM, Will Deacon <will.deacon@arm.com> wrote: > > +- calxeda,smmu-secure-config-access : Enable proper handling of buggy > + implementations that always use secure access to > + SMMU configuration registers. In this case non-secure > + aliases of secure registers have to be used during > + SMMU configuration. I'm confused. Why does this property have a "calxeda" prefix? How is it a Calxeda-specific property? ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-28 16:17 ` Timur Tabi @ 2014-02-28 16:21 ` Will Deacon 2014-02-28 17:07 ` Timur Tabi 0 siblings, 1 reply; 12+ messages in thread From: Will Deacon @ 2014-02-28 16:21 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 28, 2014 at 04:17:43PM +0000, Timur Tabi wrote: > On Fri, Feb 21, 2014 at 11:16 AM, Will Deacon <will.deacon@arm.com> wrote: > > > > +- calxeda,smmu-secure-config-access : Enable proper handling of buggy > > + implementations that always use secure access to > > + SMMU configuration registers. In this case non-secure > > + aliases of secure registers have to be used during > > + SMMU configuration. > > I'm confused. Why does this property have a "calxeda" prefix? How is > it a Calxeda-specific property? Because they wired up their SMMU backwards. It's basically an implementation-specific erratum workaround. Will ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-28 16:21 ` Will Deacon @ 2014-02-28 17:07 ` Timur Tabi 2014-03-04 10:08 ` Will Deacon 0 siblings, 1 reply; 12+ messages in thread From: Timur Tabi @ 2014-02-28 17:07 UTC (permalink / raw) To: linux-arm-kernel On 02/28/2014 10:21 AM, Will Deacon wrote: >>> > >+- calxeda,smmu-secure-config-access : Enable proper handling of buggy >>> > >+ implementations that always use secure access to >>> > >+ SMMU configuration registers. In this case non-secure >>> > >+ aliases of secure registers have to be used during >>> > >+ SMMU configuration. >> > >> >I'm confused. Why does this property have a "calxeda" prefix? How is >> >it a Calxeda-specific property? > Because they wired up their SMMU backwards. It's basically an > implementation-specific erratum workaround. Hmmmm.... Other than making the same wiring mistake, is there any reason any other ARM chip would need this property set? The reason I ask is that it's kinda weird (well, to me at least) that we have an property named for a specific SoC, but the implementation and documentation tries so hard to hide that fact. I would think that the binding document would provide some explanation as to why the property has a "calxeda" prefix. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-02-28 17:07 ` Timur Tabi @ 2014-03-04 10:08 ` Will Deacon 2014-03-04 13:20 ` Timur Tabi 0 siblings, 1 reply; 12+ messages in thread From: Will Deacon @ 2014-03-04 10:08 UTC (permalink / raw) To: linux-arm-kernel On Fri, Feb 28, 2014 at 05:07:31PM +0000, Timur Tabi wrote: > On 02/28/2014 10:21 AM, Will Deacon wrote: > >>> > >+- calxeda,smmu-secure-config-access : Enable proper handling of buggy > >>> > >+ implementations that always use secure access to > >>> > >+ SMMU configuration registers. In this case non-secure > >>> > >+ aliases of secure registers have to be used during > >>> > >+ SMMU configuration. > >> > > >> >I'm confused. Why does this property have a "calxeda" prefix? How is > >> >it a Calxeda-specific property? > > > Because they wired up their SMMU backwards. It's basically an > > implementation-specific erratum workaround. > > Hmmmm.... > > Other than making the same wiring mistake, is there any reason any other > ARM chip would need this property set? Not that I can think of, no. > The reason I ask is that it's kinda weird (well, to me at least) that we > have an property named for a specific SoC, but the implementation and > documentation tries so hard to hide that fact. I would think that the > binding document would provide some explanation as to why the property > has a "calxeda" prefix. I don't agree. We're making sensible use of a vendor prefix to isolate errata workarounds. The description clearly states that the implementation is buggy. Given that there aren't any Calxeda engineers left working on this stuff, I'm heavily inclined to leave this patch as-is. Will ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding 2014-03-04 10:08 ` Will Deacon @ 2014-03-04 13:20 ` Timur Tabi 0 siblings, 0 replies; 12+ messages in thread From: Timur Tabi @ 2014-03-04 13:20 UTC (permalink / raw) To: linux-arm-kernel Will Deacon wrote: > I don't agree. We're making sensible use of a vendor prefix to isolate > errata workarounds. The description clearly states that the implementation > is buggy. Yeah, but I'm disappointed that the patch doesn't explain the exact bug that necessitates the property. I think that's an important clue for others to determine whether they would ever need this work-around. > Given that there aren't any Calxeda engineers left working on this stuff, > I'm heavily inclined to leave this patch as-is. Fair enough. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 4/5] iommu/arm-smmu: clean up use of `flags' in page table handling code 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon ` (2 preceding siblings ...) 2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon @ 2014-02-21 17:16 ` Will Deacon 2014-02-21 17:16 ` [PATCH 5/5] iommu/arm-smmu: provide option to dsb macro when publishing tables Will Deacon 4 siblings, 0 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel Commit 972157cac528 ("arm/smmu: Use irqsafe spinlock for domain lock") fixed our page table locks to be the irq{save,restore} variants, since the DMA mapping API can be invoked from interrupt context. This patch cleans up our use of the flags variable so we can distinguish between IRQ flags (now `flags') and pte protection bits (now `prot'). Signed-off-by: Will Deacon <will.deacon@arm.com> --- drivers/iommu/arm-smmu.c | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index e04fdcb4b9ba..83297fe0878d 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -1254,7 +1254,7 @@ static bool arm_smmu_pte_is_contiguous_range(unsigned long addr, static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd, unsigned long addr, unsigned long end, - unsigned long pfn, int flags, int stage) + unsigned long pfn, int prot, int stage) { pte_t *pte, *start; pteval_t pteval = ARM_SMMU_PTE_PAGE | ARM_SMMU_PTE_AF | ARM_SMMU_PTE_XN; @@ -1276,28 +1276,28 @@ static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd, if (stage == 1) { pteval |= ARM_SMMU_PTE_AP_UNPRIV | ARM_SMMU_PTE_nG; - if (!(flags & IOMMU_WRITE) && (flags & IOMMU_READ)) + if (!(prot & IOMMU_WRITE) && (prot & IOMMU_READ)) pteval |= ARM_SMMU_PTE_AP_RDONLY; - if (flags & IOMMU_CACHE) + if (prot & IOMMU_CACHE) pteval |= (MAIR_ATTR_IDX_CACHE << ARM_SMMU_PTE_ATTRINDX_SHIFT); } else { pteval |= ARM_SMMU_PTE_HAP_FAULT; - if (flags & IOMMU_READ) + if (prot & IOMMU_READ) pteval |= ARM_SMMU_PTE_HAP_READ; - if (flags & IOMMU_WRITE) + if (prot & IOMMU_WRITE) pteval |= ARM_SMMU_PTE_HAP_WRITE; - if (flags & IOMMU_CACHE) + if (prot & IOMMU_CACHE) pteval |= ARM_SMMU_PTE_MEMATTR_OIWB; else pteval |= ARM_SMMU_PTE_MEMATTR_NC; } /* If no access, create a faulting entry to avoid TLB fills */ - if (flags & IOMMU_EXEC) + if (prot & IOMMU_EXEC) pteval &= ~ARM_SMMU_PTE_XN; - else if (!(flags & (IOMMU_READ | IOMMU_WRITE))) + else if (!(prot & (IOMMU_READ | IOMMU_WRITE))) pteval &= ~ARM_SMMU_PTE_PAGE; pteval |= ARM_SMMU_PTE_SH_IS; @@ -1359,7 +1359,7 @@ static int arm_smmu_alloc_init_pte(struct arm_smmu_device *smmu, pmd_t *pmd, static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud, unsigned long addr, unsigned long end, - phys_addr_t phys, int flags, int stage) + phys_addr_t phys, int prot, int stage) { int ret; pmd_t *pmd; @@ -1383,7 +1383,7 @@ static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud, do { next = pmd_addr_end(addr, end); ret = arm_smmu_alloc_init_pte(smmu, pmd, addr, end, pfn, - flags, stage); + prot, stage); phys += next - addr; } while (pmd++, addr = next, addr < end); @@ -1392,7 +1392,7 @@ static int arm_smmu_alloc_init_pmd(struct arm_smmu_device *smmu, pud_t *pud, static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd, unsigned long addr, unsigned long end, - phys_addr_t phys, int flags, int stage) + phys_addr_t phys, int prot, int stage) { int ret = 0; pud_t *pud; @@ -1416,7 +1416,7 @@ static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd, do { next = pud_addr_end(addr, end); ret = arm_smmu_alloc_init_pmd(smmu, pud, addr, next, phys, - flags, stage); + prot, stage); phys += next - addr; } while (pud++, addr = next, addr < end); @@ -1425,7 +1425,7 @@ static int arm_smmu_alloc_init_pud(struct arm_smmu_device *smmu, pgd_t *pgd, static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain, unsigned long iova, phys_addr_t paddr, - size_t size, int flags) + size_t size, int prot) { int ret, stage; unsigned long end; @@ -1433,7 +1433,7 @@ static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain, struct arm_smmu_cfg *root_cfg = &smmu_domain->root_cfg; pgd_t *pgd = root_cfg->pgd; struct arm_smmu_device *smmu = root_cfg->smmu; - unsigned long irqflags; + unsigned long flags; if (root_cfg->cbar == CBAR_TYPE_S2_TRANS) { stage = 2; @@ -1456,14 +1456,14 @@ static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain, if (paddr & ~output_mask) return -ERANGE; - spin_lock_irqsave(&smmu_domain->lock, irqflags); + spin_lock_irqsave(&smmu_domain->lock, flags); pgd += pgd_index(iova); end = iova + size; do { unsigned long next = pgd_addr_end(iova, end); ret = arm_smmu_alloc_init_pud(smmu, pgd, iova, next, paddr, - flags, stage); + prot, stage); if (ret) goto out_unlock; @@ -1472,13 +1472,13 @@ static int arm_smmu_handle_mapping(struct arm_smmu_domain *smmu_domain, } while (pgd++, iova != end); out_unlock: - spin_unlock_irqrestore(&smmu_domain->lock, irqflags); + spin_unlock_irqrestore(&smmu_domain->lock, flags); return ret; } static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, - phys_addr_t paddr, size_t size, int flags) + phys_addr_t paddr, size_t size, int prot) { struct arm_smmu_domain *smmu_domain = domain->priv; @@ -1489,7 +1489,7 @@ static int arm_smmu_map(struct iommu_domain *domain, unsigned long iova, if ((phys_addr_t)iova & ~smmu_domain->output_mask) return -ERANGE; - return arm_smmu_handle_mapping(smmu_domain, iova, paddr, size, flags); + return arm_smmu_handle_mapping(smmu_domain, iova, paddr, size, prot); } static size_t arm_smmu_unmap(struct iommu_domain *domain, unsigned long iova, -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 5/5] iommu/arm-smmu: provide option to dsb macro when publishing tables 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon ` (3 preceding siblings ...) 2014-02-21 17:16 ` [PATCH 4/5] iommu/arm-smmu: clean up use of `flags' in page table handling code Will Deacon @ 2014-02-21 17:16 ` Will Deacon 4 siblings, 0 replies; 12+ messages in thread From: Will Deacon @ 2014-02-21 17:16 UTC (permalink / raw) To: linux-arm-kernel On coherent systems, publishing new page tables to the SMMU walker is achieved with a dsb instruction. In fact, this can be a dsb(ishst) which also provides the mandatory barrier option for arm64. Acked-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com> --- drivers/iommu/arm-smmu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c index 83297fe0878d..1da5b41afc31 100644 --- a/drivers/iommu/arm-smmu.c +++ b/drivers/iommu/arm-smmu.c @@ -678,7 +678,7 @@ static void arm_smmu_flush_pgtable(struct arm_smmu_device *smmu, void *addr, /* Ensure new page tables are visible to the hardware walker */ if (smmu->features & ARM_SMMU_FEAT_COHERENT_WALK) { - dsb(); + dsb(ishst); } else { /* * If the SMMU can't walk tables in the CPU caches, treat them -- 1.8.2.2 ^ permalink raw reply related [flat|nested] 12+ messages in thread
end of thread, other threads:[~2014-03-04 13:20 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-02-21 17:16 [PATCH 0/5] iommu/arm-smmu: updates for 3.15 Will Deacon 2014-02-21 17:16 ` [PATCH 1/5] iommu/arm-smmu: set MAX_MASTER_STREAMIDS to MAX_PHANDLE_ARGS Will Deacon 2014-02-21 17:16 ` [PATCH 2/5] iommu/arm-smmu: support buggy implementations with secure cfg accesses Will Deacon 2014-02-21 17:16 ` [PATCH 3/5] documentation/iommu: update description of ARM System MMU binding Will Deacon 2014-02-21 18:57 ` Sergei Shtylyov 2014-02-28 16:17 ` Timur Tabi 2014-02-28 16:21 ` Will Deacon 2014-02-28 17:07 ` Timur Tabi 2014-03-04 10:08 ` Will Deacon 2014-03-04 13:20 ` Timur Tabi 2014-02-21 17:16 ` [PATCH 4/5] iommu/arm-smmu: clean up use of `flags' in page table handling code Will Deacon 2014-02-21 17:16 ` [PATCH 5/5] iommu/arm-smmu: provide option to dsb macro when publishing tables Will Deacon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).