On Tue, Nov 2, 2021 at 9:11 AM Arnd Bergmann <arnd@xxxxxxxx> wrote: > > On Tue, Nov 2, 2021 at 8:31 AM Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > On Fri, Oct 29, 2021 at 8:36 AM Joel Stanley <joel@xxxxxxxxx> wrote: > > > On Thu, 28 Oct 2021 at 14:57, Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > > On Thu, Oct 28, 2021 at 4:19 PM Lukas Bulwahn <lukas.bulwahn@xxxxxxxxx> wrote: > > > https://lore.kernel.org/all/6be32e0b5b454ed7b609317266a8e798@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ > > > > > > It looks like it's the same workaround as ARM_ERRATA_742230, which the > > > kernel does implement. > > > > > > It would be good to hear from the Nuvoton people, or an Arm person. > > > > I will happily update the patch to select ARM_ERRATA_742230 instead of > > the dead non-existing ARM_ERRATA_794072. > > > > In contrast to the current patch that basically only cleans up "dead > > config" and has no effective functional change, the new patch would > > change the behaviour. I cannot test this patch (beyond some basic > > compile test) on the hardware; so, we certainly need someone to have > > that hardware, knows how to test it or confirm otherwise that we > > should select the ARM_ERRATA_742230 fix for this hardware. > > > > The current patch should be subsumed by the new patch; the submission > > of the new patch is deferred until that person shows up. Let's see. > > I'd prefer to leave the broken Kconfig symbol in place as a reminder until it > gets fixed properly then. > Agree, this patch here should not be integrated. I rather expect that Avi or others at Nuvoton will provide a proper patch to act appropriately for the ARM_ERRATA_794072, or after proper analysis can determine that there is no change in the kernel required. Lukas
