u-boot.git/drivers/led, branch v2025.04

led: Fix next Coverity scan error

2025-03-04T18:07:23+00:00

The following was reported by Coverity scan:

*** CID 542488:  Control flow issues  (NO_EFFECT)
/drivers/led/led-uclass.c: 277 in led_get_function_name()
271                     return uc_plat->label;
272
273             /* Now try to detect function label name */
274             func = dev_read_string(dev, "function");
275             cp = dev_read_u32(dev, "color", &color);
276             // prevent coverity scan error CID 541279: (TAINTED_SCALAR)
>>>     CID 542488:  Control flow issues  (NO_EFFECT)
>>>     This less-than-zero comparison of an unsigned value is never true. "color < 0U".
277             if (color < LED_COLOR_ID_WHITE || color >= LED_COLOR_ID_MAX)
278                     cp = -EINVAL;
279

Fix it.

Addresses-Coverity-ID: 542488
Link: https://lists.denx.de/pipermail/u-boot/2025-February/581567.html
Signed-off-by: Heiko Schocher 
Reviewed-by: Quentin Schulz

led: fix coverity scan error

2025-02-18T18:30:53+00:00

The following was reported by Covervity scan:

*** CID 541279:    (TAINTED_SCALAR)
/drivers/led/led-uclass.c: 284 in led_get_function_name()
278                     if (!ret) {
279                             snprintf(uc_plat->name, LED_MAX_NAME_SIZE,
280                                      "%s:%s-%d",
281                                      cp ? "" : led_colors[color],
282                                      func ? func : "", enumerator);
283                     } else {
>>>     CID 541279:    (TAINTED_SCALAR)
>>>     Using tainted variable "color" as an index into an array "led_colors".

Fix it.
Addresses-Coverity-ID: 541279 (TAINTED_SCALAR)
Link: https://lists.denx.de/pipermail/u-boot/2025-February/580250.html
Signed-off-by: Heiko Schocher

led: add function naming option from linux

2025-02-07T16:53:39+00:00

in linux we have the option to create the name of a led
optionally through the following properties:

- function
- color
- function-enumerator

This patch adds support for parsing this properties if there
is no label property.

The led name is created in led_post_bind() and we need some
storage place for it. Currently this patch prevents to use
malloc() instead it stores the name in new member :

        char name[LED_MAX_NAME_SIZE];

of struct led_uc_plat. While at it append led tests for the
new feature.

Signed-off-by: Heiko Schocher 
Reviewed-by: Tom Rini

led: update LED boot/activity to new property implementation

2024-12-06T19:00:41+00:00

Update LED boot/activity to reference by phandle instead of label and
add to period property the "-ms" suffix.
This is a followup request by dt-schema maintainers that required LED
node to be referenced by a phandle to the node instead of indirectly by
the LED label and for timevalue to have a suffix.

While at it generalize the LED node label parsing since the logic is
common for generic LED bind and LED activity/boot.

Signed-off-by: Christian Marangi

led: include cyclic.h in led_sw_blink.c

2024-10-23T04:52:38+00:00

This makes use of the cyclic API but relies on implicitly getting the
appropriate declarations through some nested include. Include the
cyclic.h header directly.

Signed-off-by: Rasmus Villemoes 
Reviewed-by: Simon Glass 
Reviewed-by: Stefan Roese

Merge patch series "Tidy up use of 'SPL' and CONFIG_SPL_BUILD"

2024-10-11T18:23:25+00:00

Simon Glass  says:

When the SPL build-phase was first created it was designed to solve a
particular problem (the need to init SDRAM so that U-Boot proper could
be loaded). It has since expanded to become an important part of U-Boot,
with three phases now present: TPL, VPL and SPL

Due to this history, the term 'SPL' is used to mean both a particular
phase (the one before U-Boot proper) and all the non-proper phases.
This has become confusing.

For a similar reason CONFIG_SPL_BUILD is set to 'y' for all 'SPL'
phases, not just SPL. So code which can only be compiled for actual SPL,
for example, must use something like this:

   #if defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD)

In Makefiles we have similar issues. SPL_ has been used as a variable
which expands to either SPL_ or nothing, to chose between options like
CONFIG_BLK and CONFIG_SPL_BLK. When TPL appeared, a new SPL_TPL variable
was created which expanded to 'SPL_', 'TPL_' or nothing. Later it was
updated to support 'VPL_' as well.

This series starts a change in terminology and usage to resolve the
above issues:

- The word 'xPL' is used instead of 'SPL' to mean a non-proper build
- A new CONFIG_XPL_BUILD define indicates that the current build is an
  'xPL' build
- The existing CONFIG_SPL_BUILD is changed to mean SPL; it is not now
  defined for TPL and VPL phases
- The existing SPL_ Makefile variable is renamed to SPL_
- The existing SPL_TPL Makefile variable is renamed to PHASE_

It should be noted that xpl_phase() can generally be used instead of
the above CONFIGs without a code-space or run-time penalty.

This series does not attempt to convert all of U-Boot to use this new
terminology but it makes a start. In particular, renaming spl.h and
common/spl seems like a bridge too far at this point.

The series is fully bisectable. It has also been checked to ensure there
are no code-size changes on any commit.

global: Rename SPL_ to XPL_

2024-10-11T17:44:48+00:00

Use XPL_ as the symbol to indicate an SPL build. This means that SPL_ is
no-longer set.

Signed-off-by: Simon Glass

led: implement LED activity API

2024-10-10T22:02:20+00:00

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 
Reviewed-by: Simon Glass

led: implement LED boot API

2024-10-10T22:02:20+00:00

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 
Reviewed-by: Simon Glass

led: toggle LED on initial SW blink

2024-10-10T22:02:20+00:00

We currently init the LED OFF when SW blink is triggered when
on_state_change() is called. This can be problematic for very short
period as the ON/OFF blink might never trigger.

Toggle the LED (ON if OFF, OFF if ON) on initial SW blink to handle this
corner case and better display a LED blink from the user.

Signed-off-by: Christian Marangi 
Reviewed-by: Simon Glass 
Reviewed-by: Michael Trimarchi