summaryrefslogtreecommitdiffstats
path: root/drivers/leds (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'leds-next-6.11' of ↵Linus Torvalds2024-07-1851-1862/+2564
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * leds: leds-lp5569: Enable chip after chip configurationChristian Marangi2024-07-121-8/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp5569: Better handle enabling clock internal settingChristian Marangi2024-07-121-5/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp5569: Fix typo in driver nameChristian Marangi2024-07-121-1/+1
| | | | | | | | | | | | | | | | | | Remove extra x from driver name as this was a typo from copy-paste error. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240712004556.15601-1-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: flash: leds-qcom-flash: Test the correct variable in initDan Carpenter2024-07-111-3/+7
| | | | | | | | | | | | | | | | | | | | | | 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: 96a2e242a5dc ("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>
| * leds: leds-lp55xx: Convert mutex lock/unlock to guard APIChristian Marangi2024-07-115-92/+64
| | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp5523: Convert to sysfs_emit APIChristian Marangi2024-07-041-4/+4
| | | | | | | | | | | | | | | | | | Convert sprintf to the much safer sysfs_emit API to handle output for sysfs. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626221520.2846-2-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: leds-lp5569: Convert to sysfs_emit APIChristian Marangi2024-07-041-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Revert "leds: led-core: Fix refcount leak in of_led_get()"Luca Ceresoli2024-06-271-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit da1afe8e6099980fe1e2fd7436dca284af9d3f29. Commit 699a8c7c4bd3 ("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 da1afe8e6099 ("leds: led-core: Fix refcount leak in of_led_get()") - commit 445110941eb9 ("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 da1afe8e6099 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 (445110941eb9) is adding the put_device() in led_put() so it covers the entire lifetime, and it works even in the non-DT case. Fixes: da1afe8e6099 ("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>
| * leds: leds-lp5569: Add support for Texas Instruments LP5569Christian Marangi2024-06-263-3/+558
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Drop deprecated definesChristian Marangi2024-06-264-116/+0
| | | | | | | | | | | | | | | | | | Drop deprecated defines not used anymore as the related function got moved to lp55xx-common. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20240626160027.19703-20-ansuelsmth@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: leds-lp55xx: Support ENGINE program up to 128 bytesChristian Marangi2024-06-264-19/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize sysfs master_faderChristian Marangi2024-06-263-139/+156
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize sysfs engine_ledsChristian Marangi2024-06-263-129/+131
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize sysfs engine_load and engine_modeChristian Marangi2024-06-264-186/+117
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize stop_engine functionChristian Marangi2024-06-264-34/+20
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize turn_off_channels functionChristian Marangi2024-06-264-18/+13
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize set_led_current functionChristian Marangi2024-06-265-24/+26
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize multicolor_brightness functionChristian Marangi2024-06-264-40/+24
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize led_brightness functionChristian Marangi2024-06-265-41/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize firmware_loaded functionChristian Marangi2024-06-266-88/+30
| | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize update_program_memory functionChristian Marangi2024-06-266-198/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize run_engine functionChristian Marangi2024-06-266-146/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize load_engine_and_select_page functionChristian Marangi2024-06-264-33/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize load_engine functionChristian Marangi2024-06-266-84/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize probe/remove functionsChristian Marangi2024-06-266-362/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: leds-lp55xx: Generalize stop_all_engine OPChristian Marangi2024-06-266-34/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: sy7802: Add support for Silergy SY7802 flash LED controllerAndré Apitzsch2024-06-263-0/+551
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: pca9532: Change default blinking frequency to 1HzBastien Curutchet2024-06-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: pca9532: Explicitly disable hardware blink when PWM1 is unavailableBastien Curutchet2024-06-261-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: pca9532: Use PWM1 for hardware blinkingBastien Curutchet2024-06-261-10/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: pca9532: Use defines to select PWM instanceBastien Curutchet2024-06-261-9/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: trigger: input-events: Rewrite to fix a serious locking issueHans de Goede2024-06-261-102/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The input subsystem registers LEDs with default triggers while holding the input_lock and input_register_handler() takes the input_lock this means that a triggers activate method cannot directly call input_register_handler() as the old ledtrig-input-events code is doing. The initial implementation of the input-events trigger mainly did not use the simple LED trigger mechanism because that mechanism had an issue with the initial state of a newly activated LED not matching the last led_trigger_event() call for the trigger. This issue has been fixed in commit 822c91e72eac ("leds: trigger: Store brightness set by led_trigger_event()"). Rewrite the "input-events" trigger to use the simple LED trigger mechanism, registering a single input_handler at module_init() time and using led_trigger_event() to set the brightness for all LEDs controlled by this trigger. Compared to the old code this looses the ability for the user to configure a different brightness for the on state then LED_FULL, this is standard for simple LED triggers and since this trigger is only in for-leds-next ATM losing that functionality is not a regression. This also changes the configurability of the LED off timeout from a per LED setting to a global setting (runtime modifiable module-parameter). Switching to registering a single input_handler at module_init() time fixes the following locking issue reported by lockdep: [ 2840.220145] usb 1-1.3: new low-speed USB device number 3 using xhci_hcd [ 2840.307172] usb 1-1.3: New USB device found, idVendor=0603, idProduct=0002, bcdDevice= 2.21 [ 2840.307375] usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [ 2840.307423] usb 1-1.3: Product: USB Composite Device [ 2840.307456] usb 1-1.3: Manufacturer: SINO WEALTH [ 2840.333985] input: SINO WEALTH USB Composite Device as /devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3/1-1.3:1.0/0003:0603:0002.0007/input/input19 [ 2840.386545] ====================================================== [ 2840.386549] WARNING: possible circular locking dependency detected [ 2840.386554] 6.10.0-rc1+ #97 Tainted: G C E [ 2840.386558] ------------------------------------------------------ [ 2840.386562] kworker/1:1/52 is trying to acquire lock: [ 2840.386566] ffff98fcf1629300 (&led_cdev->led_access){+.+.}-{3:3}, at: led_classdev_register_ext+0x1c6/0x380 [ 2840.386590] but task is already holding lock: [ 2840.386593] ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150 [ 2840.386608] which lock already depends on the new lock. [ 2840.386611] the existing dependency chain (in reverse order) is: [ 2840.386615] -> #3 (input_mutex){+.+.}-{3:3}: [ 2840.386624] __mutex_lock+0x8c/0xc10 [ 2840.386634] input_register_handler+0x1c/0xf0 [ 2840.386641] 0xffffffffc142c437 [ 2840.386655] led_trigger_set+0x1e1/0x2e0 [ 2840.386661] led_trigger_register+0x170/0x1b0 [ 2840.386666] do_one_initcall+0x5e/0x3a0 [ 2840.386675] do_init_module+0x60/0x220 [ 2840.386683] __do_sys_init_module+0x15f/0x190 [ 2840.386689] do_syscall_64+0x93/0x180 [ 2840.386696] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2840.386705] -> #2 (&led_cdev->trigger_lock){+.+.}-{3:3}: [ 2840.386714] down_write+0x3b/0xd0 [ 2840.386720] led_trigger_register+0x12c/0x1b0 [ 2840.386725] rfkill_register+0xec/0x340 [rfkill] [ 2840.386739] wiphy_register+0x82a/0x930 [cfg80211] [ 2840.386907] brcmf_cfg80211_attach+0xcbd/0x1430 [brcmfmac] [ 2840.386952] brcmf_attach+0x1ba/0x4c0 [brcmfmac] [ 2840.386991] brcmf_pcie_setup+0x899/0xc70 [brcmfmac] [ 2840.387030] brcmf_fw_request_done+0x13b/0x180 [brcmfmac] [ 2840.387070] request_firmware_work_func+0x3b/0x70 [ 2840.387078] process_one_work+0x21a/0x590 [ 2840.387085] worker_thread+0x1d1/0x3e0 [ 2840.387090] kthread+0xee/0x120 [ 2840.387096] ret_from_fork+0x30/0x50 [ 2840.387105] ret_from_fork_asm+0x1a/0x30 [ 2840.387112] -> #1 (leds_list_lock){++++}-{3:3}: [ 2840.387123] down_write+0x3b/0xd0 [ 2840.387129] led_classdev_register_ext+0x29e/0x380 [ 2840.387134] 0xffffffffc0e6b74c [ 2840.387143] platform_probe+0x40/0xa0 [ 2840.387151] really_probe+0xde/0x340 [ 2840.387157] __driver_probe_device+0x78/0x110 [ 2840.387162] driver_probe_device+0x1f/0xa0 [ 2840.387168] __driver_attach+0xba/0x1c0 [ 2840.387173] bus_for_each_dev+0x6b/0xb0 [ 2840.387180] bus_add_driver+0x111/0x1f0 [ 2840.387185] driver_register+0x6e/0xc0 [ 2840.387191] do_one_initcall+0x5e/0x3a0 [ 2840.387197] do_init_module+0x60/0x220 [ 2840.387204] __do_sys_init_module+0x15f/0x190 [ 2840.387210] do_syscall_64+0x93/0x180 [ 2840.387217] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 2840.387224] -> #0 (&led_cdev->led_access){+.+.}-{3:3}: [ 2840.387233] __lock_acquire+0x11c6/0x1f20 [ 2840.387239] lock_acquire+0xc8/0x2b0 [ 2840.387244] __mutex_lock+0x8c/0xc10 [ 2840.387251] led_classdev_register_ext+0x1c6/0x380 [ 2840.387256] input_leds_connect+0x139/0x260 [ 2840.387262] input_attach_handler.isra.0+0x75/0x90 [ 2840.387268] input_register_device.cold+0xa1/0x150 [ 2840.387274] hidinput_connect+0x848/0xb00 [ 2840.387280] hid_connect+0x567/0x5a0 [ 2840.387288] hid_hw_start+0x3f/0x60 [ 2840.387294] hid_device_probe+0x10d/0x190 [ 2840.387298] really_probe+0xde/0x340 [ 2840.387304] __driver_probe_device+0x78/0x110 [ 2840.387309] driver_probe_device+0x1f/0xa0 [ 2840.387314] __device_attach_driver+0x85/0x110 [ 2840.387320] bus_for_each_drv+0x78/0xc0 [ 2840.387326] __device_attach+0xb0/0x1b0 [ 2840.387332] bus_probe_device+0x94/0xb0 [ 2840.387337] device_add+0x64a/0x860 [ 2840.387343] hid_add_device+0xe5/0x240 [ 2840.387349] usbhid_probe+0x4bb/0x600 [ 2840.387356] usb_probe_interface+0xea/0x2b0 [ 2840.387363] really_probe+0xde/0x340 [ 2840.387368] __driver_probe_device+0x78/0x110 [ 2840.387373] driver_probe_device+0x1f/0xa0 [ 2840.387378] __device_attach_driver+0x85/0x110 [ 2840.387383] bus_for_each_drv+0x78/0xc0 [ 2840.387390] __device_attach+0xb0/0x1b0 [ 2840.387395] bus_probe_device+0x94/0xb0 [ 2840.387400] device_add+0x64a/0x860 [ 2840.387405] usb_set_configuration+0x5e8/0x880 [ 2840.387411] usb_generic_driver_probe+0x3e/0x60 [ 2840.387418] usb_probe_device+0x3d/0x120 [ 2840.387423] really_probe+0xde/0x340 [ 2840.387428] __driver_probe_device+0x78/0x110 [ 2840.387434] driver_probe_device+0x1f/0xa0 [ 2840.387439] __device_attach_driver+0x85/0x110 [ 2840.387444] bus_for_each_drv+0x78/0xc0 [ 2840.387451] __device_attach+0xb0/0x1b0 [ 2840.387456] bus_probe_device+0x94/0xb0 [ 2840.387461] device_add+0x64a/0x860 [ 2840.387466] usb_new_device.cold+0x141/0x38f [ 2840.387473] hub_event+0x1166/0x1980 [ 2840.387479] process_one_work+0x21a/0x590 [ 2840.387484] worker_thread+0x1d1/0x3e0 [ 2840.387488] kthread+0xee/0x120 [ 2840.387493] ret_from_fork+0x30/0x50 [ 2840.387500] ret_from_fork_asm+0x1a/0x30 [ 2840.387506] other info that might help us debug this: [ 2840.387509] Chain exists of: &led_cdev->led_access --> &led_cdev->trigger_lock --> input_mutex [ 2840.387520] Possible unsafe locking scenario: [ 2840.387523] CPU0 CPU1 [ 2840.387526] ---- ---- [ 2840.387529] lock(input_mutex); [ 2840.387534] lock(&led_cdev->trigger_lock); [ 2840.387540] lock(input_mutex); [ 2840.387545] lock(&led_cdev->led_access); [ 2840.387550] *** DEADLOCK *** [ 2840.387552] 7 locks held by kworker/1:1/52: [ 2840.387557] #0: ffff98fcc1d07148 ((wq_completion)usb_hub_wq){+.+.}-{0:0}, at: process_one_work+0x4af/0x590 [ 2840.387570] #1: ffffb67e00213e60 ((work_completion)(&hub->events)){+.+.}-{0:0}, at: process_one_work+0x1d5/0x590 [ 2840.387583] #2: ffff98fcc6582190 (&dev->mutex){....}-{3:3}, at: hub_event+0x57/0x1980 [ 2840.387596] #3: ffff98fccb3c6990 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387610] #4: ffff98fcc5260960 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387622] #5: ffff98fce3999a20 (&dev->mutex){....}-{3:3}, at: __device_attach+0x26/0x1b0 [ 2840.387635] #6: ffffffff88130cc8 (input_mutex){+.+.}-{3:3}, at: input_register_device.cold+0x47/0x150 [ 2840.387649] stack backtrace: [ 2840.387653] CPU: 1 PID: 52 Comm: kworker/1:1 Tainted: G C E 6.10.0-rc1+ #97 [ 2840.387659] Hardware name: Xiaomi Inc Mipad2/Mipad, BIOS MIPad-P4.X64.0043.R03.1603071414 03/07/2016 [ 2840.387665] Workqueue: usb_hub_wq hub_event [ 2840.387674] Call Trace: [ 2840.387681] <TASK> [ 2840.387689] dump_stack_lvl+0x68/0x90 [ 2840.387700] check_noncircular+0x10d/0x120 [ 2840.387710] ? register_lock_class+0x38/0x480 [ 2840.387717] ? check_noncircular+0x74/0x120 [ 2840.387727] __lock_acquire+0x11c6/0x1f20 [ 2840.387736] lock_acquire+0xc8/0x2b0 [ 2840.387743] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387753] __mutex_lock+0x8c/0xc10 [ 2840.387760] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387766] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 2840.387773] ? klist_next+0x158/0x160 [ 2840.387781] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387787] ? lockdep_init_map_type+0x58/0x250 [ 2840.387796] ? led_classdev_register_ext+0x1c6/0x380 [ 2840.387802] led_classdev_register_ext+0x1c6/0x380 [ 2840.387810] ? kvasprintf+0x70/0xb0 [ 2840.387820] ? kasprintf+0x3e/0x50 [ 2840.387829] input_leds_connect+0x139/0x260 [ 2840.387838] input_attach_handler.isra.0+0x75/0x90 [ 2840.387846] input_register_device.cold+0xa1/0x150 [ 2840.387854] hidinput_connect+0x848/0xb00 [ 2840.387862] ? usbhid_start+0x45b/0x7b0 [ 2840.387870] hid_connect+0x567/0x5a0 [ 2840.387878] ? __mutex_unlock_slowpath+0x2d/0x260 [ 2840.387891] hid_hw_start+0x3f/0x60 [ 2840.387899] hid_device_probe+0x10d/0x190 [ 2840.387906] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.387913] really_probe+0xde/0x340 [ 2840.387919] ? pm_runtime_barrier+0x50/0x90 [ 2840.387927] __driver_probe_device+0x78/0x110 [ 2840.387934] driver_probe_device+0x1f/0xa0 [ 2840.387941] __device_attach_driver+0x85/0x110 [ 2840.387949] bus_for_each_drv+0x78/0xc0 [ 2840.387959] __device_attach+0xb0/0x1b0 [ 2840.387967] bus_probe_device+0x94/0xb0 [ 2840.387974] device_add+0x64a/0x860 [ 2840.387982] ? __debugfs_create_file+0x14a/0x1c0 [ 2840.387993] hid_add_device+0xe5/0x240 [ 2840.388002] usbhid_probe+0x4bb/0x600 [ 2840.388013] usb_probe_interface+0xea/0x2b0 [ 2840.388021] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.388028] really_probe+0xde/0x340 [ 2840.388034] ? pm_runtime_barrier+0x50/0x90 [ 2840.388040] __driver_probe_device+0x78/0x110 [ 2840.388048] driver_probe_device+0x1f/0xa0 [ 2840.388055] __device_attach_driver+0x85/0x110 [ 2840.388062] bus_for_each_drv+0x78/0xc0 [ 2840.388071] __device_attach+0xb0/0x1b0 [ 2840.388079] bus_probe_device+0x94/0xb0 [ 2840.388086] device_add+0x64a/0x860 [ 2840.388094] ? __mutex_unlock_slowpath+0x2d/0x260 [ 2840.388103] usb_set_configuration+0x5e8/0x880 [ 2840.388114] ? __pfx___device_attach_driver+0x10/0x10 [ 2840.388121] usb_generic_driver_probe+0x3e/0x60 [ 2840.388129] usb_probe_device+0x3d/0x120 [ 2840.388137] really_probe+0xde/0x340 [ 2840.388142] ? pm_runtime_barrier+0x50/0x90 [ 2840.388149] __driver_probe_device+0x78/0x110 [ 2840.388156] driver_probe_device+0x1f/0xa0 [ 2840.388163] __device_attach_driver+0x85/0x110 [ 2840.388171] bus_for_each_drv+0x78/0xc0 [ 2840.388180] __device_attach+0xb0/0x1b0 [ 2840.388188] bus_probe_device+0x94/0xb0 [ 2840.388195] device_add+0x64a/0x860 [ 2840.388202] ? lockdep_hardirqs_on+0x78/0x100 [ 2840.388210] ? _raw_spin_unlock_irqrestore+0x35/0x60 [ 2840.388219] usb_new_device.cold+0x141/0x38f [ 2840.388227] hub_event+0x1166/0x1980 [ 2840.388242] process_one_work+0x21a/0x590 [ 2840.388249] ? move_linked_works+0x70/0xa0 [ 2840.388260] worker_thread+0x1d1/0x3e0 [ 2840.388268] ? __pfx_worker_thread+0x10/0x10 [ 2840.388273] kthread+0xee/0x120 [ 2840.388279] ? __pfx_kthread+0x10/0x10 [ 2840.388287] ret_from_fork+0x30/0x50 [ 2840.388294] ? __pfx_kthread+0x10/0x10 [ 2840.388301] ret_from_fork_asm+0x1a/0x30 [ 2840.388315] </TASK> [ 2840.415630] hid-generic 0003:0603:0002.0007: input,hidraw6: USB HID v1.10 Keyboard [SINO WEALTH USB Composite Device] on usb-0000:00:14.0-1.3/input0 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240602160203.27339-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: powernv: Replace of_node_put to __freeMarileneGarcia2024-06-261-19/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: mt6360: Fix memory leak in mt6360_init_isnk_properties()Javier Carrasco2024-06-261-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 679f8652064b ("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>
| * leds: tlc591xx: Replace of_node_put to __freeMarilene A Garcia2024-06-261-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: rgb: leds-qcom-lpg: Add PPG check for setting/clearing PBS triggersAnjelique Melendez2024-06-261-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 6ab1f766a80a ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM") Fixes: 5e9ff626861a ("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>
| * leds: triggers: Flush pending brightness before activating triggerThomas Weißschuh2024-06-262-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 0db37915d912 ("leds: avoid races with workqueue") Fixes: 8c0f693c6eff ("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>
| * leds: spi-byte: Move OF ID table closer to their userAndy Shevchenko2024-06-261-7/+6
| | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: spi-byte: Use devm_mutex_init() for mutex initializationAndy Shevchenko2024-06-261-20/+6
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: spi-byte: Utilise temporary variable for struct deviceAndy Shevchenko2024-06-261-1/+1
| | | | | | | | | | | | | | | | | | We have a temporary variable to keep a pointer to struct device. Utilise it where it makes sense. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-5-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: spi-byte: Make use of device propertiesAndy Shevchenko2024-06-262-9/+7
| | | | | | | | | | | | | | | | | | | | | | Convert the module to be property provider agnostic and allow it to be used on non-OF platforms. Add mod_devicetable.h include. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-4-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: spi-byte: Get rid of custom led_init_default_state_get()Andy Shevchenko2024-06-261-12/+5
| | | | | | | | | | | | | | | | | | LED core provides a helper to parse default state from firmware node. Use it instead of custom implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-3-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: spi-byte: Call of_node_put() on error pathAndy Shevchenko2024-06-261-1/+5
| | | | | | | | | | | | | | | | Add a missing call to of_node_put(np) on error. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20240606173037.3091598-2-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: ncp5623: Use common error handling code in ncp5623_probe()Markus Elfring2024-06-261-8/+8
| | | | | | | | | | | | | | | | | | 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>
| * leds: core: Omit set_brightness error message for a LED supporting hw ↵Lee Jones2024-06-261-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | trigger only 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>
| * leds: trigger: Add new LED Input events triggerHans de Goede2024-06-213-0/+250
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: ss4200: Convert PCIBIOS_* return codes to errnosIlpo Järvinen2024-06-211-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: a328e95b82c1 ("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>
| * leds: bcm63138: Add MODULE_DESCRIPTION()Jeff Johnson2024-06-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: simatic-ipc-leds: Add missing MODULE_DESCRIPTION() macrosJeff Johnson2024-06-215-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-20 20:02:43 +0100