On 9/10/25 2:54 PM, Aleksandrs Vinarskis wrote: > > > > > > On Wednesday, September 10th, 2025 at 14:22, Konrad Dybcio > <[email protected]> wrote: > >> >> >> On 9/10/25 2:01 PM, Aleksandrs Vinarskis wrote: >> >>> From: Hans de Goede [email protected] >>> >>> 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 [email protected] >>> Reviewed-by: Lee Jones [email protected] >>> Reviewed-by: Linus Walleij [email protected] >>> Signed-off-by: Hans de Goede [email protected] >>> Signed-off-by: Aleksandrs Vinarskis [email protected] >>> --- >> >> >> 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.
Great, thank you for this context Konrad
