Re: [PATCH 1/6] media: ov5693: Add support for a privacy-led GPIO

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Sakari,

On 11/30/22 14:41, Sakari Ailus wrote:
> Hi Hans,
> 
> On Wed, Nov 30, 2022 at 12:11:44AM +0100, Hans de Goede wrote:
>> Add support for a privacy-led GPIO.
>>
>> Making the privacy LED to controlable from userspace, as using the LED
>> class subsystem would do, would make it too easy for spy-ware to disable
>> the LED.
>>
>> To avoid this have the sensor driver directly control the LED.
>>
>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
>> ---
>> Note an additional advantage of directly controlling the GPIO is that
>> GPIOs are tied directly to consumer devices. Where as with a LED class
>> device, there would need to be some mechanism to tie the right LED
>> (e.g front or back) to the right sensor.
> 
> Thanks for the patch.
> 
> This approach has the drawback that support needs to be added for each
> sensor separately. Any idea how many sensor drivers might need this?

Quite a few probably. But as discussed here I plan to write a generic
sensor_power helper library since many sensor drivers have a lot of
boilerplate code to get clks + regulators + enable/reset gpios. The plan
is to add support for a "privacy-led" to this library so that all sensors
which use this get support for free.

Laurent pointed out that some sensors may have more complex power-up
sequence demands, which is true. But looking at existing drivers
then many follow a std simple pattern which can be supported in
a helper-library.

> Most implementations have privacy LED hard-wired to the sensor's power
> rails so it'll be lit whenever the sensor is powered on.
> 
> If there would be more than just a couple of these I'd instead create a LED
> class device and hook it up to the sensor in V4L2.


A LED cladd device will allow userspace to override the privacy-led
value which is considered bad from a privacy point of view. This
was actually already discussed here:

https://lore.kernel.org/platform-driver-x86/e5d8913c-13ba-3b11-94bc-5d1ee1d736b0@xxxxxxxxxxxxxxxx/

See the part of the thread on the cover-letter with Dan, Laurent
and me participating.

And a LED class device also will be a challenge to bind to the right
sensor on devices with more then one sensor, where as mentioned
above using GPIO-mappings give us the binding to the right sensor
for free.

Regards,

Hans






[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux