summaryrefslogtreecommitdiffstats
path: root/drivers/leds
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'leds-next-6.5' of ↵Linus Torvalds2023-07-0356-345/+1938
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Drivers: - Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs - Add support for Awinic AW20036/AW20054/AW20072 LEDs New Device Support: - Add support for PMI632 LPG to QCom LPG - Add support for PMI8998 to QCom Flash - Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC New Functionality: - Implement the LP55xx Charge Pump - Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC - Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC - Enable per-pin resolution Pinctrl in LEDs GPIO Fix-ups: - Allow thread to sleep by switching from spinlock to mutex - Add lots of Device Tree bindings / support - Adapt relationships / dependencies driven by Kconfig - Switch I2C drivers from .probe_new() to .probe() - Remove superfluous / duplicate code - Replace strlcpy() with strscpy() for efficiency and overflow prevention - Staticify various functions - Trivial: Fixing coding style - Simplify / reduce code Bug Fixes: - Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename - Repair race between led_set_brightness(LED_{OFF,FULL}) - Fix Oops relating to sleeping in critical sections - Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger - Do not leak resources in error handling paths - Fix unsigned comparison which can never be negative - Provide missing NULL terminating entries in tables - Fix misnaming issues" * tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits) leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks leds: sgm3140: Add richtek,rt5033-led compatible dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks" dt-bindings: leds: Drop unneeded quotes leds: Fix config reference for AW200xx driver leds: leds-mt6323: Add support for WLEDs and MT6332 leds: leds-mt6323: Add support for MT6331 leds leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro leds: leds-mt6323: Drop MT6323_ prefix from macros and defines leds: leds-mt6323: Specify registers and specs in platform data dt-bindings: leds: leds-mt6323: Document mt6332 compatible dt-bindings: leds: leds-mt6323: Document mt6331 compatible leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches leds: simatic-ipc-leds-gpio: Split up into multiple drivers leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative leds: cht-wcove: Remove unneeded semicolon leds: cht-wcove: Fix an unsigned comparison which can never be negative ...
| * leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacksNathan Chancellor2023-06-231-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang's kernel Control Flow Integrity (kCFI) is a compiler-based security mitigation that ensures the target of an indirect function call matches the expected type of the call and trapping if they do not match exactly. The warning -Wincompatible-function-pointer-types-strict aims to catch these issues at compile time, which reveals: drivers/leds/leds-mt6323.c:598:49: error: incompatible function pointer types assigning to 'int (*)(struct led_classdev *, enum led_brightness)' from 'int (struct led_classdev *, unsigned int)' [-Werror,-Wincompatible-function-pointer-types-strict] 598 | leds->led[reg]->cdev.brightness_set_blocking = | ^ 599 | mt6323_wled_set_brightness; | ~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/leds/leds-mt6323.c:600:40: error: incompatible function pointer types assigning to 'enum led_brightness (*)(struct led_classdev *)' from 'unsigned int (struct led_classdev *)' [-Werror,-Wincompatible-function-pointer-types-strict] 600 | leds->led[reg]->cdev.brightness_get = | ^ 601 | mt6323_get_wled_brightness; | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 2 errors generated. While 'unsigned int' is ABI compatible with 'enum led_brightness' (hence no warning from -Wincompatible-function-pointer-types) and the callers of these callbacks use/pass the values as 'unsigned int', the mismatch between the prototype and the called function will trip kCFI at runtime. Change the types in the implementations to match the prototypes, clearing up the warning and avoiding kCFI failures. Fixes: 9bb0a9e0626c ("leds: leds-mt6323: Add support for WLEDs and MT6332") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230622-mt6323-wled-wincompatible-function-pointer-types-strict-v1-1-6ad256f220e8@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: sgm3140: Add richtek,rt5033-led compatibleRaymond Hackley2023-06-211-0/+1
| | | | | | | | | | | | | | | | | | Richtek's rt5033-led has pin configurations similar to sgm3140. Add it to the compatible list. Signed-off-by: Raymond Hackley <raymondhackley@protonmail.com> Link: https://lore.kernel.org/r/20230602131024.260297-1-raymondhackley@protonmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Fix config reference for AW200xx driverLukas Bulwahn2023-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 36a87f371b7a ("leds: Add AW20xx driver") adds config LEDS_AW200XX in drivers/leds/Kconfig, but then in drivers/leds/Makefile accidently refers to CONFIG_LEDS_W200XX; note the missing A! This typo makes it impossible to add the driver to a kernel build. Fix this wrong config reference. Fixes: 36a87f371b7a ("leds: Add AW20xx driver") Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Link: https://lore.kernel.org/r/20230609100233.4111-1-lukas.bulwahn@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: leds-mt6323: Add support for WLEDs and MT6332AngeloGioacchino Del Regno2023-06-091-7/+164
| | | | | | | | | | | | | | | | | | | | | | | | Add basic code to turn on and off WLEDs and wire up MT6332 support to take advantage of it. This is a simple approach due to the aforementioned PMIC supporting only on/off status so, at the time of writing, it is impossible for me to validate more advanced functionality due to lack of hardware. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-9-angelogioacchino.delregno@collabora.com
| * leds: leds-mt6323: Add support for MT6331 ledsAngeloGioacchino Del Regno2023-06-091-0/+17
| | | | | | | | | | | | | | | | | | | | Add the register offsets for MT6331. The hwspec is the same as MT6323. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-8-angelogioacchino.delregno@collabora.com
| * leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macroAngeloGioacchino Del Regno2023-06-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There is only one instance of using this macro and it's anyway not simplifying the flow, or increasing the readability of this driver. Drop this macro by open coding it in mt6323_led_set_blink(). No functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-7-angelogioacchino.delregno@collabora.com
| * leds: leds-mt6323: Drop MT6323_ prefix from macros and definesAngeloGioacchino Del Regno2023-06-091-63/+60
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This renames all definitions and macros to drop the MT6323_ prefix, since it is now possible to easily add support to more PMICs in this driver. While at it, also fix related formatting where possible. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-6-angelogioacchino.delregno@collabora.com
| * leds: leds-mt6323: Specify registers and specs in platform dataAngeloGioacchino Del Regno2023-06-091-38/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to enhance the flexibility of this driver and let it support more than just one MediaTek LEDs IP for more than just one PMIC, add platform data structure specifying the register offsets and data that commonly varies between different IPs. This commit brings no functional changes. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230601110813.2373764-5-angelogioacchino.delregno@collabora.com
| * leds: simatic-ipc-leds-gpio: Introduce more Kconfig switchesHenning Schild2023-06-082-7/+31
| | | | | | | | | | | | | | | | | | | | | | To describe the dependency chain better and allow for potential fine-grained config tuning, introduce Kconfig switch for the individual GPIO based drivers. Signed-off-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230524124628.32295-5-henning.schild@siemens.com
| * leds: simatic-ipc-leds-gpio: Split up into multiple driversHenning Schild2023-06-087-165/+261
| | | | | | | | | | | | | | | | | | | | | | In order to clearly describe the dependencies between the GPIO controller drivers and the users the driver is split up into a core, two drivers and a common header. Signed-off-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230524124628.32295-4-henning.schild@siemens.com
| * leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another tableHenning Schild2023-06-081-3/+25
| | | | | | | | | | | | | | | | | | | | | | There are two special pins needed to init the LEDs. We used to have them at the end of the gpiod_lookup table to give to "leds-gpio". A cleaner way is to have a dedicated table for the special pins. Signed-off-by: Henning Schild <henning.schild@siemens.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230524124628.32295-3-henning.schild@siemens.com
| * leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tablesHenning Schild2023-06-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The entries do not seem to be stricly needed when the number of entries is given via the number of LEDs. But adding them is a safeguard should anyone ever iterate over the tables to their end, it also gets us in line with other drivers that register "leds-gpio" tables. Reported-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Henning Schild <henning.schild@siemens.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230524124628.32295-2-henning.schild@siemens.com
| * leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be ↵Jiapeng Chong2023-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | negative The variable 'count' is defined as unsigned type, so the following if statement is invalid, we can modify the type of count to int. if (count <= 0) { dev_err(dev, "No led-sources specified\n"); return -ENODEV; } ./drivers/leds/flash/leds-qcom-flash.c:546:5-10: WARNING: Unsigned expression compared with zero: count <= 0. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5344 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230531053559.5702-1-jiapeng.chong@linux.alibaba.com
| * leds: cht-wcove: Remove unneeded semicolonJiapeng Chong2023-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | No functional modification involved. ./drivers/leds/leds-cht-wcove.c:193:2-3: Unneeded semicolon. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5343 Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230531024020.106641-1-jiapeng.chong@linux.alibaba.com
| * leds: cht-wcove: Fix an unsigned comparison which can never be negativeYang Li2023-06-081-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The return value from the call to cht_wc_leds_find_freq() is int. However, the return value is being assigned to an unsigned int variable 'ctrl', so making it an int. Eliminate the following warning: drivers/leds/leds-cht-wcove.c:236 cht_wc_leds_set_effect() warn: unsigned 'ctrl' is never less than zero. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=5341 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230531020238.102684-1-yang.lee@linux.alibaba.com
| * leds: cht-wcove: Mark cht_wc_leds_brightness_get() staticHans de Goede2023-06-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | cht_wc_leds_brightness_get() is only used internally, mark it static. Cc: Yauhen Kharuzhy <jekhor@gmail.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202305260008.QCRrKILf-lkp@intel.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230525183317.129232-1-hdegoede@redhat.com
| * leds: Add AW20xx driverMartin Kurbanov2023-06-013-0/+608
| | | | | | | | | | | | | | | | | | | | | | This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver. This driver supports following AW200XX features: - Individual 64-level DIM currents Signed-off-by: Martin Kurbanov <mmkurbanov@sberdevices.ru> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20230519130403.212479-3-mmkurbanov@sberdevices.ru Signed-off-by: Lee Jones <lee@kernel.org>
| * led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loopsLu Hongfei2023-05-251-2/+6
| | | | | | | | | | | | | | | | Ensure child node references are decremented properly in the error path. Signed-off-by: Lu Hongfei <luhongfei@vivo.com> Link: https://lore.kernel.org/r/20230525111705.3055-1-luhongfei@vivo.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: as3645a: Replace strlcpy with strscpyAzeem Shaikh2023-05-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Part of a tree-wide effort to remove deprecated strlcpy()[1] and replace it with strscpy()[2]. 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> Link: https://lore.kernel.org/r/20230524144824.2360607-1-azeemshaikh38@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: gpio: Configure per-LED pin controlMarek Vasut2023-05-251-0/+18
| | | | | | | | | | | | | | | | | | | | | | Each gpio-leds DT node DT subnode can have a pinctrl property assigned to it, parse the DT subnode pinctrl properties and configure each pin accordingly. Tested-by: Christoph Niedermaier <cniedermaier@dh-electronics.com> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://lore.kernel.org/r/20230523183151.5460-1-marex@denx.de Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Replace all non-returning strlcpy with strscpyAzeem Shaikh2023-05-253-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * leds: blinkm: 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/20230523021228.2406112-1-azeemshaikh38@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Add HAS_IOPORT dependenciesNiklas Schnelle2023-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | In a future patch HAS_IOPORT=n will result in inb()/outb() and friends not being declared. We thus need to add HAS_IOPORT as dependency for those drivers using them. Co-developed-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Arnd Bergmann <arnd@kernel.org> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20230522105049.1467313-18-schnelle@linux.ibm.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: trigger: netdev: Remove NULL check before dev_{put, hold}Yang Li2023-05-251-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The call netdev_{put, hold} of dev_{put, hold} will check NULL, so there is no need to check before using dev_{put, hold}, remove it to silence the warnings: ./drivers/leds/trigger/ledtrig-netdev.c:291:3-10: WARNING: NULL check before dev_{put, hold} functions is not needed. ./drivers/leds/trigger/ledtrig-netdev.c:401:2-9: WARNING: NULL check before dev_{put, hold} functions is not needed. Reported-by: Abaci Robot <abaci@linux.alibaba.com> Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=4929 Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Link: https://lore.kernel.org/r/20230511070820.52731-1-yang.lee@linux.alibaba.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current triggerHans de Goede2023-05-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Not all triggers use LED_INIT_DEFAULT_TRIGGER, which means that it will not get cleared when the default trigger is a trigger which does not use it such as "default-on". If the default trigger then later gets replaced by a trigger which does check LED_INIT_DEFAULT_TRIGGER, such as "timer" then that trigger will behave as if it is the default trigger which it should not do. To fix this clear the LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger, so that it will not be set for any subsequently set (non default) triggers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-5-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Fix oops about sleeping in led_trigger_blink()Hans de Goede2023-05-252-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | led_trigger_blink() calls led_blink_set() from a RCU read-side critical section so led_blink_set() must not sleep. Note sleeping was not allowed before the switch to RCU either because a spinlock was held before. led_blink_set() does not sleep when sw-blinking is used, but many LED controller drivers with hw blink support have a blink_set function which may sleep, leading to an oops like this one: [ 832.605062] ------------[ cut here ]------------ [ 832.605085] Voluntary context switch within RCU read-side critical section! [ 832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690 <snip> [ 832.606453] Call Trace: [ 832.606466] <TASK> [ 832.606487] __schedule+0x9f/0x1480 [ 832.606527] schedule+0x5d/0xe0 [ 832.606549] schedule_timeout+0x79/0x140 [ 832.606572] ? __pfx_process_timeout+0x10/0x10 [ 832.606599] wait_for_completion_timeout+0x6f/0x140 [ 832.606627] i2c_dw_xfer+0x101/0x460 [ 832.606659] ? psi_group_change+0x168/0x400 [ 832.606680] __i2c_transfer+0x172/0x6d0 [ 832.606709] i2c_smbus_xfer_emulated+0x27d/0x9c0 [ 832.606732] ? __schedule+0x430/0x1480 [ 832.606753] ? preempt_count_add+0x6a/0xa0 [ 832.606778] ? get_nohz_timer_target+0x18/0x190 [ 832.606796] ? lock_timer_base+0x61/0x80 [ 832.606817] ? preempt_count_add+0x6a/0xa0 [ 832.606842] __i2c_smbus_xfer+0xa2/0x3f0 [ 832.606862] i2c_smbus_xfer+0x66/0xf0 [ 832.606882] i2c_smbus_read_byte_data+0x41/0x70 [ 832.606901] ? _raw_spin_unlock_irqrestore+0x23/0x40 [ 832.606922] ? __pm_runtime_suspend+0x46/0xc0 [ 832.606946] cht_wc_byte_reg_read+0x2e/0x60 [ 832.606972] _regmap_read+0x5c/0x120 [ 832.606997] _regmap_update_bits+0x96/0xc0 [ 832.607023] regmap_update_bits_base+0x5b/0x90 [ 832.607053] cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove] [ 832.607094] led_blink_setup+0x28/0x100 [ 832.607119] led_trigger_blink+0x40/0x70 [ 832.607145] power_supply_update_leds+0x1b7/0x1c0 [ 832.607174] power_supply_changed_work+0x67/0xe0 [ 832.607198] process_one_work+0x1c8/0x3c0 [ 832.607222] worker_thread+0x4d/0x380 [ 832.607243] ? __pfx_worker_thread+0x10/0x10 [ 832.607258] kthread+0xe9/0x110 [ 832.607279] ? __pfx_kthread+0x10/0x10 [ 832.607300] ret_from_fork+0x2c/0x50 [ 832.607337] </TASK> [ 832.607344] ---[ end trace 0000000000000000 ]--- Add a new led_blink_set_nosleep() function which defers the actual led_blink_set() call to a workqueue when necessary to fix this. This also fixes an existing race where a pending led_set_brightness() has been deferred to set_brightness_work and might then race with a later led_cdev->blink_set() call. Note this race is only an issue with triggers mixing led_trigger_event() and led_trigger_blink() calls, sysfs API calls and led_trigger_blink_oneshot() are not affected. Note rather then adding a separate blink_set_blocking callback this uses the presence of the already existing brightness_set_blocking callback to detect if the blinking call should be deferred to set_brightness_work. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Fix set_brightness_delayed() raceHans de Goede2023-05-251-13/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a trigger wants to switch from blinking to LED on it needs to call: led_set_brightness(LED_OFF); led_set_brightness(LED_FULL); To first call disables blinking and the second then turns the LED on (the power-supply charging-blink-full-solid triggers do this). These calls happen immediately after each other, so it is possible that set_brightness_delayed() from the first call has not run yet when the led_set_brightness(LED_FULL) call finishes. If this race hits then this is causing problems for both sw- and hw-blinking: For sw-blinking set_brightness_delayed() clears delayed_set_value when LED_BLINK_DISABLE is set causing the led_set_brightness(LED_FULL) call effects to get lost when hitting the race, resulting in the LED turning off instead of on. For hw-blinking if the race hits delayed_set_value has been set to LED_FULL by the time set_brightness_delayed() runs. So led_cdev->brightness_set_blocking() is never called with LED_OFF as argument and the hw-blinking is never disabled leaving the LED blinking instead of on. Fix both issues by adding LED_SET_BRIGHTNESS and LED_SET_BRIGHTNESS_OFF work_flags making this 2 separate actions to be run by set_brightness_delayed(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Link: https://lore.kernel.org/r/20230510162234.291439-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-valueHans de Goede2023-05-253-20/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | led_blink_set[_oneshot]()'s delay_on and delay_off function parameters are pass by reference, so that hw-blink implementations can report back the actual achieved delays when the values have been rounded to something the hw supports. This is really only interesting for the sysfs API / the timer trigger. Other triggers don't really care about this and none of the callers of led_trigger_blink[_oneshot]() do anything with the returned delay values. Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value, there are 2 reasons for this: 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not. So on hw where led_cdev->blink_set() sleeps the call needs to be deferred to a workqueue, in which case the actual achieved delays are unknown (this is a preparation patch for the deferring). 2. Since the callers don't care about the actual achieved delays, allowing callers to directly pass a value leads to simpler code for most callers. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Tested-by: Yauhen Kharuzhy <jekhor@gmail.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by: Florian Westphal <fw@strlen.de> Link: https://lore.kernel.org/r/20230510162234.291439-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Switch i2c drivers back to use .probe()Uwe Kleine-König2023-05-2530-30/+30
| | | | | | | | | | | | | | | | | | | | | | | | After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230517180559.166329-1-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Make LEDS_TI_LMU_COMMON invisibleGeert Uytterhoeven2023-05-251-6/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON, which contains the common code to support TI LMU devices. This means the user is asked about the common code first, followed by the individual drivers, if their dependencies are met. Simplify this, and reduce the number of questions by making LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: flash: leds-qcom-flash: Disable LED when changing brightnessDylan Van Assche2023-05-251-0/+8
| | | | | | | | | | | | | | | | | | | | The Qualcomm PMI8998 PMIC requires the LED to be disabled when configuring the brightness. Always disable the LED when setting the brightness and re-enable it afterwards. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Link: https://lore.kernel.org/r/20230507172941.364852-3-me@dylanvanassche.be Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: flash: leds-qcom-flash: Add PMI8998 supportDylan Van Assche2023-05-251-2/+3
| | | | | | | | | | | | | | | | | | | | Add subtype for the Qualcomm PMI8998 PMIC to support it besides the PM8150 PMIC which has the same registers. Adjust the driver to recognize both PMIC subtypes as a 3 channel LED driver. Signed-off-by: Dylan Van Assche <me@dylanvanassche.be> Link: https://lore.kernel.org/r/20230507172941.364852-2-me@dylanvanassche.be Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: cht-wcove: Use breathing when LED_INIT_DEFAULT_TRIGGER is setHans de Goede2023-05-251-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | The desired default behavior of LED1 / the charge LED is breathing while charging and on/solid when full. Since triggers cannot select breathing, blink_set() gets called when charging. Use breathing when the default "charging-blink-full-solid" trigger is used to achieve the desired default behavior. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-6-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: cht-wcove: Set default trigger for charging LEDHans de Goede2023-05-251-0/+16
| | | | | | | | | | | | | | | | | | Set a default trigger for the charging LED based on the machine-model as set by the PMIC MFD driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-5-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: cht-wcove: Add support for breathing mode use hw_pattern sysfs APIHans de Goede2023-05-251-4/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hw-blinking of the LED controller in the Whiskey Cove PMIC can also be used for a hw-breathing effect. As discussed during review of v2 of the submission of the new leds-cht-wcove driver, the LED subsystem already supports breathing mode on several other LED controllers using the hw_pattern interface. Implement a pattern_set callback to implement breathing mode modelled after the breathing mode supported by the SC27xx breathing light and Crane EL15203000 LED drivers. The Whiskey Cove PMIC's breathing mode is closer to the EL15203000 one then to the SC27xx one since it does not support staying high / low for a specific time, it only supports rise and fall times. As such the supported hw_pattern and the documentation for this is almost a 1:1 copy of the pattern/docs for the EL15203000 breathing mode. Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/all/6beed61c-1fc6-6525-e873-a8978f5fbffb@gmail.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: cht-wcove: Add suspend/resume handlingHans de Goede2023-05-251-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When LED1 is showing the tablet is charging and then the device gets suspended followed by unplugging the charger, then it will incorrectly still show it is charging. To avoid this turn both LEDs off on suspend, just like the PMIC always turns them off when the tablet is powered off (even if the tablet is charging). If hw-control is supported for LED1, then restore the initial hw-control settings to let the hw control LED1 while suspended. To restore the state the LEDs had before suspending, save it before turning the LEDs off and restore it on resume. Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driverYauhen Kharuzhy2023-05-253-0/+392
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for LEDs connected to the Intel Cherry Trail Whiskey Cove PMIC. Charger and general-purpose LEDs are supported. Hardware blinking is implemented, breathing is not. This driver was tested with Lenovo Yoga Book notebook. Changes by Hans de Goede (in response to review of v2): - Since the PMIC is connected to the battery any changes we make to the LED settings are permanent, even surviving reboot / poweroff. Save LED1 register settings on probe() and if auto-/hw-control was enabled on probe() restore the settings on remove() and shutdown(). - Delay switching LED1 to software control mode to first brightness write. - Use dynamically allocated drvdata instead of a global drvdata variable. - Ensure the LED is on when activating blinking. - Fix CHT_WC_LED_EFF_BREATHING val ((3 << 1) rather then BIT(3)). Link: https://lore.kernel.org/r/20190212205901.13037-2-jekhor@gmail.com Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: qcom-lpg: Add support for PMI632 LPGLuca Weiss2023-05-251-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PMI632 PMIC contains 5 PWM channels, 3 of which can be used for LEDs. For the LED pattern it doesn't have LUT like other PMICs but uses SDAM instead. This is not currently implemented in the driver but since LPG works fine without it, add support for the PMIC now. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Acked-by: Pavel Machek <pavel@ucw.cz> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230414-pmi632-v2-4-98bafa909c36@z3ntu.xyz
| * leds: lp55xx: Configure internal charge pumpMaarten Zanders2023-05-254-14/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The LP55xx range of devices have an internal charge pump which can (automatically) increase the output voltage towards the LED's, boosting the output voltage to 4.5V. Implement this option from the devicetree. When the setting is not present it will operate in automatic mode as before. Tested on LP55231. Datasheet analysis shows that LP5521, LP5523 and LP8501 are identical in topology and are modified in the same way. Signed-off-by: Maarten Zanders <maarten.zanders@mind.be> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230421075305.37597-3-maarten.zanders@mind.be
* | leds: trigger: netdev: expose hw_control status via sysfsChristian Marangi2023-06-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Expose hw_control status via sysfs for the netdev trigger to give userspace better understanding of the current state of the trigger and the LED. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | leds: trigger: netdev: add additional specific link duplex modeChristian Marangi2023-06-211-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add additional modes for specific link duplex. Use ethtool APIs to get the current link duplex and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link duplex. Add additional modes: - half_duplex: Turn on LED when link is half duplex - full_duplex: Turn on LED when link is full duplex Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | leds: trigger: netdev: add additional specific link speed modeChristian Marangi2023-06-211-10/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add additional modes for specific link speed. Use ethtool APIs to get the current link speed and enable the LED accordingly. Under netdev event handler the rtnl lock is already held and is not needed to be set to access ethtool APIs. This is especially useful for PHY and Switch that supports LEDs hw control for specific link speed. (example scenario a PHY that have 2 LED connected one green and one orange where the green is turned on with 1000mbps speed and orange is turned on with 10mpbs speed) On mode set from sysfs we check if we have enabled split link speed mode and reject enabling generic link mode to prevent wrong and redundant configuration. Rework logic on the set baseline state to support these new modes to select if we need to turn on or off the LED. Add additional modes: - link_10: Turn on LED when link speed is 10mbps - link_100: Turn on LED when link speed is 100mbps - link_1000: Turn on LED when link speed is 1000mbps Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
* | leds: trigger: netdev: uninitialized variable in netdev_trig_activate()Dan Carpenter2023-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | The qca8k_cled_hw_control_get() function which implements ->hw_control_get sets the appropriate bits but does not clear them. This leads to an uninitialized variable bug. Fix this by setting mode to zero at the start. Fixes: e0256648c831 ("net: dsa: qca8k: implement hw_control ops") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Acked-by: Lee Jones <lee@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
* | Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski2023-06-081-4/+4
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cross-merge networking fixes after downstream PR. Conflicts: net/sched/sch_taprio.c d636fc5dd692 ("net: sched: add rcu annotations around qdisc->qdisc_sleeping") dced11ef84fb ("net/sched: taprio: don't overwrite "sch" variable in taprio_dump_class_stats()") net/ipv4/sysctl_net_ipv4.c e209fee4118f ("net/ipv4: ping_group_range: allow GID from 2147483648 to 4294967294") ccce324dabfe ("tcp: make the first N SYN RTO backoffs linear") https://lore.kernel.org/all/20230605100816.08d41a7b@canb.auug.org.au/ No adjacent changes. Signed-off-by: Jakub Kicinski <kuba@kernel.org>
| * | leds: qcom-lpg: Fix PWM period limitsBjorn Andersson2023-06-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The introduction of high resolution PWM support changed the order of the operations in the calculation of min and max period. The result in both divisions is in most cases a truncation to 0, which limits the period to the range of [0, 0]. Both numerators (and denominators) are within 64 bits, so the whole expression can be put directly into the div64_u64, instead of doing it partially. Fixes: b00d2ed37617 ("leds: rgb: leds-qcom-lpg: Add support for high resolution PWM") Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org> Tested-by: Steev Klimaszewski <steev@kali.org> Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Acked-by: Lee Jones <lee@kernel.org> Tested-by: Johan Hovold <johan+linaro@kernel.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Link: https://lore.kernel.org/r/20230515162604.649203-1-quic_bjorande@quicinc.com Signed-off-by: Johan Hovold <johan@kernel.org>
* | | leds: trigger: netdev: expose netdev trigger modes in linux includeChristian Marangi2023-05-311-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | Expose netdev trigger modes to make them accessible by LED driver that will support netdev trigger for hw control. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | leds: trigger: netdev: init mode if hw control already activeChristian Marangi2023-05-311-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On netdev trigger activation, hw control may be already active by default. If this is the case and a device is actually provided by hw_control_get_device(), init the already active mode and set the bool to hw_control bool to true to reflect the already set mode in the trigger_data. Co-developed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | leds: trigger: netdev: validate configured netdevAndrew Lunn2023-05-311-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The netdev which the LED should blink for is configurable in /sys/class/led/foo/device_name. Ensure when offloading that the configured netdev is the same as the netdev the LED is associated with. If it is not, only perform software blinking. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* | | leds: trigger: netdev: add support for LED hw controlChristian Marangi2023-05-311-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for LED hw control for the netdev trigger. The trigger on calling set_baseline_state to configure a new mode, will do various check to verify if hw control can be used for the requested mode in can_hw_control() function. It will first check if the LED driver supports hw control for the netdev trigger, then will use hw_control_is_supported() and finally will call hw_control_set() to apply the requested mode. To use such mode, interval MUST be set to the default value and net_dev MUST be set. If one of these 2 value are not valid, hw control will never be used and normal software fallback is used. The default interval value is moved to a define to make sure they are always synced. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 11:16:06 +0000