Several actions are not mitigations for a single erratum, but for
multiple errata. However, printing a line like
CPU features: detected: ARM errata 1165522, 1319367, 1530923
may give the false impression that all three listed errata have been
detected. This can confuse the user, who may think his Cortex-A57 is
suddenly affected by Cortex-A76 and Cortex-A55 errata.
Add "or" to all descriptions for mitigations for multiple errata, to
make it clear that only one or more of the errata printed are
applicable, and not necessarily all of them.
Signed-off-by: Geert Uytterhoeven <[email protected]>
---
arch/arm64/kernel/cpu_errata.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 95006a7910262288..b0ce6bf14f6a92c8 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -778,7 +778,7 @@ static const struct midr_range erratum_speculative_at_list[] = {
const struct arm64_cpu_capabilities arm64_errata[] = {
#ifdef CONFIG_ARM64_WORKAROUND_CLEAN_CACHE
{
- .desc = "ARM errata 826319, 827319, 824069, 819472",
+ .desc = "ARM errata 826319, 827319, 824069, or 819472",
.capability = ARM64_WORKAROUND_CLEAN_CACHE,
ERRATA_MIDR_RANGE_LIST(workaround_clean_cache),
.cpu_enable = cpu_enable_cache_maint_trap,
@@ -860,7 +860,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
#endif
#ifdef CONFIG_ARM64_WORKAROUND_REPEAT_TLBI
{
- .desc = "Qualcomm erratum 1009, ARM erratum 1286807",
+ .desc = "Qualcomm erratum 1009, or ARM erratum 1286807",
.capability = ARM64_WORKAROUND_REPEAT_TLBI,
.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
.matches = cpucap_multi_entry_cap_matches,
@@ -903,7 +903,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
#endif
#ifdef CONFIG_ARM64_WORKAROUND_SPECULATIVE_AT
{
- .desc = "ARM errata 1165522, 1319367, 1530923",
+ .desc = "ARM errata 1165522, 1319367, or 1530923",
.capability = ARM64_WORKAROUND_SPECULATIVE_AT,
ERRATA_MIDR_RANGE_LIST(erratum_speculative_at_list),
},
--
2.17.1
On Tue, May 12, 2020 at 02:42:38PM +0200, Geert Uytterhoeven wrote:
> Several actions are not mitigations for a single erratum, but for
> multiple errata. However, printing a line like
>
> CPU features: detected: ARM errata 1165522, 1319367, 1530923
>
> may give the false impression that all three listed errata have been
> detected. This can confuse the user, who may think his Cortex-A57 is
> suddenly affected by Cortex-A76 and Cortex-A55 errata.
>
> Add "or" to all descriptions for mitigations for multiple errata, to
> make it clear that only one or more of the errata printed are
> applicable, and not necessarily all of them.
>
> Signed-off-by: Geert Uytterhoeven <[email protected]>
> ---
> arch/arm64/kernel/cpu_errata.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
This seems to conflict with the other patch you sent to reorder the entries.
Please can you send another version, based on the arm64 for-next/kconfig
branch?
Will
Hi Will,
On Tue, May 12, 2020 at 4:12 PM Will Deacon <[email protected]> wrote:
> On Tue, May 12, 2020 at 02:42:38PM +0200, Geert Uytterhoeven wrote:
> > Several actions are not mitigations for a single erratum, but for
> > multiple errata. However, printing a line like
> >
> > CPU features: detected: ARM errata 1165522, 1319367, 1530923
> >
> > may give the false impression that all three listed errata have been
> > detected. This can confuse the user, who may think his Cortex-A57 is
> > suddenly affected by Cortex-A76 and Cortex-A55 errata.
> >
> > Add "or" to all descriptions for mitigations for multiple errata, to
> > make it clear that only one or more of the errata printed are
> > applicable, and not necessarily all of them.
> >
> > Signed-off-by: Geert Uytterhoeven <[email protected]>
> > ---
> > arch/arm64/kernel/cpu_errata.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
>
> This seems to conflict with the other patch you sent to reorder the entries.
My reordering applied to the Kconfig file.
This patch applies fine to arm64/for-next/core.
> Please can you send another version, based on the arm64 for-next/kconfig
> branch?
Then it will conflict with commit 02ab1f5018c3ad0b ("arm64: Unify
WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}") from for-next/kvm/errata?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
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
On Tue, May 12, 2020 at 04:38:19PM +0200, Geert Uytterhoeven wrote:
> On Tue, May 12, 2020 at 4:12 PM Will Deacon <[email protected]> wrote:
> > On Tue, May 12, 2020 at 02:42:38PM +0200, Geert Uytterhoeven wrote:
> > > Several actions are not mitigations for a single erratum, but for
> > > multiple errata. However, printing a line like
> > >
> > > CPU features: detected: ARM errata 1165522, 1319367, 1530923
> > >
> > > may give the false impression that all three listed errata have been
> > > detected. This can confuse the user, who may think his Cortex-A57 is
> > > suddenly affected by Cortex-A76 and Cortex-A55 errata.
> > >
> > > Add "or" to all descriptions for mitigations for multiple errata, to
> > > make it clear that only one or more of the errata printed are
> > > applicable, and not necessarily all of them.
> > >
> > > Signed-off-by: Geert Uytterhoeven <[email protected]>
> > > ---
> > > arch/arm64/kernel/cpu_errata.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > This seems to conflict with the other patch you sent to reorder the entries.
>
> My reordering applied to the Kconfig file.
Sorry, you're right. Your patch didn't apply on top of that, so I wrongly
assumed that it was the culprit.
> > Please can you send another version, based on the arm64 for-next/kconfig
> > branch?
>
> Then it will conflict with commit 02ab1f5018c3ad0b ("arm64: Unify
> WORKAROUND_SPECULATIVE_AT_{NVHE,VHE}") from for-next/kvm/errata?
Ah, that's ok. I recreate for-next/core so I have flexibility in dropping
branches if they cause problems. Please can you send a version against
for-next/kconfig, and I'll handle the conflict now that you've pointed it
out/
Cheers,
Will