props.timing is not set after commit b5a8c50e5c ("leds: ktd2692: Convert
to use ExpressWire library"). Set it with ktd2692_timing.
Fixes: b5a8c50e5c ("leds: ktd2692: Convert to use ExpressWire library")
Signed-off-by: Raymond Hackley <raymondhackley@protonmail.com>
Acked-by: Duje Mihanović <duje.mihanovic@skole.hr>
Link: https://lore.kernel.org/r/20241103083505.49648-1-raymondhackley@protonmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
An object initialized via device_get_named_child_node() requires calls
to fwnode_handle_put() when it is no longer required to avoid leaking
memory.
Add the automatic cleanup facility for 'led_node' to ensure that
fwnode_handle_put() is called in all execution paths.
Fixes: 736214b4b0 ("leds: max5970: Add support for max5970")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20241031-max5970-of_node_put-v2-1-0ffe1f1d3bc9@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This allows to setup ordered workqueue for LEDs events. This may be
useful, because default 'system_wq' does not guarantee execution order
of each work_struct, thus for several brightness update requests (for
multiple LEDs), real brightness switch could be in random order.
Yes, for sysfs-based LEDs we have flush_work() call inside
brightness_store() operation, but it's blocking call, so userspace
caller can be blocked at a long time, which means LEDs animation stream
can be broken.
Ordered workqueue has the same behaviour as system_wq + flush_work(),
but all scheduled works are async and userspace caller is not blocked,
which it better for userspace animation scheduling.
Signed-off-by: Alexey Romanov <avromanov@salutedevices.com>
Signed-off-by: Dmitry Rokosov <ddrokosov@salutedevices.com>
Link: https://lore.kernel.org/r/20240903223936.21292-1-ddrokosov@salutedevices.com
[Lee: Couple of style fix-ups]
Signed-off-by: Lee Jones <lee@kernel.org>
Since commit 92a81562e6 ("leds: lp55xx: Add multicolor framework
support to lp55xx") there are two subsequent tests if the chan_nr
(reg property) is in valid range. One in the lp55xx_init_led()
function and one in the lp55xx_parse_common_child() function that
was added with the mentioned commit.
There are two issues with that.
First is in the lp55xx_parse_common_child() function where the reg
property is tested right after it is read from the device tree.
Test for the upper range is not correct though. Valid reg values are
0 to (max_channel - 1) so it should be >=.
Second issue is that in case the parsed value is out of the range
the probe just fails and no error message is shown as the code never
reaches the second test that prints and error message.
Remove the test form lp55xx_parse_common_child() function completely
and keep the one in lp55xx_init_led() function to deal with it.
Fixes: 92a81562e6 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Cc: stable@vger.kernel.org
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Link: https://lore.kernel.org/r/20241017150812.3563629-1-michal.vokac@ysoft.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>
The framework for multicolor brightness control is already in place
in the lp55xx-common code but the function to control the multicolor
brightness for this particular chip is still missing.
Implement the multicolor_brightness_fn function to allow multicolor
brightness control of LEDs connected to the LP5562 LED driver.
Signed-off-by: Michal Vokáč <michal.vokac@ysoft.com>
Link: https://lore.kernel.org/r/20241009095635.2790613-1-michal.vokac@ysoft.com
Signed-off-by: Lee Jones <lee@kernel.org>
After commit 0edb555a65 ("platform: Make platform_driver::remove()
return void") .remove() is (again) the right callback to implement for
platform drivers.
Convert all platform drivers below drivers/leds/ to use .remove(), with
the eventual goal to drop struct platform_driver::remove_new(). As
.remove() and .remove_new() have the same prototypes, conversion is done
by just changing the structure member name in the driver initializer.
While touching these files, make indention of the struct initializer
consistent in several files.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@baylibre.com>
Link: https://lore.kernel.org/r/20241010203622.839625-5-u.kleine-koenig@baylibre.com
Signed-off-by: Lee Jones <lee@kernel.org>
The Power LUT (Look-up Table) register base was missing, also
add the bit define for sending serial LED data in reverse order,
and use the BIT() macro to define the bits in the control
register.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20241010-bcm63138-leds-v4-4-cdb80780a555@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
This adds code to optionally read the width of the shift register
chain from the device tree and use it to set up the register
controlling the shifter hardware.
If the property is not present, the boot-time default is used so
existing device trees keep working as this is what they assume.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20241010-bcm63138-leds-v4-3-cdb80780a555@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Use scoped helpers and guards to handle DT node iterations
and spinlocks. This cuts some lines of code and eliminates
common mistakes (such as the missing of_node_put()).
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20241010-bcm63138-leds-v4-2-cdb80780a555@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Reorganize kerneldoc parameter names to match the parameter
order in the function header.
Problems identified using Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Link: https://lore.kernel.org/r/20240930112121.95324-8-Julia.Lawall@inria.fr
Signed-off-by: Lee Jones <lee@kernel.org>
Commit 156a5bb89c ("leds: Move led_init_default_state_get() to the
global header") moved the only element leds-gpio required from the local
leds.h to its global counterpart. Drop the inclusion of the local leds.h
as it is no longer used.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240927-leds_unused_leds_h-v1-5-46fbf41ed4ae@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Commit 156a5bb89c ("leds: Move led_init_default_state_get() to the
global header") moved the only element leds-gpio required from the local
leds.h to its global counterpart. Drop the inclusion of the local leds.h
as it is no longer used.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240927-leds_unused_leds_h-v1-3-46fbf41ed4ae@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>
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 path.
This also prevents possible memory leaks if new error paths are added
without the required call to fwnode_handle_put().
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-17-95c0614b38c8@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 path.
This also prevents possible memory leaks if new error paths are added
without the required call to fwnode_handle_put().
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-16-95c0614b38c8@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().
The error handling after 'err_put_child' has been moved to the only goto
that jumps to it (second device_for_each_child_node()), and the call to
fwnode_handle_put() has been removed accordingly.
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-15-95c0614b38c8@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 'err_child_out', as an immediate return is possible.
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-14-95c0614b38c8@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 'err', as an immediate return is possible.
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-13-95c0614b38c8@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 path.
This also prevents possible memory leaks if new error paths are added
without the required call to fwnode_handle_put().
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-12-95c0614b38c8@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 'err_node_out', as an immediate return is possible.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20240927-leds_device_for_each_child_node_scoped-v1-11-95c0614b38c8@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 'child_out', as an immediate return is possible.
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-10-95c0614b38c8@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 'child_out', as an immediate return is possible.
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-9-95c0614b38c8@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 'child_out', as an immediate return is possible.
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-8-95c0614b38c8@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().
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-7-95c0614b38c8@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 'err_child_out', as an immediate return is possible.
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-6-95c0614b38c8@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().
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-5-95c0614b38c8@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().
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-4-95c0614b38c8@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().
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-3-95c0614b38c8@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().
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-2-95c0614b38c8@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The device_for_each_child_node() macro requires explicit calls to
fwnode_handle_put() upon early exits to avoid memory leaks, and in
this case the error paths are handled after jumping to
'out_flash_realease', which misses that required call to
to decrement the refcount of the child node.
A more elegant and robust solution is using the scoped variant of the
loop, which automatically handles such early exits.
Fix the child node refcounting in the error paths by using
device_for_each_child_node_scoped().
Cc: stable@vger.kernel.org
Fixes: 679f865206 ("leds: Add mt6360 driver")
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-1-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
no_llseek had been defined to NULL two years ago, in commit 868941b144
("fs: remove no_llseek")
To quote that commit,
At -rc1 we'll need do a mechanical removal of no_llseek -
git grep -l -w no_llseek | grep -v porting.rst | while read i; do
sed -i '/\<no_llseek\>/d' $i
done
would do it.
Unfortunately, that hadn't been done. Linus, could you do that now, so
that we could finally put that thing to rest? All instances are of the
form
.llseek = no_llseek,
so it's obviously safe.
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The update_hw_blink() function prints an error message when hardware is
not able to handle a blink configuration on its own. IMHO, this isn't a
'real' error since the software fallback is used afterwards.
Remove the error messages to avoid flooding the logs with unnecessary
messages.
Cc: stable@vger.kernel.org
Fixes: 48ca7f302c ("leds: pca9532: Use PWM1 for hardware blinking")
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240826133237.134604-1-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
With the new __counted_by annotation, the "num_leds" variable needs to
valid for accesses to the "leds" array. This requirement is not met in
gpio_leds_create(), since "num_leds" starts at "0", so "leds" index "0"
will not be considered valid (num_leds would need to be "1" to access
index "0").
Fix this by setting the allocation size after allocation, and then update
the final count based on how many were actually added to the array.
Fixes: 52cd75108a ("leds: gpio: Annotate struct gpio_leds_priv with __counted_by")
Signed-off-by: Kees Cook <kees@kernel.org>
Reviewed-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20240716212455.work.809-kees@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Simplify the code a bunch by using managed resource helpers.
Also, there is no need to save clk pointer anymore.
Suggested-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Huan Yang <link@vivo.com>
Link: https://lore.kernel.org/r/20240821013725.785956-1-link@vivo.com
Signed-off-by: Lee Jones <lee@kernel.org>
Drop the manual access to the fwnode of the device to iterate over its
child nodes. `device_for_each_child_node` macro provides direct access
to the child nodes, and given that the `child` variable is only required
within the loop, the scoped variant of the macro can be used.
Use the `device_for_each_child_node_scoped` macro to iterate over the
direct child nodes of the device.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Link: https://lore.kernel.org/r/20240820-device_child_node_access-v3-2-1ee09bdedb9e@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use scoped for_each_available_child_of_node_scoped() when iterating over
device nodes to make code a bit simpler.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Marek Behún <kabel@kernel.org>
Link: https://lore.kernel.org/r/20240816-cleanup-h-of-node-put-var-v1-16-1d0292802470@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
At beginning of probe() function, the driver iterates over OF children
and assigns found device node for later. The code uses
for_each_available_child_of_node() which drops the references on
children on each successful pass, thus the probe function operates later
on the device node without holding the reference.
Fix this by increasing the reference count for found child node and
drop it at the end of the probe, because it is not needed further (the
V4L init code takes its own references).
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240816-cleanup-h-of-node-put-var-v1-3-1d0292802470@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
Replace msleep() with usleep_range() in sun50i_a100_ledc_suspend()
to address the checkpatch.pl warning. msleep() for such short delay
can lead to inaccurate sleep times. Switch to usleep_range()
provide more precise delay.
Fix the following warning from checkpatch.pl:
WARNING: msleep < 20ms can sleep for up to 20ms;
see Documentation/timers/timers-howto.rst
+ msleep(1);
Signed-off-by: Abhishek Tamboli <abhishektamboli9@gmail.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Link: https://lore.kernel.org/r/20240816171129.6411-1-abhishektamboli9@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
With CONFIG_LEDS_CLASS_MULTICOLOR=m, a builtin leds-blinkm driver causes
a link failure:
arm-linux-gnueabi-ld: drivers/leds/leds-blinkm.o: in function `blinkm_set_mc_brightness':
leds-blinkm.c:(.text.blinkm_set_mc_brightness+0xc): undefined reference to `led_mc_calc_color_components'
Add a more specific dependency that only allows multicoler mode to
be enabled for blinkm if it can build and link.
Fixes: 56e8c56c9a ("leds: Add multicolor support to BlinkM LED driver")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Joseph Strauss <jstrauss@mailbox.org>
Link: https://lore.kernel.org/r/20240807075614.2118068-1-arnd@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
The current implementation accesses the `child` fwnode handle outside of
device_for_each_child_node() without incrementing its refcount.
Add the missing call to `fwnode_handle_get(child)`.
The cleanup process where `child` is accessed is not right either
because a single call to `fwnode_handle_put()` is carried out in case of
an error, ignoring unasigned nodes at the point when the error happens.
Keep `child` inside of the first loop, and use the helper pointer that
receives references via `fwnode_handle_get()` to handle the child nodes
within the second loop. Keeping `child` inside the first node has also
the advantage that the scoped version of the loop can be used.
Fixes: ee4e80b296 ("leds: pca995x: Add support for PCA995X chips")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240807-leds-pca995x-fix-fwnode-usage-v1-1-8057c84dc583@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The iterated nodes are direct children of the device node, and the
`device_for_each_child_node()` macro accounts for child node
availability.
`fwnode_for_each_available_child_node()` is meant to access the child
nodes of an fwnode, and therefore not direct child nodes of the device
node.
Use `device_for_each_child_node()` to indicate device's direct child
nodes.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240805-device_for_each_child_node-available-v3-2-48243a4aa5c0@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
LED controller should be reset during initialization to avoid abnormal
behaviors. For example, when power to SoC is recycled but power to LED
controller is not, LED controller should not presume to be in original
state.
Signed-off-by: Jack Chen <zenghuchen@google.com>
Link: https://lore.kernel.org/r/20240801153048.3813581-1-zenghuchen@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
The flash module has status bits to indicate different thermal
conditions which are called as OTSTx. For each OTSTx status,
there is a recommended total flash current for all channels to
prevent the flash module entering into higher thermal level.
For example, the total flash current should be limited to 1000mA/500mA
respectively when the HW reaches the OTST1/OTST2 thermal level.
Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
Link: https://lore.kernel.org/r/20240705-qcom_flash_thermal_derating-v3-1-8e2e2783e3a6@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
The iterated nodes are direct children of the device node, and the
`device_for_each_child_node()` macro accounts for child node
availability.
`fwnode_for_each_available_child_node()` is meant to access the child
nodes of an fwnode, and therefore not direct child nodes of the device
node.
In this case, the child nodes are not required outside the loop, and
the scoped version of the macro can be used to remove the repetitive
`goto put` pattern.
Use `device_for_each_child_node_scoped_scoped()` to indicate device's
direct child nodes.
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20240721-device_for_each_child_node-available-v2-4-f33748fd8b2d@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The current implementation accesses the `child` fwnode handle outside of
fwnode_for_each_available_child_node() without incrementing its
refcount. Add the missing call to `fwnode_handle_get(child)`.
The cleanup process where `child` is accessed is not right either
because a single call to `fwnode_handle_put()` is carried out in case of
an error, ignoring unasigned nodes at the point when the error happens.
Keep `child` inside of the first loop, and use the helper pointer that
receives references via `fwnode_handle_get()` to handle the child nodes
within the second loop.
Moreover, the iterated nodes are direct children of the device node,
and the `device_for_each_child_node()` macro accounts for child node
availability. By restricting `child` to live within that loop, the
scoped version of it can be used to simplify the error handling.
`fwnode_for_each_available_child_node()` is meant to access the child
nodes of an fwnode, and therefore not direct child nodes of the device
node.
Use `device_for_each_child_node_scoped()` to indicate device's direct
child nodes.
Fixes: 8325642d27 ("leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20240721-device_for_each_child_node-available-v2-3-f33748fd8b2d@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for PCA9956B chip, which belongs to the same family.
This chip features 24 instead of 16 outputs, so add a chipdef struct to
deal with the different register layouts.
Reviewed-by: Marek Vasut <marex@denx.de>
Signed-off-by: Pieterjan Camerlynck <pieterjanca@gmail.com>
Link: https://lore.kernel.org/r/20240711-pca995x-v4-2-702a67148065@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add multicolor support to the BlinkM driver, making it easier to control
from userspace. The BlinkM LED is a programmable RGB LED. The driver
currently supports only the regular LED sysfs class, resulting in the
creation of three distinct classes, one for red, green, and blue. The
user then has to input three values into the three seperate brightness
files within those classes. The multicolor LED framework makes the
device easier to control with the multi_intensity file: the user can
input three values at once to form a color, while still controlling the
lightness with the brightness file.
The main struct blinkm_led has changed slightly. The struct led_classdev
for the regular sysfs classes remain. The blinkm_probe function checks
CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate
sysfs classes or the single multicolor one, but never both. The
blinkm_set_mc_brightness() function had to be added to calculate the
three color components and then set the fields of the blinkm_data
structure accordingly.
Signed-off-by: Joseph Strauss <jstrauss@mailbox.org>
Link: https://lore.kernel.org/r/20240710184844.108006-1-jstrauss@mailbox.org
Signed-off-by: Lee Jones <lee@kernel.org>
This patch provides support for enabling blinking of LEDs when RX or TX
errors are detected.
Approach taken in this patch is similar to one for TX or RX data
transmission indication (i.e. TRIGGER_NETDEV_TX/RX attribute).
One can inspect transmission errors with:
ip -s link show eth0
Example LED configuration:
cd /sys/devices/platform/amba_pl@0/a001a000.leds/leds/
echo netdev > mode:blue/trigger && \
echo eth0 > mode:blue/device_name && \
echo 1 > mode:blue/tx_err
Signed-off-by: Lukasz Majewski <lukma@denx.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20240710100651.4059887-1-lukma@denx.de
Signed-off-by: Lee Jones <lee@kernel.org>
The torch_current_max should be checked not exceeding the upper bound.
If it does, throw a warning message and set to LM3601X_MAX_TORCH_I_UA.
LM3601x torch brigthness register (LM3601X_LED_TORCH_REG) takes 0 as the
minimum output (2.4 mA). However, 0 of led_brightness means LED_OFF.
Adding a -1 offset to brightness before writing to brightness
register, so when users write minimum brightness (1), it sets lm3601x
output the minimum.
Signed-off-by: Jack Chen <zenghuchen@google.com>
Link: https://lore.kernel.org/r/20240704191500.766846-1-zenghuchen@google.com
Signed-off-by: Lee Jones <lee@kernel.org>
- Add new Trigger for Input Events
- Add new led_mc_set_brightness() call to adapt colour/brightness for mutli-colour LEDs
- Add new lled_mc_trigger_event() call to call the above based on given trigger conditions
- Add new led_get_color_name() call, a wrapper around the existing led_colors[] array
- Add a new flag to avoid automatic renaming of LED devices
- New Drivers
- Add support for Silergy SY7802 Flash LED Controller
- Add support for Texas Instruments LP5569 LED Controller
- Add support for ChromeOS EC LED Controller
- New Device Support
- Add support for KTD202{6,7} to Kinetic KTD2026/7 LEDs
- Fix-ups
- Replace ACPI/DT firmware helpers with agnostic variants
- Make use of resource managed devm_* API calls
- Device Tree binding adaptions/conversions/creation
- Constify/staticise applicable data structures
- Trivial; spelling, whitespace, coding-style adaptions
- Drop i2c_device_id::driver_data where the value is unused
- Utilise centrally provided helpers and macros to aid simplicity/duplication
- Use generic platform device properties instead of OF/ACPI specific ones
- Consolidate/de-duplicate various functionality
- Remove superfluous/duplicated/unused sections
- Make use of the new *_scoped() guard APIs
- Improve/simplify error handling
- Bug Fixes
- Flush pending brightness changes before activating the trigger
- Repair incorrect device naming preventing matches
- Prevent memory leaks by correctly free resources during error handling routines
- Repair locking issue causing circular dependency splats and lock-ups
- Unregister sysfs entries before deactivating triggers to prevent use-after issues
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Use correct return codes expected by the callers
- Omit set_brightness() error message for a LEDs that support only HW triggers
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWgMEACgkQUa+KL4f8
d2Glng//Sw3+ev7IFn4PmNfMHtKeWlJEerT8kyF0GdK05zn7ImlydkSVW5RvHN8B
J2A8cfXXkhggYoG2i4zjs1wtfPDXP9iJMhVaRnPPuWgYJpPrhUFSSkJKiauSKyGN
Tp3Vn6QaHM5Gs/THUidcTV0+USE6j9+DXdLjLASAi2YXqoGCC3KWcq4Hb6NdGM/Q
ajEuGnrO1HEF0dOaEgkYuNIXcADHzeeQlU0Y96bGv7qnUBw7LAIpH+AC1d49jcXS
gIJNxmtmn0QqCK0/lS74DmR9r2quofeYer6G5WDJVv72R8KIljFN16AGFLdC8ID/
3B4JnjQKpEyn344gmvqzx23dp3jqvCupgDcojR6RY7yIZTXSjg0R0OocKYQlDnNY
LoNZqZ9J2nNDWNlx7r7PXuIAm7Bb9kdY0/PWgXOwWsEb19DcxyAHE3+xGeyQF6f5
/s1bGZxQyfBnDZm8+XiJ6KTsiZ1t0MljG9y7xil6vtzJIJTynao9qzZipcrx7UuT
3UyoGa/Z4o95OkQye9n6tKGJJDKLJIZL7x4pGOW3HeHgfvJ1koyHr8WwhmK4Zoh/
xeHfHABuaMoulTsuGjtnRP4/UWOTEf2hh7FK1mSrpxSCvv+I9W4lTO9QBkXU8xuD
1oCekcTYWOwKhxaFX4jjaGEHXIWYzXDjE7hqroLzj8Ifhqe9xrc=
=0Kyu
-----END PGP SIGNATURE-----
Merge tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds
Pull LED updates from Lee Jones:
"Core Frameworks:
- New trigger for Input Events
- New led_mc_set_brightness() call to adapt colour/brightness for
mutli-colour LEDs
- New lled_mc_trigger_event() call to call the above based on given
trigger conditions
- New led_get_color_name() call, a wrapper around the existing
led_colors[] array
- A new flag to avoid automatic renaming of LED devices
New Drivers:
- Silergy SY7802 Flash LED Controller
- Texas Instruments LP5569 LED Controller
- ChromeOS EC LED Controller
New Device Support:
- KTD202{6,7} support for Kinetic KTD2026/7 LEDs
Fix-ups:
- Replace ACPI/DT firmware helpers with agnostic variants
- Make use of resource managed devm_* API calls
- Device Tree binding adaptions/conversions/creation
- Constify/staticise applicable data structures
- Trivial; spelling, whitespace, coding-style adaptions
- Drop i2c_device_id::driver_data where the value is unused
- Utilise centrally provided helpers and macros to aid simplicity and
avoid duplication
- Use generic platform device properties instead of OF/ACPI specific
ones
- Consolidate/de-duplicate various functionality
- Remove superfluous/duplicated/unused sections
- Make use of the new *_scoped() guard APIs
- Improve/simplify error handling
Bug Fixes:
- Flush pending brightness changes before activating the trigger
- Repair incorrect device naming preventing matches
- Prevent memory leaks by correctly free resources during error
handling routines
- Repair locking issue causing circular dependency splats and
lock-ups
- Unregister sysfs entries before deactivating triggers to prevent
use-after issues
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Use correct return codes expected by the callers
- Omit set_brightness() error message for a LEDs that support only HW
triggers"
* tag 'leds-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (65 commits)
leds: leds-lp5569: Enable chip after chip configuration
leds: leds-lp5569: Better handle enabling clock internal setting
leds: leds-lp5569: Fix typo in driver name
leds: flash: leds-qcom-flash: Test the correct variable in init
leds: leds-lp55xx: Convert mutex lock/unlock to guard API
leds: leds-lp5523: Convert to sysfs_emit API
leds: leds-lp5569: Convert to sysfs_emit API
Revert "leds: led-core: Fix refcount leak in of_led_get()"
leds: leds-lp5569: Add support for Texas Instruments LP5569
leds: leds-lp55xx: Drop deprecated defines
leds: leds-lp55xx: Support ENGINE program up to 128 bytes
leds: leds-lp55xx: Generalize sysfs master_fader
leds: leds-lp55xx: Generalize sysfs engine_leds
leds: leds-lp55xx: Generalize sysfs engine_load and engine_mode
leds: leds-lp55xx: Generalize stop_engine function
leds: leds-lp55xx: Generalize turn_off_channels function
leds: leds-lp55xx: Generalize set_led_current function
leds: leds-lp55xx: Generalize multicolor_brightness function
leds: leds-lp55xx: Generalize led_brightness function
leds: leds-lp55xx: Generalize firmware_loaded function
...
- Add support for ROHM BD96801 Power Management IC
- Add support for Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
- Add support for Marvell 88PM886 Power Management IC
- New Device Support
- Add support for Keyboard Backlight to ChromeOS Embedded Controller
- Add support for LEDs to ChromeOS Embedded Controller
- Add support for Charge Control to ChromeOS Embedded Controller
- Add support for the HW Monitoring Service to ChromeOS Embedded Controller
- Add support for AUXADCs to MediaTek MT635{7,8,9} Power Management ICs
- New Functionality
- Allow Syscon consumers to supply their own Regmaps on registration
- Fix-ups
- Constify/staticise applicable data structures
- Remove superfluous/duplicated/unused sections
- Device Tree binding adaptions/conversions/creation
- Trivial; spelling, whitespace, coding-style adaptions
- Utilise centrally provided helpers and macros to aid simplicity/duplication
- Drop i2c_device_id::driver_data where the value is unused
- Replace ACPI/DT firmware helpers with agnostic variants
- Move over to GPIOD (descriptor-based) APIs
- Annotate a bunch of __counted_by() cases
- Straighten out some includes
- Bug Fixes
- Ensure potentially asserted recent lines are deasserted during initialisation
- Avoid "<module>.ko is added to multiple modules" warnings
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Fix Wvoid-pointer-to-enum-cast warnings
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEdrbJNaO+IJqU8IdIUa+KL4f8d2EFAmaWf6sACgkQUa+KL4f8
d2HhAw//UMujhKk/IfzGck3RoaKH3H22oVpd98BpzJCZBKSpl9pGsumHCicBMVAK
gp8SuwKNCAX+Fa/TubHz0xH6FWxLFXezh5DvO1t1DrPNokG+u4QPTfgMJ1IfBMHO
w7aL74rtJEyWBeod4+qNVoq6KNDaWjiWQlxGQ+9IoSNmxSTL6pkYMqo935RnqhRr
nm2TfSOIshk4tiO9tVA1ecCgjVwsG51803hypmd1AH6qBb7JsY6k1HWukLGaqUiV
+57oQzCTPIRYJhYdca06xi4ZmPg2kmoYKlxqW5ExyM7Mxs9aZZzwwZ7929LKXC6o
ebAPDc3auoww7B5mHbbVuBj0gDZKtfXpBRKSHLNtmhi0xmjnwZxQIumkpVGQALkI
0TQffgYVU4O7IXsAZG9w5igyMzEo9SZJMyrfFaQ0iB3rx5bXuh4b6btfewAkyI1H
+o3Yjymf4CR1trY9qnWCGWM/COQLIiGRhsk/RqGjy0xtpQo1Skx+AIkc6QD2zl6Y
ohC0JzEWTQe7c1DOM3SLpNoCb/GbFpVi0RrXRVfRltPHpVb/r54Zlbo+PrCaC8FB
EkU+86XbxGMh7hLtz5yhmnNCWKHQ6jbaFESwtZLo4d42CKvZaobL4xVCL56OntsH
ikmTNG+X0mUAZiCwGgK5OhEVCAtCcjRtz1U93wgDBaz7Y39z+yM=
=DSjk
-----END PGP SIGNATURE-----
Merge tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
Pull MFD updates from Lee Jones:
"New Drivers:
- ROHM BD96801 Power Management IC
- Cirrus Logic CS40L50 Haptic Driver with Waveform Memory
- Marvell 88PM886 Power Management IC
New Device Support:
- Keyboard Backlight to ChromeOS Embedded Controller
- LEDs to ChromeOS Embedded Controller
- Charge Control to ChromeOS Embedded Controller
- HW Monitoring Service to ChromeOS Embedded Controller
- AUXADCs to MediaTek MT635{7,8,9} Power Management ICs
New Functionality:
- Allow Syscon consumers to supply their own Regmaps on registration
Fix-ups:
- Constify/staticise applicable data structures
- Remove superfluous/duplicated/unused sections
- Device Tree binding adaptions/conversions/creation
- Trivial; spelling, whitespace, coding-style adaptions
- Utilise centrally provided helpers and macros to aid
simplicity/duplication
- Drop i2c_device_id::driver_data where the value is unused
- Replace ACPI/DT firmware helpers with agnostic variants
- Move over to GPIOD (descriptor-based) APIs
- Annotate a bunch of __counted_by() cases
- Straighten out some includes
Bug Fixes:
- Ensure potentially asserted recent lines are deasserted during
initialisation
- Avoid "<module>.ko is added to multiple modules" warnings
- Supply a bunch of MODULE_DESCRIPTIONs to silence modpost warnings
- Fix Wvoid-pointer-to-enum-cast warnings"
* tag 'mfd-next-6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd: (87 commits)
mfd: timberdale: Attach device properties to TSC2007 board info
mfd: tmio: Move header to platform_data
mfd: tmio: Sanitize comments
mfd: tmio: Update include files
mmc: tmio/sdhi: Fix includes
mfd: tmio: Remove obsolete io accessors
mfd: tmio: Remove obsolete platform_data
watchdog: bd96801_wdt: Add missing include for FIELD_*()
dt-bindings: mfd: syscon: Add APM poweroff mailbox
dt-bindings: mfd: syscon: Split and enforce documenting MFD children
dt-bindings: mfd: rk817: Merge support for RK809
dt-bindings: mfd: rk817: Fixup clocks and reference dai-common
dt-bindings: mfd: syscon: Add TI's opp table compatible
mfd: omap-usb-tll: Use struct_size to allocate tll
dt-bindings: mfd: Explain lack of child dependency in simple-mfd
dt-bindings: mfd: Dual licensing for st,stpmic1 bindings
mfd: omap-usb-tll: Annotate struct usbtll_omap with __counted_by
mfd: tps6594-core: Remove unneeded semicolon in tps6594_check_crc_mode()
mfd: lm3533: Move to new GPIO descriptor-based APIs
mfd: tps65912: Use devm helper functions to simplify probe
...
Documentation say that clock internal config needs to be set BEFORE chip
is enabled. Align code to this and move the CHIP enable after the CHIP
is configured.
While at it also make use of STATUS reg and check when STARTUP is
completed instead of sleep for 1-2 ms.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240712004556.15601-3-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Better handle enabling clock internal setting. In further testing it was
notice that internal clock config MUST be set before clock output config
or the LED CHIP might stop working.
This wasn't documented and was actually found on devices that have 2
chip chained where one chip provide clock for the other.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240712004556.15601-2-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This code was passing the incorrect pointer to PTR_ERR_OR_ZERO() so it
always returned success. It should have been checking the array element
instead of the array itself.
Fixes: 96a2e242a5 ("leds: flash: Add driver to support flash LED module in QCOM PMICs")
Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/ZoWJS_epjIMCYITg@stanley.mountain
Signed-off-by: Lee Jones <lee@kernel.org>
Convert any entry of mutex lock/unlock to guard API and simplify code.
With the use of guard API, handling for selttest functions can be
greatly simplified.
Suggested-by: Markus Elfring <Markus.Elfring@web.de>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626221520.2846-3-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Convert sprintf to the much safer sysfs_emit API to handle output for
sysfs.
Also better handle situation where on the same chip there may be LED
open and shorted at the same time.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626221520.2846-1-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
This reverts commit da1afe8e60.
Commit 699a8c7c4b ("leds: Add of_led_get() and led_put()"), introduced in
5.5, added of_led_get() and led_put() but missed a put_device() in
led_put(), thus creating a leak in case the consumer device is removed.
Arguably device removal was not very popular, so this went apparently
unnoticed until 2022. In January 2023 two different patches got merged to
fix the same bug:
- commit da1afe8e60 ("leds: led-core: Fix refcount leak in of_led_get()")
- commit 445110941e ("leds: led-class: Add missing put_device() to led_put()")
They fix the bug in two different ways, which creates no patch conflicts,
and both were merged in v6.2. The result is that now there is one more
put_device() than get_device()s, instead of one less.
Arguably device removal is not very popular yet, so this apparently hasn't
been noticed as well up to now. But it blew up here while I'm working with
device tree overlay insertion and removal. The symptom is an apparently
unrelated list of oopses on device removal, with reasons:
kernfs: can not remove 'uevent', no directory
kernfs: can not remove 'brightness', no directory
kernfs: can not remove 'max_brightness', no directory
...
Here sysfs fails removing attribute files, which is because the device name
changed and so the sysfs path. This is because the device name string got
corrupted, which is because it got freed too early and its memory reused.
Different symptoms could appear in different use cases.
Fix by removing one of the two fixes.
The choice was to remove commit da1afe8e60 because:
* it is calling put_device() inside of_led_get() just after getting the
device, thus it is basically not refcounting the LED device at all
during its entire lifetime
* it does not add a corresponding put_device() in led_get(), so it fixes
only the OF case
The other fix (445110941e) is adding the put_device() in led_put() so it
covers the entire lifetime, and it works even in the non-DT case.
Fixes: da1afe8e60 ("leds: led-core: Fix refcount leak in of_led_get()")
Co-developed-by: Hervé Codina <herve.codina@bootlin.com>
Signed-off-by: Hervé Codina <herve.codina@bootlin.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Link: https://lore.kernel.org/r/20240625-led-class-device-leak-v2-1-75fdccf47421@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add support for Texas Instruments LP5569 LED driver.
Texas Instruments LP5569 is 9 channels chip with programmable engines.
It almost a copy of LP5523 with fundamental changes to regs order and
regs content.
Has difference in how the clock is handled and doesn't support detecting
clock time automatically, different handling for selftest and different
scheme for the status regs.
LED chip supports ENGINE and MUX to group LED and run precompiled code
with magic values to run patterns. This is loaded via the sysfs entry
and it's passed as a string of ASCII HEX char.
One some devices using this LED Controller (a NBG7815 Router) it was
found loading big precompiled pattern with up to 96 bytes of code. To
have support for this "extended" scenario, hardcode each engine to
support 4 pages of precompiled pattern (128 bytes of code) and 1 page
for each MUX. This gives plenty of space for any kind precompiled
pattern keeping simple logic for page handling of each engine and mux.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-21-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Some LED chip supports up to 16 pages and with some magic they can be
divided in 4 page for each ENGINE + 1 for each MUX. Following this we
can support bigger programs up to 128 bytes.
Rework the update_program_memory function to support program of multiple
pages instead of hardcoding it to one page per programs.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-19-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize sysfs master_fader since their implementation is the same across
some lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-18-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize sysfs engine_leds since their implementation is the same across
some lp55xx based LED driver.
While at it simplify the implementation for show_engine_leds.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-17-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize sysfs engine_load and engine_mode since their implementation
is the same acrosso some lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-16-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize stop_engine function as the implementation is the same for
most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-15-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize turn_off_channels function as the implementation is the same for
most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-14-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize set_led_current function as the implementation is the same for
most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-13-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize multicolor_brightness function as the implementation is the
same for most of the lp55xx based LED driver.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-12-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize led_brightness function as the implementation is the same for
most of the lp55xx based LED driver.
Introduce a new option in device_config, reg_led_pwm_base since the reg
value is not the same for every LED chip.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-11-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize firmware_loaded function as lp55xx based LED driver all share
the same logic.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-10-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
LED Driver based on lp55xx all use the same logic to write memory in
SMEM. The only difference is that legacy chip doesn't support pages and
have the engine regs one after another.
To handle this apply the same logic used for load_engine also for
update_program_memory.
Introduce a new config in device_config, base_prog. For LED chip
that doesn't support pages, offset this values of 32 for each engine.
Update all lp55xx based LED driver to use this new function and define
all the required bits.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-9-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize run_engine function for lp55xx based LED driver. The logic is
similar to every LED driver, rework it with more macro magic and account
for LED model that might have OP MODE and EXEC at base offset in the
reg.
Update any lp55xx based LED driver to use this generalized function and
declare required bits.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-8-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Generalize load_engine_and_select_page by reworking the implementation
and making it part of the generic load_engine function.
Add a new option in device_config, pages_per_engine used to define pages
assigned to each engine. With this option set, it's assumed LED chip
supports pages and load_engine will correctly setup the write page.
An equal amount of pages is assigned to each engine and they are
assigned from page 0.
Update any lp55xx based LED driver to define the option and use the new
function.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-7-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
LED driver based on lp55xx have all a very similar implementation for
load_engine function. Move the function to lp55xx-common and rework the
define to be more dynamic instead of having to declare a temp array for
them.
Engine mask are the same for every LED based on lp55xx.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-6-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Now that stop_all_engine is generalized, probe and remove function are
the same across every lp55xx based LED driver and can be generalized.
To permit to use a common probe, make use of the OF match_data and i2c
driver_data value to store the device_config struct specific for the
LED.
Also drop the now unused exported symbol in lp55xx-common and make them
static.
Update any lp55xx based LED driver to use the new generic probe/remove.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-5-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
In all the lp55xx based driver, we have a similar implementation of the
stop_all_engine function with the only difference of the required sleep
for the OP MODE change.
The main difference is legacy LEDs require a min of 152 us while new one
use a generic 1-2ms. The new one use a 1-2ms sleep as suggested in the
datasheet IN ALTERNATIVE to a much more robust approach by using the
newly introduced ENGINE_BUSY bit in the STATUS reg.
To better handle sleep after OP MODE change, add support for polling the
ENGINE_BUSY bit and use the legacy sleep for old LEDs.
With this change, stop_all_engine can be generalized and moved to
lp55xx-common.
To make more clear the double usage of lp55xx_reg, define a union for
additional scope of mask and shift.
Update all lp55xx based driver to use the new generalized function and
define the required bits in the device_config struct.
Suggested-by: Lee Jones <lee@kernel.org>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Link: https://lore.kernel.org/r/20240626160027.19703-4-ansuelsmth@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The SY7802 is a current-regulated charge pump which can regulate two
current levels for Flash and Torch modes.
It is a high-current synchronous boost converter with 2-channel high
side current sources. Each channel is able to deliver 900mA current.
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: André Apitzsch <git@apitzsch.eu>
Link: https://lore.kernel.org/r/20240624-sy7802-v5-2-7abc9d96bfa6@apitzsch.eu
Signed-off-by: Lee Jones <lee@kernel.org>
Default blinking period is set to 2s. This is too long to be handled by
the hardware (maximum is 1.69s).
Set the default blinking period to 1s to match what is done in the
other LED drivers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-5-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
When a LED is used to drive a beeper, it uses PWM1. This can cause
conflicts if an other LED want to use PWM1 for blinking.
Disable use of hardware for blinking when one or more LEDs are used to
drive beepers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-4-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
PSC0/PWM0 are used by all LEDs for brightness and blinking. This causes
conflicts when you set a brightness of a new LED while an other one is
already using PWM0 for blinking.
Use PSC1/PWM1 for blinking.
Check that no other LED is already blinking with a different PSC1/PWM1
configuration to avoid conflict.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-3-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
Two tables are used to configure the PWM and PSC registers of the two
PWM available in the pca9532. Magic numbers are used to access this table
instead of defines.
Add defines PCA9532_PWM_ID_0 and PCA9532_PWM_ID_1 and use them in place of
these magic numbers.
Signed-off-by: Bastien Curutchet <bastien.curutchet@bootlin.com>
Link: https://lore.kernel.org/r/20240617143910.154546-2-bastien.curutchet@bootlin.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use __free for device_node values, and thus drop calls to
of_node_put.
The variable attribute __free adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The of_node_put calls were removed, and the
for_each_available_child_of_node was replaced to the equivalent
for_each_available_child_of_node_scoped which use the __free.
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: MarileneGarcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240601031713.1307859-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
The fwnode_for_each_child_node() loop requires manual intervention to
decrement the child refcount in case of an early return.
Add the missing calls to fwnode_handle_put(child) to avoid memory leaks
in the error paths.
Cc: stable@vger.kernel.org
Fixes: 679f865206 ("leds: Add mt6360 driver")
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20240611-leds-mt6360-memleak-v1-1-93642eb5011e@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use __free() for device_node values, and thus drop calls to
of_node_put().
The variable attribute __free() adds a scope based cleanup to
the device node. The goal is to reduce memory management issues
in the kernel code.
The for_each_available_child_of_node() was replaced to the equivalent
for_each_available_child_of_node_scoped() which uses the __free().
Suggested-by: Julia Lawall <julia.lawall@inria.fr>
Signed-off-by: Marilene A Garcia <marilene.agarcia@gmail.com>
Link: https://lore.kernel.org/r/20240611001740.10490-1-marilene.agarcia@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
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>
The race fixed in timer_trig_activate() between a blocking
set_brightness() call and trigger->activate() can affect any trigger.
So move the call to flush_work() into led_trigger_set() where it can
avoid the race for all triggers.
Fixes: 0db37915d9 ("leds: avoid races with workqueue")
Fixes: 8c0f693c6e ("leds: avoid flush_work in atomic context")
Cc: stable@vger.kernel.org
Tested-by: Dustin L. Howett <dustin@howett.net>
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-led-trigger-flush-v2-1-f4f970799d77@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
There is no code that uses ID table directly, except the
struct device_driver at the end of the file. Hence, move
table closer to its user. It's always possible to access
them via a pointer.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-7-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20240606173037.3091598-6-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a label so that a bit of exception handling can be better reused
at the end of this function implementation.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Link: https://lore.kernel.org/r/5faec5de-fc36-4b38-abcb-c61954a824cd@web.de
Signed-off-by: Lee Jones <lee@kernel.org>
If both set_brightness functions return -ENOTSUPP, then the LED doesn't
support setting a fixed brightness value, and the error message isn't
helpful. This can be the case e.g. for LEDs supporting a specific hw
trigger only.
Pinched the subject line and commit message from Heiner:
Link: https://lore.kernel.org/all/44177e37-9512-4044-8991-bb23b184bf37@gmail.com/
Reworked the function to provide Heiner's required semantics whilst
simultaneously increasing readability and flow.
Cc: Pavel Machek <pavel@ucw.cz>
Cc: linux-leds@vger.kernel.org
Suggested-by: Heiner Kallweit <hkallweit1@gmail.com>
Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new trigger which turns LEDs on when there is input
(/dev/input/event*) activity and turns them back off again after there has
been no activity for 5 seconds.
This is primarily intended to control LED devices which are a backlight for
capacitive touch-buttons, such as e.g. the menu / home / back buttons found
on the bottom bezel of many somewhat older smartphones and tablets.
This can also be used to turn on the keyboard backlight LED on input
events and turn the keyboard backlight off again when idle.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531135910.168965-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
ich7_lpc_probe() uses pci_read_config_dword() that returns PCIBIOS_*
codes. The error handling code assumes incorrectly it's a normal errno
and checks for < 0. The return code is returned from the probe function
as is but probe functions should return normal errnos.
Remove < 0 from the check and convert PCIBIOS_* returns code using
pcibios_err_to_errno() into normal errno before returning it.
Fixes: a328e95b82 ("leds: LED driver for Intel NAS SS4200 series (v5)")
Cc: <stable@vger.kernel.org>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Link: https://lore.kernel.org/r/20240527132700.14260-1-ilpo.jarvinen@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
Fix the 'make W=1" issue:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/blink/leds-bcm63138.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20240517-md-leds-bcm63138-v1-1-247b7302edb6@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
Fix the 'make W=1' issues:
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-apollolake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-core.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-elkhartlake.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-f7188x.o
WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds.o
Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com>
Link: https://lore.kernel.org/r/20240517-md-simatic-ipc-v1-1-bbbd199262b8@quicinc.com
Signed-off-by: Lee Jones <lee@kernel.org>
These drivers don't use the driver_data member of struct i2c_device_id,
so don't explicitly initialize this member.
This prepares putting driver_data in an anonymous union which requires
either no initialization or named designators. But it's also a nice
cleanup on its own.
While add it, also remove commas after the sentinel entries.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240522165358.62238-2-u.kleine-koenig@pengutronix.de
Signed-off-by: Lee Jones <lee@kernel.org>
Some triggers call led_trigger_event() from their activate() callback
to initialize the brightness of the LED for which the trigger is being
activated.
In order for the LED's initial state to be set correctly this requires that
the led_trigger_event() call uses the new version of trigger->led_cdevs,
which has the new LED.
AFAICT led_trigger_event() will always use the new version when it is
running on the same CPU as where the list_add_tail_rcu() call was made,
which is why the missing synchronize_rcu() has not lead to bug reports.
But if activate() is pre-empted, sleeps or uses a worker then
the led_trigger_event() call may run on another CPU which may still use
the old trigger->led_cdevs list.
Add a synchronize_rcu() call to ensure that any led_trigger_event() calls
done from activate() always use the new list.
Triggers using led_trigger_event() from their activate() callback are:
net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Triggers which have trigger specific sysfs attributes typically store
related data in trigger-data allocated by the activate() callback and
freed by the deactivate() callback.
Calling device_remove_groups() after calling deactivate() leaves a window
where the sysfs attributes show/store functions could be called after
deactivation and then operate on the just freed trigger-data.
Move the device_remove_groups() call to before deactivate() to close
this race window.
This also makes the deactivation path properly do things in reverse order
of the activation path which calls the activate() callback before calling
device_add_groups().
Fixes: a7e7a31563 ("leds: triggers: add device attribute support")
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
'is31fl3190_regmap_config' and 'is31fl3196_regmap_config' are not modified
in this diver and are only used as a const struct regmap_config.
Constifying these structures moves some data to a read-only section, so
increase overall security.
On a x86_64, with allmodconfig:
Before:
text data bss dec hex filename
13827 2002 32 15861 3df5 drivers/leds/leds-is31fl319x.o
After:
text data bss dec hex filename
14467 1370 32 15869 3dfd drivers/leds/leds-is31fl319x.o
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/82a5cb26ff8af1865a790286bdbc3c4a2bd149f1.1714892598.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.
The LEDs are exposed as multicolor devices.
A hardware trigger, which is active by default, is provided to let the
EC itself take over control over the LED.
The driver is designed to be probed via the cros_ec mfd device.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
led_get_color_name() is a safer alternative to led_colors.
led-class-multicolor.c is the only external user of led_colors and its
removal allows unexporting the array.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-2-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
This is similar to the existing led_colors[] array but is safer to use and
usable by everyone.
Getting string representations of color ids is useful for drivers
which are handling color IDs anyways, for example for the multicolor API.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-1-500b50f41e0f@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Commit 66601a29bb ("leds: class: If no default trigger is given, make
hw_control trigger the default trigger") causes ledtrig-netdev to get
set as default trigger on various network LEDs.
This causes users to hit a pre-existing AB-BA deadlock issue in
ledtrig-netdev between the LED-trigger locks and the rtnl mutex,
resulting in hung tasks in kernels >= 6.9.
Solving the deadlock is non trivial, so for now revert the change to
set the hw_control trigger as default trigger, so that ledtrig-netdev
no longer gets activated automatically for various network LEDs.
The netdev trigger is not needed because the network LEDs are usually under
hw-control and the netdev trigger tries to leave things that way so setting
it as the active trigger for the LED class device is a no-op.
Fixes: 66601a29bb ("leds: class: If no default trigger is given, make hw_control trigger the default trigger")
Reported-by: Genes Lists <lists@sapience.com>
Closes: https://lore.kernel.org/all/9d189ec329cfe68ed68699f314e191a10d4b5eda.camel@sapience.com/
Reported-by: Johannes Wüller <johanneswueller@gmail.com>
Closes: https://lore.kernel.org/lkml/e441605c-eaf2-4c2d-872b-d8e541f4cf60@gmail.com/
Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Other warnings refer to the name after renaming, which is clearer when
that name is mentioned first.
It is also clearer where "ret" comes from.
While at it, also add the necessary newline to the message and fix the
parameter alignment.
Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-1-ee577415a521@weissschuh.net
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new led_mc_trigger_event() function for triggers which want to
change the color of a multi-color LED based on their trigger conditions.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new led_mc_set_brightness() function for in kernel color/brightness
changing of multi-color LEDs.
led-class-multicolor can be build as a module and led_mc_set_brightness()
will have the builtin callers, so put led_mc_set_brightness() inside
led-core instead, just like how led_set_brightness() is part of the core
and not of the led-class object.
This also adds a new LED_MULTI_COLOR led_classdev flag to allow
led_mc_set_brightness() to verify that it is operating on a multi-color
LED classdev, avoiding casting the passed in LED classdev to a multi-color
LED classdev, when it actually is not a multi-color LED.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-5-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
The mutex must be initialized before the LED class device is registered
otherwise there is a race where it may get used before it is initialized:
DEBUG_LOCKS_WARN_ON(lock->magic != lock)
WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock
...
RIP: 0010:__mutex_lock+0x7db/0xc10
...
set_brightness_delayed_set_brightness.part.0+0x17/0x60
set_brightness_delayed+0xf1/0x100
process_one_work+0x222/0x5a0
Move the mutex_init() call earlier to avoid this race condition and
switch to devm_mutex_init() to avoid the need to add error-exit
cleanup to probe() if probe() fails later on.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Link: https://lore.kernel.org/r/20240531114124.45346-4-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add an i2c_device_id id_table to match manually instantiated
(non device-tree / ACPI instantiated) KTD202x controllers as
found on some x86 boards.
This table shows the maximum support LED channel for KTD2026
(three LEDs) and KTD-2027 (4 LEDs).
Link: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531114124.45346-3-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
This LED controller is installed on a Xiaomi pad2 and it is an x86
platform. The original driver is based on the device tree and can't be
used for this ACPI based system. This patch migrated the driver to use
fwnode to access the properties. Moreover, the fwnode API supports the
device tree so this work won't affect the original implementations.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andy@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20240531114124.45346-2-hdegoede@redhat.com
Signed-off-by: Lee Jones <lee@kernel.org>
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover
'struct reg_cfg' isn't defined anywhere, so remove it.
Found with cppcheck, unusedStructMember.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/e389be5e1012dc05fc2641123883ca3b0747525a.1714328839.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Lee Jones <lee@kernel.org>
match_string() returns the array index of a matching string.
Use it instead of the open-coded implementation.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://lore.kernel.org/r/20240426152515.872917-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
