Hi, On 11/25/22 12:11, Dan Scally wrote: > > On 25/11/2022 11:06, Andy Shevchenko wrote: >> On Fri, Nov 25, 2022 at 12:58:46PM +0200, Laurent Pinchart wrote: >>> On Fri, Nov 25, 2022 at 10:17:17AM +0000, Dan Scally wrote: >> ... >> >>> Can the LED framework be used without having the LED exposed to >>> userspace ? >> I believe the correct question here is "can the states of some leds be >> read-only from user perspective" (this way any changes into led subsystems >> looks less intrusive, esp. taking into account that subsystem is de facto >> unmaintained). >> > > I think the answer to that is yes: > > > https://elixir.bootlin.com/linux/latest/source/drivers/leds/led-class.c#L47 Interesting, I did not know that. But what is the added value of using the LED subsytem then for a simple only on/off LED driven by a GPIO? One of the challenges with using LED triggers for the privacy led, is that we need at least 2 triggers: "camera-front" and "camera-back" and then somehow to let what ever code sets the triggers know if it is dealing with the front or back sensor. Where as with GPIO-s we *bind* them to the sensor i2c_client so if we just have the sensor-driver look for an optional GPIO called "privacy-led" then we don't have this how to we bind the LED to the sensor problem; and if we drop the sysfs interface I fail to see the value in using the LED subsystem for GPIO a driven LED. Also see my other reply for a proposal to be able to share the code dealing with this between sensor drivers (and also remove some other gpio/clk/regulator boilerplate from sensor drivers). Regards, Hans
