| Age | Commit message (Collapse) | Author |
|---|
|
https://git.kernel.org/pub/scm/linux/kernel/git/lee/leds.git
|
|
The reg property from the device tree is used directly as an array index
into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS
would cause an out-of-bounds write during probe.
Fixes: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB849718B43321DB7E5A05D17BC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB8497F11B30FE7D74CAA25135C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB8497570FD162D0D42A9864E3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB849724B0FF00255F4760FAE0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB849732C162CFE9E2C525AC16C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84971D3AF982F4F707A378F0C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84975929B6ED7CDFBCEB7D76C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 259230378c65 ("leds: Add LED1202 I2C driver")
Signed-off-by: Manuel Fombuena <fombuena@outlook.com>
Assisted-by: Claude:claude-sonnet-4-6
Link: https://patch.msgid.link/GV1PR08MB84978D0F499774773C7DA1FCC5F52@GV1PR08MB8497.eurprd08.prod.outlook.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: 3c1ab50d0a31 ("drivers/leds/leds-pca9532.c: add gpio capability")
Signed-off-by: Cosmo Chou <chou.cosmo@gmail.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703014201.69829-1-chou.cosmo@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
files)
Replace the #include of <linux/mod_devicetable.h> by the more specific
<linux/device-id/*.h> where applicable. For most cases the include
can be dropped completely, only a few drivers need one or two headers
added.
Acked-by: Danilo Krummrich <dakr@kernel.org>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/1a3f2007c5c5dcf555c09a4035ce3ae8ef1b6c49.1782808461.git.u.kleine-koenig@baylibre.com
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
|
|
If lp5860_device_init() fails, a missing mutex_destroy() should be called.
Use devm_mutex_init() instead of mutex_init() to fix it.
This also simplifies the remove function.
Fixes: f0a66563aa2d ("leds: Add support for TI LP5860 LED driver chip")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/311792e767ab803d4744bc26155e6dac253d9b45.1781970783.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
In lp5860_device_init(), if lp5860_init_dt() fails, an already unlocked
mutex is unlocked another time.
Slightly rework how the lock is taken/released to avoid this potential
double unlock.
Fixes: f0a66563aa2d ("leds: Add support for TI LP5860 LED driver chip")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://patch.msgid.link/0f4d556e0532bfa881d7d83c1e244572117a89e3.1781970674.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Add 25G, 40G, 50G, and 100G as available speeds to the netdev LED trigger.
Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260520200337.204431-2-mike.marciniszyn@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <jre@pengutronix.de>
Link: https://patch.msgid.link/20260605-multicolor-default-v2-2-ed07271df6b0@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
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 <matthias.fend@emfend.at>
Link: https://patch.msgid.link/20260527-leds-tps6131x-ovp-v1-1-1ac70d03c9eb@emfend.at
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <arnd@arndb.de>
Link: https://patch.msgid.link/20260526103738.3389272-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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: stable@vger.kernel.org
Fixes: e381322b0190 ("leds: Introduce userspace LED class driver")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260524235553.189134-1-W_Armin@gmx.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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) <u.kleine-koenig@baylibre.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Link: https://patch.msgid.link/20260522104222.4081017-2-u.kleine-koenig@baylibre.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <alhouseenyousef@gmail.com>
Link: https://patch.msgid.link/20260521181205.15130-1-alhouseenyousef@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
While the LED is controlled fully by the hardware, the value cached by
the LED driver core is incorrect. Return ENODATA to userspace in this
case.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://patch.msgid.link/20260521-cros_ec-leds-hw-trigger-brightness-v1-1-6cd9d7c9671e@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Replace the OF based lookup with the fwnode equivalent to get support
for ACPI and software nodes.
Signed-off-by: Alban Bedel <alban.bedel@lht.dlh.de>
Link: https://patch.msgid.link/20260513115853.1584230-1-alban.bedel@lht.dlh.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <kauschluss@disroot.org>
Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-7-73f9702fb461@disroot.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <kauschluss@disroot.org>
Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-6-73f9702fb461@disroot.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <craig@mcqueen.au>
Link: https://patch.msgid.link/20260423113638.2079302-1-craig@mcqueen.au
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <sozdayvek@gmail.com>
Link: https://patch.msgid.link/20260510003632.35942-1-sozdayvek@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <wse@tuxedocomputers.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260509214603.262368-2-W_Armin@gmx.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Thomas Weißschuh <linux@weissschuh.net> # leds-cros_ec.c
Reviewed-by: Tzung-Bi Shih <tzungbi@kernel.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260505102846.186219-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <s.trumtrar@pengutronix.de>
Link: https://patch.msgid.link/20260505-v6-14-topic-ti-lp5860-v10-1-ee29341a75e4@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <sozdayvek@gmail.com>
Link: https://patch.msgid.link/20260504123730.1094-1-sozdayvek@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427070117.18363-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
kconfiglint reports:
X001: CONFIG_LEDS_AS3668 referenced in Makefile but not defined
in any Kconfig
The AS3668 LED driver was introduced in
commit c7dd343a3756 ("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 <sashal@kernel.org>
Acked-by: Lukas Timmermann <linux@timmermann.space>
Link: https://patch.msgid.link/20260426000322.55999-1-sashal@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <rosenp@gmail.com>
Link: https://patch.msgid.link/20260409171555.14580-1-rosenp@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <piotr@kubik.pl>
Link: https://patch.msgid.link/20260408115106.379834-1-piotr@kubik.pl
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 575f10dc64a2 ("leds: pca955x: Add
HW blink support").
Signed-off-by: Tobias Deiminger <tobias.deiminger@linutronix.de>
Link: https://patch.msgid.link/20260331202848.658676-1-tobias.deiminger@linutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The driver includes the legacy GPIO header <linux/gpio.h> but does
not use any symbols from it so drop the include.
Signed-off-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260327-leds-st1202-v1-1-15c107cc9fb9@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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/20260603012840.2254293-10-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
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 <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260327102729.797254-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
In preparation to class_find_device_by_of_node() going away switch to
using class_find_device_by_fwnode().
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260322-remove-device-find-by-of-node-v1-5-b72eb22a1215@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260316-gpio-of-kconfig-v2-4-de2f4b00a0e4@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 <richard.lyu@suse.com>
Link: https://patch.msgid.link/20260320035451.31071-1-richard.lyu@suse.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix formatting issues reported by checkpatch.pl, such as extra empty
lines, lack of braces on some branches, and misaligned function
arguments.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260311-led-swnode-name-v1-2-798a49e041c6@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
If a software node defining an LED is missing explicit 'label', 'color',
or 'function' properties, led_compose_name() currently fails with
-EINVAL, because fallback to using node name in place of LED name/label
is only implemented for OF nodes.
Implement similar fallback for software nodes. Unlike OF nodes, which
use the short 'name' attribute of the device tree node to avoid
including the address block, use fwnode_get_name() directly since
swnodes do not include an address block and always have a valid name.
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Link: https://patch.msgid.link/20260311-led-swnode-name-v1-1-798a49e041c6@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Replace unused argument pinc with used argument pin.
Signed-off-by: Lukas Kraft <rebootrequired42@gmail.com>
Link: https://patch.msgid.link/20260312210958.48467-1-rebootrequired42@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
check.
Change generated with coccinelle.
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Link: https://patch.msgid.link/20260310-b4-is_err_or_null-v1-51-bd63b656022d@avm.de
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The EEPROM has limited writes and the contents might have factory set
values that should not be changed. The values currently written by this
driver are just one example of values, but might not be correct for many
use-cases. Do not overwrite the EEPROM with these example values every
probe.
At some point it would be better to populate the content of the EEPROM
based on a configuration provided by the user and check that the values
in EEPROM are not already the same to avoid unneeded write cycles.
That configuration would depend on how the device is used on the board to
which it is attached, for that Device Tree might be the right way. Until a
method can be devised, gate the EEPROM writing behind a module param.
Reported-by: David Owens <daowens01@gmail.com>
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20260305203706.841384-5-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
This register is read but the contents are never checked, remove
the read until we add status checking. While here add an error
message should the preceding fault check fail.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20260305203706.841384-4-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The lock is taken while unlocking the EEPROM but then released, it should
instead be held for the whole EEPROM programming process. To do this
merge in the lp8860_unlock_eeprom() function to the only call site in
the lp8860_init() function. This way we hold the lock for all steps.
While here, rename this function to lp8860_program_eeprom() to better
represent what it really does.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20260305203706.841384-3-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
No need to use goto to jump to a label that also just returns,
return directly in the if statements.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://patch.msgid.link/20260305203706.841384-2-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
