Re: [PATCH 0/3] platform/x86: int3472/discrete: Make it work with IPU6

[Hans de Goede <hdegoede@redhat.com>]

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