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
