[PATCH 02/23] board: st: Update LED management for stm32mp1

[Quentin Schulz]

Hi Patrice,

On 12/5/25 10:24 AM, Patrice CHOTARD wrote:
> 
> 
> On 12/4/25 16:38, Quentin Schulz wrote:
>> Hi Patrice,
>>
>> On 11/14/25 5:23 PM, Patrice Chotard wrote:
>>> Remove get_led() and setup_led() which became obsolete since
>>> led_boot_on() introduction. led_boot_on() is automatically called
>>> from board_r.c
>>>
>>
>> Yes, but called later than board_init(). If this compromise is fine then it's ok.
>>
>>> Regarding "u-boot,error-led" property can't be used anymore since commit
>>> Since commit 516a13e8db32 ("led: update LED boot/activity to new property implementation")
>>>
>>> Instead get the LED labeled "red:status".
>>
>> Would this work with stm32mp157a-dhcor-avenger96 (led4), stm32mp157c-odyssey (red but not "status" as function?) and stm32mp15xx-dhcom (error but possibly broken since commit 332facce6f5669fc1bb8d150c08cee2ebdae6d2b which removed the led with that label)? Seems like Odissey has LED=y and LED_GPIO=y so it probably worked before this patch? The other two, their defconfigs don't seem to enable LED support (new or legacy) so I guess it never was used anyway?
> 
> Hi Quentin
> 
> Regarding stm32mp157a-dhcor-avenger96, stm32mp157c-odyssey, stm32mp15xx-dhcom, these boards are not
> STMicroelectronics board, so i don't maintain them.
> 

Seems like Marek is handling the DHCOR/DHCOM stuff, and he's in Cc so I 
guess there's a chance he sees this and do something about it.

As for Odyssey, you are listed as maintainer but maybe we could add the 
people who contributed to it?
I see Marcin Sloniewski, Grzegorz Szymaszek and Heesub Shin for the DT. 
According to 69df7ff4b844fb22d02a941d57d8e6c2d6b679dc, you probably 
contacted them and had no feedback. But maybe add in the commit log that 
this is going to break them and hint at how to fix it maybe? For the 
error LED, I guess simply removing the error label and adding the status 
function should be enough? That would change the way to interact with 
the LED though (when using the label for example).

>>
>> I'm also wondering how you get this string... I don't see any label or LED_FUNCTION_STATUS function for the LED devices on ST boards. I'm probably missing on something?
> 
> As indicated in the cover-letter, the LED "red:status" has been added in kernel device tree by this serie:
> 
> [4] https://patchwork.kernel.org/project/linux-arm-kernel/list/?series=1023034
> 
> U-Boot will inherit of these properties when the above kernel serie will be merged and U-Boot device tree
> synchronization will be performed.
> 

So are we supposed to wait on those patches being sync'ed with U-Boot in 
order to merge this series? Because if I understood correctly, this will 
break LED support that currently should be working.

I personally don't care what you're doing with the STM boards, but I 
depend on this series to be merged to continue the work on removing 
legacy LED support (which I also don't care too much about but now that 
there are patches for it, let's finish this :) ). So if 1 or 2 releases 
of broken LED support until the Linux kernel DT is sync'ed in U-Boot is 
fine with you, that's fine with me as well. We could also edit 
-u-boot.dtsi DTS manually until the sync and have the best of both worlds.

Cheers,
Quentin