diff options
author | Tom Rini <trini@konsulko.com> | 2024-10-10 16:02:37 -0600 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2024-10-10 16:02:37 -0600 |
commit | c264a5940e9704edec78286248b813fd2663b387 (patch) | |
tree | 2bf863577570c9262969e312119a71ae07406d05 /include/dm-demo.h | |
parent | a404065479be2c1fe1167c3c91367e8194a69d1b (diff) | |
parent | aadf575050a1cba4c1a95c05a4f3a1737f6b0c14 (diff) | |
download | u-boot-c264a5940e9704edec78286248b813fd2663b387.zip u-boot-c264a5940e9704edec78286248b813fd2663b387.tar.gz u-boot-c264a5940e9704edec78286248b813fd2663b387.tar.bz2 |
Merge patch series "led: introduce LED boot and activity function"
Christian Marangi <ansuelsmth@gmail.com> says:
This series is a reworked version of the previous seried:
misc: introduce STATUS LED activity function
This series port and expand the legacy concept of LED boot from
the legacy Status LED API to new LED API.
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.
Additional Kconfg are also introduced to set the LED boot and
activity. Those are referenced by label.
A documentation for old and these new LED API is created.
Diffstat (limited to 'include/dm-demo.h')
0 files changed, 0 insertions, 0 deletions