[PATCH 03/11] doc: cmd: document the led shell command

[Quentin Schulz]

Hi all,

On 11/13/25 11:58 AM, Quentin Schulz wrote:
> Hi all,
> 
> On 11/12/25 6:48 PM, Quentin Schulz wrote:
>> From: Quentin Schulz <quentin.schulz at cherry.de>
[...]

> 
> It seems like there's another led shell command that you can build with 
> CONFIG_LED_STATUS_CMD=y that uses the legacy LED API... Should it be 
> mentioned/have its own documentation page?
> 
> Maybe we should spend time porting the 5 defconfigs that make use of 
> this legacy API to the new one and entirely retire the legacy LED API. 
> However, there seems to be some discrepancies between the LED_BOOT 
> behavior and that of CONFIG_LED_STATUS_BOOT. The former blinks for a 
> brief period of time and then is solid on once reaching U-Boot's main 
> loop. The latter is blinking sometime after relocation and then turned 
> off on first BOOTP packet.
> 
> Out of the 5 defconfigs, 3 are using GPIO LEDs with 
> CONFIG_LED_STATUS_GPIO=y so it shouldn't be too difficult to migrate to 
> the new API just to get the LEDs working (I am not talking about keeping 
> the same behavior). The other two are configs/eb_cpu5282_defconfig and 
> configs/eb_cpu5282_internal_defconfig which I assume are for the same 
> product, but it has not seen actual updates (aside from tree-wide 
> migrations) in the last 13 years. From what I could tell, this is also 
> GPIO leds, but controlled by writing directly to the GPIO registers 
> instead of using a driver. Maybe we can issue a deprecation notice and 
> tell the maintainers/users of that board they have X releases to migrate 
> else it gets support for the LEDs removed.
> For the other boards, we probably need to check how to use the DT for 
> the LEDs that are currently configured via the legacy API.
> 
> This is at the end of my todo list though.
> 

Multiple series sent for tackling that:
- 
https://lore.kernel.org/u-boot/20251112-led-old-dt-v1-0-2892d49517db@cherry.de/
- 
https://lore.kernel.org/u-boot/20251114162417.4054006-1-patrice.chotard@foss.st.com/
- 
https://lore.kernel.org/u-boot/20251119-legacy-led-unused-code-v1-0-bc0ae1235baa@cherry.de/
- 
https://lore.kernel.org/all/20251119-corvus-led-red-green-v1-0-ce86b8d59dfc@cherry.de/
- 
https://lore.kernel.org/all/20251119-led-legacy-vining-v1-1-6107439085a0@cherry.de/
- 
https://lore.kernel.org/all/20251119-bus-led-removal-v1-1-340218264e59@cherry.de/
- 
https://lore.kernel.org/u-boot/20251120-legacy-led-sunxi-v1-1-c4c1422fd242@cherry.de/
- 
https://lore.kernel.org/u-boot/20251120-legacy-led-removal-v1-0-369d44338358@cherry.de/

I think this series here is not blocked by those. (I'm commenting here 
because it is not uncommon for series with open questions to stay on the 
list without review and never merged: so this open question is now 
answered I believe).

Cheers,
Quentin