summaryrefslogtreecommitdiff
path: root/drivers/leds/led-class.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'leds-next-6.11' of ↵Linus Torvalds2024-07-171-1/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * 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>
* | Merge tag 'mfd-next-6.11' of ↵Linus Torvalds2024-07-171-4/+5
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * leds: class: Add flag to avoid automatic renaming of LED devicesThomas Weißschuh2024-06-141-0/+2
| | | | | | | | | | | | | | | | | | | | Add a mechanism for drivers to opt-out of the automatic device renaming on conflicts. Those drivers will provide their own conflict resolution. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240526-cros_ec-kbd-led-framework-v3-2-ee577415a521@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: class: Warn about name collisions earlierThomas Weißschuh2024-06-141-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | leds: class: Revert: "If no default trigger is given, make hw_control ↵Hans de Goede2024-06-161-6/+0
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | trigger the default trigger" Commit 66601a29bb23 ("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: 66601a29bb23 ("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>
* leds: class: If no default trigger is given, make hw_control trigger the ↵Heiner Kallweit2024-03-071-0/+6
| | | | | | | | | | | | default trigger If a hw_control_trigger is defined, it's usually desirable to make it the default trigger. Therefore make it the default trigger, except the driver explicitly set a default trigger. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/f33543de-3800-488f-a779-1fa282614462@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: class: Don't expose color sysfs entryTakashi Iwai2023-11-221-14/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | The commit c7d80059b086 ("leds: class: Store the color index in struct led_classdev") introduced a new sysfs entry "color" that is commonly created for the led classdev. Unfortunately, this conflicts with the "color" sysfs entry of already existing drivers such as Logitech HID or System76 ACPI drivers. The driver probe fails due to the conflict, hence it leads to a severe regression with the missing keyboard, for example. This patch reverts partially the change in the commit above for removing the led class color sysfs entries again for addressing the regressions. The newly introduced led_classdev.color field is kept as it's already used by other driver. Fixes: c7d80059b086 ("leds: class: Store the color index in struct led_classdev") Reported-by: Johannes Penßel <johannes.penssel@gmail.com> Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155 Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de Signed-off-by: Lee Jones <lee@kernel.org>
* leds: Make leds_class a static const structureIvan Orlov2023-08-181-13/+13
| | | | | | | | | | | | Now that the driver core allows for struct class to be in read-only memory, move the leds_class structure to be declared at build time placing it into read-only memory, instead of having to be dynamically allocated at boot time. Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Ivan Orlov <ivan.orlov0322@gmail.com> Link: https://lore.kernel.org/r/20230810174905.7997-1-ivan.orlov0322@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: class: Store the color index in struct led_classdevJean-Jacques Hiblot2023-08-171-0/+21
| | | | | | | | | | Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the user space or used by the LED consumer. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: Provide devm_of_led_get_optional()Jean-Jacques Hiblot2023-08-171-0/+25
| | | | | | | | | | | Add an optional variant of devm_of_led_get(). It behaves the same as devm_of_led_get() except where the LED doesn't exist. In this case, instead of returning -ENOENT, the function returns NULL. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230728153731.3742339-2-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
* led: led-class: Read max-brightness from devicetreeAstrid Rost2023-07-281-0/+4
| | | | | | | | | | | | | | | | | Normally, the maximum brightness is determined by the hardware, and this property is not required. This property is used to set a software limit. It could happen that an LED is made so bright that it gets damaged or causes damage due to restrictions in a specific system, such as mounting conditions. Note that this flag is mainly used for PWM-LEDs, where it is not possible to map brightness to current. Drivers for other controllers should use led-max-microamp. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Astrid Rost <astrid.rost@axis.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/r/20230703130313.548519-3-astrid.rost@axis.com Signed-off-by: Lee Jones <lee@kernel.org>
* leds: Replace all non-returning strlcpy with strscpyAzeem Shaikh2023-05-251-1/+1
| | | | | | | | | | | | | | | | | | strlcpy() reads the entire source buffer first. This read may exceed the destination size limit. This is both inefficient and can lead to linear read overflows if a source string is not NUL-terminated [1]. In an effort to remove strlcpy() completely [2], replace strlcpy() here with strscpy(). No return values were used, so direct replacement is safe. [1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy [2] https://github.com/KSPP/linux/issues/89 Signed-off-by: Azeem Shaikh <azeemshaikh38@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230523021451.2406362-1-azeemshaikh38@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
* driver core: class: remove module * from class_create()Greg Kroah-Hartman2023-03-171-1/+1
| | | | | | | | | | | | The module pointer in class_create() never actually did anything, and it shouldn't have been requred to be set as a parameter even if it did something. So just remove it and fix up all callers of the function in the kernel tree at the same time. Cc: "Rafael J. Wysocki" <rafael@kernel.org> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20230313181843.1207845-4-gregkh@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: led-core: Fix refcount leak in of_led_get()Miaoqian Lin2023-01-301-0/+1
| | | | | | | | | | | class_find_device_by_of_node() calls class_find_device(), it will take the reference, use the put_device() to drop the reference when not need anymore. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20221220121807.1543790-1-linmq006@gmail.com
* leds: led-class: Add generic [devm_]led_get()Hans de Goede2023-01-271-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | Add a generic [devm_]led_get() method which can be used on both devicetree and non devicetree platforms to get a LED classdev associated with a specific function on a specific device, e.g. the privacy LED associated with a specific camera sensor. Note unlike of_led_get() this takes a string describing the function rather then an index. This is done because e.g. camera sensors might have a privacy LED, or a flash LED, or both and using an index approach leaves it unclear what the function of index 0 is if there is only 1 LED. This uses a lookup-table mechanism for non devicetree platforms. This allows the platform code to map specific LED class_dev-s to a specific device,function combinations this way. For devicetree platforms getting the LED by function-name could be made to work using the standard devicetree pattern of adding a -names string array to map names to the indexes. Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-5-hdegoede@redhat.com
* leds: led-class: Add __devm_led_get() helperHans de Goede2023-01-271-12/+17
| | | | | | | | | | | | | | Add a __devm_led_get() helper which registers a passed in led_classdev with devm for unregistration. This is a preparation patch for adding a generic (non devicetree specific) devm_led_get() function. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-4-hdegoede@redhat.com
* leds: led-class: Add led_module_get() helperHans de Goede2023-01-271-12/+18
| | | | | | | | | | | | | | Split out part of of_led_get() into a generic led_module_get() helper function. This is a preparation patch for adding a generic (non devicetree specific) led_get() function. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-3-hdegoede@redhat.com
* leds: led-class: Add missing put_device() to led_put()Hans de Goede2023-01-271-1/+4
| | | | | | | | | | | | | | | | | | | | led_put() is used to "undo" a successful of_led_get() call, of_led_get() uses class_find_device_by_of_node() which returns a reference to the device which must be free-ed with put_device() when the caller is done with it. Add a put_device() call to led_put() to free the reference returned by class_find_device_by_of_node(). And also add a put_device() in the error-exit case of try_module_get() failing. Fixes: 699a8c7c4bd3 ("leds: Add of_led_get() and led_put()") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230120114524.408368-2-hdegoede@redhat.com
* leds: led-core: Update fwnode with device_set_nodeSander Vanheule2022-01-121-4/+2
| | | | | | | | | | Update a newly created device's fwnode and of_node pointers using the recently added device_set_node helper. This keeps some firmware node specifics out of led-class and should help tracking future changes regarding device firmware node updates. Signed-off-by: Sander Vanheule <sander@svanheule.net> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: leds-core: Implement the retain-state-shutdown propertyEddie James2021-08-201-2/+8
| | | | | | | | | | | Read the retain-state-shutdown device tree property to set the existing LED_RETAIN_AT_SHUTDOWN flag. Then check the flag when unregistering, and if set, don't set the brightness to OFF. This is useful for systems that want to keep the HW state of the LED across reboots. Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: class: The -ENOTSUPP should never be seen by user spaceAndy Shevchenko2021-05-281-4/+0
| | | | | | | | | | Drop the bogus error code and let of_led_get() to take care about absent of_node. Fixes: e389240ad992 ("leds: Add managed API to get a LED from a device driver") Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: led-class: Fix incorrectly documented param 'dev'Lee Jones2021-05-281-1/+1
| | | | | | | | | | | | | | Fixes the following W=1 kernel build warning(s): drivers/leds/led-class.c:521: warning: Function parameter or member 'dev' not described in 'devm_led_classdev_unregister' drivers/leds/led-class.c:521: warning: Excess function parameter 'parent' description in 'devm_led_classdev_unregister' Cc: Pavel Machek <pavel@ucw.cz> Cc: John Lenz <lenz@cs.wisc.edu> Cc: Richard Purdie <rpurdie@openedhand.com> Cc: linux-leds@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: led-core: Get rid of enum led_brightnessAbanoub Sameh2021-02-191-2/+1
| | | | | | | | | | | This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead. We can get rid of led_brightness completely and patches can also be supplied for the other drivers' files. Signed-off-by: Abanoub Sameh <abanoubsameh@protonmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: parse linux,default-trigger DT property in LED coreMarek Behún2020-09-261-0/+5
| | | | | | | | | | | | | | | | | | | | Do the parsing of `linux,default-trigger` DT property to LED core. Currently it is done in many different drivers and the code is repeated. This patch removes the parsing from 23 drivers: an30259a, aw2013, bcm6328, bcm6358, cr0014114, el15203000, gpio, is31fl32xx, lm3532, lm36274, lm3692x, lm3697, lp50xx, lp8860, lt3593, max77650, mt6323, ns2, pm8058, pwm, syscon, tlc591xx and turris-omnia. There is one driver in drivers/input which parses this property on it's own. I shall send a separate patch there after this is applied. There are still 8 drivers that parse this property on their own because they do not pass the led_init_data structure to the registering function. I will try to refactor those in the future. Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: core: Flush scheduled work for system suspendKai-Heng Feng2020-07-121-0/+1
| | | | | | | | | | | | | | | | Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon system suspend. led_set_brightness_nopm() uses schedule_work() to set LED brightness. However, there's no guarantee that the scheduled work gets executed because no one flushes the work. So flush the scheduled work to make sure LED gets turned off. Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Fixes: 81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm} functions") Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: core: Fix warning message when init_dataRicardo Ribalda Delgado2020-04-061-1/+1
| | | | | | | | | | | | The warning message when a led is renamed due to name collition can fail to show proper original name if init_data is used. Eg: [ 9.073996] leds-gpio a0040000.leds_0: Led (null) renamed to red_led_1 due to name collision Fixes: bb4e9af0348d ("leds: core: Add support for composing LED class device names") Signed-off-by: Ricardo Ribalda Delgado <ribalda@kernel.org> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: populate the device's of_nodeJean-Jacques Hiblot2020-01-061-1/+3
| | | | | | | | | If initialization data is available and its fwnode is actually a of_node, store this information in the led device's structure. This will allow the device to use or provide OF-based API such (devm_xxx). Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: Add managed API to get a LED from a device driverJean-Jacques Hiblot2020-01-061-0/+49
| | | | | | | | | If the LED is acquired by a consumer device with devm_led_get(), it is automatically released when the device is detached. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: Add of_led_get() and led_put()Tomi Valkeinen2020-01-061-0/+44
| | | | | | | | | | | | | This patch adds basic support for a kernel driver to get a LED device. This will be used by the led-backlight driver. Only OF version is implemented for now, and the behavior is similar to PWM's of_pwm_get() and pwm_put(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Jean-Jacques Hiblot <jjhiblot@ti.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: core: Fix devm_classdev_match to reference correct structureDan Murphy2019-11-031-1/+1
| | | | | | | | Fix the devm_classdev_match pointer initialization to the correct structure type. Signed-off-by: Dan Murphy <dmurphy@ti.com> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: remove PAGE_SIZE limit of /sys/class/leds/<led>/triggerAkinobu Mita2019-11-031-4/+4
| | | | | | | | | | | | | | | | | | | | | Reading /sys/class/leds/<led>/trigger returns all available LED triggers. However, the size of this file is limited to PAGE_SIZE because of the limitation for sysfs attribute. Enabling LED CPU trigger on systems with thousands of CPUs easily hits PAGE_SIZE limit, and makes it impossible to see all available LED triggers and which trigger is currently activated. We work around it here by converting /sys/class/leds/<led>/trigger to binary attribute, which is not limited by length. This is _not_ good design, do not copy it. Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com>A Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: Allow to call led_classdev_unregister() unconditionallyAndy Shevchenko2019-08-261-0/+4
| | | | | | | | | | | | | | | If in the certain driver the LED is optional, and it's a majority of them, the call of led_classdev_unregister() still requires some additional checks. The usual pattern on unregistering is to check for NULL, but we also check for IS_ERR() in case device_create_with_groups() fails. The change will reduce a burden in a lot of drivers to repeatedly check for above conditions. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: Switch to use fwnode instead of be stuck with OF oneAndy Shevchenko2019-08-231-2/+2
| | | | | | | | | | | | | | There is no need to be stuck with OF node when we may use agnostic firmware node instead. It allows users to get property if needed independently of provider. Note, some OF parts are left because %pfw [1] is in progress. [1]: https://lore.kernel.org/patchwork/cover/1054863/ Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* Merge tag 'generic_lookup_helpers' into for-nextJacek Anaszewski2019-07-301-8/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generic Device Lookup Helpers Persistent tag for others to pull this branch from Based on patch series from Suzuki K Poulose <suzuki.poulose@arm.com> with Subject: [PATCH v3 0/7] drivers: Add generic device lookup helpers Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> * tag 'generic_lookup_helpers': platform: Add platform_find_device_by_driver() helper drivers: Add generic helper to match any device drivers: Introduce device lookup variants by ACPI_COMPANION device drivers: Introduce device lookup variants by device type drivers: Introduce device lookup variants by fwnode drivers: Introduce device lookup variants by of_node drivers: Introduce device lookup variants by name
| * drivers: Introduce device lookup variants by nameSuzuki K Poulose2019-07-301-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a helper to match the device name for device lookup. Also reuse this generic exported helper for the existing bus_find_device_by_name(). and add similar variants for driver/class. Cc: Alessandro Zummo <a.zummo@towertech.it> Cc: Alexander Aring <alex.aring@gmail.com> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Dan Murphy <dmurphy@ti.com> Cc: Harald Freudenberger <freude@linux.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Lee Jones <lee.jones@linaro.org> Cc: linux-leds@vger.kernel.org Cc: linux-rtc@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: linux-wpan@vger.kernel.org Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Peter Oberparleiter <oberpar@linux.ibm.com> Cc: "Rafael J. Wysocki" <rafael@kernel.org> Cc: Stefan Schmidt <stefan@datenfreihafen.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20190723221838.12024-2-suzuki.poulose@arm.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | leds: core: Add support for composing LED class device namesJacek Anaszewski2019-07-251-3/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add generic support for composing LED class device name. The newly introduced led_compose_name() function composes device name according to either <color:function> or <devicename:color:function> pattern, depending on the configuration of initialization data. Backward compatibility with in-driver hard-coded LED class device names is assured thanks to the default_label and devicename properties of newly introduced struct led_init_data. In case none of the aforementioned properties was found, then, for OF nodes, the node name is adopted for LED class device name. At the occassion of amending the Documentation/leds/leds-class.txt unify spelling: colour -> color. Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh. The tool allows retrieving details of a LED class device's parent device, which proves that using vendor or product name for devicename part of LED name doesn't convey any added value since that information had been already available in sysfs. The script performs also basic validation of a LED class device name. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Baolin Wang <baolin.wang@linaro.org> Cc: Dan Murphy <dmurphy@ti.com> Cc: Daniel Mack <daniel@zonque.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Oleh Kravchenko <oleg@kaa.org.ua> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Simon Shields <simon@lineageos.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz>
* | leds: class: Improve LED and LED flash class registration APIJacek Anaszewski2019-07-251-12/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replace of_led_classdev_register() with led_classdev_register_ext(), which accepts easily extendable struct led_init_data, instead of the fixed struct device_node argument. The latter can be now passed in an fwnode property of the struct led_init_data. The modification is driven by the need for passing additional arguments required for the forthcoming generic mechanism for composing LED names. Currently the LED name is conveyed in the "name" char pointer property of the struct led_classdev. This is redundant since LED class device name is accessible throughout the whole LED class device life time via associated struct device's kobj->name property. The change will not break any existing clients since the patch alters also existing led_classdev{_flash}_register() macro wrappers, that pass NULL in place of init_data, which leads to using legacy name initialization path basing on the struct led_classdev's "name" property. Three existing users of devm_of_led_classdev_registers() are modified to use devm_led_classdev_register(), which will not impact their operation since they in fact didn't need to pass struct device_node on registration from the beginning. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Baolin Wang <baolin.wang@linaro.org> Cc: Dan Murphy <dmurphy@ti.com> Cc: Daniel Mack <daniel@zonque.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Oleh Kravchenko <oleg@kaa.org.ua> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Simon Shields <simon@lineageos.org> Acked-by: Pavel Machek <pavel@ucw.cz>
* treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: avoid races with workqueuePavel Machek2019-05-021-0/+1
| | | | | | | | | | | | | | | | | | | | | There are races between "main" thread and workqueue. They manifest themselves on Thinkpad X60: This should result in LED blinking, but it turns it off instead: root@amd:/data/pavel# cd /sys/class/leds/tpacpi\:\:power root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger root@amd:/sys/class/leds/tpacpi::power# echo timer > trigger It should be possible to transition from blinking to solid on by echo 0 > brightness; echo 1 > brightness... but that does not work, either, if done too quickly. Synchronization of the workqueue fixes both. Fixes: 1afcadfcd184 ("leds: core: Use set_brightness_work for the blocking op") Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: class: ensure workqueue is initialized before setting brightnessLuis Henriques2018-05-241-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An application can try to set brightness before all the initialization is done, in particular before the workqueue is initialized with the call to led_init_core(). Here's a WARNING easy to trigger: [ 36.780813] WARNING: CPU: 3 PID: 1411 at ../kernel/workqueue.c:1444 __queue_work+0x37b/0x420 [ 36.780815] Modules linked in: ... [ 36.780868] CPU: 3 PID: 1411 Comm: systemd-backlig Not tainted 4.16.9-1-default #1 openSUSE Tumbleweed (unreleased) [ 36.780868] Hardware name: Dell Inc. Precision 5510/0N8J4R, BIOS 1.6.1 12/11/2017 [ 36.780870] RIP: 0010:__queue_work+0x37b/0x420 [ 36.780871] RSP: 0018:ffffaced048b7d78 EFLAGS: 00010086 [ 36.780873] RAX: 0000000000000000 RBX: ffffffffb3f01440 RCX: 0000000000000000 [ 36.780873] RDX: ffffffffc05a90d8 RSI: 0000000000000000 RDI: ffff8eac7dce2700 [ 36.780874] RBP: ffff8ea547c16400 R08: ffff8ea547800000 R09: ffff8eac7dc22700 [ 36.780875] R10: 0000000000000000 R11: 0000000000000040 R12: 0000000000000003 [ 36.780876] R13: 0000000000000200 R14: ffffffffc05a90d0 R15: ffff8eac7dce8600 [ 36.780877] FS: 00007f871e61cf40(0000) GS:ffff8eac7dcc0000(0000) knlGS:0000000000000000 [ 36.780878] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 36.780879] CR2: 000055c91115e308 CR3: 0000000883ee0005 CR4: 00000000003606e0 [ 36.780880] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 36.780880] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 36.780881] Call Trace: [ 36.780886] queue_work_on+0x81/0x90 [ 36.780889] brightness_store+0x5d/0x90 [ 36.780892] kernfs_fop_write+0x105/0x180 [ 36.780894] __vfs_write+0x26/0x150 [ 36.780897] ? common_file_perm+0x51/0x150 [ 36.780900] ? security_file_permission+0x3c/0xb0 [ 36.780901] vfs_write+0xad/0x1a0 [ 36.780903] SyS_write+0x42/0x90 [ 36.780906] do_syscall_64+0x76/0x140 [ 36.780908] entry_SYSCALL_64_after_hwframe+0x42/0xb7 [ 36.780910] RIP: 0033:0x7f871dd04c94 [ 36.780910] RSP: 002b:00007ffeb3a57d38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 36.780912] RAX: ffffffffffffffda RBX: 000055c91115c810 RCX: 00007f871dd04c94 [ 36.780912] RDX: 0000000000000001 RSI: 000055c91115c810 RDI: 0000000000000004 [ 36.780913] RBP: 00007ffeb3a57e10 R08: 0000000000000003 R09: 0000000000000000 [ 36.780914] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 [ 36.780914] R13: 000055c911158f30 R14: 000055c90f3a9a4e R15: 0000000000000004 [ 36.780917] Code: 74 18 e8 49 80 00 00 48 85 c0 74 0e 48 8b 40 20 48 3b 68 08 0f 84 c2 fc ff ff 0f 0b 48 83 c4 10 5b 5d 41 5c 41 5d 41 5e 41 5f c3 <0f> 0b e9 82 fd ff ff 83 cd 02 49 8d 57 60 e9 69 fd ff ff 80 3d [ 36.780942] ---[ end trace 1fce4edad54c4017 ]--- This patch initializes and acquires the led_access mutex early in the of_led_classdev_register function, so that any application trying to write to sysfs to set brightness will block until initialization ends. Signed-off-by: Luis Henriques <lhenriques@suse.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: core: add OF variants of LED registering functionsRafał Miłecki2017-03-081-10/+16
| | | | | | | | | | | | | | These new functions allow passing an additional device_node argument that will be internally set for created LED device. Thanks to this LED core code and triggers will be able to access DT node for reading extra info. The easiest solution for achieving this was reworking old functions to more generic ones & adding simple defines for API compatibility. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* leds: class: Add new optional brightness_hw_changed attributeHans de Goede2017-01-291-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some LEDs may have their brightness level changed autonomously (outside of kernel control) by hardware / firmware. This commit adds support for an optional brightness_hw_changed attribute to signal such changes to userspace (if a driver can detect them): What: /sys/class/leds/<led>/brightness_hw_changed Date: January 2017 KernelVersion: 4.11 Description: Last hardware set brightness level for this LED. Some LEDs may be changed autonomously by hardware/firmware. Only LEDs where this happens and the driver can detect this, will have this file. This file supports poll() to detect when the hardware changes the brightness. Reading this file will return the last brightness level set by the hardware, this may be different from the current brightness. Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to their flags field and call led_classdev_notify_brightness_hw_changed() with the hardware set brightness when they detect a hardware / firmware triggered brightness change. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* led: core: Use atomic bit-field for the blink-flagsHans de Goede2016-11-221-0/+1
| | | | | | | | | | | | | All the LED_BLINK* flags are accessed read-modify-write from e.g. led_set_brightness and led_blink_set_oneshot while both set_brightness_work and the blink_timer may be running. If these race then the modify step done by one of them may be lost, switch the LED_BLINK* flags to a new atomic work_flags bit-field to avoid this race. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: Use macro for max device node name sizeDavid Lechner2016-11-221-1/+2
| | | | | | | | Use a macro instead of hard-coding the max device node name size. The uleds driver introduced a macro for this value, so using it. Signed-off-by: David Lechner <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: avoid error message when a USB LED device is unpluggedHeiner Kallweit2016-03-141-0/+2
| | | | | | | | | | | | | | | When a USB LED device is unplugged the remove call chain calls led_classdev_unregister which tries to switch the LED off. As the device has been removed already this results in a ENODEV error message in dmesg. Avoid this error message by ignoring ENODEV in calls from led_classdev_unregister if the LED device is flagged as pluggable. Therefore a new flag LED_HW_PLUGGABLE was introduced which should be set by all LED drivers handling pluggable LED devices (mainly USB LED devices). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: turn off the LED and wait for completion on unregistering LED class deviceMilo Kim2016-01-041-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Workqueue, 'set_brightness_work' is used for scheduling brightness control. This workqueue is canceled when the LED class device is unregistered. Currently, LED subsystem handles like below. cancel_work_sync(&led_cdev->set_brightness_work) led_set_brightness(led_cdev, LED_OFF) However, this could be a problem. Workqueue is going to be canceled but LED device needs to be off. The worst case is null pointer access due to scheduling a workqueue. LED module is loaded. LED driver private data is allocated by using devm_zalloc(). LED module is unloaded. led_classdev_unregister() is called. cancel_work_sync() led_set_brightness(led_cdev, LED_OFF) schedule_work() if LED driver uses brightness_set_blocking() In the meantime, driver private data will be freed. ..scheduling.. brightness_set_blocking() callback is invoked. For the brightness control, LED driver tries to access private data but resource is removed! To avoid this problem, LED subsystem should turn off the brightness first and wait for completion. led_set_brightness(led_cdev, LED_OFF) flush_work(&led_cdev->set_brightness_work) It guarantees that LED driver turns off the brightness prior to resource management. Cc: linux-leds@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Milo Kim <milo.kim@ti.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: Drivers shouldn't enforce SYNC/ASYNC brightness settingJacek Anaszewski2016-01-041-2/+0
| | | | | | | | | | | | | | | | This patch removes SET_BRIGHTNESS_ASYNC and SET_BRIGHTNESS_SYNC flags. led_set_brightness() now calls led_set_brightness_nosleep() instead of choosing between sync and async op basing on the flags defined by the driver. From now on, if a user wants to make sure that brightness will be set synchronously, they have to use led_set_brightness_sync() API. It is now being made publicly available since it has become apparent that it is a caller who should decide whether brightness is to be set in a synchronous or an asynchronous way. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
* leds: core: Add led_set_brightness_nosleep{nopm} functionsJacek Anaszewski2016-01-041-2/+2
| | | | | | | | | | | | | | | | | This patch adds led_set_brightness_nosleep() and led_set_brightness_nopm() functions, that guarantee setting LED brightness in a non-blocking way. The latter is used from pm_ops context and doesn't modify the brightness cached in the struct led_classdev. Its execution always ends up with a call to brightness setting op - either directly or through a set_brightness_work, regardless of LED_SUSPENDED flag state. The patch also replaces led_set_brightness_async() with led_set_brightness_nosleep() in all places where the most vital was setting brightness in a non sleeping way but not necessarily asynchronously, which is not needed for non-blocking drivers. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
* leds: core: Move LED core callbacks out of led-class.cJacek Anaszewski2015-11-031-68/+1
| | | | | | | | | | Since the API for controlling LED brightness and blinking is defined in the LED core, move the related timer and work callbacks to the led-core.c, and initialize them through a new led_core_init API. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Pavel Machek <pavel@ucw.cz>
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-22 04:22:27 +0000