From: mitchelh@codeaurora•org (Mitchel Humpherys)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] iommu/arm-smmu: don't touch the secure STLBIALL register
Date: Tue, 06 Jan 2015 15:30:49 -0800 [thread overview]
Message-ID: <vnkw61cjebbq.fsf@mitchelh-linux.qualcomm.com> (raw)
In-Reply-To: <CAL_JsqJYZ+-qt8UXPP7=pCsZFXeOkB8ogOzbuusdv1Cb+o1d2A@mail.gmail.com> (Rob Herring's message of "Tue, 6 Jan 2015 16:35:28 -0600")
On Tue, Jan 06 2015 at 02:35:28 PM, Rob Herring <robherring2@gmail•com> wrote:
> On Tue, Jan 6, 2015 at 2:16 PM, Mitchel Humpherys
> <mitchelh@codeaurora•org> wrote:
>> On Tue, Jan 06 2015 at 06:15:07 AM, Will Deacon <will.deacon@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.
-Mitch
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-01-06 23:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-23 17:39 [PATCH] iommu/arm-smmu: don't touch the secure STLBIALL register Mitchel Humpherys
2015-01-06 14:15 ` Will Deacon
2015-01-06 20:16 ` Mitchel Humpherys
2015-01-06 22:35 ` Rob Herring
2015-01-06 23:30 ` Mitchel Humpherys [this message]
2015-01-07 10:13 ` Will Deacon
2015-01-07 17:52 ` Mitchel Humpherys
2015-01-07 18:04 ` Will Deacon
2015-01-07 18:35 ` Mitchel Humpherys
2015-01-07 18:53 ` Will Deacon
2015-01-08 20:58 ` Rob Herring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vnkw61cjebbq.fsf@mitchelh-linux.qualcomm.com \
--to=mitchelh@codeaurora$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox