Re: [PATCH v2 5/6] video: backlight: lm3533_bl: Set initial mapping mode from DT

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] The backlight device is exposed to userspace before its hardware initialization is complete.
--

commit 106cefce156b039f4639eecee3b1a98c82987da6
Author: Svyatoslav Ryhel <clamor95@gmail.com>

video: backlight: lm3533_bl: Set initial mapping mode from DT

This commit adds support to obtain the initial mapping mode from DT instead
of leaving it unconfigured. It also updates the linear sysfs code.

> diff --git a/drivers/video/backlight/lm3533_bl.c b/drivers/video/backlight/lm3533_bl.c
> index 42da652df58d9..c03d0d1667e42 100644
> --- a/drivers/video/backlight/lm3533_bl.c
> +++ b/drivers/video/backlight/lm3533_bl.c

[ ... ]

> @@ -317,14 +318,6 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>  
>  	platform_set_drvdata(pdev, bl);
>  
> -	ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
> -	if (ret < 0) {
> -		dev_err(&pdev->dev, "failed to create sysfs attributes\n");
> -		return ret;
> -	}
> -
> -	backlight_update_status(bd);
> -
>  	device_property_read_u32(&pdev->dev, "led-max-microamp",
>  				 &bl->max_current);
>  	bl->max_current = clamp(bl->max_current, LM3533_LED_MAX_CURRENT_MIN,
> @@ -333,9 +326,20 @@ static int lm3533_bl_probe(struct platform_device *pdev)
>  	bl->pwm = 0;
>  	device_property_read_u32(&pdev->dev, "ti,pwm-config-mask", &bl->pwm);
>  
> +	bl->linear = device_property_read_bool(&pdev->dev,
> +					       "ti,linear-mapping-mode");
> +
>  	ret = lm3533_bl_setup(bl);

[Severity: High]
This is a pre-existing issue, but I noticed a potential race condition here
with devm_backlight_device_register() being called earlier in this function.

When devm_backlight_device_register() is called, it creates the device in
sysfs, exposes standard attributes like brightness, and immediately fires a
KOBJ_ADD uevent.

Could a userspace daemon like systemd-backlight react to this uevent and
write a saved brightness value concurrently with the rest of this probe
function?

If that happens, it would trigger lm3533_bl_ops.update_status, which calls
lm3533_ctrlbank_set_brightness() to configure the hardware to drive the LEDs.

Because the driver has not yet read device tree limits like led-max-microamp
and applied them via lm3533_bl_setup() and lm3533_ctrlbank_set_max_current(),
could driving the LEDs before configuring the hardware's maximum safe current
limit result in physical hardware damage?

>  	if (ret)
> -		goto err_sysfs_remove;
> +		return ret;
> +
> +	ret = sysfs_create_group(&bd->dev.kobj, &lm3533_bl_attribute_group);
> +	if (ret < 0) {
> +		dev_err(&pdev->dev, "failed to create sysfs attributes\n");
> +		return ret;
> +	}
> +
> +	backlight_update_status(bd);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260528135123.103745-1-clamor95@gmail.com?part=5