[PATCH v3 00/25] led: Remove old status-LED code

Simon Glass sjg at chromium.org
Fri Dec 6 01:01:05 CET 2024


Hi Peter,

On Thu, 5 Dec 2024 at 13:36, Peter Robinson <pbrobinson at gmail.com> wrote:
>
>
>
> On Tue, 3 Dec 2024 at 19:51, Simon Glass <sjg at chromium.org> wrote:
>>
>> Hi Tom,
>>
>> On Tue, 3 Dec 2024 at 12:48, Tom Rini <trini at konsulko.com> wrote:
>> >
>> > On Thu, Nov 07, 2024 at 07:33:51PM +0000, Peter Robinson wrote:
>> > > Hi Simon,
>> > >
>> > > > On Tue, 5 Nov 2024 at 07:18, Peter Robinson <pbrobinson at gmail.com> wrote:
>> > > > >
>> > > > > On Sun, 3 Nov 2024 at 00:34, Simon Glass <sjg at chromium.org> wrote:
>> > > > > >
>> > > > > > There has been an LED framework in U-Boot which uses driver model for
>> > > > > > about 9 years now. Recent work is underway to improve it and provide
>> > > > > > more features. It is probably a good time to drop the old code, which
>> > > > > > is only used by 5 boards:
>> > > > >
>> > > > > I don't believe, from what I can tell, they are feature comparable, at
>> > > > > the very least I have not been able to get the Pinephone working with
>> > > > > this so as it stands I still don't think this patch set is ready yet.
>> > > >
>> > > > I don't have that hardware, nor the other 4, so cannot do anything
>> > > > with this feedback.
>> > >
>> > > Don't you have any HW that has a LED on it that you can substitute to
>> > > see what it does?
>> > >
>> > > > Can you please be clear what you are asking me to do?
>> > >
>> > > Either produce patches that work on the the pinephone, or docs I, or
>> > > other developers, can use to implement the functionality.
>> > >
>> > > Currently on the Pinephone the green LED lights up in the TPL/SPL
>> > > (very early before ATF) stage and is lit up right through the the
>> > > various FW stages, with your patch set I get no LED what so ever.
>> >
>> > Please note that needing to confirm that we have equivalent
>> > functionality between old and new frameworks (and
>> > https://lore.kernel.org/all/20241110115054.2555-1-ansuelsmth@gmail.com/
>> > might cover that) is why this series isn't ready for -next at this time.
>>
>> Yes, I'm not sure if Peter saw that, so I sent him the link.
>
>
> I have seen it, I have not had the chance to dig out my pinephone to test it again because I was traveling and had competing priorities on my time (and I do this as a hobby).
>
> But also I think we have a little time on this, the new functionality only landed recently and we've had a LOT of deprecated functionality hang around for a lot longer than that. I think we should get this right rather than jam it through.

There's plenty of time for you to test. But we're really not losing
anything by applying these patches (and also [1]). It is more likely
to work for your board, but if it doesn't, we can focus efforts on
what is wrong rather than trying to keep the old code around.

One of the challenges I have, as someone who also does this as a
hobby, is that few people are willing to take on deprecation efforts.
This work is not very interesting, most of the time, and it is
extremely hard to get things to actually land, since anyone can raise
their hand and say that it doesn't solve a particular use case. I
suppose most people do U-Boot things in their spare time and few have
a lot of time to test or try things out. So there needs to be a
balance struck, to encourage more people to help.

Regards,
Simon

[1] https://patchwork.ozlabs.org/project/uboot/list/?series=432093&state=*


More information about the U-Boot mailing list