Re: [PATCH v6 1/1] leds: st1202: Add hardware-accelerated blink support

On Thu, 2026-08-06 at 17:42 +0000, [email protected] wrote:

> New issues:
> - [High] Hardware blinking destructively overwrites the PWM state of
> all other active LEDs, forcing them permanently off.

This is an inherent hardware constraint. The LED1202 uses a single
global pattern sequencer with shared timing registers, making it
impossible for two channels to run independent blink configurations
simultaneously. When blink_set() is called, the shared timing is
reconfigured for the requested delays and other channels' PWM slots are
set to LED_OFF so they remain dark rather than outputting unintended
values. This behaviour is described in the commit message.

> - [Medium] Hardware blink forces maximum brightness, ignoring user-
> configured brightness.

led_cdev->blink_brightness is set inside led_set_software_blink(), which
is the fallback path taken when blink_set() is absent or returns non-
zero. Since st1202_blink_set() returns 0 on success,
led_set_software_blink() is never reached and blink_brightness is not
updated by the core before our callback is invoked. Using it would risk
reading 0 or a stale value from a previous software blink, causing the
LED to blink invisibly. U8_MAX is intentional.

> Pre-existing issues:
> - [High] The driver improperly assigns a sleeping function to the
> led_cdev->brightness_set callback, causing a 'sleeping in atomic' bug.
> - [High] A dangling fwnode pointer is stored in `led->fwnode` due to a
> dropped reference count, leading to a UAF upon dereference.

The two pre-existing issues are already tracked for a follow-up
submission.

-- 
Manuel Fombuena