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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 4 Oct 2019 at 17:24, Arnd Bergmann <arnd@xxxxxxxx> wrote:
>
> On Fri, Oct 4, 2019 at 4:23 PM Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> 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?



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux