[PATCH v2] arm64: dts: rockchip: Turn all LEDs on at boot for Radxa boards

[FUKAUMI Naoki]

Hi Quentin,

On 11/12/25 03:32, Quentin Schulz wrote:
> Hi all,
> 
> On 11/11/25 5:14 PM, Dragan Simic wrote:
>> Hello all,
>>
>> (+ Quentin)
>>
>> On Tuesday, November 11, 2025 16:32 CET, FUKAUMI Naoki 
>> <naoki at radxa.com> wrote:
>>> On 11/11/25 23:46, Dragan Simic wrote:
>>>> On Tuesday, November 11, 2025 14:07 CET, "Diederik de Haas" 
>>>> <diederik at cknow-tech.com> wrote:
>>>>> On Tue Nov 11, 2025 at 6:41 AM CET, FUKAUMI Naoki wrote:
>>>>>> Radxa's boards turn all LEDs on at boot(loader), but some boards 
>>>>>> don't
>>>>>> have `default-state` property in Linux kernel tree but have it in
>>>>>> U-Boot tree instead[1].
>>>>>>
>>>>>> This patch adds `default-state = "on"` for (almost) all LEDs (with a
>>>>>> few exceptions which should be "off" such as RGB LEDs on E25 and LAN/
>>>>>> WAN LEDs on E20C/E52C).
>>>>>
>>>>> I'm missing the *why* these changes would be an improvement.
>>>>>
>>>>> Personally, for both 'heartbeat' and 'netdev' triggers, I want them to
>>>>> be off by default and once it gets a 'heartbeat' or a 'netdev' 
>>>>> trigger,
>>>>> THEN I want the LED to be on/blinking.
>>>>
>>>> That's a good question for Naoki.  My own preference would also
>>>> be to have the device's power LED turned on by U-Boot as quickly
>>>> as possible after supplying power to the board or turning it on
>>>> by pressing the power button.  I'm actually not a big fan of
>>>> having all the LEDs shining for a couple of seconds or so, which
>>>> may actually look like some error condition to me.
>>>>
>>>> Having all that in mind, I may suggest that just the U-Boot's
>>>> behavior is changed to turn the power LEDs on only.
>>>
>>> I can't quite explain it, but...
>>>
>>> - 1st (Power) LED
>>>
>>> The 1st (power) LED turns on automatically/immediately without software
>>> intervention. (On some boards, this LED cannot be controlled by software
>>> at all.)
>>>
>>> In DTS, this should be described using `default-state = "on"`. The use
>>> of the Linux-specific property `linux,default-trigger = "default-on"` is
>>> unsuitable for non-Linux environments.
>>>
>>> - 2nd (Heartbeat) LED
>>>
>>> The 2nd (heartbeat) LED can be controlled by software. It should be lit
>>> up as quickly as possible to indicate that the very first software
>>> (e.g., the bootloader) is running.
>>>
>>> On Linux, usually this is used as `linux,default-trigger = "heartbeat"`.
>>> It indicates that kernel is running (regardless of the `default-state`
>>> setting), and its behavior can be modified in user space.
>>
>> As discussed already in the #linux-rockchip IRC channel, [1] perhaps
>> the best option would be to have the power LEDs turned on as quickly
>> upon powering on the board as possible, and to have U-Boot pulsate
>> the heartbeat LEDs using the LED_BOOT feature.  In such a scenario,
>> no other LEDs would be turned on early, and the LED-related DT parts
>> specific to U-Boot would be migrated to the kernel DTs.
>>
>> [1] https://libera.catirclogs.org/linux-rockchip/2025-11-11#38997824;
>>
> 
> The LED_BOOT feature (guarded by the Kconfig symbol of the same name) in 
> U-Boot only applies if /options/u-boot/boot-led property is set.

For the default state of the heartbeat LED, I'm thinking of using 
LED_BOOT (/options/u-boot/boot-led), but I'm concerned that this is 
U-Boot-specific.

> If the driver for the LED (typically a GPIO LED controller I guess, so 
> LED_GPIO symbol) is compiled in, then, as far as I could tell, the Boot 
> LED will be turned on right before entering the main loop of U-Boot.
> 
> If LED_BLINK (if HW blinking is supported) or LED_SW_BLINK is enabled, 
> the Boot LED will be blinking some time after relocation but still 
> turned on soon after (if it reaches that part of the code). This means 
> it'll be on before the kernel starts.
> 
> I'm not sure there's a way to hook something *after* we've entered U- 
> Boot main-loop (read "call led_boot_blink() from some board file"), 
> aside from calling `led <led-name> blink <period>` from U-Boot CLI.
> 
> I'm a bit bummed by this behavior, I would have preferred the ability to 
> have the Boot LED blink until the kernel starts. I could then have a 
> different period for U-Boot (50% duty cycle at 250ms period by default) 
> and for the kernel. Of course, if it's SW blinking, once exiting U-Boot 
> it won't blink anymore until the kernel takes over, but that's also a 
> nice information to have. Anyway, I'm not sure this is actually possible 
> with the LED_BOOT feature though one should be able to do this by 
> specifying the label of an LED node to fetch from DT and then calling 
> led_set_period(dev, period_ms); followed by led_set_state(dev, 
> LEDST_BLINK); in a board file, but this is also not so nice as it then 
> also requires some C board-specific code in U-Boot.
> 
> In U-Boot, only LEDs which have a "default-state" properties will be 
> auto-configured, otherwise one needs to control them manually (e.g. via 
> the `led` CLI command).

As you know, default "default-state" is "off".
  https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/leds/common.yaml?h=v6.17#n74

As far as I understand, there should not be any workarounds for specific 
implementations.
  https://lore.kernel.org/linux-rockchip/3389401.44csPzL39Z@phil/

So removing `default-state = "off"` is acceptable, right?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> If one wants to detect via an LED the current boot stage (U-Boot 
> reached, kernel started), then we need to NOT use LED_BOOT feature and 
> have U-Boot set the "boot" LED the opposite state than the default HW 
> state, i.e. if the LED is on without any running SW (power applied to 
> the device, empty boot media), then U-Boot should set it to off. Then 
> the kernel simply needs to start the heartbeat mode whenever ready. If 
> the default HW state is off, then U-Boot should set it on. I haven't 
> looked into the kernel side of things, but there could be a window 
> during which default-state property is applied before the heartbeat is 
> actually started.
> 
> The logic exposed in the previous paragraph should provide visual cues 
> on the current boot stage.
> 
> Note that LEDs with linux,default-trigger = "pattern" (with default- 
> state property) will be blinking once auto-configured in U-Boot as well 
> according to my reading of the led-uclass.c.
> 
> Hope this helps.
> 
> Cheers,
> Quentin
>