On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio
<konrad.dyb...@oss.qualcomm.com> wrote:
>
>
> On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote:
>
> > From: Hans de Goede ha...@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.shevche...@gmail.com
> > Reviewed-by: Lee Jones l...@kernel.org
> > Reviewed-by: Linus Walleij linus.wall...@linaro.org
> > Signed-off-by: Hans de Goede ha...@kernel.org
> > Signed-off-by: Aleksandrs Vinarskis a...@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-10397d682...@kernel.org/
>
> Konrad
