Re: [PATCH v4 4/4] leds: aw2013: Move assignment of chip->num_leds

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] leds: aw2013: commit message rationale does not match driver
  locking or code
--

commit 1ce6b90ecf6b0a7b5d8097b414e8e137a3fe0609
Author: Paul Sajna <sajattack@postmarketos.org>

> leds: aw2013: Move assignment of chip->num_leds
>
> devm_led_classdev_register_ext() executes default triggers
> synchronously, which call aw20xx_brightness_set().
> aw20xx_chip_in_use() silently returns false, skipping chip enablement and
> causing unbalanced regulator disables while probe is still running.
>
> Increment chip->num_leds inside the loop, so that each call gets the
> correct value for it's default trigger.
>
> Signed-off-by: Paul Sajna <sajattack@postmarketos.org>

[Severity: Medium]
Does this commit message match the locking and execution flow in
leds-aw2013?

aw2013_probe_dt() sets brightness_set_blocking to aw2013_brightness_set()
and leaves brightness_set NULL, so default triggers activated during
devm_led_classdev_register_ext() queue set_brightness_work instead of
calling aw2013_brightness_set() synchronously.

Furthermore, aw2013_probe() holds chip->mutex across aw2013_probe_dt(), and
aw2013_brightness_set() locks chip->mutex before calling
aw2013_chip_in_use().  Any queued work therefore waits until
aw2013_probe_dt() has finished and chip->num_leds is already set.

Also, aw2013_chip_disable() returns early when !chip->enabled, preventing
an unbalanced regulator_bulk_disable() if aw2013_chip_enable() was skipped,
and the driver functions are named aw2013_brightness_set() and
aw2013_chip_in_use() rather than aw20xx_*.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261108-aw2013-aw20xx-rename-v4-0-826529beeb52@postmarketos.org?part=4