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

[Peter Robinson]

On Thu, 24 Oct 2024 at 17:36, Simon Glass <sjg at chromium.org> wrote:
>
> Hi Peter,
>
> On Thu, 24 Oct 2024 at 14:16, Peter Robinson <pbrobinson at gmail.com> wrote:
> >
> > On Tue, 22 Oct 2024 at 09:48, Peter Robinson <pbrobinson at gmail.com> wrote:
> > >
> > > > On Mon, Oct 21, 2024 at 01:38:08PM +0200, Simon Glass 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:
> > > > >
> > > > >    ./tools/qconfig.py -f LED_STATUS
> > > > >    5 matches
> > > > >    eb_cpu5282 eb_cpu5282_internal mx23_olinuxino pinephone
> > > > >    socfpga_vining_fpga
> > > > >
> > > > > This series attempts that.
> > > > >
> > > > > Changes in v2:
> > > > > - Combine code-removal and defconfig changes
> > > > > - Add a patch to enable LED and LED_BOOT for these boards
> > > > > - Add a patch to enable LED and LED_BOOT for these boards
> > > > > - Enable LED on the 5 affected platforms
> > > > > - Reorder patches for bisectability
> > > >
> > > > So I believe this means you missed the feedback of just doing the blind
> > > > migration rather than disabling the feature, like we used to often do
> > > > for cases where it's just a matter of changing CONFIG options. It
> > > > should:
> > > > - Not introduce a failure to build
> > > > - Just work on platforms with either OF_UPSTREAM or semi-recent device
> > > >   trees
> > > > - Just start working on those platforms when they do move to
> > > >   OF_UPSTREAM.
> > >
> > > Also when the migration was first bought up I had a quick look at how
> > > to do it for the pinephone and I came up empty handed. Now I've seen
> > > the patch for the pinephone and grep for LED_BOOT the only form of
> > > docs I find is in the Kconfig and include/led.h, they refer to things
> > > that aren't in-tree and the out of tree reference to
> > > dtschema/schemas/options/u-boot.yaml, the only in-tree u-boot.yaml is
> > > ./dts/upstream/Bindings/mtd/partitions/u-boot.yaml, that I find has no
> > > reference to boott leds at all.
> > >
> > > I feel the reason there's been a recent move to add users of the
> > > obsolete method is because the docs for that actually existed and
> > > there's nothing for the new method. Maybe the first patch in the
> > > series should be to add some actually useful doc rahter than go from
> > > docs for the old method to nothing.
> >
> > So I've tried the patch on the pinephone and it doesn't work.
> >
> > I suspect you need to at least enable a led driver like LED_GPIO but
> > even when I do that, while I can make the led turn on/off manually, it
> > doesn't come on in early boot like it does with the old code. There's
> > definitely something else missing here.
>
> It's good that you have one of these boards. Would you be able to
> debug it and send a patch?

Well I spent some time this morning and never got any further other
wise I probably would have. When I first tested this against the
2024.10 release I discovered the new boot led stuff has been only
added in this cycle [1] yet you mention above the other code has been
obsolete for 9 years, not sure how that's possible if there's been
nothing to migrate to. Also looking at the patchset the docs are
bbasically non existent! so without having to dig through the code to
work out how to specify the led, like Is there DT requirements etc
it's not something that I have many more cycles for ATM.

Peter

[1]  https://lists.denx.de/pipermail/u-boot/2024-October/566459.html