On Fri, 4 Oct 2019 at 17:24, Arnd Bergmann <a...@arndb.de> wrote: > > On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel <ard.biesheu...@linaro.org> > wrote: > > > > How is it relevant whether the boot CPU is A5 or A7? These are bL > > little cores that only implement NEON for feature parity with their bl > > big counterparts, but CPU intensive tasks are scheduled on big cores, > > where NEON performance is much better than scalar. > > > > If we need a policy for this in the kernel, I'd prefer it to be one at > > the arch/arm level where we disable kernel mode NEON entirely, either > > via a command line option, or via a policy based on the the types of > > all CPUs. > > I don't think there was ever a b.L system with an A5, and most of the > A7+A15 systems did not age well, being high-end phone chips in > 2014 that quickly got replaced with A53 parts and that no longer > get kernel upgrades. > > The only chips I can think of that one might still care about here > are Exynos 542x (Chromebook 2 EOL 2019, Odroid XU4 ) and > Allwinner A80 (Cubieboard 4). > > Just checking for Cortex-A7 being the boot CPU is probably > sufficient, that takes care of the common case of all the > A7-only embedded chips that people definitely are going to care > about for a long time. >
But do you agree that disabling kernel mode NEON altogether for these systems is probably more sensible than testing for CPU part IDs in an arbitrary crypto driver?
