From: Robin Murphy <robin.murphy@arm.com>
To: "Ivan T. Ivanov" <iivanov@suse.de>, Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
Shawn Guo <shawnguo@kernel.org>,
Dong Aisheng <aisheng.dong@nxp.com>,
linux-arm-kernel@lists.infradead.org, linux-imx@nxp.com
Subject: Re: [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue
Date: Thu, 20 Apr 2023 18:02:24 +0100 [thread overview]
Message-ID: <f2e964ef-4358-6a74-1f94-52cc1df3b1cb@arm.com> (raw)
In-Reply-To: <rbzinid5ogfwd6mzgx3qey3xy4haok5jx3ghyvzzmteki2kxnn@224msirsgukg>
On 18/04/2023 5:54 pm, Ivan T. Ivanov wrote:
> On 04-17 16:35, Mark Rutland wrote:
>
>>>>> @@ -835,7 +835,8 @@ static inline bool system_supports_bti(void)
>>>>> static inline bool system_supports_tlb_range(void)
>>>>> {
>>>>> return IS_ENABLED(CONFIG_ARM64_TLB_RANGE) &&
>>>>> - cpus_have_const_cap(ARM64_HAS_TLB_RANGE);
>>>>> + cpus_have_const_cap(ARM64_HAS_TLB_RANGE) &&
>>>>> + !cpus_have_const_cap(ARM64_WORKAROUND_NXP_ERR050104);
>>>>> }
>>>>
>>>> It'd be better to handle this in the detection of ARM64_HAS_TLB_RANGE, as we
>>>> have for CNP where has_useable_cnp() checks for ARM64_WORKAROUND_NVIDIA_CARMEL_CNP.
>>>
>>> It's not needed in either place, since neither Cortex-A53 or Cortex-A72
>>> support FEAT_TLBIRANGE, so this could never be true on affected platforms
>>> anyway.
>>
>> Ah, even better -- we can just drop it.
>
> Ok.
>
>>
>>> Tangentially, I understand this platform has an SMMU[1], so I'd say it would
>>> also be worth checking what SMMU_IDR0.BTM reports. With any luck it might be
>>> 0, but if it's 1 then strictly it would want to be overridden as part of a
>>> complete workaround as well. That wouldn't be a practical issue right now,
>>> not least since the current Linux driver doesn't even use BTM, but it's
>>> something which could need to be borne in mind in future.
>>
>> Absolutely.
>
> I don't completely understand implication of this, but for SMMU inside
> iMX8QM report that "Broadcast TLB maintenance is supported"
Aha, in fact it seems we might be OK. I double-checked and it turns out
that thanks to an MMU-500 erratum, we can't necessarily believe IDR0.BTM
anyway. Thus anyone who adds DVM support to an SMMUv2 driver is going to
need to implement some new firmware property or platform detection, at
which point the chances of it getting silently enabled for i.MX8 (if
indeed BTM isn't already a lie there) seem sufficiently remote that I'd
feel fairly comfortable not doing anything explicit for now.
(The case of concern wouldn't be so much the expected use of DVM to
share CPU pagetables with the SMMU, which in principle the regular CPU
workaround should already cover, but more anyone trying to play clever
tricks using DVM and CPU instructions to maintain private SMMU contexts
rather than register-based commands.)
Thanks,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-04-20 17:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-12 12:55 [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 Cache coherency issue Ivan T. Ivanov
2023-04-13 11:19 ` Mark Rutland
2023-04-14 11:36 ` Robin Murphy
2023-04-17 15:35 ` Mark Rutland
2023-04-18 16:54 ` Ivan T. Ivanov
2023-04-20 17:02 ` Robin Murphy [this message]
2023-04-18 13:25 ` Ivan T. Ivanov
2023-04-17 3:07 ` Peng Fan
2023-04-17 14:48 ` Frank Li
-- strict thread matches above, loose matches on Subject: below --
2026-07-29 3:28 [PATCH] arm64: errata: Add NXP iMX8QM workaround for A53 cache " Peng Fan (OSS)
2026-07-29 3:42 ` sashiko-bot
2026-07-29 9:50 ` Mark Rutland
2026-07-29 12:52 ` Peng Fan
2026-07-29 17:09 ` Frank Li
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=f2e964ef-4358-6a74-1f94-52cc1df3b1cb@arm.com \
--to=robin.murphy@arm.com \
--cc=aisheng.dong@nxp.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=iivanov@suse.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=mark.rutland@arm.com \
--cc=shawnguo@kernel.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.