- 07 Mar, 2024 40 commits
-
-
Abdel Alkuor authored
NCP5623 is DC-DC multi-LEDs driver which has three PWMs that can be programmed up to 32 steps giving 32768 colors hue. NCP5623 driver supports gradual dimming upward/downward with programmable delays. Also, the driver supports driving a single LED or multi-LED like RGB. Signed-off-by:
Abdel Alkuor <alkuor@gmail.com> Link: https://lore.kernel.org/r/20240305042049.1533279-2-alkuor@gmail.comSigned-off-by:
Lee Jones <lee@kernel.org>
-
Abdel Alkuor authored
NCP5623 is DC-DC multi-LED controller which can be used for RGB illumination or backlight LCD display. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20240305042049.1533279-1-alkuor@gmail.comSigned-off-by:
-
Randy Dunlap authored
Drop one struct member description to fix a kernel-doc warning: drivers/leds/leds-mlxreg.c:42: warning: Excess struct member 'led_data' description in 'mlxreg_led_data' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20240229071931.7870-4-rdunlap@infradead.orgSigned-off-by:
-
Randy Dunlap authored
Change "cled" to "cdev" to quieten kernel-doc warnings: leds-mlxcpld.c:86: warning: Function parameter or struct member 'cdev' not described in 'mlxcpld_led_priv' leds-mlxcpld.c:86: warning: Excess struct member 'cled' description in 'mlxcpld_led_priv' Signed-off-by:
-
Randy Dunlap authored
Add a short struct description and remove one extraneous struct field description to quieten these warnings: leds-lm3601x.c:73: warning: missing initial short description on line: * struct lm3601x_led - leds-lm3601x.c:100: warning: Excess struct member 'led_name' description in 'lm3601x_led' Signed-off-by:
-
Arnd Bergmann authored
gpio_led_register_device() is built whenever CONFIG_LEDS_GPIO_REGISTER is enabled, and this may be used even when CONFIG_NEW_LEDS is turned off. However, the stub declaration in the header is provided for all configs without CONFIG_NEW_LEDS, resulting in a build failure: drivers/leds/leds-gpio-register.c:24:1: error: redefinition of 'gpio_led_register_device' 24 | gpio_led_register_device(int id, const struct gpio_led_platform_data *pdata) | ^ include/linux/leds.h:646:39: note: previous definition is here Change the #ifdef check to match the definition. Note: this apparently took years of randconfig builds to hit, since a number of other drivers just 'select NEW_LEDS' anyway. Signed-off-by:Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240228093834.2230004-1-arnd@kernel.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Only few variants support PPG and store LPG per-channel data and pattern in SDAM modules. Disallow the nvmem for other variants to make the binding precise. Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20240226073713.19045-2-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
"qcom,pm8550-pwm" is compatible with "qcom,pm8350c-pwm" (latter used as fallback), thus it is enough for the "if:then:" clause to check for the presence of the fallback "qcom,pm8350c-pwm". Signed-off-by:
-
Rafał Miłecki authored
It's common for routers to have LED indicating link on the WAN port. Some devices however have an extra LED that's meant to be used if WAN connection is actually "online" (there is Internet access available). It was suggested to add #define for such use case. Link: https://lore.kernel.org/linux-devicetree/80e92209-5578-44e7-bd4b-603a29053ddf@collabora.com/T/#uSigned-off-by:
Rafał Miłecki <rafal@milecki.pl> Reviewed-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20240223112223.1368-1-zajec5@gmail.comSigned-off-by:
-
Ondrej Jirman authored
Enabling strobe and then setting brightness to 0 causes the driver to enter invalid state after strobe end timer fires. We should cancel strobe mode resources when changing brightness (aka torch mode). Fixes: cef8ec8c ("leds: add sgm3140 driver") Signed-off-by:
Ondrej Jirman <megi@xff.cz> Link: https://lore.kernel.org/r/20240217191133.1757553-1-megi@xff.czSigned-off-by:
-
Duje Mihanović authored
The ExpressWire library does not depend on NEW_LEDS and selecting it from a subsystem other than LEDs may cause Kconfig warnings: WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y] Selected by [y]: - BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y] Move it out of the "if NEW_LEDS" block to allow selection from other subsystems (in particular backlight) without raising this warning. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202402161410.IG9I4odj-lkp@intel.com/Suggested-by:
Daniel Thompson <daniel.thompson@linaro.org> Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library") Reviewed-by:
Duje Mihanović <duje.mihanovic@skole.hr> Link: https://lore.kernel.org/r/20240216-expresswire-deps-v2-2-8be59c4a75f5@skole.hrSigned-off-by:
-
Duje Mihanović authored
This reverts commit b1ae40a5. The ExpressWire library introduced in commit 25ae5f5f4168 ("leds: Introduce ExpressWire library") does not depend on NEW_LEDS, but without this revert it would never get compiled if NEW_LEDS is not enabled. Revert this commit to allow the library to be compiled. Link: https://lore.kernel.org/2cacd8dc-6150-4aa2-af9e-830a202fb0a8@app.fastmail.comSuggested-by:
-
George Stark authored
In the probe() callback in case of error mutex is destroyed being locked which is not allowed so unlock the mutex before destroying. Fixes: 59ea3c9f ("leds: add aw2013 driver") Signed-off-by:
George Stark <gnstark@salutedevices.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20231214173614.2820929-2-gnstark@salutedevices.comSigned-off-by:
-
Arnd Bergmann authored
The lpg driver fails to link now when the pbs driver is in a loadable module: x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_brightness_set': leds-qcom-lpg.c:(.text+0xe7f): undefined reference to `qcom_pbs_trigger_event' x86_64-linux-ld: drivers/leds/rgb/leds-qcom-lpg.o: in function `lpg_probe': leds-qcom-lpg.c:(.text+0x16a5): undefined reference to `get_pbs_client_device' Add a dependency to avoid the broken configuration. Apparently there is still a use for lpg with pbs disabled entirely for certain chips, so allow both but not LEDS_QCOM_LPG=y with QCOM_PBS=m. Fixes: 214110175679 ("leds: rgb: leds-qcom-lpg: Add support for PPG through single SDAM") Signed-off-by:Jean Delvare <jdelvare@suse.de> Link: https://lore.kernel.org/r/20240212111526.829122-1-arnd@kernel.orgSigned-off-by:
-
Aren Moynihan authored
If none of the managed LEDs enable LED_CORE_SUSPENDRESUME, then we shouldn't need to set it here. This makes it possible to use multicolor groups with GPIO LEDs that enable retain-state-suspended in the device tree. Signed-off-by:
Aren Moynihan <aren@peacevolution.org> Acked-by:
Pavel Machek <pavel@ucw.cz> Link: https://lore.kernel.org/r/20240206185400.596979-1-aren@peacevolution.org [Lee: Changed the comment to respect proper grammar] Signed-off-by:
-
Christian Marangi authored
Commit d5e01266 ("leds: trigger: netdev: add additional specific link speed mode") in the various changes, reworked the way to set the LINKUP mode in commit cee4bd16 ("leds: trigger: netdev: Recheck NETDEV_LED_MODE_LINKUP on dev rename") and moved it to a generic function. This changed the logic where, in the previous implementation the dev from the trigger event was used to check if the carrier was ok, but in the new implementation with the generic function, the dev in trigger_data is used instead. This is problematic and cause a possible kernel panic due to the fact that the dev in the trigger_data still reference the old one as the new one (passed from the trigger event) still has to be hold and saved in the trigger_data struct (done in the NETDEV_REGISTER case). On calling of get_device_state(), an invalid net_dev is used and this cause a kernel panic. To handle this correctly, move the call to get_device_state() after the new net_dev is correctly set in trigger_data (in the NETDEV_REGISTER case) and correctly parse the new dev. Fixes: d5e01266 ("leds: trigger: netdev: add additional specific link speed mode") Cc: stable@vger.kernel.org Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/20240203235413.1146-1-ansuelsmth@gmail.comSigned-off-by:
-
Marijn Suijten authored
Inherit PM660L PMIC LPG/triled block configuration from downstream drivers and DT sources, consisting of a triled block with automatic trickle charge control and source selection, three colored led channels belonging to the synchronized triled block and one loose PWM channel. Signed-off-by:
Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20240204-pm660l-lpg-v5-1-2f54d1a0894b@somainline.orgSigned-off-by:
-
Stefan Kalscheuer authored
Use extended classdev registration to generate generic device names from color and function enums instead of reading only the label from the device tree. Signed-off-by:
Stefan Kalscheuer <stefan@stklcode.de> Link: https://lore.kernel.org/r/20240204150726.29783-1-stefan@stklcode.deSigned-off-by:
-
Amitesh Singh authored
This implements power management for pca9633 which enables device sleep and resume on system-wide sleep/hibernation Signed-off-by:
Amitesh Singh <singh.amitesh@gmail.com> Link: https://lore.kernel.org/r/20240203162524.343936-1-singh.amitesh@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Avoid code duplication and factor out common functionality to new helper led_match_default_trigger(). Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/d78eef6f-c18c-4546-b83e-6d1890849154@gmail.comSigned-off-by:
-
Heiner Kallweit authored
Commit 682e98564ffb ("leds: trigger: panic: Simplify led_trigger_set_panic") removed the last external user of variable trigger_list. So stop exporting it. If in future a need should arise again to access this variable, I think we better add some accessor instead of exporting the variable directly. Signed-off-by: -
Arnd Bergmann authored
Along the same lines as making devm_led_classdev_register() declared extern unconditional, do the same thing for the two sub-classes that have similar stubs. The users of these interfaces go to great lengths to allow building with both the generic leds API and the extended version, but realistically there is not much use in this, so just simplify it to always rely on it and remove the confusing fallback logic. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/r/20240109090715.982332-2-arnd@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
These two functions have stub implementations that are called when NEW_LEDS and/or LEDS_CLASS are disabled, theorerically allowing drivers to optionally use the LED subsystem. However, this has never really worked because a built-in driver is unable to link against these functions if the LED class is in a loadable module. Heiner ran into this problem with a driver that newly gained a LEDS_CLASS dependency and suggested using an IS_REACHABLE() check. This is the reverse approach, removing the stub entirely to acknowledge that it is pointless in its current form, and that not having it avoids misleading developers into thinking that they can rely on it. This survived around 1000 randconfig builds to validate that any callers of the interface already have the correct Kconfig dependency already, with the exception of the one that Heiner just added. Cc: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/linux-leds/0f6f432b-c650-4bb8-a1b5-fe3372804d52@gmail.com/T/#uSigned-off-by:
-
Colin Ian King authored
Don't populate the read-only array coeff_table on the stack at run time, instead make it static const. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Link: https://lore.kernel.org/r/20240119232630.2752239-1-colin.i.king@gmail.comSigned-off-by:
-
Heiner Kallweit authored
I don't see why we iterate over all triggers to find the panic trigger. We *are* the panic trigger. Therefore we also know that the panic trigger doesn't have an activate() hook. So we can simplify the code significantly. Signed-off-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/r/84c0fa67-2f03-4474-aa75-914d65d88dd0@gmail.comSigned-off-by:
-
Rafał Miłecki authored
Most wireless routers and access points can operate in multiple bands simultaneously. Vendors often equip their devices with per-band LEDs. Add defines for those very common functions to allow cleaner & clearer bindings. Signed-off-by:
-
Heiner Kallweit authored
A bigger number of board device tree files, plus few drivers, set default-on as default trigger for LED's. Therefore add an alias for module auto-loading. Signed-off-by:
-
Heiner Kallweit authored
This a follow-up to 5edf7f11313d ("leds: trigger: Load trigger modules on-demand if used as default trigger") and sets an alias for the audio triggers. Signed-off-by: -
Florian Eckert authored
The 'led-trigger-tty' uses the same naming in the ABI documentation as the 'led-trigger-netdev'. Which leads to the following warning when building the documentation. Warning: /sys/class/leds/<led>/rx is defined 2 times: Documentation/ABI/testing/sysfs-class-led-trigger-tty:7 Documentation/ABI/testing/sysfs-class-led-trigger-netdev:49 Warning: /sys/class/leds/<led>/tx is defined 2 times: Documentation/ABI/testing/sysfs-class-led-trigger-tty:15 Documentation/ABI/testing/sysfs-class-led-trigger-netdev:34 Renaming the 'What' path by prefixing it with 'tty_' solves this problem. Fixes: 6dec6598 ("leds: ledtrig-tty: Add additional line state evaluation") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Florian Eckert <fe@dev.tdt.de> Link: https://lore.kernel.org/r/20240110133410.81645-1-fe@dev.tdt.deSigned-off-by:
-
Christian Marangi authored
Document now hidable link speed modes for the LED netdev trigger. Link speed modes are now showed only if the named network device supports them and are hidden if not. Signed-off-by:
Marek Behún <kabel@kernel.org> Link: https://lore.kernel.org/r/20240111160501.1774-2-ansuelsmth@gmail.comSigned-off-by:
-
Christian Marangi authored
With the addition of more link speed mode to the netdev trigger, it was pointed out that there may be a problem with bloating the attribute list with modes that won't ever be supported by the trigger as the attached device name doesn't support them. To clear and address this problem, change the logic where these additional trigger modes are listed. Since the netdev trigger REQUIRE a device name to be set, attach to the device name change function additional logic to parse the supported link speed modes using ethtool APIs and show only the supported link speed modes attribute. Link speed attribute are refreshed on device_name set and on NETDEV_CHANGE events. This only apply to the link speed modes and every other mode is still provided by default. Signed-off-by:
-
Heiner Kallweit authored
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 authored
Add module alias ledtrig:netdev to enable auto-loading of the module. Signed-off-by:
-
Heiner Kallweit authored
Even if a trigger is set as default trigger for a LED device, the respective trigger module (if built as module) isn't automatically loaded by the kernel if the LED device is registered. I think we can do better. Try to load the module asynchronously by alias ledtrig:<trigger name>. This requires that such an alias is added to relevant triggers. Signed-off-by:
-
Anjelique Melendez authored
Update the pm8350c lpg_data struct so that pm8350c devices are treated as PWM devices that support two-nvmem PPG scheme. Signed-off-by:
Anjelique Melendez <quic_amelende@quicinc.com> Link: https://lore.kernel.org/r/20231221185838.28440-8-quic_amelende@quicinc.comSigned-off-by:
-
Anjelique Melendez authored
On PMICs such as PM8350C, the pattern lookup table (LUT) is stored in a separate SDAM from the one where the lpg per-channel data is stored. Add support for PPG with a dedicated LUT SDAM while maintaining backward compatibility for those targets that use only a single SDAM. Co-developed-by:
Guru Das Srinagesh <quic_gurus@quicinc.com> Signed-off-by:
-
Anjelique Melendez authored
Update the pmi632 lpg_data struct so that pmi632 devices use PPG for LUT pattern. Signed-off-by:
Luca Weiss <luca.weiss@fairphone.com> Link: https://lore.kernel.org/r/20231221185838.28440-6-quic_amelende@quicinc.comSigned-off-by:
-
Anjelique Melendez authored
In some PMICs like pmi632, the pattern look up table (LUT) and LPG configuration is stored in a single SDAM module instead of LUT peripheral. This feature is called PPG. PPG uses Qualcomm Programmable Boot Sequencer (PBS) inorder to trigger pattern sequences for PMICs. Signed-off-by:
-
Anjelique Melendez authored
Update leds-qcom-lpg binding to support LPG PPG. Signed-off-by:
-
Heiner Kallweit authored
The current codes uses the sw_control path in set_baseline_state() when called from netdev_trig_activate() even if we're hw-controlled. This may result in errors when led_set_brightness() is called because we may not have set_brightness led ops (if hw doesn't support setting a "LED" to ON). In addition this path may schedule trigger_data->work which doesn't make sense when being hw-controlled. Therefore set trigger_data->hw_control = true before calling set_device_name() from netdev_trig_activate(). In this call chain we have to prevent set_baseline_state() from being called, because this would call hw_control_set(). Use led_cdev->trigger_data == NULL as indicator for being called from netdev_trig_activate(). Signed-off-by:
-
