On Fri, 6 Dec 2024 at 00:01, Simon Glass sjg@chromium.org wrote:
Hi Peter,
On Thu, 5 Dec 2024 at 13:36, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, 3 Dec 2024 at 19:51, Simon Glass sjg@chromium.org wrote:
Hi Tom,
On Tue, 3 Dec 2024 at 12:48, Tom Rini trini@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@gmail.com
wrote:
> > On Sun, 3 Nov 2024 at 00:34, Simon Glass sjg@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.