kernel/drivers/leds/led-core.c, branch linux-6.9.y

Merge tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds

2023-11-03T00:53:19Z

Pull LED updates from Lee Jones: "Core Frameworks: - Add support for a bunch more colours New Drivers: - Add support for Kinetic KTD2026/7 RGB/White LEDs New Functionality: - Add support for device to enter HW Controlled Mode to Turris Omnia LEDs - Add support for HW Gamma Correction to Turris Omnia LEDs Fix-ups: - Apply new __counted_by() annotation to several data structures containing flexible arrays - Rid the return value from Platform's .remove() operation - Use *_cansleep() variants for instances were threads can sleep - Improve the semantics when setting the brightness - Generic clean-ups; code reduction, coding style, standard patterns - Replace strncpy() with strscpy() - Fix-up / add various documentation - Re-author the GPIO associated Trigger to use trigger-sources - Move to using standard APIs and helpers - Improve error checking - Stop using static GPIO bases Bug Fixes: - Fix Pointer to Enum casing warnings - Do not pretend that I2C backed device supports SMBUS - Ensure PWM LEDs are extinguished when disabled, rather than held in a state - Fix 'output may be truncated' warnings" * tag 'leds-next-6.7' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (43 commits) leds: lp5521: Add an error check in lp5521_post_init_device leds: gpio: Update headers leds: gpio: Remove unneeded assignment leds: gpio: Move temporary variable for struct device to gpio_led_probe() leds: gpio: Refactor code to use devm_gpiod_get_index_optional() leds: gpio: Utilise PTR_ERR_OR_ZERO() leds: gpio: Keep driver firmware interface agnostic leds: core: Refactor led_update_brightness() to use standard pattern leds: turris-omnia: Fix brightness setting and trigger activating leds: sc27xx: Move mutex_init() down leds: trigger: netdev: Move size check in set_device_name leds: Add ktd202x driver dt-bindings: leds: Add Kinetic KTD2026/2027 LED leds: core: Add more colors from DT bindings to led_colors dt-bindings: leds: Last color ID is now 14 (LED_COLOR_ID_LIME) leds: tca6507: Don't use fixed GPIO base leds: lp3952: Convert to use maple tree register cache leds: lm392x: Convert to use maple tree register cache leds: aw200xx: Convert to use maple tree register cache leds: lm3601x: Convert to use maple tree register cache ...

leds: core: Refactor led_update_brightness() to use standard pattern

2023-11-01T11:29:18Z

The standard conditional pattern is to check for errors first and bail out if any. Refactor led_update_brightness() accordingly. While at it, drop unneeded assignment and return 0 unconditionally on success. Signed-off-by: Andy Shevchenko Acked-by: Denis Osterland-Heim Reviewed-by: Hans de Goede Link: https://lore.kernel.org/r/20231016153051.1409074-1-andriy.shevchenko@linux.intel.com Signed-off-by: Lee Jones

leds: core: Add more colors from DT bindings to led_colors

2023-11-01T11:29:06Z

The colors are already part of DT bindings. Make sure the kernel is able to convert them to strings. Signed-off-by: Ondrej Jirman Link: https://lore.kernel.org/r/20231008144014.1180334-1-megi@xff.cz Signed-off-by: Lee Jones

leds: Drop BUG_ON check for LED_COLOR_ID_MULTI

2023-09-19T14:16:23Z

Commit c3f853184bed ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false") fixed a no-op BUG_ON. This turned out to cause a regression, since some in-tree device-tree files already use LED_COLOR_ID_MULTI. Drop the BUG_ON altogether. Fixes: c3f853184bed ("leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false") Reported-by: Da Xue Closes: https://lore.kernel.org/linux-leds/ZQLelWcNjjp2xndY@duo.ucw.cz/T/ Signed-off-by: Marek Behún Link: https://lore.kernel.org/r/20230918140724.18634-1-kabel@kernel.org Signed-off-by: Lee Jones

leds: Fix BUG_ON check for LED_COLOR_ID_MULTI that is always false

2023-08-17T10:26:36Z

At the time we call BUG_ON(props.color == LED_COLOR_ID_MULTI); the props variable is still initialized to zero. Call the BUG_ON only after we parse fwnode into props. Fixes: 77dce3a22e89 ("leds: disallow /sys/class/leds/*:multi:* for now") Signed-off-by: Marek Behún Link: https://lore.kernel.org/r/20230801151623.30387-1-kabel@kernel.org Signed-off-by: Lee Jones

leds: Fix oops about sleeping in led_trigger_blink()

2023-05-25T11:16:31Z

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 [ 832.606453] Call Trace: [ 832.606466] [ 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] [ 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 Reviewed-by: Jacek Anaszewski Tested-by: Yauhen Kharuzhy Link: https://lore.kernel.org/r/20230510162234.291439-4-hdegoede@redhat.com Signed-off-by: Lee Jones

leds: Fix set_brightness_delayed() race

2023-05-25T11:16:30Z

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 Reviewed-by: Jacek Anaszewski Tested-by: Yauhen Kharuzhy Link: https://lore.kernel.org/r/20230510162234.291439-3-hdegoede@redhat.com Signed-off-by: Lee Jones

leds: move default_state read from fwnode to core

2021-08-18T06:27:30Z

This patch introduces a new function to read initial default_state from fwnode. Suggested-by: Pavel Machek Signed-off-by: Denis Osterland-Heim Signed-off-by: Pavel Machek

leds: led-core: Get rid of enum led_brightness

2021-02-19T10:35:28Z

This gets rid of enum led_brightness in the main led files, because it is deprecated, and an unsigned int can be used instead. We can get rid of led_brightness completely and patches can also be supplied for the other drivers' files. Signed-off-by: Abanoub Sameh Signed-off-by: Pavel Machek

leds: disallow /sys/class/leds/:multi: for now

2020-08-03T12:00:06Z

All the LEDs in the queue are RGB, so they should not use multi for their color. Make sure we don't add such LED by mistake (and make it part of ABI). Signed-off-by: Pavel Machek