| Age | Commit message (Collapse) | Author |
|---|
|
The msm8960 RPM resource table is missing the QDSS clock entry (resource
ID 209) that is present in the android-msm-mako-3.4 downstream kernel.
Add it so that RPM clock initialization succeeds.
Tested-by: Rudraksha Gupta <guptarud@gmail.com>
Signed-off-by: Antony Kurniawan Soemardi <linux@smankusors.com>
Link: https://patch.msgid.link/20260514-msm8960-wifi-v2-3-7cbae45dab5e@smankusors.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix spelling mistake in comments:
- succes -> success (4 times)
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
Link: https://patch.msgid.link/20260514181954.1442-1-shofiqtest@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Convert max77620_pm_power_off() to the sys-off callback prototype and
register it with the sys-off API when the device tree marks the PMIC as
a system power controller. This also removes the global max77620_scratch
pointer by passing the chip instance through the callback data.
This modernizes the driver's poweroff handling and aligns it with
the kernel sys-off infrastructure.
Signed-off-by: Diogo Ivo <diogo.ivo@tecnico.ulisboa.pt>
Link: https://patch.msgid.link/20260514-smaug-poweroff-v1-2-30f9a4688966@tecnico.ulisboa.pt
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
On the MT6397 family each buck regulator has a separate supply. LDOs are
split into various groups with independent supplies. There is also a
supply for the regulator control logic.
Add descriptions for all of the supplies for the MT6359.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260514091520.2718987-2-wenst@chromium.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
MT6365 PMIC is compatible with MT6359, so add the compatible strings
for the main and sub devices (regulator, rtc, audio codec).
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
The rtc block of MT6359 PMIC is compatible with the one found in MT6358
but this compatibility was never expressed in the dt-bindings, so add
the missing compatible string for the rtc subnode.
Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://patch.msgid.link/20260429-mediatek-genio-mt6365-cleanup-v1-1-6f43838be92f@collabora.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Currently the code checks if a firmware was received, however it does
not verify that the firmware size is larger than the firmware header. As
the firmware pointer is dereferenced as a pointer to the header
structure this could lead to an out of bounds memory access. Add the
missing check.
Fixes: ace6d1448138 ("mfd: cs42l43: Add support for cs42l43 core driver")
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://patch.msgid.link/20260508134804.1787461-1-ckeepax@opensource.cirrus.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>
Acked-by: Guru Das Srinagesh <linux@gurudas.dev>
Link: https://patch.msgid.link/20260427070109.18271-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
If ec_device_probe() fails, cros_ec_class_release releases memory for the
cros_ec_dev structure. However, because the drvdata was already set,
sub-drivers like cros_ec_typec can still retrieve the stale pointer via the
platform device. This leads to a use-after-free when cros_ec_typec attempts
to access &typec->ec->ec->dev on a device that has already been released.
Move dev_set_drvdata() to ensure that the pointer is only made available
once all initialization steps have succeeded.
sysfs: cannot create duplicate filename '/class/chromeos/cros_ec'
Call trace:
sysfs_do_create_link_sd+0x94/0xdc
sysfs_create_link+0x30/0x44
device_add_class_symlinks+0x90/0x13c
device_add+0xf0/0x50c
ec_device_probe+0x150/0x4f0
platform_probe+0xa0/0xe0
...
BUG: KASAN: invalid-access in __memcpy+0x44/0x230
Write at addr f5ffff809e2d33ac by task kworker/u32:5/125
Pointer tag: [f5], memory tag: [fe]
Tainted : [W]=WARN, [O]=OOT_MODULE
Hardware name: Google Navi unprovisioned 0x7FFFFFFF/sku0 board/sku3
Workqueue: events_unbound deferred_probe_work_func
Call trace:
__memcpy+0x44/0x230
cros_ec_check_features+0x60/0xcc [cros_ec_proto]
cros_typec_probe+0xe8/0x6e0 [cros_ec_typec]
platform_probe+0xa0/0xe0
Cc: stable@vger.kernel.org
Fixes: 1c1d152cc5ac ("platform/chrome: cros_ec_dev - utilize new cdev_device_add helper function")
Co-developed-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Link: https://patch.msgid.link/20260427131721.1165078-1-akuchynski@chromium.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
AST2700 consists of two interconnected SoC instances, each with its own
System Control Unit (SCU). The SCU0 provides pin control, interrupt
controllers, clocks, resets, and address-space mappings for the
Secondary and Tertiary Service Processors (SSP and TSP).
Describe the SSP/TSP address mappings using the standard
memory-region and memory-region-names properties.
Disallow legacy child nodes that are not present on AST2700, including
p2a-control and smp-memram. The latter is unnecessary as software can
access the scratch registers via the SCU syscon.
Also allow the AST2700 SoC0 pin controller to be described as a child
node of the SCU0, and add an example illustrating the SCU0 layout,
including reserved-memory, interrupt controllers, and pinctrl.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Linus Walleij <linusw@kernel.org>
Link: https://patch.msgid.link/20260428-upstream_pinctrl-v8-2-eb8ef9ab0498@aspeedtech.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Support for the Motorola EZX phones based on Intel PXA processors was
removed in 2022, but this driver remained present in the tree. As far
as I can tell, the support was never quite functional upstream because
the board files did not actually instantiate the SPI device for the PCAP.
There are still also drivers for the various mfd cells: keys, touchscreen,
regulator and rtc, all of which are obviously orphaned as well but can
be removed separately as the Kconfig dependency now prevents them from
being enabled.
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202604301209.f1YXTsIr-lkp@intel.com/
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Acked-by: Harald Welte <laforge@gnumonks.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260430162855.2029285-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
i2c_check_functionality() returns a boolean status rather than an error
code - directly use it as a boolean value.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260505114543.159381-2-thorsten.blum@linux.dev
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Inline the i2c_check_functionality() check, since the function returns a
boolean status rather than an error code.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Link: https://patch.msgid.link/20260428165800.590496-3-thorsten.blum@linux.dev
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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 7c8844481a1c
("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>
|
|
Add compatible string, i2c_devcie_id and spi_devcie_id to support
8a34002.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Link: https://patch.msgid.link/20260429072047.1111427-3-dev.mbstr@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
Fix writes to page register in 8A3400x family (Clock Matrix).
All calls to rsmu_write_page_register() (both in i2c and spi) have
resulted in early return, because all addresses in
include/linux/mfd/idt8a340_reg.h are less than RSMU_CM_SCSR_BASE.
There were 2 separate patch series which have to be merged in one time:
mfd and ptp. The latter have been merged, the former[1] have not.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Fixes: 67d6c76fc815 ("mfd: rsmu: Support 32-bit address space")
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Link: https://patch.msgid.link/20260429072047.1111427-2-dev.mbstr@gmail.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: b6d6454fdb66f ("[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: af25277b1ddc ("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: 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>
|
|
RGB LEDs
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>
|
