[PATCH] leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts

[PATCH] leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts

[Paul Sherman]

ledtrig_cpu_init() uses cpuhp_setup_state() which invokes the startup
callback on every already-online CPU at registration time. On systems
with large CPU counts this serializes callbacks across all online CPUs,
causing boot delays proportional to the number of CPUs.

On a 64-hart RISC-V system this caused ledtrig_cpu_init() to consume
~250 seconds at boot. The same pathology affects any system using
cpuhp_setup_state() where one CPU is slow to acknowledge.

Use cpuhp_setup_state_nocalls() instead, which skips callbacks for
already-online CPUs at registration time. The trigger operates correctly
for future hotplug events regardless.

Tested-on: Milk-V Pioneer (SG2042, 64-hart RISC-V)
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Paul Sherman <shermanpauldylan@gmail.com>
---
 drivers/leds/trigger/ledtrig-cpu.c | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/leds/trigger/ledtrig-cpu.c b/drivers/leds/trigger/ledtrig-cpu.c
index 679323c2ccda0..ce75d5f54684c 100644
--- a/drivers/leds/trigger/ledtrig-cpu.c
+++ b/drivers/leds/trigger/ledtrig-cpu.c
@@ -163,7 +163,15 @@ static int __init ledtrig_cpu_init(void)
 
 	register_syscore(&ledtrig_cpu_syscore);
 
-	ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "leds/trigger:starting",
+	/*
+	 * Use cpuhp_setup_state_nocalls() to avoid invoking ledtrig_online_cpu()
+	 * on every already-online CPU at registration time. On systems with large
+	 * CPU counts (e.g. 64-hart RISC-V) cpuhp_setup_state() would serialize
+	 * callbacks across all online CPUs, causing multi-hundred-second delays
+	 * during boot. The trigger operates correctly for future hotplug events
+	 * regardless.
+ 	 */
+	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "leds/trigger:starting",
 				ledtrig_online_cpu, ledtrig_prepare_down_cpu);
 	if (ret < 0)
 		pr_err("CPU hotplug notifier for ledtrig-cpu could not be registered: %d\n",
-- 
2.53.0

Re: [PATCH] leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Skipping hotplug startup callbacks during initialization leaves the CPU LED triggers in an incorrect inactive state for all already-online CPUs.
- [Low] The commit message description is not capitalized, violating LED subsystem conventions.
--

--- Patch [1]: [PATCH] leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts ---
commit 2aa3e021f1cce38c0cc7487063d486ab550d6162
Author: Paul Sherman <shermanpauldylan@gmail.com>

leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts

This commit changes ledtrig_cpu_init() to use cpuhp_setup_state_nocalls()
instead of cpuhp_setup_state(). This avoids invoking the hotplug callbacks for
already-online CPUs at registration time to prevent boot delays on systems
with large CPU counts.

> leds: trigger: cpu: use cpuhp_setup_state_nocalls() for large CPU counts

[Severity: Low]
This isn't a bug, but the commit message description starts with a lowercase
letter. The LED subsystem guidelines mandate: "Always capitalize the description
after the subsystem prefix for MFD, LED, and Backlight subsystems."

> diff --git a/drivers/leds/trigger/ledtrig-cpu.c b/drivers/leds/trigger/ledtrig-cpu.c
> index 679323c2ccda0..ce75d5f54684c 100644
> --- a/drivers/leds/trigger/ledtrig-cpu.c
> +++ b/drivers/leds/trigger/ledtrig-cpu.c
> @@ -163,7 +163,15 @@ static int __init ledtrig_cpu_init(void)
>  
>  	register_syscore(&ledtrig_cpu_syscore);
>  
> -	ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "leds/trigger:starting",
> +	/*
> +	 * Use cpuhp_setup_state_nocalls() to avoid invoking ledtrig_online_cpu()
> +	 * on every already-online CPU at registration time. On systems with large
> +	 * CPU counts (e.g. 64-hart RISC-V) cpuhp_setup_state() would serialize
> +	 * callbacks across all online CPUs, causing multi-hundred-second delays
> +	 * during boot. The trigger operates correctly for future hotplug events
> +	 * regardless.
> + 	 */
> +	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "leds/trigger:starting",
> +				ledtrig_online_cpu, ledtrig_prepare_down_cpu);

[Severity: High]
Does skipping the hotplug startup callbacks during initialization leave the CPU
LED triggers in an incorrect inactive state for all already-online CPUs?

By replacing cpuhp_setup_state() with cpuhp_setup_state_nocalls(), the driver
skips invoking ledtrig_online_cpu() for already-online CPUs during registration.
Because the cpu_trig per-CPU variables and num_active_cpus are zero-initialized,
they remain in the inactive state.

On architectures that do not emit ledtrig_cpu events during idle transitions,
these CPUs will never call ledtrig_cpu(CPU_LED_START), so their LEDs will never
turn on unless they undergo a hotplug offline/online cycle.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727221607.5216-1-shermanpauldylan@gmail.com?part=1