Thread (11 messages) flat view 11 messages, 3 authors, 2017-05-19
STALE3408d

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

From: Dave.Martin@arm.com (Dave Martin)
Date: 2017-05-19 14:09:47

On Fri, May 19, 2017 at 02:56:20PM +0100, Ard Biesheuvel wrote:
On 19 May 2017 at 14:46, Dave Martin [off-list ref] wrote:
[...]
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help