On Tue, Jan 06, 2015 at 11:30:49PM +0000, Mitchel Humpherys wrote: > On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring <robherri...@gmail.com> wrote: > > On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys > > <mitch...@codeaurora.org> wrote: > >> On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon <will.dea...@arm.com> > >> wrote: > >>>> /* Invalidate the TLB, just in case */ > >>>> - writel_relaxed(0, gr0_base + ARM_SMMU_GR0_STLBIALL); > >>>> writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLH); > >>>> writel_relaxed(0, gr0_base + ARM_SMMU_GR0_TLBIALLNSNH); > >>> > >>> I was slightly worried that this would break the Calxeda implementation > >>> with ARM_SMMU_OPT_SECURE_CFG_ACCESS, but actually these registers aren't > >>> even aliased there so I think there's a bigger bug for them. > >>> > >>> Anyway, given that their hardware has gone the way of the dodo, I'll take > >>> the patch as-is unless you have any further comments? > >>> > >>> Will > >> > >> Yeah I agree that this shouldn't affect the (now defunct) Calxeda > >> implementation. I've tested this on some hardware here and we crash > >> when we touch that register since it's secure-only (not banked, as you > >> mentioned). > > > > It's not quite dead: > > > > http://www.eweek.com/servers/calxedas-arm-based-server-chips-re-emerge-with-new-company.html > > > > But AFAIK, production systems don't enable the SMMU, but someone could > > still want to at some point. A note in the commit log here would be > > nice so it gets recorded. > > Actually, as Will mentioned this shouldn't affect Calxeda since this > isn't a banked register. I think the confusion is from the `S' prefix > in the spec. The /s/ (lower-case, italic) prefix means that there are > secure and non-secure versions of the register, while the S (upper-case, > non-italic) prefix means "this is a secure register" (which may or may > not have a banked non-secure counterpart). This particular register is > an S-only register (there's no non-secure counterpart) so the Calxeda > workaround isn't relevant here, AFAICT.
Right, but I think the problem is that we go and write zero to ARM_SMMU_GR0_TLBIALLH and ARM_SMMU_GR0_TLBIALLNSNH at what *would be* their non-secure aliases for the secure side (i.e. + 0x400). If would be better to check for the ARM_SMMU_OPT_SECURE_CFG_ACCESS feature and, if it's set then zero ARM_SMMU_GR0_STLBIALL at the correct address otherwise do the ARM_SMMU_GR0_TLBIALLH and ARM_SMMU_GR0_TLBIALLNSNH. Will _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
