[RFC PATCH] arm64: neon: Remove support for nested or hardirq kernel-mode NEON

[Dave.Martin@arm.com (Dave Martin)]

On Fri, May 19, 2017 at 02:56:20PM +0100, Ard Biesheuvel wrote:
> On 19 May 2017 at 14:46, Dave Martin <Dave.Martin@arm.com> wrote:

[...]

> > OK -- when do you expect your kernel-mode-neon series (or relevant bits
> > of it) to be merged?  With that in place, I can carry this patch in
> > the SVE series, or propose it to be merged separately.
> >
> 
> There is no reason for any of this to go through the crypto tree or
> mailing list. So for now, let's go with kernel_neon_allowed(), and I

Arg, I just changed it back...

What are the intended meanings of

	!kernel_neon_allowed() && !may_use_simd()
	!kernel_neon_allowed() && may_use_simd()
	kernel_neon_allowed() && !may_use_simd()
	kernel_neon_allowed() && may_use_simd()

?

I'm still a little confused here...

> can respin my patches against that and ask Catalin or Will to queue it
> for v4.13. I will be travelling next week, though, so no ETA yet.

OK.  It they get queued for v4.13 that's fine for me.

> > I'd also expect CONFIG_KERNEL_NEON_MODE_NEON_FALLBACK and
> > kernel_neon_need_fallback() to be folded in (=y and true respectively),
> > since removal of nesting support will mean that fallback code is always
> > needed for clients that may run elsewhere than in task context.
> 
> Yes. So we no longer have to reason about whether a fallback should be
> provided, which is an improvement imo.

Agreed, it seems simpler this way.

Cheers
---Dave