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

Hi Yureka,

On Mon, Jul 27, 2026 at 10:49:57AM +0200, Yureka Lilian wrote:
> 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.
> 
> 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.

I think nohlt will break the PSCI cpuidle proposal here:

https://lore.kernel.org/all/[email protected]/

> 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?

I keep changing my mind about this patch :/

What do you think about a funny sort of hybrid approach where:

  * We have idle=, but it really only affects the idle loop
  * We have a cpu_errata entry to detect (based on the MIDR) this CPU
    and then avoid patching in the WFIT instructions (i.e. don't detect
    the ARM64_HAS_WFXT capability).

I think that would solve the case for you, as well as giving others finer
grained control over the idle implementation and adding the infrastructure
we need to handle a CPU with broken wfit.

Will