@@ -156,6 +156,7 @@ struct ov5693_device {
struct gpio_desc *reset;
struct gpio_desc *powerdown;
+ struct gpio_desc *privacy_led;
struct regulator_bulk_data supplies[OV5693_NUM_SUPPLIES];
struct clk *xvclk;
@@ -789,6 +790,7 @@ static int ov5693_sensor_init(struct ov5693_device *ov5693)
static void ov5693_sensor_powerdown(struct ov5693_device *ov5693)
{
+ gpiod_set_value_cansleep(ov5693->privacy_led, 0);
gpiod_set_value_cansleep(ov5693->reset, 1);
gpiod_set_value_cansleep(ov5693->powerdown, 1);
@@ -818,6 +820,7 @@ static int ov5693_sensor_powerup(struct ov5693_device *ov5693)
gpiod_set_value_cansleep(ov5693->powerdown, 0);
gpiod_set_value_cansleep(ov5693->reset, 0);
+ gpiod_set_value_cansleep(ov5693->privacy_led, 1);
usleep_range(5000, 7500);
@@ -1325,6 +1328,13 @@ static int ov5693_configure_gpios(struct ov5693_device *ov5693)
return PTR_ERR(ov5693->powerdown);
}
+ ov5693->privacy_led = devm_gpiod_get_optional(ov5693->dev, "privacy-led",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(ov5693->privacy_led)) {
+ dev_err(ov5693->dev, "Error fetching privacy-led GPIO\n");
+ return PTR_ERR(ov5693->privacy_led);
+ }
+
return 0;
}
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@redhat.com> --- 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. --- drivers/media/i2c/ov5693.c | 10 ++++++++++ 1 file changed, 10 insertions(+)