kernel/linux.git/drivers/leds/Kconfig, branch v6.12.80

leds: blinkm: Fix CONFIG_LEDS_CLASS_MULTICOLOR dependency

2024-08-16T16:04:42+00:00

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 Acked-by: Joseph Strauss Link: https://lore.kernel.org/r/20240807075614.2118068-1-arnd@kernel.org Signed-off-by: Lee Jones

leds: Add multicolor support to BlinkM LED driver

2024-08-01T12:40:02+00:00

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 Link: https://lore.kernel.org/r/20240710184844.108006-1-jstrauss@mailbox.org Signed-off-by: Lee Jones

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

2024-06-26T16:08:31+00:00

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 Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com Signed-off-by: Lee Jones

leds: spi-byte: Make use of device properties

2024-06-26T15:56:04+00:00

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 Link: https://lore.kernel.org/r/20240606173037.3091598-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones

leds: Add ChromeOS EC driver

2024-06-21T10:41:46+00:00

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 Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones

leds: expresswire: Don't depend on NEW_LEDS

2024-03-07T08:48:11+00:00

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 Closes: https://lore.kernel.org/20240212111819.936815-1-arnd@kernel.org Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202402161410.IG9I4odj-lkp@intel.com/ Suggested-by: Daniel Thompson Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library") Reviewed-by: Daniel Thompson Signed-off-by: Duje Mihanović Link: https://lore.kernel.org/r/20240216-expresswire-deps-v2-2-8be59c4a75f5@skole.hr Signed-off-by: Lee Jones

leds: Make flash and multicolor dependencies unconditional

2024-03-07T08:48:03+00:00

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 Acked-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20240109090715.982332-2-arnd@kernel.org Signed-off-by: Lee Jones

leds: Introduce ExpressWire library

2024-03-07T08:45:03+00:00

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 Reviewed-by: Linus Walleij Reviewed-by: Daniel Thompson Signed-off-by: Duje Mihanović Link: https://lore.kernel.org/r/20240125-ktd2801-v5-1-e22da232a825@skole.hr Signed-off-by: Lee Jones

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

2023-12-21T14:45:35+00:00

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 Reviewed-by: Jernej Skrabec Link: https://lore.kernel.org/r/20231214192131.1309912-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones

leds: aw200xx: Add support for aw20108 device

2023-12-13T11:29:01+00:00

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 Signed-off-by: Dmitry Rokosov Link: https://lore.kernel.org/r/20231125200519.1750-10-ddrokosov@salutedevices.com Signed-off-by: Lee Jones