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

[Peter Robinson]

On Fri, 6 Dec 2024 at 00:01, Simon Glass <sjg at chromium.org> wrote:

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

I'm sorry but I disagree, bulldozing patches in just because it's suitable
for you but breaks actual usecases is not the right way to do thing, at the
moment this works and it useful features for users. Actively breaking valid
UX Is hostile and not the right way to do things!


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

I do this as a hobby too, you are not unique here.


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

I'm sorry, I do feel for you, I have the same problem and I end up spending
most of my spare of late reading emails due to the deluge.

But actively breaking valid usecases by bulldozing things through, it NOT
the way to handle things, I'm sorry here what role you perceive you play
whether it be a full time employee, paid contractor or hobbyist isn't a
valid reason for forcing through patches, please do not use that as a
reason.