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
