leds: nic78bx: Tidy up ACPI ID table

Tidy up ACPI ID table:

- Drop ACPI_PTR() and hence replace acpi.h with mod_devicetable.h and
other necessary headers

- Remove explicit driver_data initialize

leds: nic78bx: Tidy up ACPI ID table

Tidy up ACPI ID table:

- Drop ACPI_PTR() and hence replace acpi.h with mod_devicetable.h and
other necessary headers

- Remove explicit driver_data initializer

- Drop comma in the terminator entry

With that done, extend compile test coverage.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Rename simple directory to simatic

The drivers contained in this directory are not simplistic.

Signed-off-by: Lee Jones <[email protected]>

leds: Kconfig: leds-st1202: Add select for required LEDS_TRIGGER_PATTERN

leds-st1202 requires the LED Pattern Trigger (LEDS_TRIGGER_PATTERN), which
is not selected when LED Trigger support is (LEDS_

leds: Kconfig: leds-st1202: Add select for required LEDS_TRIGGER_PATTERN

leds-st1202 requires the LED Pattern Trigger (LEDS_TRIGGER_PATTERN), which
is not selected when LED Trigger support is (LEDS_TRIGGERS).

To reproduce this:

- make menuconfig KCONFIG_CONFIG=
- select LEDS_ST1202 dependencies OF, I2C and LEDS_CLASS.
- select LEDS_ST1202
- LEDS_TRIGGERS is selected but LEDS_TRIGGER_PATTERN isn't.

The absence of LEDS_TRIGGER_PATTERN explicitly required can lead to builds
in which LEDS_ST1202 is selected while LEDS_TRIGGER_PATTERN isn't. The direct
result of that would be that /sys/class/leds/<led>/hw_pattern wouldn't be
available and there would be no way of interacting with the driver and
hardware from user space.

Add select LEDS_TRIGGER_PATTERN to Kconfig to meet the requirement and
indirectly document it as well.

Signed-off-by: Manuel Fombuena <[email protected]>
Link: https://lore.kernel.org/r/CWLP123MB5473F4DF3A668F7DD057A280C5C22@CWLP123MB5473.GBRP123.PROD.OUTLOOK.COM
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: max77705: Add LEDs support

This adds basic support for LEDs for the max77705 PMIC.

Signed-off-by: Dzmitry Sankouski <[email protected]>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@l

leds: max77705: Add LEDs support

This adds basic support for LEDs for the max77705 PMIC.

Signed-off-by: Dzmitry Sankouski <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/20250123-starqltechn_integration_upstream-v17-7-8b06685b6612@gmail.com
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: lp8864: Add support for Texas Instruments LP8864, LP8864S, LP8866 LED-backlights

Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers
with I2C interface.

Link: https://

leds: lp8864: Add support for Texas Instruments LP8864, LP8864S, LP8866 LED-backlights

Add driver for TI LP8864, LP8864S, LP8866 4/6 channel LED-backlight drivers
with I2C interface.

Link: https://www.ti.com/lit/gpn/lp8864-q1
Link: https://www.ti.com/lit/gpn/lp8864s-q1
Link: https://www.ti.com/lit/gpn/lp8866-q1
Link: https://www.ti.com/lit/gpn/lp8866s-q1
Signed-off-by: Alexander Sverdlin <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add LED1202 I2C driver

The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 l

leds: Add LED1202 I2C driver

The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 low-side current generators with independent dimming
control.
Internal volatile memory allows the user to store up to 8 different patterns,
each pattern is a particular output configuration in terms of PWM
duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but
common to all patterns. Each device tree LED node will have a corresponding
entry in /sys/class/leds with the label name. The brightness property
corresponds to the per channel analog dimming, while the patterns[1-8] to the
PWM dimming control.

Signed-off-by: Vicentiu Galanopulo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add LED1202 I2C driver

The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 l

leds: Add LED1202 I2C driver

The output current can be adjusted separately for each channel by 8-bit
analog (current sink input) and 12-bit digital (PWM) dimming control. The
LED1202 implements 12 low-side current generators with independent dimming
control.
Internal volatile memory allows the user to store up to 8 different patterns,
each pattern is a particular output configuration in terms of PWM
duty-cycle (on 4096 steps). Analog dimming (on 256 steps) is per channel but
common to all patterns. Each device tree LED node will have a corresponding
entry in /sys/class/leds with the label name. The brightness property
corresponds to the per channel analog dimming, while the patterns[1-8] to the
PWM dimming control.

Signed-off-by: Vicentiu Galanopulo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add AAEON UP board LED driver

Add support for LEDs on AAEON UP boards. These leds are managed by the
onboard FPGA:
- UP boards: yellow, green, red
- UP Squared boards: blue, yellow, green, red

leds: Add AAEON UP board LED driver

Add support for LEDs on AAEON UP boards. These leds are managed by the
onboard FPGA:
- UP boards: yellow, green, red
- UP Squared boards: blue, yellow, green, red

Based on the work done by Gary Wang <[email protected]>, largely
rewritten.

Signed-off-by: Thomas Richard <[email protected]>
Link: https://lore.kernel.org/r/20241211-aaeon-up-board-pinctrl-support-v1-2-24719be27631@bootlin.com
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add driver for LEDs from qnap-mcu devices

This adds a driver that connects to the qnap-mcu mfd driver and provides
access to the LEDs on it.

Signed-off-by: Heiko Stuebner <[email protected]>
Li

leds: Add driver for LEDs from qnap-mcu devices

This adds a driver that connects to the qnap-mcu mfd driver and provides
access to the LEDs on it.

Signed-off-by: Heiko Stuebner <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: turris-omnia: Notify sysfs on MCU global LEDs brightness change

Recall that on Turris Omnia, the LED controller has a global brightness
property, which allows the user to make the front LED pa

leds: turris-omnia: Notify sysfs on MCU global LEDs brightness change

Recall that on Turris Omnia, the LED controller has a global brightness
property, which allows the user to make the front LED panel dimmer.

There is also a button on the front panel, which by default is
configured so that pressing it changes the global brightness to a lower
value (unless it is at 0%, in which case pressing the button changes the
global brightness to 100%).

Newer versions of the MCU firmware support informing the SOC that the
brightness was changed by button press event via an interrupt.

Now that we have the turris-omnia-mcu driver, which adds support for MCU
interrupts, add the ability to inform the userspace (via a sysfs
notification) that the global brightness was changed.

Signed-off-by: Marek Behún <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: turris-omnia: Use command execution functions from the MCU driver

Use the MCU command execution functions from the MCU driver instead of
the ad-hoc implementation in the LED driver. This allow

leds: turris-omnia: Use command execution functions from the MCU driver

Use the MCU command execution functions from the MCU driver instead of
the ad-hoc implementation in the LED driver. This allows as to drop the
LED driver implementation, which is a duplicate.

Signed-off-by: Marek Behún <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: blinkm: Fix CONFIG_LEDS_CLASS_MULTICOLOR dependency

With CONFIG_LEDS_CLASS_MULTICOLOR=m, a builtin leds-blinkm driver causes
a link failure:

arm-linux-gnueabi-ld: drivers/leds/leds-blinkm.o:

leds: blinkm: Fix CONFIG_LEDS_CLASS_MULTICOLOR dependency

With CONFIG_LEDS_CLASS_MULTICOLOR=m, a builtin leds-blinkm driver causes
a link failure:

arm-linux-gnueabi-ld: drivers/leds/leds-blinkm.o: in function `blinkm_set_mc_brightness':
leds-blinkm.c:(.text.blinkm_set_mc_brightness+0xc): undefined reference to `led_mc_calc_color_components'

Add a more specific dependency that only allows multicoler mode to
be enabled for blinkm if it can build and link.

Fixes: 56e8c56c9af0 ("leds: Add multicolor support to BlinkM LED driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Joseph Strauss <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add multicolor support to BlinkM LED driver

Add multicolor support to the BlinkM driver, making it easier to control
from userspace. The BlinkM LED is a programmable RGB LED. The driver
curren

leds: Add multicolor support to BlinkM LED driver

Add multicolor support to the BlinkM driver, making it easier to control
from userspace. The BlinkM LED is a programmable RGB LED. The driver
currently supports only the regular LED sysfs class, resulting in the
creation of three distinct classes, one for red, green, and blue. The
user then has to input three values into the three seperate brightness
files within those classes. The multicolor LED framework makes the
device easier to control with the multi_intensity file: the user can
input three values at once to form a color, while still controlling the
lightness with the brightness file.

The main struct blinkm_led has changed slightly. The struct led_classdev
for the regular sysfs classes remain. The blinkm_probe function checks
CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate
sysfs classes or the single multicolor one, but never both. The
blinkm_set_mc_brightness() function had to be added to calculate the
three color components and then set the fields of the blinkm_data
structure accordingly.

Signed-off-by: Joseph Strauss <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: leds-lp5569: Add support for Texas Instruments LP5569

Add support for Texas Instruments LP5569 LED driver.

Texas Instruments LP5569 is 9 channels chip with programmable engines.

It almost a

leds: leds-lp5569: Add support for Texas Instruments LP5569

Add support for Texas Instruments LP5569 LED driver.

Texas Instruments LP5569 is 9 channels chip with programmable engines.

It almost a copy of LP5523 with fundamental changes to regs order and
regs content.

Has difference in how the clock is handled and doesn't support detecting
clock time automatically, different handling for selftest and different
scheme for the status regs.

LED chip supports ENGINE and MUX to group LED and run precompiled code
with magic values to run patterns. This is loaded via the sysfs entry
and it's passed as a string of ASCII HEX char.

One some devices using this LED Controller (a NBG7815 Router) it was
found loading big precompiled pattern with up to 96 bytes of code. To
have support for this "extended" scenario, hardcode each engine to
support 4 pages of precompiled pattern (128 bytes of code) and 1 page
for each MUX. This gives plenty of space for any kind precompiled
pattern keeping simple logic for page handling of each engine and mux.

Signed-off-by: Christian Marangi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: spi-byte: Make use of device properties

Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.

Add mod_devicetable.h include.

Signed-off-by: Andy Sh

leds: spi-byte: Make use of device properties

Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.

Add mod_devicetable.h include.

Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Add ChromeOS EC driver

The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.

The LEDs are exposed as multicolor devices.
A hard

leds: Add ChromeOS EC driver

The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.

The LEDs are exposed as multicolor devices.
A hardware trigger, which is active by default, is provided to let the
EC itself take over control over the LED.

The driver is designed to be probed via the cros_ec mfd device.

Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: expresswire: Don't depend on NEW_LEDS

The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:

WARNING: unmet direct d

leds: expresswire: Don't depend on NEW_LEDS

The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:

WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]

Move it out of the "if NEW_LEDS" block to allow selection from other
subsystems (in particular backlight) without raising this warning.

Reported-by: Arnd Bergmann <[email protected]>
Closes: https://lore.kernel.org/[email protected]
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Suggested-by: Daniel Thompson <[email protected]>
Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library")
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Duje Mihanović <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Make flash and multicolor dependencies unconditional

Along the same lines as making devm_led_classdev_register() declared
extern unconditional, do the same thing for the two sub-classes
that h

leds: Make flash and multicolor dependencies unconditional

Along the same lines as making devm_led_classdev_register() declared
extern unconditional, do the same thing for the two sub-classes
that have similar stubs.

The users of these interfaces go to great lengths to allow building
with both the generic leds API and the extended version, but realistically
there is not much use in this, so just simplify it to always rely
on it and remove the confusing fallback logic.

Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: Introduce ExpressWire library

The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses

leds: Introduce ExpressWire library

The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses for enabling the protocol (possibly because it
does not support PWM unlike KTD2801). Despite these differences the
ExpressWire handling code can be shared between the two, so in
preparation for adding KTD2801 support introduce a library implementing
this protocol.

Suggested-by: Daniel Thompson <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Duje Mihanović <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: sun50i-a100: Convert to be agnostic to property provider

Convert the driver to be agnostic to the property provider.
LEDS subsytem is not dependent on OF, so no need to make drivers
be a such.

leds: sun50i-a100: Convert to be agnostic to property provider

Convert the driver to be agnostic to the property provider.
LEDS subsytem is not dependent on OF, so no need to make drivers
be a such.

Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: aw200xx: Add support for aw20108 device

Add support for the Awinic aw20108 device, which belongs to the same LED
drivers family. The new device supports 108 LEDs using a matrix of 12x9
outputs

leds: aw200xx: Add support for aw20108 device

Add support for the Awinic aw20108 device, which belongs to the same LED
drivers family. The new device supports 108 LEDs using a matrix of 12x9
outputs."

Signed-off-by: George Stark <[email protected]>
Signed-off-by: Dmitry Rokosov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: max5970: Add support for max5970

The MAX5970 is hot swap controller and has 4 indication LED.

Signed-off-by: Patrick Rudolph <[email protected]>
Signed-off-by: Naresh Solanki <Nar

leds: max5970: Add support for max5970

The MAX5970 is hot swap controller and has 4 indication LED.

Signed-off-by: Patrick Rudolph <[email protected]>
Signed-off-by: Naresh Solanki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: aw2013: Select missing dependency REGMAP_I2C

The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
be selected.

Otherwise build process may fail with:
ld: drivers/leds/leds-aw

leds: aw2013: Select missing dependency REGMAP_I2C

The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
be selected.

Otherwise build process may fail with:
ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe':
leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c'

Signed-off-by: Dang Huynh <[email protected]>
Acked-by: Nikita Travkin <[email protected]>
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: sun50i-a100: New driver for the A100 LED controller

Some Allwinner sunxi SoCs, starting with the A100, contain an LED
controller designed to drive RGB LED pixels. Add a driver for it using
the

leds: sun50i-a100: New driver for the A100 LED controller

Some Allwinner sunxi SoCs, starting with the A100, contain an LED
controller designed to drive RGB LED pixels. Add a driver for it using
the multicolor LED framework, and with LEDs defined in the device tree.

Acked-by: Guo Ren <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Samuel Holland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...

leds: turris-omnia: Support HW controlled mode via private trigger

Add support for enabling MCU controlled mode of the Turris Omnia LEDs
via a LED private trigger called "omnia-mcu". Recall that pri

leds: turris-omnia: Support HW controlled mode via private trigger

Add support for enabling MCU controlled mode of the Turris Omnia LEDs
via a LED private trigger called "omnia-mcu". Recall that private LED
triggers will only be listed in the sysfs trigger file for LEDs that
support them (currently there is no user of this mechanism).

When in MCU controlled mode, the user can still set LED color, but the
blinking is done by MCU, which does different things for different LEDs:
- WAN LED is blinked according to the LED[0] pin of the WAN PHY
- LAN LEDs are blinked according to the LED[0] output of the
corresponding port of the LAN switch
- PCIe LEDs are blinked according to the logical OR of the MiniPCIe port
LED pins

In the future I want to make the netdev trigger to transparently offload
the blinking to the HW if user sets compatible settings for the netdev
trigger (for LEDs associated with network devices).
There was some work on this already, and hopefully we will be able to
complete it sometime, but for now there are still multiple blockers for
this, and even if there weren't, we still would not be able to configure
HW controlled mode for the LEDs associated with MiniPCIe ports.

In the meantime let's support HW controlled mode via the private LED
trigger mechanism. If, in the future, we manage to complete the netdev
trigger offloading, we can still keep this private trigger for backwards
compatibility, if needed.

We also set "omnia-mcu" to cdev->default_trigger, so that the MCU keeps
control until the user first wants to take over it. If a different
default trigger is specified in device-tree via the
'linux,default-trigger' property, LED class will overwrite
cdev->default_trigger, and so the DT property will be respected.

Signed-off-by: Marek Behún <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>

show more ...