Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [Medium] Race condition in `store_linear` leading to hardware and software state mismatch. --
commit 52a62eb2455ff3beba4492c4d5e3f63ad2e5e71d Author: Svyatoslav Ryhel <[email protected]> video: backlight: lm3533_bl: Implement backlight_scale property This commit implements the backlight_scale property for the lm3533_bl driver. It describes whether the backlight operates in linear or non-linear mode based on the device state. > diff --git a/drivers/video/backlight/lm3533_bl.c > b/drivers/video/backlight/lm3533_bl.c > --- a/drivers/video/backlight/lm3533_bl.c > +++ b/drivers/video/backlight/lm3533_bl.c > @@ -142,6 +142,7 @@ static ssize_t store_linear(struct device *dev, struct > device_attribute *attr, > { > struct lm3533_bl *bl = dev_get_drvdata(dev); > int ctrlbank = lm3533_bl_get_ctrlbank_id(bl); > + struct backlight_device *bd = bl->bd; > unsigned long linear; > int ret; > > @@ -153,6 +154,9 @@ static ssize_t store_linear(struct device *dev, struct > device_attribute *attr, > if (ret) > return ret; > > + bd->props.scale = linear ? BACKLIGHT_SCALE_LINEAR : > + BACKLIGHT_SCALE_NON_LINEAR; [Severity: Medium] Could this allow the hardware state and the software property to diverge during concurrent writes? Since kernfs does not serialize concurrent writes to sysfs files, if two threads write contradictory values at the same time, the regmap updates and the bd->props.scale updates could interleave. This might result in the hardware being configured in one mode while bd->props.scale incorrectly reports the opposite mode. Would it make sense to protect this update sequence with a lock to ensure both the hardware and software properties are updated atomically? > + > return len; > } -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=13
