Pull LED updates from Lee Jones:
"New Support & Features:
- Core: Extend netdev trigger speeds up to 100G
- PWM Multicolor: Introduce default-intensity property
- Analog Devices LTC3220: Add support for 18 channel LED driver
- NXP PCA963x: Add multicolor LED class support
Improvements & Fixes:
- GPIO: Clear error pointers for skipped LEDs
- Broadcom BCM63138: Use %pe to print pinctrl error instead of %ld
- ISSI IS31FL319x: Modernize device registration by using fwnode APIs
- NXP PCA9532: Fix inverted GPIO output polarity
- NXP PCA9532: Fix phantom device registration on missing hardware
- STMicroelectronics ST1202: Correct and extend hw_pattern
documentation
- STMicroelectronics ST1202: Fix channel disable logic on zero
brightness and ensure brightness changes are applied in active mode
- STMicroelectronics ST1202: Fix hardware pattern sequence
programming, validate inputs, and correct pattern duration
calculations
- STMicroelectronics ST1202: Validate LED reg property against
channel count
- TI LP5860: Fix a potential double-unlock during device
initialization and fix error handling path by using
devm_mutex_init()
Cleanups & Refactoring:
- GPIO: Make legacy gpiolib interface optional
Device Tree Binding Updates:
- Core: Add default-intensity property
- Core: Document "gpio" trigger
- Analog Devices LTC3220: Add DT binding for LTC3220 18 channel LED
driver
- Broadcom BCM6358: Convert to DT schema
- LaCie NS2: Convert to DT schema
- NXP PCA963x: Add multicolor LED support
- NXP PCA963x: Fix reg maximum for pca9635
- TI TPS65217: Convert backlight bindings to DT schema"
* tag 'leds-next-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (29 commits)
leds: is31fl319x: Modernize registration
dt-bindings: leds: lacie,ns2-leds: Convert to DT schema
leds: pca963x: Add multicolor LED class support
dt-bindings: leds: nxp,pca963x: Add multicolor LED support
dt-bindings: leds: nxp,pca963x: Fix reg maximum for pca9635
leds: gpio: Clear error pointers for skipped LEDs
dt-bindings: leds: backlight: Convert TPS65217 to DT schema
leds: pca9532: Fix phantom device registration on missing hardware
leds: gpio: Make legacy gpiolib interface optional
leds: bcm63138: Use %pe to print pinctrl error instead of %ld
dt-bindings: leds: Add default-intensity property
leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
dt-bindings: leds: Add LTC3220 18 channel LED Driver
dt-bindings: leds: bcm6358: Convert to DT schema
dt-bindings: leds: Document "gpio" trigger
leds: st1202: Correct and extend hw_pattern documentation
leds: st1202: Validate LED reg property against channel count
leds: st1202: Disable channel when brightness is set to zero
leds: st1202: Fix brightness having no effect while pattern mode is active
leds: st1202: Fix spurious pattern sequence start in setup
...
Use _ext version to have properties parsed to avoid needing to parse
them in the driver itself. More modern properties are recognized and
the LEDs can be referenced via phandle.
Due to the maximum current mechanics, LEDs are not registered right
in the first iteration over the nodes.
Signed-off-by: Andreas Kemnade <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Allow grouping of individual PCA963x PWM channels into a single
multicolor LED device by adding support for the LED multicolor class.
A child node with sub-children is treated as a multicolor group,
others are treated as single leds, keeping full backwards compatibility.
Signed-off-by: Loic Poulain <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
gpio_led_get_gpiod() returns an error pointer when a platform-data
LED's GPIO is unavailable. gpio_led_probe() skips registration in that
case, but leaves the error pointer in led_dat->gpiod.
The skipped entry remains included in priv->num_leds. During shutdown,
gpio_led_shutdown() walks those entries and passes the error pointer to
gpio_led_set(), producing:
gpiod_set_value: invalid GPIO (errorpointer: -ENOENT)
Clear led_dat->gpiod before skipping the LED so skipped entries do not
retain error-valued descriptors.
Fixes: 45d4c6de4e ("leds: gpio: Try to lookup gpiod from device")
Suggested-by: Lee Jones <[email protected]>
Assisted-by: ChatGPT:GPT-5.5-Thinking
Signed-off-by: Steve Dunnagan <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
The initial PWM and PSC register writes in pca9532_configure() do not
check the return values of i2c_smbus_write_byte_data(). If the I2C
device is physically absent from the bus, the write fails with -ENXIO.
However, the driver ignores this error and allows probe() to complete
successfully.
This results in the registration of phantom LED class devices and
gpiochips backed by non-existent hardware. Subsequent GPIO reads from
these phantom chips return bogus values (due to -ENXIO being truncated
to an unsigned char in pca9532_gpio_get_value()), silently corrupting
hardware state tracking in userspace.
Propagate the I2C write failures back to probe() so the driver core
can gracefully abort binding and release devres-managed resources.
Fixes: e14fa82439 ("leds: Add pca9532 led driver")
Signed-off-by: Cosmo Chou <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
There are still a handful of ancient mips/armv5/sh boards that use the
gpio_led:gpio member to pass an old-style gpio number, but all modern
users have been converted to gpio descriptors.
While the CONFIG_GPIOLIB_LEGACY option that guards devm_gpio_request_one()
and related helpers is currently turned on in all kernel builds,
the plan is to only enable it on the few platforms that actually
pass gpio numbers in any platform_data.
Split out the legacy portion of the platform_data handling into a custom
helper function that is guarded with in #ifdef block, to allow the
the leds-gpio driver to compile cleanly when CONFIG_GPIOLIB_LEGACY
gets turned off. Once the last user is converted, this function can
be removed.
Link: https://lore.kernel.org/all/[email protected]/
Signed-off-by: Arnd Bergmann <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]> # for input
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
When brightness_set() is called with LED_OFF, only the ILED register is
zeroed; the channel enable bit is left set from probe time. A hardware
channel enabled with ILED=0 still draws a small residual current, causing
a dim glow even when the LED is supposed to be off.
Fix this by splitting st1202_channel_set() into a lockless inner function
__st1202_channel_set() and a locking wrapper, then calling the inner
function from brightness_set() while it already holds the mutex. The
channel is now disabled when value is zero and re-enabled when non-zero,
in the same lock region as the ILED write.
Fixes: 259230378c ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB8497F11B30FE7D74CAA25135C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
Once a hardware pattern is running (PATS=1), writing to the brightness
sysfs attribute only updates the ILED register. The visible output is
ILED x Pattern_PWM / 4095, so the change has little effect and the LED
never returns to steady static operation as the user expects.
The LED1202 has a single global sequencer shared across all channels.
Stopping it in brightness_set() to force static mode would halt running
patterns on all other active LEDs.
Instead, set all 8 PWM slots for the channel to ST1202_PATTERN_PWM_FULL
before writing ILED. With every step at full duty cycle, the output is
ILED x FULL / 4095 = ILED regardless of the sequencer state, without
disturbing other channels.
This also enables basic LED operation without the pattern trigger: with
the trigger set to none, the brightness sysfs attribute fully controls
the LED as a simple on/off device.
Fixes: 259230378c ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB8497570FD162D0D42A9864E3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
st1202_setup() writes PATS and PATSR to the Configuration register as
its final step, which starts the hardware pattern sequencer during
device probe before any patterns have been programmed. This causes the
device to run a sequence with whatever values happen to be in the
pattern registers at the time.
Remove the write. The device reset at the start of setup restores all
registers to their power-on defaults, leaving PATS and PATSR cleared.
Fixes: 259230378c ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB849724B0FF00255F4760FAE0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
pattern_clear() sets all PWM registers for the channel to LED_OFF (0).
In static mode (PATS=0), the LED output is ILED x Pattern0_PWM / 4095;
with Pattern0 at zero the LED remains dark regardless of the ILED value.
The LED1202 has a single global sequencer shared across all channels.
If another channel starts the sequencer after this one has been cleared,
the cleared channel runs through all 8 steps at zero duty cycle and
stays dark regardless of ILED.
Set all 8 PWM slots to ST1202_PATTERN_PWM_FULL so that ILED alone
controls the channel brightness in both static and sequencer modes.
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB849732C162CFE9E2C525AC16C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
The PATy_DUR register encodes duration as N × 22.2 ms, with register
value 0 reserved as a pattern skip indicator (§7.10). The driver
incorrectly subtracted 1 from the register value:
value / ST1202_MILLIS_PATTERN_DUR_MIN - 1
This caused two problems:
- All programmed durations were off by one step (~22 ms too short).
- Writing the minimum duration (22 ms) produced register value 0,
silently skipping the pattern step instead of setting a 22 ms
duration.
The maximum duration constant was also wrong at 5660 ms. The 8-bit
register saturates at 255, giving a maximum of 5610 ms (22 ms × 255).
Values above 5653 ms were already producing a uint8_t overflow and
writing 0 to the hardware.
Fix the formula by removing the erroneous subtraction, and derive the
maximum from the register width so the relationship is explicit. Update
the documentation to reflect the correct maximum.
This exposes a secondary issue: pattern_clear() was calling
st1202_duration_pattern_write() with ST1202_MILLIS_PATTERN_DUR_MIN to
reset unused slots, accidentally relying on the broken formula to
produce register value 0. With the corrected formula, the same call
writes 0x01 (22 ms), leaving unused slots as valid 22 ms zero-PWM
steps and making the LED appear off for 7 × 22 ms out of every cycle.
Write 0 directly to the duration registers in pattern_clear() so unused
slots are always explicitly marked as skip, independently of the
conversion formula.
Fixes: 259230378c ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
Input validation for pattern duration is performed inside the write
loop, after the pattern sequence has already been stopped. If
validation fails mid-loop the chip is left with the sequence stopped
and partially written pattern data, with no recovery.
Move all input validation before the mutex and before any hardware
interaction, so an invalid input leaves the chip state unchanged.
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84975929B6ED7CDFBCEB7D76C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
The LED1202 datasheet (section 4.8) states that modifications to the
Pattern Sequence Repetition register (PAT_REP) and pattern duration
registers are only applied after the sequence has completed or been
stopped. When the device is running in infinite loop mode (PAT_REP =
0xFF) the sequence never completes on its own, so these writes are
silently ignored by the hardware.
Neither pattern_clear() nor pattern_set() stop the running sequence
before modifying pattern registers, causing any subsequent pattern
reprogramming to have no effect when the previous pattern was set to
infinite repeat.
Fix this by clearing PATS in the Configuration register before touching
any pattern registers in both functions, ensuring the hardware accepts
the new values immediately.
Note that the LED1202 has a single global pattern sequencer shared by
all channels: PATS, PATSR, the duration registers, and PAT_REP are
chip-wide. Stopping the sequencer in pattern_clear() therefore halts
any pattern running on other channels. This is an inherent hardware
constraint; pattern_set() restarts the sequencer when a new pattern is
programmed.
Fixes: 259230378c ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <[email protected]>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84978D0F499774773C7DA1FCC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <[email protected]>
The pca9532_gpio_set_value() function incorrectly mapped the requested
value to PCA9532_ON and PCA9532_OFF, inverting the GPIO output polarity.
A requested logical high (val=1) incorrectly enabled the LED output
driver, which on this open-drain device pulls the pin low, while a
requested logical low (val=0) released the pin.
Correct the mapping so that val=1 yields PCA9532_OFF (pin released /
high-impedance) and val=0 yields PCA9532_ON (pin driven low).
pca9532_gpio_direction_input() is also updated to pass val=1 to
pca9532_gpio_set_value() to align with the corrected polarity mapping,
ensuring the pin remains not driven when configured as an input.
Fixes: 3c1ab50d0a ("drivers/leds/leds-pca9532.c: add gpio capability")
Signed-off-by: Cosmo Chou <[email protected]>
Reviewed-by: Bartosz Golaszewski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Like all LED drivers, pwm-multicolor supports turning on an LED on boot
by setting linux,default-trigger, e.g. to "default-on". pwm-multicolor
however scales the brightness of the color-component sub-LEDs with their
individual intensity value. Since these intensities are
zero-initialized, on boot a trigger is invisible until colors are set
from userspace.
Fix linux,default-trigger for pwm-multicolor by allowing for nonzero
default-intensities but default to 0 for backwards-compatibility.
Signed-off-by: Jonas Rebmann <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Pull LED updates from Lee Jones:
"New Support & Features:
- Samsung S2MU005: Add support for the Samsung S2MU005 PMIC which
includes flash and RGB LED controllers
- Texas Instruments:
- LP5812: Add support for the TI LP5812 LED driver
- LP5860: Add support for the Texas Instruments LP5860 LED matrix
driver via SPI
Improvements & Fixes:
- Core:
- Adjust the brightness sysfs node documentation to clarify that
only decimal values are accepted
- Fix a race condition in the software blink logic when stopping
blinking and setting brightness simultaneously
- Introduce the `multi_max_intensity` sysfs attribute for
multicolor LEDs to support hardware-based global brightness
control
- Replace OF-based device lookup with firmware node equivalents
to support ACPI and software nodes
- Return `ENODATA` when reading brightness from
hardware-controlled LEDs
- Set the coherent DMA mask to zero for the Samsung PMIC device
to suppress unnecessary "DMA mask not set" messages
- ams OSRAM AS3668: Fix a Kconfig symbol name mismatch in the
Makefile that prevented the driver from being built
- BlinkM: Fix spelling and comment style issues in the driver
- DAC124S085: Declare the SPI command word as `__le16` to ensure
correct endianness and pass sparse checks
- GPIO Trigger: Use `GPIOD_FLAGS_BIT_NONEXCLUSIVE` to allow sharing
GPIOs between the LED trigger and other drivers
- NXP PCA9532: Fix an issue where the LED would stop blinking when
changing brightness to a non-zero value
- Qualcomm: Unify the user-visible company name to "Qualcomm" across
flash LED config options
- Qualcomm LPG: Optimize memory allocation by combining main
structure and channels into a single allocation using flexible
array members
- Texas Instruments
- LP5860: Add missing `CONFIG_OF` dependency to prevent build
warnings
- TPS6131x: Increase the overvoltage protection threshold to 6V
to avoid false triggers with 5V input supplies
- Userspace LEDs (uLEDs):
- Fix a potential buffer overread by using `strnchr()` for name
string validation
- Return `-EFAULT` on `copy_to_user()` failure to properly handle
read errors
Cleanups & Refactoring:
- Core:
- Convert various `i2c_device_id` arrays to use named
initializers for improved robustness and readability
- Multi-color: Fix incorrect `KernelVersion` and `Date` tags for
the `multi_max_intensity` ABI
- Broadcom BCM63138 / ChromeOS EC: Move `MODULE_DEVICE_TABLE`
declarations next to the ID tables for consistency
- LP5812: Fix a sysfs ABI reference in the documentation
- ST1202: Remove an unused legacy GPIO header include
Device Tree Binding Updates:
- Class: Document the keyboard backlight LED class naming
conventions, including a new scheme for zoned backlights
- Core: Dual-license the common LED bindings header under GPLv2
and BSD-2-Clause
- IR SPI LED: Add a new 30% duty-cycle value for the IR transmitter
used in Xiaomi Redmi Note 8
- Samsung S2M series:
- Document the flash LED device bindings for Samsung S2M series
PMICs
- Document the pattern behavior for Samsung S2M series PMIC RGB
- S2MU005: Add device tree bindings for the S2MU005 PMIC,
including its flash and RGB LED sub-devices
- TI LM3560: Document the TI LM3559 and LM3560 synchronous boost
flash drivers"
* tag 'leds-next-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (30 commits)
leds: tps6131x: Increase overvoltage protection threshold to 6V
leds: Fix sysfs ABI date
leds: Fix CONFIG_OF dependency for LEDS_LP5860_CORE
leds: uleds: Fix potential buffer overread
leds: Use named initializers for arrays of i2c_device_data
leds: uleds: Return -EFAULT on copy_to_user() failure
leds: core: Report ENODATA for brightness of hardware controlled LED
leds: class: Use firmware nodes for device lookup
Documentation: leds: Document pattern behavior of Samsung S2M series PMIC RGB LEDs
leds: rgb: Add support for Samsung S2M series PMIC RGB LED device
leds: flash: Add support for Samsung S2M series PMIC flash LED device
dt-bindings: leds: Document Samsung S2M series PMIC flash LED device
leds: core: Fix race condition for software blink
leds: Adjust documentation of brightness sysfs node
leds: dac124s085: Declare SPI command word as __le16
leds: Introduce the multi_max_intensity sysfs attribute
dt-bindings: leds: Document TI LM3560 Synchronous Boost Flash Driver
leds: bcm63138/cros_ec: Move MODULE_DEVICE_TABLE next to the table itself
leds: Add support for TI LP5860 LED driver chip
Documentation: leds: leds-class: Document keyboard backlight LED class naming
...
Currently, there may be cases where the overvoltage detection is triggered
even with a valid and generally functioning hardware setup. This occurs,
for example, when the input voltage exceeds the currently used overvoltage
threshold of 4.65V (typical). Since input voltages up to 5V are supported,
the threshold should be adjusted accordingly.
While the target output voltage setting has no effect on the LED operation
used here, it indirectly selects the threshold for overvoltage detection.
Set this to a value of 4.95V to select a threshold of 6V (typical).
Signed-off-by: Matthias Fend <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Building LEDS_LP5860_SPI without CONFIG_OF leads to a build time warning:
WARNING: unmet direct dependencies detected for LEDS_LP5860_CORE
Depends on [n]: NEW_LEDS [=y] && LEDS_CLASS_MULTICOLOR [=y] && LEDS_CLASS [=y] && OF [=n]
Selected by [y]:
- LEDS_LP5860_SPI [=y] && NEW_LEDS [=y] && LEDS_CLASS_MULTICOLOR [=y] && SPI [=y]
Address this by adding the same dependency here as well.
Fixes: 3daf2c4ef82b ("leds: Add support for TI LP5860 LED driver chip")
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
The name string supplied by userspace is not guaranteed to be
null-terminated, so using strchr() on it might result in a buffer
overread. The same thing will happen when said string is used by
the LED class device.
Fix this by using strnchr() instead and explicitly check that
the name string is properly null-terminated.
Cc: [email protected]
Fixes: e381322b01 ("leds: Introduce userspace LED class driver")
Signed-off-by: Armin Wolf <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace and commas.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <[email protected]>
Reviewed-by: Alexander Sverdlin <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
uleds_read() copies the current brightness value to userspace but
ignores copy_to_user() failures. It then clears the pending update and
reports a successful full read even when no data was copied.
Return -EFAULT when the copy fails and leave the update pending so a
later read can retry.
Signed-off-by: Yousef Alhouseen <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Add support for the RGB LEDs found in certain Samsung S2M series PMICs.
The device has three LED channels, controlled as a single device. These
LEDs are typically used as status indicators in mobile phones.
The driver includes initial support for the S2MU005 PMIC RGB LEDs.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Add support for flash LEDs found in certain Samsung S2M series PMICs.
The device has two channels for LEDs, typically for the back and front
cameras in mobile devices. Both channels can be independently
controlled, and can be operated in torch or flash modes.
The driver includes initial support for the S2MU005 PMIC flash LEDs.
Signed-off-by: Kaustabh Chakraborty <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
led_set_brightness() function: Change handling of software blink to
avoid race conditions when stopping blink and setting brightness.
Triggers may call led_set_brightness(LED_OFF),
led_set_brightness(LED_FULL) in quick succession to disable blinking and
turn the LED on. If the delayed work task has not yet disabled blinking
by the time the second call occurs, then the brightness also needs to be
changed in the delayed work task.
Signed-off-by: Craig McQueen <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
dac124s085_set_brightness() builds a 16-bit SPI command word:
u16 word;
...
word = cpu_to_le16(((led->id) << 14) | REG_WRITE_UPDATE |
(brightness & 0xfff));
ret = spi_write(led->spi, (const u8 *)&word, sizeof(word));
cpu_to_le16() returns __le16, but the local 'word' is declared as
plain u16, which sparse flags:
drivers/leds/leds-dac124s085.c:42:14: warning: incorrect type in
assignment (different base types)
The bytes that hit the wire are correct because cpu_to_le16() does
the right thing on either endianness, but mixing the annotated and
unannotated types defeats sparse's __bitwise checking and would let
a future reader treat the buffer as a host-endian u16 by mistake.
Declare 'word' as __le16 to match how it is built and consumed.
No functional change.
Signed-off-by: Stepan Ionichev <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Some multicolor LEDs support global brightness control in hardware,
meaning that the maximum intensity of the color components is not
connected to the maximum global brightness. Such LEDs cannot be
described properly by the current multicolor LED class interface,
because it assumes that the maximum intensity of each color component
is described by the maximum global brightness of the LED.
Fix this by introducing a new sysfs attribute called
"multi_max_intensity" holding the maximum intensity values for the
color components of a multicolor LED class device. Drivers can use
the new max_intensity field inside struct mc_subled to tell the
multicolor LED class code about those values. Intensity values written
by userspace applications will be limited to this maximum value.
Drivers for multicolor LEDs that do not support global brightness
control in hardware might still want to use the maximum global LED
brightness supplied via devicetree as the maximum intensity of each
individual color component. Such drivers should set max_intensity
to 0 so that the multicolor LED core can act accordingly.
The lp50xx and ncp5623 LED drivers already use hardware-based control
for the global LED brightness. Modify those drivers to correctly
initalize .max_intensity to avoid being limited to the maximum global
brightness supplied via devicetree.
Reviewed-by: Werner Sembach <[email protected]>
Reviewed-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Armin Wolf <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it
exports, because this is easier to read and verify. It also makes more
sense since #ifdef for ACPI or OF could hide both of them.
Most of the privers already have this correctly placed, so adjust
the missing ones. No functional impact.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Thomas Weißschuh <[email protected]> # leds-cros_ec.c
Reviewed-by: Tzung-Bi Shih <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Add support for the Texas Instruments LP5860 LED driver chip
via SPI interfaces.
The LP5860 is an LED matrix driver for up to 196 LEDs, which supports
short and open detection of the individual channel select lines.
It can be connected to SPI or I2C bus. For now add support for SPI only.
Signed-off-by: Steffen Trumtrar <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Fix two issues in the comment above mutex_lock_interruptible() in
blinkm_transfer_hw():
- Spelling mistake (Aquire -> Acquire).
- Trailing "*/" was on the same line as text; move it to its own
line to match kernel coding style.
No functional change.
Signed-off-by: Stepan Ionichev <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
kconfiglint reports:
X001: CONFIG_LEDS_AS3668 referenced in Makefile but not defined
in any Kconfig
The AS3668 LED driver was introduced in
commit c7dd343a37 ("leds:
as3668: Driver for the ams Osram 4-channel i2c LED driver").
That commit defined the Kconfig symbol as LEDS_OSRAM_AMS_AS3668 in
drivers/leds/Kconfig but used the shorter name LEDS_AS3668 in the
Makefile's obj-* line.
Because the Makefile references CONFIG_LEDS_AS3668 which does not exist,
the driver can never be built — the obj-* line always evaluates to
obj- += leds-as3668.o (empty config), so the object file is never
compiled regardless of what the user selects in menuconfig.
Fix the Makefile to reference the correct Kconfig symbol
CONFIG_LEDS_OSRAM_AMS_AS3668, matching what is defined in
drivers/leds/Kconfig.
Assisted-by: Claude:claude-opus-4-6 kconfiglint
Signed-off-by: Sasha Levin <[email protected]>
Acked-by: Lukas Timmermann <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Use a flexible array member to combine kzalloc and kcalloc. This
required moving the struct lpg_channel definition up as flexible array
members require a full definition.
Add __counted_by for extra runtime analysis.
Signed-off-by: Rosen Penev <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
When a GPIO is shared between the LED trigger driver and another driver,
the LED trigger driver needs to request the GPIO with
GPIOD_FLAGS_BIT_NONEXCLUSIVE to allow both drivers to monitor the same
GPIO pin.
Without this flag, if another driver has already claimed the GPIO,
the LED trigger driver's gpiod_get_optional() call fails silently,
and the LED trigger doesn't work.
This is needed for scenarios like:
- SFP module presence/status LED triggered by SFP Mod_ABS/Rx_LOS
Both GPIOs are also monitored by the SFP driver for module state
management, so they need to be shared.
Signed-off-by: Piotr Kubik <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
pca9532 unexpectedly stopped blinking when changing brightness to a
non-zero value. To reproduce:
echo timer > /sys/class/leds/led-1/trigger # blinks
echo 255 > /sys/class/leds/led-1/brightness # blinking stops, light on
cat /sys/class/leds/led-1/trigger # still claims [timer]
According to Documentation/leds/leds-class.rst, only brightness = 0
shall be a stop condition:
> You can change the brightness value of a LED independently of the
> timer trigger. However, if you set the brightness value to LED_OFF it
> will also disable the timer trigger.
Therefore add a guard to continue blinking when brightness != LED_OFF,
similar to how pca955x does it since 575f10dc64 ("leds: pca955x: Add
HW blink support").
Signed-off-by: Tobias Deiminger <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
get_device_state() calls __ethtool_get_link_ksettings() on the trigger's
netdev, which will soon take the dev's ops lock. Three of its callers
already hold that lock and one doesn't, so the function would either
deadlock or run unprotected depending on the path.
Make get_device_state() expect the dev's ops lock held and switch to
netif_get_link_ksettings():
* netdev_trig_notify() NETDEV_UP / NETDEV_CHANGE / NETDEV_CHANGENAME
arrive with the dev's ops lock held (per netdevices.rst).
* set_device_name() does not hold the lock, take it explicitly.
Due to lock ordering we need to reshuffle the code in set_device_name()
a little bit. We need to find the device earlier on, so that we can
lock it before we take trigger_data->lock.
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
It is a usual pattern in the kernel to make releasing functions be NULL-aware
so they become a no-op. This helps reducing unneeded checks in the code where
the given resource is optional.
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
The mutex_lock()/mutex_unlock() pattern requires explicitly pairing
lock and unlock calls. Use guard(mutex) instead so the lock is
automatically released when the scope exits.
Convert to guard(mutex) in lm3642_torch_brightness_set(),
lm3642_strobe_brightness_set(), and lm3642_indicator_brightness_set().
Add #include <linux/cleanup.h> to support scoped guards.
Signed-off-by: Richard Lyu <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Lee Jones <[email protected]>
Linus Torvalds