u-boot.git/drivers/led/Kconfig, branch master Unnamed repository; edit this file 'description' to name the repository. led: remove legacy API 2026-03-18T19:07:36+00:00 Quentin Schulz quentin.schulz@cherry.de 2025-11-20T12:48:06+00:00 fcbf81694c9399a71ac100b4de15089c3e09dd8c No user of the legacy LED API anymore (except Sunxi with the PinePhone but that is now a Sunxi-specific implementation), so let's remove anything related. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> 
No user of the legacy LED API anymore (except Sunxi with the PinePhone
but that is now a Sunxi-specific implementation), so let's remove
anything related.

Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Merge patch series "led: fixes" 2025-10-17T14:58:10+00:00 Tom Rini trini@konsulko.com 2025-10-17T14:58:10+00:00 a46a2e2227b5d5010ac5837a104040ce9474ef95 Patrice Chotard <patrice.chotard@foss.st.com> says: - Update led_get_by_label() - Fix led Kconfig Link: https://lore.kernel.org/r/20251009130844.11703-1-patrice.chotard@foss.st.com 
Patrice Chotard <patrice.chotard@foss.st.com> says:

  - Update led_get_by_label()
  - Fix led Kconfig

Link: https://lore.kernel.org/r/20251009130844.11703-1-patrice.chotard@foss.st.com
led: Add LED dependency for LED_ACTIVITY and LED_BOOT 2025-10-17T14:57:45+00:00 Patrice Chotard patrice.chotard@foss.st.com 2025-10-09T13:08:34+00:00 827ccb84ff433001b59168d81a59489e339ec2c0 Add LED dependency for LED_ACTIVITY and LED_BOOT. Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Yegor Yefremov <yegorslists@googlemail.com> Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com> 
Add LED dependency for LED_ACTIVITY and LED_BOOT.

Signed-off-by: Patrice Chotard <patrice.chotard@foss.st.com>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Reviewed-by: Yegor Yefremov <yegorslists@googlemail.com>
led: Mark LED_STATUS as depending on LED being disabled 2025-10-08T22:13:00+00:00 Tom Rini trini@konsulko.com 2025-09-26T15:31:34+00:00 f34a86c1ef0e93e9724c44b8ecb5e523c891c825 The LED_STATUS functionality is part of the legacy LED framework. This cannot be enabled at the same time as the new LED API is. Make the text prompt be clear this is legacy and add a dependency on LED being disabled. Signed-off-by: Tom Rini <trini@konsulko.com> 
The LED_STATUS functionality is part of the legacy LED framework. This
cannot be enabled at the same time as the new LED API is. Make the text
prompt be clear this is legacy and add a dependency on LED being
disabled.

Signed-off-by: Tom Rini <trini@konsulko.com>
led: implement LED activity API 2024-10-10T22:02:20+00:00 Christian Marangi ansuelsmth@gmail.com 2024-10-01T12:24:38+00:00 aad8cfa3ca4b1bb18c4a55d2bbee4f58d3095d64 Implement LED activity API similar to BOOT LED API. Usual activity might be a file transfer with TFTP, a flash write... User of this API will call led_activity_on/off/blink() to signal these kind of activity. New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to enable support for it. It's introduced a new /options/u-boot property "activity-led" and "activity-led-period" to define the activity LED label and the default period when the activity LED is set to blink mode. If "activity-led-period" is not defined, the value of 250 (ms) is used by default. If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled, led_boot_blink call will fallback to simple LED ON. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Implement LED activity API similar to BOOT LED API.

Usual activity might be a file transfer with TFTP, a flash write...

User of this API will call led_activity_on/off/blink() to signal these
kind of activity.

New Kconfig is implemented similar to BOOT LED, LED_ACTIVITY to
enable support for it.

It's introduced a new /options/u-boot property "activity-led" and
"activity-led-period" to define the activity LED label and the
default period when the activity LED is set to blink mode.

If "activity-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: implement LED boot API 2024-10-10T22:02:20+00:00 Christian Marangi ansuelsmth@gmail.com 2024-10-01T12:24:36+00:00 914fd75a5d2f4cfa7828b48abed50a146063d1bd Implement LED boot API to signal correct boot of the system. led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the designated boot LED. New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature. This makes use of the /options/u-boot property "boot-led" to the define the boot LED. It's also introduced a new /options/u-boot property "boot-led-period" to define the default period when the LED is set to blink mode. If "boot-led-period" is not defined, the value of 250 (ms) is used by default. If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled, led_boot_blink call will fallback to simple LED ON. To cache the data we repurpose the now unused led_uc_priv for storage of global LED uclass info. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> 
Implement LED boot API to signal correct boot of the system.

led_boot_on/off/blink() are introduced to turn ON, OFF and BLINK the
designated boot LED.

New Kconfig is introduced, CONFIG_LED_BOOT to enable the feature.
This makes use of the /options/u-boot property "boot-led" to the
define the boot LED.
It's also introduced a new /options/u-boot property "boot-led-period"
to define the default period when the LED is set to blink mode.

If "boot-led-period" is not defined, the value of 250 (ms) is
used by default.

If CONFIG_LED_BLINK or CONFIG_LED_SW_BLINK is not enabled,
led_boot_blink call will fallback to simple LED ON.

To cache the data we repurpose the now unused led_uc_priv for storage of
global LED uclass info.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: Implement software led blinking 2024-07-30T18:35:23+00:00 Michael Polyntsov michael.polyntsov@iopsys.eu 2024-07-19T09:12:12+00:00 b557f55e90f087ec310592b833441cd326206f61 If hardware (or driver) doesn't support leds blinking, it's now possible to use software implementation of blinking instead. This relies on cyclic functions. Signed-off-by: Michael Polyntsov <michael.polyntsov@iopsys.eu> Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu> Reviewed-by: Simon Glass <sjg@chromium.org> 
If hardware (or driver) doesn't support leds blinking, it's
now possible to use software implementation of blinking instead.
This relies on cyclic functions.

Signed-off-by: Michael Polyntsov <michael.polyntsov@iopsys.eu>
Signed-off-by: Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>
Reviewed-by: Simon Glass <sjg@chromium.org>
led: add TI LP5562 LED driver 2023-12-13T16:35:16+00:00 Doug Zobel douglas.zobel@climate.com 2023-11-17T11:38:11+00:00 f9dc67d18ee258d08fa620248d97e206b1cb849f Driver for the TI LP5562 4 channel LED controller. Supports independent on/off control of all 4 channels. Supports LED_BLINK on 3 independent channels: blue/green/red. The white channel can blink, but shares the blue channel blink rate. Heavily based on patch originally from Doug Zobel [1]. I have modified it so it matches the DT bindings in the linux tree, and also follows the linux driver implementation more closely. This should address Tom's concerns, and also matches my goal of making the U-Boot driver work with our existing .dts which is known to work in linux. As our boards only have the R,G,B outputs connected, I have not actually tested how the white channel behaves, but the R,G,B work exactly as expected. [1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zobel@climate.com/ Cc: Doug Zobel <douglas.zobel@climate.com> Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> 
Driver for the TI LP5562 4 channel LED controller. Supports
independent on/off control of all 4 channels. Supports LED_BLINK on 3
independent channels: blue/green/red. The white channel can blink, but
shares the blue channel blink rate.

Heavily based on patch originally from Doug Zobel [1].

I have modified it so it matches the DT bindings in the linux tree,
and also follows the linux driver implementation more closely. This
should address Tom's concerns, and also matches my goal of making the
U-Boot driver work with our existing .dts which is known to work in
linux.

As our boards only have the R,G,B outputs connected, I have not
actually tested how the white channel behaves, but the R,G,B work
exactly as expected.

[1] https://lore.kernel.org/u-boot/1547150757-1561-1-git-send-email-douglas.zobel@climate.com/

Cc: Doug Zobel <douglas.zobel@climate.com>
Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
arm: bcmbca: replace ARCH_BCM6753 symbols in Kconfig with BCM6855 2022-10-31T12:55:59+00:00 William Zhang william.zhang@broadcom.com 2022-08-22T18:49:08+00:00 8c1a9c7de7d95f681adead869329cf8e53024c11 As CONFIG_ARCH_BCM6753 is replaced with CONFIG_BCM6855, update the driver Kconfig to use the new config symbol. Signed-off-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com> 
As CONFIG_ARCH_BCM6753 is replaced with CONFIG_BCM6855, update the
driver Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>
arm: bcmbca: replace ARCH_BCM6858 symbols in Kconfig with BCM6858 2022-10-31T12:55:59+00:00 William Zhang william.zhang@broadcom.com 2022-08-22T18:39:45+00:00 2dab3ee50c600e4e58f8bbf444ce8ffaee783916 As CONFIG_ARCH_BCM6858 is replaced with CONFIG_BCM6858, update the driver Kconfig to use the new config symbol. Signed-off-by: William Zhang <william.zhang@broadcom.com> Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com> 
As CONFIG_ARCH_BCM6858 is replaced with CONFIG_BCM6858, update the
driver Kconfig to use the new config symbol.

Signed-off-by: William Zhang <william.zhang@broadcom.com>
Reviewed-by: Philippe Reynes <philippe.reynes@softathome.com>