Re: [PATCH v2 04/20] crypto: arm/chacha - expose ARM ChaCha routine as library function

On Fri, 4 Oct 2019 at 17:24, Arnd Bergmann [off-list ref] wrote:

On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel [off-list ref] wrote:

quoted

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?