On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio [off-list ref] wrote:

On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:

quoted

From: Hans de Goede hansg@kernel.org

Add 'name' argument to of_led_get() such that it can lookup LEDs in
devicetree by either name or index.

And use this modified function to add devicetree support to the generic
(non devicetree specific) [devm_]led_get() function.

This uses the standard devicetree pattern of adding a -names string array
to map names to the indexes for an array of resources.

Reviewed-by: Andy Shevchenko andy.shevchenko@gmail.com
Reviewed-by: Lee Jones lee@kernel.org
Reviewed-by: Linus Walleij linus.walleij@linaro.org
Signed-off-by: Hans de Goede hansg@kernel.org
Signed-off-by: Aleksandrs Vinarskis alex@vinarskis.com
---

I was thinking, perhaps we should introduce some sort of an exclusive
access mechanism, so that the e.g. user (or malware) can't listen to
uevents and immediately shut down the LED over sysfs

It is already done by the original series from Hans (linked in cover),
which was merged few years back. It is also the reason why this
approach is used instead of typically used trigger-source - that
would've indeed allowed anyone with access to sysfs to disable the
indicator.

As per Hans [1], v4l2-core would disable sysfs of privacy indicator:

    sd->privacy_led = led_get(sd->dev, "privacy-led")
    led_sysfs_disable(sd->privacy_led);


Of course, this security only holds if one has secure boot enforced,
kernel, modules, _and_ device-tree blobs are signed.

Regards,
Alex

[1] https://lore.kernel.org/all/daf442a6-b4d6-4213-8ec0-10397d682cc4@kernel.org/ (local)

Konrad