[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7CDF8A66-14E4-47E7-A6D7-6CF0C6C62CC8@hpe.com>
Date: Wed, 23 Mar 2022 01:01:39 +0000
From: "Verdun, Jean-Marie" <verdun@....com>
To: Arnd Bergmann <arnd@...db.de>
CC: "Hawkins, Nick" <nick.hawkins@....com>,
Russell King <linux@...linux.org.uk>,
Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...id.au>,
Olof Johansson <olof@...om.net>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] [v1] arch: arm: configs: gxp_defconfig
Hi,
> Unfortunately that is not possible at the moment, as this is a 'bool'
> option rather than
> a 'tristate'. I don't know if it might be possible to change that, but
> this is probably
> done for a good reason.
You are right.
> I think it should be possible to detect this erratum at runtime, especially now
> that we understand what the hardware issue is.
> We should probably add a CONFIG_ARM_ERRATA_764319 Kconfig
> option that controls whether a workaround is enabled or not. One
> way that I think this can be handled is to have a custom inline asm
> for the trapping register CP14 accesses, using a __ex_table fixup,
> similar to what we do for trapping user space memory access.
I like this idea. Let me try to implement it and propose something.
Thanks for the feedbacks.
> Another option would be to detect affected systems by the CPU
> revision register or from some DT properties.
ARM might be able to provide that. Let me ask them
vejmarie
Powered by blists - more mailing lists