Re: [PATCH] mips: cps: Assemble jr.hb with an R2 ISA level

[Maciej W. Rozycki]

On Thu, 7 May 2026, Rosen Penev wrote:

> diff --git a/arch/mips/kernel/cps-vec.S b/arch/mips/kernel/cps-vec.S
> index 2ae7034a3d5c..70413c816eb0 100644
> --- a/arch/mips/kernel/cps-vec.S
> +++ b/arch/mips/kernel/cps-vec.S
> @@ -373,8 +373,11 @@ LEAF(mips_cps_boot_vpes)
>  	.set	pop
>  
>  	PTR_LA	t1, 1f
> +	.set	push
> +	.set	MIPS_ISA_LEVEL_RAW
>  	jr.hb	t1
>  	 nop
> +	.set	pop
>  1:	mfc0	t1, CP0_MVPCONTROL
>  	ori	t1, t1, MVPCONTROL_VPC
>  	mtc0	t1, CP0_MVPCONTROL
> @@ -487,8 +490,11 @@ LEAF(mips_cps_boot_vpes)
>  	li	t0, TCHALT_H
>  	mtc0	t0, CP0_TCHALT
>  	PTR_LA	t0, 1f
> +	.set	push
> +	.set	MIPS_ISA_LEVEL_RAW
>  1:	jr.hb	t0
>  	 nop
> +	.set	pop
>  
>  2:
>  

 This seems exceedingly pedantic to me at the cost of cluttering code with 
these .set push/pop blocks.  Why not simply wrap the whole code block down 
to the end of the CONFIG_MIPS_MT_SMP conditional instead, analogously to 
how mips_cps_core_init() has been arranged?  The presence of MT implies R2 
after all.

 Ah, I can see we have MIPS_ISA_LEVEL_RAW always hardcoded to a 64-bit one 
and commit 8dbc1864b74f ("MIPS: CPS: Fix MIPS_ISA_LEVEL_RAW fallout") 
reporting the MOVE macro getting expanded to a 64-bit DADDU instruction on 
64-bit ISAs, which is obviously not incorrect (you get what you asked 
for), though also problematic in this use case.

 This is actually no longer relevant however, as this was changed back in 
2025 with binutils commit 40fc1451c63d ("[MIPS] Map 'move' to 'or'.") 
targetting version 2.26, while our requirement nowadays is 2.30, according 
to Documentation/process/changes.rst.  It is a fairly recent requirement 
though, from Linux 6.16 only, and the previous one was 2.25, so backports 
would be affected and it might be too early to rely on for a bug fix.

 Still my guts' feeling is we should define MIPS_ISA_LEVEL_RAW and the 
other such macros to a 32-bit or 64-bit ISA according to the machine word 
size of the CPU/ISA chosen for the whole kernel build.  This would enable 
the cleanup I suggested at the top with no reservation and remove the risk 
of GAS choosing to produce 64-bit instructions where a 32-bit CPU/ISA has 
been chosen in the configuration.

 You are welcome to do that, however as it stands your patch is not 
incorrect and fixes a real problem, so:

Reviewed-by: Maciej W. Rozycki <macro@xxxxxxxxxxx>

  Maciej