Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>

[Yureka Lilian <yureka@cyberchaos.dev>]

On 7/22/26 23:43, Will Deacon wrote:
> On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
>> diff --git a/arch/arm64/lib/delay.c b/arch/arm64/lib/delay.c
>> index e278e060e78a..2452990ed37a 100644
>> --- a/arch/arm64/lib/delay.c
>> +++ b/arch/arm64/lib/delay.c
>> @@ -15,6 +15,8 @@
>>   
>>   #include <clocksource/arm_arch_timer.h>
>>   
>> +#include "../kernel/idle.h"
>> +
>>   #define USECS_TO_CYCLES(time_usecs)			\
>>   	xloops_to_cycles((time_usecs) * 0x10C7UL)
>>   
>> @@ -49,7 +51,8 @@ void __delay(unsigned long cycles)
>>   		 * Start with WFIT. If an interrupt makes us resume
>>   		 * early, use a WFET loop to complete the delay.
>>   		 */
>> -		wfit(end);
>> +		if (likely(idle == ARM64_IDLE_WFI))
>> +			wfit(end);
> Rather than scatter the idle implementation check across all users of
> WFI*, why not move this into the macro itself? That way, the callers can
> all stay like they are but the macro behaves as specified.
>
> Will

In practise, I could only find the following uses of WFI / WFIT / wfi() 
/ wfit() in arm64 code: 1) the default idle loop and delay() function; 
arguably the only "real" users 2) parking cores after different kinds of 
unexpected situations / crashes.

Just to confirm, you are suggesting to add the conditionals to 
arch/arm64/include/asm/barrier.h, and have wfi() and wfit() macros not 
actually do WFI / WFIT depending on the value of the idle param?

I'm torn about this: We should maybe first discuss what effect idle= 
should have: Should it prevent WFI running anywhere in the kernel when 
idle=nop, OR is its intended use case to change the default arm64 
implementations for idle and delay, while still allowing other parts of 
the kernel to use WFI (for example, for custom cpuidle implementation)? 
I think the existing nohlt parameter, which disables all idle states, is 
more fitting for the first goal, even though it currently does not 
prevent the wfit in the delay function.

For preventing WFI anywhere, I think alternatives patching based on the 
earlyparam would be the most reliable way to achieve that, and second 
most reliable way is putting the conditional in the wfi() / wfit() macros.

But my assumption is that what we want to achieve is actually closer to 
changing only the default idle implementation, while allowing an idle 
state registered at later point to still do its thing (including using 
WFI for this purpose). And for this (and to be more flexible with other 
idle modes e.g. yield), what I proposed in this patch makes more sense, 
and I'm relatively confident it will fulfill the Apple Silicon use case 
without adding many more scattered checks other than these two.
Does this make sense?


Thanks!

— Yureka