kernel/linux.git/drivers/video/backlight, branch v6.1.168

backlight: qcom-wled: Support ovp values for PMI8994

2026-03-04T12:20:01+00:00

[ Upstream commit f29f972a6e7e3f187ea4d89b98a76c1981ca4d53 ] WLED4 found in PMI8994 supports different ovp values. Fixes: 6fc632d3e3e0 ("video: backlight: qcom-wled: Add PMI8994 compatible") Signed-off-by: Barnabás Czémán Reviewed-by: Konrad Dybcio Reviewed-by: Daniel Thompson (RISCstar) Link: https://patch.msgid.link/20260116-pmi8950-wled-v3-2-e6c93de84079@mainlining.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: led-bl: Add devlink to supplier LEDs

2026-01-11T14:18:30+00:00

[ 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: Take led_access lock when required

2026-01-11T14:18:29+00:00

[ Upstream commit a33677b9211b6c328ad359b072043af94f7c9592 ] 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 Stable-dep-of: 9341d6698f4c ("backlight: led-bl: Add devlink to supplier LEDs") Signed-off-by: Sasha Levin

video: backlight: lp855x_bl: Set correct EPROM start for LP8556

2025-12-06T21:12:16+00:00

[ Upstream commit 07c7efda24453e05951fb2879f5452b720b91169 ] According to LP8556 datasheet EPROM region starts at 0x98 so adjust value in the driver accordingly. Signed-off-by: Svyatoslav Ryhel Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250909074304.92135-2-clamor95@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: pm8941: Add NULL check in wled_configure()

2025-06-27T10:07:14+00:00

[ Upstream commit e12d3e1624a02706cdd3628bbf5668827214fa33 ] devm_kasprintf() returns NULL when memory allocation fails. Currently, wled_configure() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: f86b77583d88 ("backlight: pm8941: Convert to using %pOFn instead of device_node.name") Signed-off-by: Henry Martin Reviewed-by: Dmitry Baryshkov Reviewed-by: "Daniel Thompson (RISCstar)" Link: https://lore.kernel.org/r/20250401091647.22784-1-bsdhenrymartin@gmail.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

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

2025-05-02T05:46:51+00:00

[ Upstream commit 276822a00db3c1061382b41e72cafc09d6a0ec30 ] 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 Signed-off-by: Sasha Levin

backlight: led_bl: Convert to platform remove callback returning void

2025-05-02T05:46:51+00:00

[ Upstream commit c4c4fa57fd3cc00020152baa169337521f90b2ad ] 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 Stable-dep-of: 276822a00db3 ("backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()") Signed-off-by: Sasha Levin

backlight: lp8788: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit 392346827fbe8a7fd573dfb145170d7949f639a6 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: c5a51053cf3b ("backlight: add new lp8788 backlight driver") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-4-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: lm3639: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit abb5a5d951fbea3feb5c4ba179b89bb96a1d3462 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 0f59858d5119 ("backlight: add new lm3639 backlight driver") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-3-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin

backlight: da9052: Fully initialize backlight_properties during probe

2024-03-26T22:20:53+00:00

[ Upstream commit 0285e9efaee8276305db5c52a59baf84e9731556 ] props is stack allocated and the fields that are not explcitly set by the probe function need to be zeroed or we'll get undefined behaviour (especially so power/blank states)! Fixes: 6ede3d832aaa ("backlight: add driver for DA9052/53 PMIC v1") Signed-off-by: Daniel Thompson Link: https://lore.kernel.org/r/20240220153532.76613-2-daniel.thompson@linaro.org Signed-off-by: Lee Jones Signed-off-by: Sasha Levin