Document Top Control and Status Register (TCSR) controller on Qualcomm
Nord SoC.
Signed-off-by: Deepti Jaggi <deepti.jaggi@oss.qualcomm.com>
Signed-off-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260504081122.825635-1-shengchao.guo@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
Improve code style. This includes the following:
- Formatting the max77759_chgr_irqs entries to fit in a single line
instead of breaking them into multiple lines to improve readability.
- Refactoring comments such that they're full sentences and have
punctuation marks for a couple of macro definitions to adhere to the
documentation style.
- Explicitly initializing `MAX77759_CHGR_MODE_OFF`.
Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
Link: https://patch.msgid.link/20260504-fix-mfd-max77759-driver-v1-1-4d4a31a1d214@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
The old-style gpio handling in wm8994 came from a commit 7c8844481a
("mfd: wm8994: Emulate level triggered interrupts if required") in
linux-3.11, but nothing in the kernel ever set the 'irq_gpio' member
in the wm8994_pdata structure, so this was always dead code.
Remove it now to reduce the dependency on the legacy gpio interfaces.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260427143437.3059210-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
There are board files in-tree that want to request GPIOs from this chip.
They currently rely on the GPIO core's mechanism of matching software
nodes' labels against GPIO controller names. We want to remove this
behavior from the kernel and to this end, we need to associate the
referenced GPIO controller with its target software node.
Create a dedicated GPIO software node for cs5535, assign it to the GPIO
cell and expose its address in a new header.
We only expose a single software node instance but that's alright: all
existing hardware only contains a single cs5535 companion and the geode
board file for which we expose this is legacy anyway.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260429-cs5535-swnode-v1-1-2bc5e17ddcf9@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
The various struct pci_device_id arrays were initialized mostly by one
of the PCI_DEVICE macros and then list expressions. The latter isn't
easily readable if you're not into PCI. Using named initializers is more
explicit and thus easier to parse.
The secret plan is to make struct pci_device_id::driver_data an
anonymous union (similar to
https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
and that requires named initializers. But it's also a nice cleanup on
its own.
This change doesn't introduce changes to the compiled pci_device_id
arrays. Tested on x86 and arm64.
Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/20260429170652.4178050-2-u.kleine-koenig@baylibre.com
Signed-off-by: Lee Jones <lee@kernel.org>
Due to lack of time I did not perform reviews of patches for Samsung
PMIC drivers last year, at least not in timely manner. I still can
perform limited testing of the code on hardware, but that does not
warrant having "M" here.
Maintainer should be responsive, so drop my name and shift these drivers
maintenance to André Draszik (from previous reviewer role).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: André Draszik <andre.draszik@linaro.org>
Link: https://patch.msgid.link/20260428135216.100135-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
Convert the Hisilicon Hi655x PMIC binding from the text format to DT schema
to enable dtbs_check validation.
The 'regulators' child node is added based on existing usage in
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts, which defines child
regulator nodes not documented in the original .txt binding.
The uppercase LDO names are retained to match existing DTS usage.
Signed-off-by: Shaunak Datar <shaunakkdatar@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260423113237.260652-1-shaunakkdatar@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The Khadas VIM4 MCU register is slightly different
from previous boards' MCU.
This board also features a switchable power source for its fan.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260421-add-mcu-fan-khadas-vim4-v4-1-447114a28f2d@aliel.fr
Signed-off-by: Lee Jones <lee@kernel.org>
The RZ/G3{E,L} SoCs have an LVDS Common (LVDS_CMN) region which is common
to all LVDS channels. The RZ/G3L has single-link, but the RZ/G3E has both
single and dual-link.
Use the syscon interface to access these registers for scalability.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260421172910.218497-2-biju.das.jz@bp.renesas.com
Signed-off-by: Lee Jones <lee@kernel.org>
On devices with a UCSI PPM in the EC, check for cros_ec_ucsi to be
defined in the OF device tree or an ACPI node. If it is defined by
either OF or ACPI, it does not need to be added as a subdevice of
cros_ec_dev mfd. cros_ec_ucsi will load from the OF or ACPI node.
Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Link: https://patch.msgid.link/20260403222253.1888991-2-jthies@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
When platform_device_register() fails in sm501_register_device(), the
embedded struct device in pdev has already been initialized by
device_initialize(), but the failure path only reports the error and
returns without dropping the device reference for the current platform
device:
sm501_register_device()
-> platform_device_register(pdev)
-> device_initialize(&pdev->dev)
-> setup_pdev_dma_masks(pdev)
-> platform_device_add(pdev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: b6d6454fdb ("[PATCH] mfd: SM501 core driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260415162627.3558789-1-lgs201920130244@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add register definitions and a new 'type' enum to be passed via MFD
private data to support the BQ25792, which is a newer variant of the
BQ257xx family.
BQ25792 shares similar logic of operation with the already supported
BQ25703A but has a completely different register map and different
electrical constraints.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260331-bq25792-v6-9-0278fba33eb9@flipper.net
Signed-off-by: Lee Jones <lee@kernel.org>
TI BQ25792 is similar in operation to BQ25703A, but has a different
register layout and different current/voltage capabilities.
Expand the existing BQ25703A binding to include BQ25792, and move the
voltage and current limits into per-variant conditional statements.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Tested-by: Chris Morgan <macromorgan@hotmail.com>
Link: https://patch.msgid.link/20260331-bq25792-v6-1-0278fba33eb9@flipper.net
Signed-off-by: Lee Jones <lee@kernel.org>
Add a "spacemit-p1-reboot" cell for the SpacemiT P1 chip.
Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Tested-by: Vincent Legoll <legoll@online.fr> # OrangePi-RV2
Link: https://patch.msgid.link/20251102230352.914421-3-aurelien@aurel32.net
Signed-off-by: Lee Jones <lee@kernel.org>
The BD72720 header reserves an ID for BUCK11. While this does not (at
the moment) cause problems I can see, it is misleading as the BD72720
contains only 10 BUCKs.
Make the code clearer and drop the BUCK11 ID.
Fixes: af25277b1d ("mfd: rohm-bd71828: Support ROHM BD72720")
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Link: https://patch.msgid.link/812c3749a18d609d6f4698506bc516ec7183dfdd.1775565298.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
To allow instantiating subdevices such as the regulator and poweroff
devices that do not have corresponding device tree nodes with a
"compatible" property, use devm_mfd_add_devices() with MFD cells instead
of devm_of_platform_populate(). Since different PMICs in the SC27xx
series contain different components, use separate MFD cell tables for
each PMIC model. Define cells for all components that have upstream
drivers at this point.
Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
Link: https://patch.msgid.link/20260329-sc27xx-mfd-cells-v3-3-9158dee41f74@abscue.de
Signed-off-by: Lee Jones <lee@kernel.org>
Currently, the TPS65219 driver unconditionally registers a poweroff
handler. This causes issues on systems where a different component
(such as TF-A firmware) should handle system poweroff instead.
Make the poweroff handler registration conditional based on the
"system-power-controller" device tree property. This follows the
standard kernel pattern where only the designated power controller
registers for system poweroff operations.
On systems where the property is absent, the PMIC will not register
a poweroff handler, allowing other poweroff mechanisms to function.
Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
Link: https://patch.msgid.link/20260401112257.1248437-3-a-kaur@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>
In tps65910_i2c_probe(), a dummy I2C transfer is performed to work
around silicon erratum SWCZ010. However, the return value of
i2c_master_send() is not checked.
If this dummy transfer fails, the driver continues execution without
detecting the error. This may lead to subsequent I2C operations also
failing, but the driver would incorrectly report success.
Add proper return value checking for the dummy I2C transfer. If the
transfer fails, log the error and return an appropriate error code
to the caller.
Signed-off-by: Wenyuan Li <2063309626@qq.com>
Link: https://patch.msgid.link/tencent_01102156392EC89EDF2CA22A7C8B4ABB2509@qq.com
Signed-off-by: Lee Jones <lee@kernel.org>
The "multi_max_intensity" sysfs attribute was not included
in kernel 7.1, so update the KernelVersion and Date tags
accordingly.
Fixes: b1a9b7a904af ("leds: Introduce the multi_max_intensity sysfs attribute")
Signed-off-by: Armin Wolf <W_Armin@gmx.de>
Link: https://patch.msgid.link/20260527001422.51111-1-W_Armin@gmx.de
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: e381322b01 ("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>
Add documentation to describe how hardware patterns (as defined by the
documentation of leds-trigger-pattern) are parsed and implemented by the
Samsung S2M series PMIC RGB LED driver.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-8-73f9702fb461@disroot.org
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>
Certain Samsung S2M series PMICs have a flash LED controller with
two LED channels, and with torch and flash control modes. Document the
devicetree schema for the device.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260516-s2mu005-pmic-v7-1-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>
Adjust documentation of brightness sysfs node about accepted value range.
The code accepts only decimal values. We may not relax that due to different
readings for, e.g., octal 0100, which becomes 64 instead of currently parsed
100.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20260513220620.369825-1-andriy.shevchenko@linux.intel.com
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>
Document TI LM3559 and LM3560 Synchronous Boost Flash Driver used for
camera flash LEDs.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260506064847.37795-2-clamor95@gmail.com
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 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 <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>
Documentation/ABI/testing/sysfs-class-led-multicolor is a plain ABI
description without a .rst suffix. The lp5812 documentation incorrectly
referred to sysfs-class-led-multicolor.rst, which does not exist.
This was reported by documentation-file-ref-check (make refcheckdocs).
Signed-off-by: Xinhong Hu <tp5092@foxmail.com>
Link: https://patch.msgid.link/tencent_26F6155ED10CA20CC65F62FD659218853809@qq.com
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>
Changes leds/common.h DT binding header file to be published under GPLv2
or BSD-2-Clause license terms. This change allows this common LED
bindings header file to be used in software components as bootloaders
and OSes that are not published under GPLv2 terms.
All contributors to leds/common.h file in copy.
Signed-off-by: Corvin Köhne <c.koehne@beckhoff.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Gergo Koteles <soyer@irl.hu>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Rafał Miłecki <rafal@milecki.pl>
Link: https://patch.msgid.link/20260408062942.7128-1-corvin.koehne@gmail.com
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 575f10dc64 ("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>
30 duty cycle for IR transmitter is used in Xiaomi Redmi Note 8 (ginkgo).
Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
Reviewed-by: Sean Young <sean@mess.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260325-ginkgo-add-usb-ir-vib-v1-4-446c6e865ad6@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
