aboutsummaryrefslogtreecommitdiff
path: root/drivers/leds
AgeCommit message (Collapse)AuthorFilesLines
2024-06-21leds: bcm63138: Add MODULE_DESCRIPTION()Jeff Johnson1-0/+1
Fix the 'make W=1" issue: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/blink/leds-bcm63138.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com> Link: https://lore.kernel.org/r/20240517-md-leds-bcm63138-v1-1-247b7302edb6@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: simatic-ipc-leds: Add missing MODULE_DESCRIPTION() macrosJeff Johnson5-0/+5
Fix the 'make W=1' issues: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-apollolake.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-core.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-elkhartlake.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds-gpio-f7188x.o WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/simple/simatic-ipc-leds.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240517-md-simatic-ipc-v1-1-bbbd199262b8@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: rt4505: Add MODULE_DESCRIPTION()Jeff Johnson1-0/+1
Fix the 'make W=1" issue: WARNING: modpost: missing MODULE_DESCRIPTION() in drivers/leds/flash/leds-rt4505.o Signed-off-by: Jeff Johnson <quic_jjohnson@quicinc.com> Link: https://lore.kernel.org/r/20240517-md-leds-rt4505-v1-1-2f388ff6b672@quicinc.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: Drop explicit initialization of struct i2c_device_id::driver_data to 0Uwe Kleine-König15-17/+17
These drivers don't use the driver_data member of struct i2c_device_id, so don't explicitly initialize this member. This prepares putting driver_data in an anonymous union which requires either no initialization or named designators. But it's also a nice cleanup on its own. While add it, also remove commas after the sentinel entries. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240522165358.62238-2-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: trigger: Call synchronize_rcu() before calling trig->activate()Hans de Goede1-0/+7
Some triggers call led_trigger_event() from their activate() callback to initialize the brightness of the LED for which the trigger is being activated. In order for the LED's initial state to be set correctly this requires that the led_trigger_event() call uses the new version of trigger->led_cdevs, which has the new LED. AFAICT led_trigger_event() will always use the new version when it is running on the same CPU as where the list_add_tail_rcu() call was made, which is why the missing synchronize_rcu() has not lead to bug reports. But if activate() is pre-empted, sleeps or uses a worker then the led_trigger_event() call may run on another CPU which may still use the old trigger->led_cdevs list. Add a synchronize_rcu() call to ensure that any led_trigger_event() calls done from activate() always use the new list. Triggers using led_trigger_event() from their activate() callback are: net/bluetooth/leds.c, net/rfkill/core.c and drivers/tty/vt/keyboard.c. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531120124.75662-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: trigger: Unregister sysfs attributes before calling deactivate()Hans de Goede1-1/+1
Triggers which have trigger specific sysfs attributes typically store related data in trigger-data allocated by the activate() callback and freed by the deactivate() callback. Calling device_remove_groups() after calling deactivate() leaves a window where the sysfs attributes show/store functions could be called after deactivation and then operate on the just freed trigger-data. Move the device_remove_groups() call to before deactivate() to close this race window. This also makes the deactivation path properly do things in reverse order of the activation path which calls the activate() callback before calling device_add_groups(). Fixes: a7e7a3156300 ("leds: triggers: add device attribute support") Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240504162533.76780-1-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: is31fl319x: Constify struct regmap_configChristophe JAILLET1-2/+2
'is31fl3190_regmap_config' and 'is31fl3196_regmap_config' are not modified in this diver and are only used as a const struct regmap_config. Constifying these structures moves some data to a read-only section, so increase overall security. On a x86_64, with allmodconfig: Before: text data bss dec hex filename 13827 2002 32 15861 3df5 drivers/leds/leds-is31fl319x.o After: text data bss dec hex filename 14467 1370 32 15869 3dfd drivers/leds/leds-is31fl319x.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/82a5cb26ff8af1865a790286bdbc3c4a2bd149f1.1714892598.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21Merge branches 'ib-leds-mfd-6.11', 'ib-leds-platform-power-6.11' and ↵Lee Jones6-39/+103
'ib-mfd-leds-platform-6.11' into ibs-for-leds-merged
2024-06-21leds: Add ChromeOS EC driverThomas Weißschuh3-0/+293
The ChromeOS Embedded Controller exposes an LED control command. Expose its functionality through the leds subsystem. The LEDs are exposed as multicolor devices. A hardware trigger, which is active by default, is provided to let the EC itself take over control over the LED. The driver is designed to be probed via the cros_ec mfd device. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-4-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: core: Unexport led_colors[] arrayThomas Weißschuh2-3/+1
There are no external users left, make the array static. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-3-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: multicolor: Use led_get_color_name() functionThomas Weißschuh1-1/+1
led_get_color_name() is a safer alternative to led_colors. led-class-multicolor.c is the only external user of led_colors and its removal allows unexporting the array. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-2-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-21leds: core: Introduce led_get_color_name() functionThomas Weißschuh1-0/+9
This is similar to the existing led_colors[] array but is safer to use and usable by everyone. Getting string representations of color ids is useful for drivers which are handling color IDs anyways, for example for the multicolor API. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20240613-cros_ec-led-v3-1-500b50f41e0f@weissschuh.net Signed-off-by: Lee Jones <lee@kernel.org>
2024-06-16leds: class: Revert: "If no default trigger is given, make hw_control ↵Hans de Goede1-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>
2024-06-14leds: class: Add flag to avoid automatic renaming of LED devicesThomas Weißschuh1-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>
2024-06-14leds: class: Warn about name collisions earlierThomas Weißschuh1-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>
2024-05-31leds: trigger: Add led_mc_trigger_event() functionHans de Goede1-0/+20
Add a new led_mc_trigger_event() function for triggers which want to change the color of a multi-color LED based on their trigger conditions. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-6-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: core: Add led_mc_set_brightness() functionHans de Goede2-0/+32
Add a new led_mc_set_brightness() function for in kernel color/brightness changing of multi-color LEDs. led-class-multicolor can be build as a module and led_mc_set_brightness() will have the builtin callers, so put led_mc_set_brightness() inside led-core instead, just like how led_set_brightness() is part of the core and not of the led-class object. This also adds a new LED_MULTI_COLOR led_classdev flag to allow led_mc_set_brightness() to verify that it is operating on a multi-color LED classdev, avoiding casting the passed in LED classdev to a multi-color LED classdev, when it actually is not a multi-color LED. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-5-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: Initialize mutex earlierHans de Goede1-4/+4
The mutex must be initialized before the LED class device is registered otherwise there is a race where it may get used before it is initialized: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 2 PID: 2045 at kernel/locking/mutex.c:587 __mutex_lock ... RIP: 0010:__mutex_lock+0x7db/0xc10 ... set_brightness_delayed_set_brightness.part.0+0x17/0x60 set_brightness_delayed+0xf1/0x100 process_one_work+0x222/0x5a0 Move the mutex_init() call earlier to avoid this race condition and switch to devm_mutex_init() to avoid the need to add error-exit cleanup to probe() if probe() fails later on. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Link: https://lore.kernel.org/r/20240531114124.45346-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: I2C ID tables for KTD2026 and 2027Kate Hsuan1-0/+8
Add an i2c_device_id id_table to match manually instantiated (non device-tree / ACPI instantiated) KTD202x controllers as found on some x86 boards. This table shows the maximum support LED channel for KTD2026 (three LEDs) and KTD-2027 (4 LEDs). Link: https://www.kinet-ic.com/uploads/KTD2026-7-04h.pdf Signed-off-by: Kate Hsuan <hpa@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-3-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-31leds: rgb: leds-ktd202x: Get device properties through fwnode to support ACPIKate Hsuan2-31/+34
This LED controller is installed on a Xiaomi pad2 and it is an x86 platform. The original driver is based on the device tree and can't be used for this ACPI based system. This patch migrated the driver to use fwnode to access the properties. Moreover, the fwnode API supports the device tree so this work won't affect the original implementations. Signed-off-by: Kate Hsuan <hpa@redhat.com> Tested-by: André Apitzsch <git@apitzsch.eu> # on BQ Aquaris M5 Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Andy Shevchenko <andy@kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20240531114124.45346-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: mt6370: Remove unused field 'reg_cfgs' from 'struct mt6370_priv'Christophe JAILLET1-1/+0
In 'struct mt6370_priv', the 'reg_cfgs' field is unused. Moreover 'struct reg_cfg' isn't defined anywhere, so remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/e389be5e1012dc05fc2641123883ca3b0747525a.1714328839.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: lp50xx: Remove unused field 'num_of_banked_leds' from 'struct lp50xx'Christophe JAILLET1-4/+0
In 'struct lp50xx', the 'num_of_banked_leds' field is only written and is never used. Moreover, storing such an information in the 'priv' structure looks pointless, so remove it. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/a0d472ff587d13a2b91ec32c8776061019caab6a.1714324500.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: lp50xx: Remove unused field 'bank_modules' from 'struct lp50xx_led'Christophe JAILLET1-1/+0
In 'struct lp50xx_led', the 'bank_modules' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/bc2e5e57b93ca0a33bcc84e9bdc89f26fc8f6d57.1714324500.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: aat1290: Remove unused field 'torch_brightness' from 'struct aat1290_led'Christophe JAILLET1-2/+0
In 'struct aat1290_led', the 'torch_brightness' field is unused. Remove it. Found with cppcheck, unusedStructMember. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/f7c8c22242544b11e95d9a77d7d0ea17f5a24fd5.1714318454.git.christophe.jaillet@wanadoo.fr Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: sun50i-a100: Use match_string() helper to simplify the codeAndy Shevchenko1-8/+6
match_string() returns the array index of a matching string. Use it instead of the open-coded implementation. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20240426152515.872917-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: pwm: Disable PWM when going to suspendUwe Kleine-König1-1/+7
On stm32mp1xx based machines (and others) a PWM consumer has to disable the PWM because an enabled PWM refuses to suspend. So check the LED_SUSPENDED flag and depending on that set the .enabled property. Link: https://bugzilla.kernel.org/show_bug.cgi?id=218559 Fixes: 76fe464c8e64 ("leds: pwm: Don't disable the PWM when the LED should be off") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20240417153846.271751-2-u.kleine-koenig@pengutronix.de Signed-off-by: Lee Jones <lee@kernel.org>
2024-05-02leds: trigger: pattern: Add support for hrtimerMartin Kurbanov1-23/+103
Currently, led pattern trigger uses timer_list to schedule brightness changing. As we know from timer_list API [1], it's not accurate to milliseconds and depends on HZ granularity. Example: "0 10 0 0 50 10 50 0 100 10 100 0 150 10 150 0 200 10 200 0 250 10 250 0", we expect it to be 60ms long, but it can actually be up to ~120ms (add ~10ms for each pattern when HZ == 100). But sometimes, userspace needs time accurate led patterns to make sure that pattern will be executed during expected time slot. To achieve this goal the patch introduces optional hrtimer usage for led trigger pattern, because hrtimer is microseconds accurate timer. [1]: kernel/time/timer.c#L104 Signed-off-by: Martin Kurbanov <mmkurbanov@salutedevices.com> Link: https://lore.kernel.org/r/20240416201847.357099-1-mmkurbanov@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: mt6360: Fix the second LED can not enable torch mode by V4L2ChiaEn Wu1-1/+11
V4L2 will disable strobe mode of the LED device when enable torch mode, but this logic will conflict with the "priv->fled_torch_used" in "mt6360_strobe_set()". So after enabling torch mode of the first LED, the second LED will not be able to enable torch mode correctly. Therefore, at the beginning of "mt6360_strobe_set()", check whether the state of the upcoming change and the current LED device state are the same, so as to avoid the above problem. Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> Link: https://lore.kernel.org/r/28FE6F1712799128000.chiaen_wu@richtek.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: qcom-lpg: Add support for PMI8950 PWMGianluca Boiano1-0/+8
The PMI8950 PMIC contains 1 PWM channel Signed-off-by: Gianluca Boiano <morf3089@gmail.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20240402-pmi8950-pwm-support-v1-1-1a66899eeeb3@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: apu: Remove duplicate DMI lookup dataArnd Bergmann1-2/+1
Building with W=1 shows a warning about an unused dmi_system_id table: drivers/leds/leds-apu.c:85:35: error: 'apu_led_dmi_table' defined but not used [-Werror=unused-const-variable=] 85 | static const struct dmi_system_id apu_led_dmi_table[] __initconst = { Since the current version doesn't even do anything about the different implementations but only checks the type of system, just drop the custom lookup logic and call dmi_check_system() using the table itself. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20240403080702.3509288-16-arnd@kernel.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: trigger: netdev: Remove not needed call to led_set_brightness in ↵Heiner Kallweit1-2/+0
deactivate led_trigger_set() is the only caller of the deactivate() callback, and it calls led_set_brightness(LED_OFF) anyway after deactivate(). So we can remove the call here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/8dc929e7-8e14-4c85-aa28-9c5fe2620f52@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12leds: simatic-ipc-leds-gpio: Add support for module BX-59AXing Tong Wu2-6/+47
This is used for the Siemens Simatic IPC BX-59A, which has its LEDs connected to GPIOs provided by the Nuvoton NCT6126D. Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Xing Tong Wu <xingtong.wu@siemens.com> Link: https://lore.kernel.org/r/20240314070506.2384-1-xingtong_wu@163.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-12Merge branches 'ib-leds-mips-sound-6.10' and 'ib-leds-locking-6.10' into ↵Lee Jones7-74/+84
ibs-for-leds-merged
2024-04-11leds: an30259a: Use devm_mutex_init() for mutex initializationGeorge Stark1-10/+4
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-9-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: mlxreg: Use devm_mutex_init() for mutex initializationGeorge Stark1-9/+5
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses mutex which was destroyed already in module's remove() so use devm API instead. Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-8-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: nic78bx: Use devm API to cleanup module's resourcesGeorge Stark1-10/+13
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's remove() so use devm API instead of remove(). Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-7-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: lm3532: Use devm API to cleanup module's resourcesGeorge Stark1-12/+17
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's remove() so use devm API instead of remove(). Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-6-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: lp3952: Use devm API to cleanup module's resourcesGeorge Stark1-10/+11
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's remove() so use devm API instead of remove(). Also drop explicit turning LEDs off from remove() due to they will be off anyway by led_classdev_unregister(). Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-5-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: aw200xx: Use devm API to cleanup module's resourcesGeorge Stark1-11/+21
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's remove() so use devm API instead of remove(). Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20240411161032.609544-4-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-04-11leds: aw2013: Use devm API to cleanup module's resourcesGeorge Stark1-12/+13
In this driver LEDs are registered using devm_led_classdev_register() so they are automatically unregistered after module's remove() is done. led_classdev_unregister() calls module's led_set_brightness() to turn off the LEDs and that callback uses resources which were destroyed already in module's remove() so use devm API instead of remove(). Signed-off-by: George Stark <gnstark@salutedevices.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Nikita Travkin <nikita@trvn.ru> Link: https://lore.kernel.org/r/20240411161032.609544-3-gnstark@salutedevices.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-28leds: trigger: audio: Remove this triggerHeiner Kallweit1-67/+0
Now that the audio trigger is fully integrated in sound/core/control_led.c, we can remove it here. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/1e339779-6d04-4392-8ea2-5592c0fd1aa2@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-28ALSA: control-led: Integrate mute led triggerHeiner Kallweit2-8/+0
This driver is the only one calling ledtrig_audio_set(), therefore the LED audio trigger isn't usable standalone. So it makes sense to fully integrate LED audio triger handling here. The module aliases ensure that the driver is auto-loaded (if built as module) if a LED device has one of the two audio triggers as default trigger. In addition disable building the old audio mute LED trigger. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/107634e6-d9ad-4a9f-881d-1eb72ea1a5a7@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-28leds: trigger: Store brightness set by led_trigger_event()Heiner Kallweit1-2/+4
If a simple trigger is assigned to a LED, then the LED may be off until the next led_trigger_event() call. This may be an issue for simple triggers with rare led_trigger_event() calls, e.g. power supply charging indicators (drivers/power/supply/power_supply_leds.c). Therefore persist the brightness value of the last led_trigger_event() call and use this value if the trigger is assigned to a LED. In addition add a getter for the trigger brightness value. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Link: https://lore.kernel.org/r/b1358b25-3f30-458d-8240-5705ae007a8a@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-14Merge tag 'mm-nonmm-stable-2024-03-14-09-36' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Pull non-MM updates from Andrew Morton: - Kuan-Wei Chiu has developed the well-named series "lib min_heap: Min heap optimizations". - Kuan-Wei Chiu has also sped up the library sorting code in the series "lib/sort: Optimize the number of swaps and comparisons". - Alexey Gladkov has added the ability for code running within an IPC namespace to alter its IPC and MQ limits. The series is "Allow to change ipc/mq sysctls inside ipc namespace". - Geert Uytterhoeven has contributed some dhrystone maintenance work in the series "lib: dhry: miscellaneous cleanups". - Ryusuke Konishi continues nilfs2 maintenance work in the series "nilfs2: eliminate kmap and kmap_atomic calls" "nilfs2: fix kernel bug at submit_bh_wbc()" - Nathan Chancellor has updated our build tools requirements in the series "Bump the minimum supported version of LLVM to 13.0.1". - Muhammad Usama Anjum continues with the selftests maintenance work in the series "selftests/mm: Improve run_vmtests.sh". - Oleg Nesterov has done some maintenance work against the signal code in the series "get_signal: minor cleanups and fix". Plus the usual shower of singleton patches in various parts of the tree. Please see the individual changelogs for details. * tag 'mm-nonmm-stable-2024-03-14-09-36' of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm: (77 commits) nilfs2: prevent kernel bug at submit_bh_wbc() nilfs2: fix failure to detect DAT corruption in btree and direct mappings ocfs2: enable ocfs2_listxattr for special files ocfs2: remove SLAB_MEM_SPREAD flag usage assoc_array: fix the return value in assoc_array_insert_mid_shortcut() buildid: use kmap_local_page() watchdog/core: remove sysctl handlers from public header nilfs2: use div64_ul() instead of do_div() mul_u64_u64_div_u64: increase precision by conditionally swapping a and b kexec: copy only happens before uchunk goes to zero get_signal: don't initialize ksig->info if SIGNAL_GROUP_EXIT/group_exec_task get_signal: hide_si_addr_tag_bits: fix the usage of uninitialized ksig get_signal: don't abuse ksig->info.si_signo and ksig->sig const_structs.checkpatch: add device_type Normalise "name (ad@dr)" MODULE_AUTHORs to "name <ad@dr>" dyndbg: replace kstrdup() + strchr() with kstrdup_and_replace() list: leverage list_is_head() for list_entry_is_head() nilfs2: MAINTAINERS: drop unreachable project mirror site smp: make __smp_processor_id() 0-argument macro fat: fix uninitialized field in nostale filehandles ...
2024-03-14Merge tag 'leds-next-6.9' of ↵Linus Torvalds22-85/+811
git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "Core Framework: - Introduce ExpressWire library New Drivers: - Add support for ON Semiconductor NCP5623 RGB LED Driver New Device Support: - Add support for PM660L to Qualcomm's LPG driver New Functionality: - Dynamically load modules required for the default-trigger - Add some support for suspend and resume - Allow LEDs to remain lit during suspend Fix-ups: - Device Tree binding adaptions/conversions/creation - Fix include lists; alphabetise, remove unused, explicitly add used - Add new led_match_default_trigger to avoid duplication - Add module alias' to aid auto-loading - Default to hw_control if no others are specified - De-bloat the supported link speed attribute lists - Remove superfluous code and simplify overall - Constify some variables Bug Fixes: - Prevent kernel panic when renaming the net interface - Fix Kconfig related build errors - Ensure mutexes are unlocked prior to destroying them - Provide clean-up between state changes to avoid invalid state - Fix some broken kernel-doc headers" * tag 'leds-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (41 commits) leds: ncp5623: Add MS suffix to time defines leds: Add NCP5623 multi-led driver dt-bindings: leds: Add NCP5623 multi-LED Controller leds: mlxreg: Drop an excess struct mlxreg_led_data member leds: leds-mlxcpld: Fix struct mlxcpld_led_priv member name leds: lm3601x: Fix struct lm3601_led kernel-doc warnings leds: Fix ifdef check for gpio_led_register_device() dt-bindings: leds: qcom-lpg: Narrow nvmem for other variants dt-bindings: leds: qcom-lpg: Drop redundant qcom,pm8550-pwm in if:then: dt-bindings: leds: Add LED_FUNCTION_WAN_ONLINE for Internet access leds: sgm3140: Add missing timer cleanup and flash gpio control leds: expresswire: Don't depend on NEW_LEDS Revert "leds: Only descend into leds directory when CONFIG_NEW_LEDS is set" leds: aw2013: Unlock mutex before destroying it leds: qcom-lpg: Add QCOM_PBS dependency leds: rgb: leds-group-multicolor: Allow LEDs to stay on in suspend leds: trigger: netdev: Fix kernel panic on interface rename trig notify leds: qcom-lpg: Add PM660L configuration and compatible leds: spi-byte: Use devm_led_classdev_register_ext() leds: pca963x: Add support for suspend and resume ...
2024-03-14Merge tag 'backlight-next-6.9' of ↵Linus Torvalds5-90/+108
git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight Pull backlight updates from Lee Jones: "New Drivers: - Add support for Kinetic KTD2801 Backlight Fix-ups: - Fix include lists; alphabetise, remove unused, explicitly add used - Device Tree binding adaptions/conversions/creation - Use dev_err_probe() to clean-up error paths - Use/convert to new/better APIs/helpers/MACROs instead of hand-rolling implementations Bug Fixes: - Fix changes of NULL pointer dereference - Remedy a bunch of logic errors - Initialise (zero) Backlight properties data structures" * tag 'backlight-next-6.9' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight: (32 commits) backlight: pandora_bl: Drop unneeded ENOMEM error message backlight: lm3630a_bl: Simplify probe return on gpio request error backlight: lm3630a_bl: Handle deferred probe backlight: as3711_bl: Handle deferred probe backlight: bd6107: Handle deferred probe backlight: l4f00242t03: Simplify with dev_err_probe() backlight: gpio: Simplify with dev_err_probe() backlight: lp8788: Fully initialize backlight_properties during probe backlight: lm3639: Fully initialize backlight_properties during probe backlight: da9052: Fully initialize backlight_properties during probe backlight: lm3630a: Use backlight_get_brightness helper in update_status backlight: lm3630a: Don't set bl->props.brightness in get_brightness backlight: lm3630a: Initialize backlight_properties on init backlight: mp3309c: Fully initialize backlight_properties during probe backlight: mp3309c: Utilise temporary variable for struct device backlight: mp3309c: Use dev_err_probe() instead of dev_err() backlight: mp3309c: Make use of device properties dt-bindings: backlight: qcom-wled: Fix bouncing email addresses backlight: hx8357: Utilise temporary variable for struct device backlight: hx8357: Make use of dev_err_probe() ...
2024-03-07leds: ncp5623: Add MS suffix to time definesAbdel Alkuor1-5/+5
To make the time macro defines clearer, add MS as a suffix. Signed-off-by: Abdel Alkuor <alkuor@gmail.com> Link: https://lore.kernel.org/r/20240305133824.1551809-1-alkuor@gmail.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07leds: Add NCP5623 multi-led driverAbdel Alkuor3-0/+283
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.com Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07leds: mlxreg: Drop an excess struct mlxreg_led_data memberRandy Dunlap1-1/+0
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.org Signed-off-by: Lee Jones <lee@kernel.org>
2024-03-07leds: leds-mlxcpld: Fix struct mlxcpld_led_priv member nameRandy Dunlap1-1/+1
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 <rdunlap@infradead.org> Acked-by: Vadim Pasternak <vadimp@nvidia.com> Link: https://lore.kernel.org/r/20240229071931.7870-3-rdunlap@infradead.org Signed-off-by: Lee Jones <lee@kernel.org>
Powered by cgit, Gruvboxed by Blaster4385.