[PATCH v1 1/3] arm64/sve: Split _sve_flush macro into separate Z, P and FFR flushes

[Dave P Martin]

On Mon, May 10, 2021 at 01:23:46PM +0100, Mark Brown wrote:
> Trivial refactoring to support further work, no change to generated code.
> 
> Signed-off-by: Mark Brown <broonie at kernel.org>
> ---
>  arch/arm64/include/asm/fpsimdmacros.h | 6 +++++-
>  arch/arm64/kernel/entry-fpsimd.S      | 4 +++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/fpsimdmacros.h b/arch/arm64/include/asm/fpsimdmacros.h
> index a2563992d2dc..3b6b2ed2e550 100644
> --- a/arch/arm64/include/asm/fpsimdmacros.h
> +++ b/arch/arm64/include/asm/fpsimdmacros.h
> @@ -213,9 +213,13 @@
>  	mov	v\nz\().16b, v\nz\().16b
>  .endm
>  
> -.macro sve_flush
> +.macro sve_flush_z
>   _for n, 0, 31, _sve_flush_z	\n
> +.endm
> +.macro sve_flush_p
>   _for n, 0, 15, _sve_pfalse	\n
> +.endm
> +.macro sve_flush_ffr
>  		_sve_wrffr	0

This doesn't flush the FFR as advertised, but writes whatever happens to
be in P0 to the FFR.

Thinking about it, is there ever a situation when we would want to flush
the P-regs and not the FFR (or vice-versa)?  I can't see where we would
want to do that myself.

If not, can we keep these combined?  We could either keep the name
sve_flush_p (since the FFR is a predicate register, if a weird kind of
one), or go with something more descriptive such as sve_flush_p_and_ffr.

(p_ffr would be terser but might be confused with things the existing
"pffr" naming for the pointer to the FFR in the regs backing storage.)

[...]

Cheers
---Dave