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

[Patrice CHOTARD]

On 12/5/25 11:43, Quentin Schulz wrote:
> 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 have already try to contact these people you mentioned when i converted STMicroelectronics 
boards to CONFIG_UPSTREAM flags but unfortunately none of them replied.

> 
>>>
>>> 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 will not wait the DT sync to merge this series, i was just waiting for review from my 
colleague Patrick Delaunay or from other people present on the mailing list.

As you have reviewed this serie, i will submit a pull request for U-Boot next.

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

Thanks
Patrice

> 
> Cheers,
> Quentin