kernel/drivers/video/backlight/led_bl.c, branch linux-rolling-stable

backlight: led-bl: Add devlink to supplier LEDs

2025-12-18T13:03:17Z

[ Upstream commit 9341d6698f4cfdfc374fb6944158d111ebe16a9d ] LED Backlight is a consumer of one or multiple LED class devices, but devlink is currently unable to create correct supplier-producer links when the supplier is a class device. It creates instead a link where the supplier is the parent of the expected device. One consequence is that removal order is not correctly enforced. Issues happen for example with the following sections in a device tree overlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; }; In this example, the devlink should be created between the backlight-addon (consumer) and the pca9632@62 (supplier). Instead it is created between the backlight-addon (consumer) and the parent of the pca9632@62, which is typically the I2C bus adapter. On removal of the above overlay, the LED driver can be removed before the backlight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98 Another way to reproduce the bug without any device tree overlays is unbinding the LED class device (pca9632@62) before unbinding the consumer (backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbind Fix by adding a devlink between the consuming led-backlight device and the supplying LED device, as other drivers and subsystems do as well. Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Signed-off-by: Luca Ceresoli Reviewed-by: Daniel Thompson (RISCstar) Reviewed-by: Herve Codina Tested-by: Alexander Sverdlin Link: https://patch.msgid.link/20250519-led-backlight-add-devlink-to-supplier-class-device-v6-1-845224aeb2ce@bootlin.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: led_bl: Include

2025-09-16T16:05:19Z

Include to declare struct of_count_phandle_with_args(). Avoids dependency on backlight header to include it. Signed-off-by: Thomas Zimmermann Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250715122643.137027-13-tzimmermann@suse.de Signed-off-by: Lee Jones

backlight: led_bl: Use devm_kcalloc() for array space allocation

2025-09-16T15:48:49Z

Replace calls of devm_kzalloc() with devm_kcalloc() in led_bl_get_leds() and led_bl_parse_levels() for safer memory allocation with built-in overflow protection. Signed-off-by: Qianfeng Rong Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250819035804.433615-1-rongqianfeng@vivo.com Signed-off-by: Lee Jones

backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()

2025-02-11T14:12:38Z

Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable(). Fixes: ae232e45acf9 ("backlight: add led-backlight driver") Cc: stable@vger.kernel.org Signed-off-by: Herve Codina Link: https://lore.kernel.org/r/20250122091914.309533-1-herve.codina@bootlin.com Signed-off-by: Lee Jones

Get rid of 'remove_new' relic from platform driver struct

2024-12-01T23:12:43Z

The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds

backlight: led-backlight: Use backlight power constants

2024-07-04T15:45:25Z

Replace FB_BLANK_ constants with their counterparts from the backlight subsystem. The values are identical, so there's no change in functionality. Signed-off-by: Thomas Zimmermann Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20240624152033.25016-11-tzimmermann@suse.de Signed-off-by: Lee Jones

backlight: led_bl: Remove redundant of_match_ptr()

2023-08-21T11:16:56Z

The driver depends on CONFIG_OF, it is not necessary to use of_match_ptr() here. Signed-off-by: Ruan Jinjie Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20230818012308.2058373-1-ruanjinjie@huawei.com Signed-off-by: Lee Jones

backlight: led_bl: Take led_access lock when required

2023-06-26T15:29:42Z

The led_access lock must be held when calling led_sysfs_enable() and led_sysfs_disable(). This fixes warnings such as this: [ 2.432495] ------------[ cut here ]------------ [ 2.437316] WARNING: CPU: 0 PID: 22 at drivers/leds/led-core.c:349 led_sysfs_disable+0x54/0x58 [ 2.446105] Modules linked in: [ 2.449218] CPU: 0 PID: 22 Comm: kworker/u2:1 Not tainted 6.3.8+ #1 [ 2.456268] Hardware name: Generic AM3517 (Flattened Device Tree) [ 2.462402] Workqueue: events_unbound deferred_probe_work_func [ 2.468353] unwind_backtrace from show_stack+0x10/0x14 [ 2.473632] show_stack from dump_stack_lvl+0x24/0x2c [ 2.478759] dump_stack_lvl from __warn+0x9c/0xc4 [ 2.483551] __warn from warn_slowpath_fmt+0x64/0xc0 [ 2.488586] warn_slowpath_fmt from led_sysfs_disable+0x54/0x58 [ 2.494567] led_sysfs_disable from led_bl_probe+0x20c/0x3b0 [ 2.500305] led_bl_probe from platform_probe+0x5c/0xb8 [ 2.505615] platform_probe from really_probe+0xc8/0x2a0 [ 2.510986] really_probe from __driver_probe_device+0x88/0x19c [ 2.516967] __driver_probe_device from driver_probe_device+0x30/0xcc [ 2.523498] driver_probe_device from __device_attach_driver+0x94/0xc4 [ 2.530090] __device_attach_driver from bus_for_each_drv+0x80/0xcc [ 2.536437] bus_for_each_drv from __device_attach+0xf8/0x19c [ 2.542236] __device_attach from bus_probe_device+0x8c/0x90 [ 2.547973] bus_probe_device from deferred_probe_work_func+0x80/0xb0 [ 2.554504] deferred_probe_work_func from process_one_work+0x228/0x4c0 [ 2.561187] process_one_work from worker_thread+0x1fc/0x4d0 [ 2.566925] worker_thread from kthread+0xb4/0xd0 [ 2.571685] kthread from ret_from_fork+0x14/0x2c [ 2.576446] Exception stack(0xd0079fb0 to 0xd0079ff8) [ 2.581573] 9fa0: 00000000 00000000 00000000 00000000 [ 2.589813] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.598052] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 [ 2.604888] ---[ end trace 0000000000000000 ]--- Signed-off-by: Mans Rullgard Reviewed-by: Daniel Thompson Link: https://lore.kernel.org/r/20230619160249.10414-1-mans@mansr.com Signed-off-by: Lee Jones

backlight: led_bl: Convert to platform remove callback returning void

2023-03-16T15:08:36Z

The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20230308073945.2336302-7-u.kleine-koenig@pengutronix.de

backlight: Use backlight_get_brightness() throughout

2020-07-20T09:27:06Z

Introduce the backlight_get_brightness() helper in all video/backlight/* drivers. This simplifies the code and align the implementation of the update_status() operation across the different backlight drivers. Some of the drivers gains a little extra functionality by the change as they now respect the fb_blank() ioctl. Signed-off-by: Sam Ravnborg Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones