Add support for multi-color LEDs

[simonguinot]

This PR adds support for multi-color LEDs built with several monochromatic LED.

It imports the leds-group-multicolor DT binding from Linux and introduces the leds-group-multicolor driver.

Here is an example of DT fragment that defines an RGB LED with a group of monochromatic PWM LEDs:

/ { 
        monochromatic-leds { 
                compatible = "pwm-leds";

                red_pwm_led: led-0 { 
                        pwms = <&pwm1 1 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
                };

                green_pwm_led: led-1 { 
                        pwms = <&pwm2 1 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
                };

                blue_pwm_led: led-2 { 
                        pwms = <&pwm3 1 PWM_MSEC(20) PWM_POLARITY_NORMAL>;
                };
        };

        multi-led { 
                compatible = "leds-group-multicolor";

                leds = <&red_pwm_led>, <&green_pwm_led>, <&blue_pwm_led>;
                label = "RGB LED";
                color-mapping = <LED_COLOR_ID_RED>,
                                <LED_COLOR_ID_GREEN>,
                                <LED_COLOR_ID_BLUE>;
        };
};

The leds-group-multicolor driver implements the ->set_color() API method. Instead of calling led_set_brightness() for each monochromatic LED, led_set_color() can be called on the leds-group-multicolor compatible device to configure all the LEDs at once.

Note that the color-mapping DT property, shown in the above example, is not mandatory.

[simonguinot]

Implements #51858

[bjarki-andreasen]

Really like the addition, some comments but overall really nice

[simonguinot]

Really like the addition, some comments but overall really nice

Thank you very much for your fast feedback. I really appreciate it. Hopefully this will initiate more reviews.

But to be honest, I don't think this composite driver is nice. IMO it is not the right approach to bring support for multi-color LEDs in Zephyr. It would be more optimized to support them directly in GPIO and PWM drivers (#69227). But unfortunately this kind of hits the sacred rule of Linux compatibility. And we really need to move forward on this multi-color LED topic...

[gmarull]

Really like the addition, some comments but overall really nice

Thank you very much for your fast feedback. I really appreciate it. Hopefully this will initiate more reviews.

But to be honest, I don't think this composite driver is nice. IMO it is not the right approach to bring support for multi-color LEDs in Zephyr. It would be more optimized to support them directly in GPIO and PWM drivers (#69227). But unfortunately this kind of hits the sacred rule of Linux compatibility. And we really need to move forward on this multi-color LED topic...

I think this is often a confusion about DT/Zephyr. DT describes hardware, and while it suggests a certain implementation pattern, you can technically do whatever you want as you have the full connections in DT (e.g. get PWM instances instead of LED instance). It may lead to some macro crimes, but I guess it should be doable if memory usage is a concern.

[simonguinot]

Really like the addition, some comments but overall really nice

Thank you very much for your fast feedback. I really appreciate it. Hopefully this will initiate more reviews.
But to be honest, I don't think this composite driver is nice. IMO it is not the right approach to bring support for multi-color LEDs in Zephyr. It would be more optimized to support them directly in GPIO and PWM drivers (#69227). But unfortunately this kind of hits the sacred rule of Linux compatibility. And we really need to move forward on this multi-color LED topic...

I think this is often a confusion about DT/Zephyr. DT describes hardware, and while it suggests a certain implementation pattern, you can technically do whatever you want as you have the full connections in DT (e.g. get PWM instances instead of LED instance). It may lead to some macro crimes, but I guess it should be doable if memory usage is a concern.

For Linux, a LED is a channel. The LED DT descriptions and drivers in Linux are following this statement. When the need came to support multi-channel LEDs (because these devices actually exist), then composite devices and drivers were introduced. It was the only option without breaking everything. That's why in Linux multi-color LEDs are described in DT with composite devices. But a LED device can have several channels, and a correct hardware description should reflect that without using composite devices. So the Linux LED bindings are not good. And by rule we sacredly copy them.

About the leds-group-multicolor DT binding, the implementation is more constrained than suggested. It intends to support any kind of underlying LED devices (PWM, GPIO; dedicated controller, strip, mixed), and not just PWM. So having a driver duplicating code, using insane macros or other contortions, all to match an unneeded pseudo device representation is not a good idea.

That being said I think that this leds-group-multicolor driver does actually make sense for some specific use cases, such as RGB LED built with mixed LEDs of different controllers for example. So it is nice to have it anyway.

But when it comes to RGB LEDs built from GPIO or PWM lines, then it should use a different DT description, and it should be supported directly by the led-pwm and led-gpio drivers, because the code is already there. And for the GPIO part, it is implemented by #69227.

[rruuaanng]

It looks redundant :-o

[simonguinot]

You mean redundant with the node name ?

There is a discussion here: LED.#92473 (comment). Feel free to join.

[Copilot]

Pull Request Overview

This PR adds support for multi-color LEDs by importing a new DT binding and introducing a corresponding driver that wraps multiple monochromatic LEDs into one multi-color interface.

• Import and refactor existing LED bindings to share common led-node.yaml fields.
• Add leds-group-multicolor DT binding, Kconfig, CMake integration, and driver implementation.
• Update test and sample configurations to include multi-color and PWM setups.

Reviewed Changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tests/drivers/build_all/led/prj.conf	Remove CONFIG_PWM from build-all tests
tests/drivers/build_all/led/app.overlay	Add multi-led overlay node for multi-color
samples/drivers/led/pwm/prj.conf	Remove CONFIG_PWM from PWM sample
dts/bindings/led/pwm-leds.yaml	Include led-node.yaml for child label
dts/bindings/led/leds-group-multicolor.yaml	New DT binding for multi-color LED grouping
dts/bindings/led/led-node.yaml	New common LED node binding (label/color-mapping)
dts/bindings/led/led-controller.yaml	Include led-node.yaml, remove duplicate props
dts/bindings/led/gpio-leds.yaml	Include led-node.yaml for GPIO LEDs
drivers/led/leds_group_multicolor.c	Multi-color LED driver implementation
drivers/led/Kconfig.pwm	Adjust PWM LED driver dependencies
drivers/led/Kconfig.leds-group-multicolor	New Kconfig for multi-color LED driver
drivers/led/Kconfig	Register multi-color Kconfig file
drivers/led/CMakeLists.txt	Add multi-color driver to build

Comments suppressed due to low confidence (3)

samples/drivers/led/pwm/prj.conf:3

• Removing CONFIG_PWM from the PWM sample prj.conf disables the PWM LED driver and will break the sample build. Please restore CONFIG_PWM or update the sample dependencies accordingly.

CONFIG_LED=y

drivers/led/leds_group_multicolor.c:23

• [nitpick] The field name led suggests a single LED but holds an array of LED specs; consider renaming it to leds for clarity.

	const struct led_dt_spec *led;

[Copilot]

[nitpick] Using select PWM is discouraged because it implicitly enables PWM and can lead to conflicting configurations. Prefer depends on PWM to correctly express the dependency.

Suggested change

	select PWM
	depends on PWM

[Copilot]

The multi-color LED driver relies on the underlying PWM LED driver (LED_PWM). Add depends on LED_PWM to the Kconfig so that the necessary driver is enabled when multi-color support is selected.

Suggested change

	depends on DT_HAS_LEDS_GROUP_MULTICOLOR_ENABLED
	depends on DT_HAS_LEDS_GROUP_MULTICOLOR_ENABLED && LED_PWM

[Copilot]

There is a typo in brigtness; it should be spelled brightness.

Suggested change

	brigtness granularity) and lesser than 50 milliseconds (average visual
	brightness granularity) and lesser than 50 milliseconds (average visual

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud