Re: [PATCH v7 8/9] leds: st1202: validate LED reg property against channel count

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] The driver assigns a sleepable function to the LED subsystem's non-blocking `brightness_set` callback, leading to "scheduling while atomic" kernel panics.
--

Note: The format of this review is altered to use a free-form summary instead
of inline diff quotes due to recitation restrictions.

commit e35dcdba8764dc455863a8cb25600d5218b1d1a5
Author: Manuel Fombuena <fombuena@outlook.com>

leds: st1202: validate LED reg property against channel count

The reg property from the device tree is used directly as an array index
into chip->leds[] without bounds checking. A value >= ST1202_MAX_LEDS
would cause an out-of-bounds write during probe.

[Severity: High]
This is a pre-existing issue, but does this code cause a "scheduling while
atomic" panic when a software trigger like heartbeat or timer is configured?

In drivers/leds/leds-st1202.c during st1202_dt_init(), the driver assigns
st1202_brightness_set to led->led_cdev.brightness_set. The brightness_set
callback is expected to be non-blocking by the LED subsystem core.

However, st1202_brightness_set() uses guard(mutex)(&chip->lock) and performs
I2C transactions, both of which are blocking operations.

When a software trigger fires in a softirq timer context, it calls
led_set_brightness_nosleep(), which directly invokes the brightness_set
callback. Since the callback attempts to acquire a mutex and perform I2C
transfers from this atomic context, it causes a kernel panic.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/GV1PR08MB8497C0B898789BB73ACE6EE3C5F52@GV1PR08MB8497.eurprd08.prod.outlook.com?part=8