[PATCH 12/37] arm64: Use a positive cpucap for FP/SIMD

[Mark Brown]

On Tue, Sep 19, 2023 at 10:28:25AM +0100, Mark Rutland wrote:

> Currently we have a negative cpucap which describes the *absence* of
> FP/SIMD rather than *presence* of FP/SIMD. This largely works, but is
> somewhat awkward relative to other cpucaps that describe the presence of
> a feature, and it would be nicer to have a cpucap which describes the
> presence of FP/SIMD:

This also looks good but feels like it should be more commits but still

Reviewed-by: Mark Brown <broonie at kernel.org>

> +void cpu_enable_fpsimd(const struct arm64_cpu_capabilities *__always_unused p)
> +{
> +	unsigned long enable = CPACR_EL1_FPEN_EL1EN | CPACR_EL1_FPEN_EL0EN;
> +	write_sysreg(read_sysreg(CPACR_EL1) | enable, CPACR_EL1);
> +	isb();
> +}

We should probably just use sysreg_clear_set() but whatever, that's
really in the weeds coding style.

>  void do_fpsimd_acc(unsigned long esr, struct pt_regs *regs)
>  {
> -	/* TODO: implement lazy context saving/restoring */
> -	WARN_ON(1);
> +	/* Even if we chose not to use FPSIMD, the hardware could still trap: */
> +	if (unlikely(!system_supports_fpsimd())) {
> +		force_signal_inject(SIGILL, ILL_ILLOPC, regs->pc, 0);
> +		return;
> +	}
> +
> +	/*
> +	 * When FPSIMD is enabled, we should never take a trap unless something
> +	 * has gone very wrong.
> +	 */
> +	BUG();
>  }

This is a good change but is pretty much orthogonal to the rest of the
commit and wasn't called out in the commit log.  The unlikely() there
also seems concerning - this isn't performance sensitive and the likely
case is a BUG() which I hope is never actually likely.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20230919/0b341a02/attachment.sig>