[PATCH 0/7] misc: introduce STATUS LED activity function

[Quentin Schulz]

Hi Christian,

On 6/5/24 9:21 PM, Christian Marangi wrote:
> This series expand the STATUS LED framework with a new color
> and a big new feature. One thing that many device need is a way
> to communicate to the user that the device is actually doing
> something.
> 
> This is especially useful for recovery steps where an
> user (for example) insert an USB drive, keep a button pressed
> and the device autorecover.
> 
> There is currently no way to signal the user externally that
> the bootloader is processing/recoverying aside from setting
> a LED on.
> 
> A solid LED on is not enough and won't actually signal any
> kind of progress.
> Solution is the good old blinking LED but uboot doesn't
> suggest (and support) interrupts and almost all the LED
> are usually GPIO LED that doesn't support HW blink.
> 

I haven't used it yet but we do have a cyclic framework now for things 
happening in the background. I think this is a good use-case for this 
framework? Something would set the blinking frequency (could be from CLI 
directly, or as part of board files, or architecture, etc...) and the 
LED would just blink then. This would allow to highlight stages in the 
boot process, though that is not like an activity LED so if you're stuck 
in a stage, you wouldn't know if something is still happening or if 
you're really stuck (e.g. no packet on TFTP or TFTP very slow). The 
benefit is that it would be way less intrusive than patching all 
commands that could make use of that LED. Right now, this only adds 
support to MTD, SPI and TFTP, but what about MMC, NVMe, USB, other net 
stuff (e.g. wget), etc...

Cheers,
Quentin