[RFC PATCH v3 0/4] Simplify kernel-mode NEON

[ard.biesheuvel@linaro.org (Ard Biesheuvel)]

On 30 May 2017 at 18:02, Dave Martin <Dave.Martin@arm.com> wrote:
> On Thu, May 25, 2017 at 07:24:57PM +0100, Dave Martin wrote:
>> This series aims to simplify kernel-mode NEON.
>
> Hi Ard, do you have any further comments on this series?
>
> I'd like to have it finalised as far as possible (modulo minor tweaks
> and bugfixes) so that I can port the SVE patches on top of it.
>
> Also, how do you think we should handle merging of this change?  There's
> a flag-day issue here, since the kernel_mode_neon() API is being changed
> in an incompatible way.
>

I think the patches look fine now. The best way to merge these imo is
to start with the changes in the clients, i.e., add an arm64 specific
asm/simd.h that defines may_use_simd() as { return true; }, update all
the crypto code with the fallbacks, and put this stuff on top of that.
That way, there is a small window where the 'hint' is interpreted
differently in the sha256 code, but apart from that, we should be
bisection proof without a flag day AFAICT.

BTW I got my ZD1211 working on my MacchiatioBin board. The performance
is terrible, but that should not matter: if I can saturate a CPU doing
NEON from userland and/or kernel process context, the softirq
interruptions by the mac80211 code should exercise the updated code
paths. I haven't tried that yet: let me get the code changes out
today, so you can put your stuff on top. Then we can give it a good
spin.

-- 
Ard.