When selecting the high resolution values from the array, FIELD_GET() is
used to pull from a 3 bit register, yet the array being indexed has only
5 values in it. Odds are the hardware is sane, but just to be safe,
properly check before just overflowing and reading random data and then
setting up chip values based on that.
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Link: https://patch.msgid.link/2026021934-nearby-playroom-036b@gregkh
Signed-off-by: Lee Jones <lee@kernel.org>
This was done entirely with mindless brute force, using
git grep -l '\<k[vmz]*alloc_objs*(.*, GFP_KERNEL)' |
xargs sed -i 's/\(alloc_objs*(.*\), GFP_KERNEL)/\1)/'
to convert the new alloc_obj() users that had a simple GFP_KERNEL
argument to just drop that argument.
Note that due to the extreme simplicity of the scripting, any slightly
more complex cases spread over multiple lines would not be triggered:
they definitely exist, but this covers the vast bulk of the cases, and
the resulting diff is also then easier to check automatically.
For the same reason the 'flex' versions will be done as a separate
conversion.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
The LP5812 is a 4x3 matrix RGB LED driver with an autonomous animation
engine and time-cross-multiplexing (TCM) support for up to 12 LEDs or
4 RGB LEDs. Each LED can be configured through the related registers
to realize vivid and fancy lighting effects.
This patch adds minimal driver support for the LP5812, implementing
only the essential functionality: I2C communication with the device,
LED registration, brightness control in manual mode, and basic sysfs
interfaces for LED configuration and fault monitoring.
Signed-off-by: Nam Tran <trannamatk@gmail.com>
Link: https://patch.msgid.link/20260115161013.40706-2-trannamatk@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The lpg_lut_store() function currently ignores the return value of
regmap_bulk_write() and always returns 0. This can cause hardware write
failures to go undetected, leading the caller to believe LUT programming
succeeded when it may have failed.
Check the return value of regmap_bulk_write() in lpg_lut_store and return
the error to the caller on failure.
Fixes: 24e2d05d1b ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn>
Link: https://patch.msgid.link/20260108175133.638-1-vulab@iscas.ac.cn
Signed-off-by: Lee Jones <lee@kernel.org>
The PWM signal from the LPG channel can be routed to PMIC GPIOs with
proper GPIO configuration, and it is not necessary to enable the
TRILED channel in that case. This also applies to the LPG channels
that mapped to TRILED channels. Additionally, enabling the TRILED
channel unnecessarily would cause a voltage increase in its power
supply. Hence remove it.
Fixes: 24e2d05d1b ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://patch.msgid.link/20251119-lpg_triled_fix-v3-2-84b6dbdc774a@oss.qualcomm.com
Signed-off-by: Lee Jones <lee@kernel.org>
fwnode_for_each_child_node() is now the same as
fwnode_for_each_available_child_node() on all backends (OF, ACPI and
swnode). In order to remove the available variants, switch the uses to
non-available variants.
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Lee Jones <lee@kernel.org>
When determining the actual best period by looping through all
possible PWM configs, the resolution currently used is based on
bit shift value which is off-by-one above the possible maximum
PWM value allowed.
So subtract one from the resolution before determining the best
period so that the maximum duty cycle requested by the PWM user
won't result in a value above the maximum allowed by the selected
resolution.
Cc: stable@vger.kernel.org # 6.4
Fixes: b00d2ed376 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-3-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently the
best matched period is never reported back to the PWM consumer, so the
consumer will still be using the requested period which is higher than
the best matched one. This will result in PWM consumer requesting
duty cycle values higher than the allowed PWM value.
For example, a consumer might request a period of 5ms while the best
(closest) period the PWM hardware will do is 4.26ms. For this best
matched resolution, if the selected resolution is 8-bit wide, when
the consumer asks for a duty cycle of 5ms, the PWM value will be 300,
which is outside of what the resolution allows. This will happen with
all possible resolutions when selected.
Since for these Hi-Res PWMs, the current implementation is capping the PWM
value at a 15-bit resolution, even when lower resolutions are selected,
the value will be wrapped around by the HW internal logic to the selected
resolution.
Fix the issue by capping the PWM value to the maximum value allowed by
the selected resolution.
Cc: stable@vger.kernel.org # 6.4
Fixes: b00d2ed376 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM")
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-2-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Ideally, the requested duty cycle should never translate to a PWM
value higher than the selected resolution (PWM size), but currently the
best matched period is never reported back to the PWM consumer, so the
consumer will still be using the requested period which is higher than
the best matched one. This will result in PWM consumer requesting
duty cycle values higher than the allowed PWM value.
For example, a consumer might request a period of 5ms while the best
(closest) period the PWM hardware will do is 4.26ms. For this best
matched resolution, if the selected resolution is 9-bit wide, when
the consumer asks for a duty cycle of 5ms, the PWM value will be 600,
which is outside of what the resolution allows. Similar will happen
if the 6-bit resolution is selected.
Since for these normal PWMs (non Hi-Res), the current implementation is
capping the PWM value at a 9-bit resolution, even when the 6-bit
resolution is selected, the value will be wrapped around to 6-bit value
by the HW internal logic.
Fix the issue by capping the PWM value to the maximum value allowed by
the selected resolution.
Fixes: 7a3350495d ("leds: rgb: leds-qcom-lpg: Add support for 6-bit PWM resolution")
Suggested-by: Anjelique Melendez <anjelique.melendez@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20250305-leds-qcom-lpg-fix-max-pwm-on-hi-res-v4-1-bfe124a53a9f@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
PULL LED updates from Lee Jones:
- Remove unused local header files from various drivers
- Revert platform driver removal to the original method for consistency
- Introduce ordered workqueues for LED events, replacing the less
efficient system_wq
- Switch to a safer iteration macro in several drivers to prevent
potential memory leaks
- Fix a refcounting bug in the mt6360 flash LED driver
- Fix an uninitialized variable in the mt6370_mc_pattern_clear()
function
- Resolve Smatch warnings in the leds-bcm6328 driver
- Address a potential NULL pointer dereference in the brightness_show()
function
- Fix an incorrect format specifier in the ss4200 driver
- Prevent a resource leak in the max5970 driver's probe function
- Add support for specifying the number of serial shift bits in the
device tree for the BCM63138 family
- Implement multicolor brightness control in the lp5562 driver
- Add a device tree property to override the default LED pin polarity
- Add a property to specify the default brightness value when the LED
is initially on
- Set missing timing properties for the ktd2692 driver
- Document the "rc-feedback" trigger for controlling LEDs based on
remote control activity
- Convert text bindings to YAML for the pca955x driver to enable device
tree validation
- Remove redundant checks for invalid channel numbers in the lp55xx
driver
- Update the MAINTAINERS file with current contact information
* tag 'leds-next-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (46 commits)
leds: ss4200: Fix the wrong format specifier for 'blinking'
leds: pwm: Add optional DT property default-brightness
dt-bindings: leds: pwm: Add default-brightness property
leds: class: Protect brightness_show() with led_cdev->led_access mutex
leds: ktd2692: Set missing timing properties
leds: max5970: Fix unreleased fwnode_handle in probe function
leds: Introduce ordered workqueue for LEDs events instead of system_wq
MAINTAINERS: Replace Siemens IPC related bouncing maintainers
leds: bcm6328: Replace divide condition with comparison for shift value
leds: lp55xx: Remove redundant test for invalid channel number
dt-bindings: leds: pca955x: Convert text bindings to YAML
leds: rgb: leds-mt6370-rgb: Fix uninitialized variable 'ret' in mt6370_mc_pattern_clear
leds: lp5562: Add multicolor brightness control
dt-bindings: leds: Add 'active-high' property
leds: Switch back to struct platform_driver::remove()
leds: bcm63138: Add some register defines
leds: bcm63138: Handle shift register config
leds: bcm63138: Use scopes and guards
dt-bindings: leds: bcm63138: Add shift register bits
leds: leds-gpio-register: Reorganize kerneldoc parameter names
...
Fix the uninitialized symbol 'ret' in the function mt6370_mc_pattern_clear
to resolve the following warning:
drivers/leds/rgb/leds-mt6370-rgb.c:604 mt6370_mc_pattern_clear()
error: uninitialized symbol 'ret'.
Initialize 'ret' to 0 to prevent undefined behavior from uninitialized
access.
Signed-off-by: Suraj Sonawane <surajsonawane0215@gmail.com>
Link: https://lore.kernel.org/r/20241016042142.8088-1-surajsonawane0215@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Switch to device_for_each_child_node_scoped() to simplify the code by
removing the need for calls to fwnode_handle_put() in the error paths.
This also prevents possible memory leaks if new error paths are added
without the required call to fwnode_handle_put().
After switching to the scoped variant, there is no longer need for a
jump to 'fwnode_release', as an immediate return is possible. Given that
the loop is called in the probe function, and it already uses
dev_err_probe(), the common "dev_err() + return" has been updated as
well.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-18-95c0614b38c8@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
Currently, all LED LPG devices will call lpg_{set,clear}_pbs_trigger()
when setting brightness regardless of if they support PPG and have PBS
triggers. Check if device supports PPG before setting/clearing PBS
triggers.
Fixes: 6ab1f766a8 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM")
Fixes: 5e9ff62686 ("leds: rgb: leds-qcom-lpg: Include support for PPG with dedicated LUT SDAM")
Signed-off-by: Anjelique Melendez <quic_amelende@quicinc.com>
Reviewed-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20240607005250.4047135-1-quic_amelende@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
Greg Kroah-Hartman
Linus Torvalds
Kees Cook
Nam Tran
Haotian Zhang
Fenglin Wu
Konrad Dybcio
Sakari Ailus
Christophe JAILLET
Andy Shevchenko
Abel Vesa
Yuanjun Gong
Anjelique Melendez
Jakob Riepler
Suraj Sonawane
Javier Carrasco
WangYuli
Al Viro
Krzysztof Kozlowski
Anjelique Melendez