kernel/drivers/leds/Kconfig, branch linux-6.9.y

leds: expresswire: Don't depend on NEW_LEDS

2024-03-07T08:48:11Z

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:03Z

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:03Z

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:35Z

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:01Z

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

leds: max5970: Add support for max5970

2023-12-13T11:28:41Z

The MAX5970 is hot swap controller and has 4 indication LED. Signed-off-by: Patrick Rudolph Signed-off-by: Naresh Solanki Link: https://lore.kernel.org/r/20231123132803.1107174-1-naresh.solanki@9elements.com Signed-off-by: Lee Jones

leds: aw2013: Select missing dependency REGMAP_I2C

2023-12-13T11:28:35Z

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 Acked-by: Nikita Travkin Fixes: 59ea3c9faf32 ("leds: add aw2013 driver") Link: https://lore.kernel.org/r/20231103114203.1108922-1-danct12@riseup.net Signed-off-by: Lee Jones

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

2023-12-13T11:28:30Z

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 Acked-by: Jernej Skrabec Acked-by: Palmer Dabbelt Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20231029212738.7871-3-samuel@sholland.org Signed-off-by: Lee Jones

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

2023-11-01T11:28:46Z

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 Link: https://lore.kernel.org/r/20230918161104.20860-4-kabel@kernel.org Signed-off-by: Lee Jones

leds: pca995x: Add support for PCA995X chips

2023-07-28T08:26:28Z

The PCA995x chips are I2C controlled LED drivers. Each chip has up to 16 outputs, each one with an individual 8-bit resolution PWM for brightness control. Signed-off-by: Isai Gaspar Signed-off-by: Marek Vasut # Basically rewrite the driver Link: https://lore.kernel.org/r/20230713163516.21644-2-marex@denx.de Signed-off-by: Lee Jones