@@ -688,6 +688,7 @@ struct ov8865_sensor {
struct i2c_client *i2c_client;
struct gpio_desc *reset;
struct gpio_desc *powerdown;
+ struct gpio_desc *privacy_led;
struct regulator *avdd;
struct regulator *dvdd;
struct regulator *dovdd;
@@ -2432,10 +2433,12 @@ static int ov8865_sensor_power(struct ov8865_sensor *sensor, bool on)
gpiod_set_value_cansleep(sensor->reset, 0);
gpiod_set_value_cansleep(sensor->powerdown, 0);
+ gpiod_set_value_cansleep(sensor->privacy_led, 1);
/* Time to enter streaming mode according to power timings. */
usleep_range(10000, 12000);
} else {
+ gpiod_set_value_cansleep(sensor->privacy_led, 0);
gpiod_set_value_cansleep(sensor->powerdown, 1);
gpiod_set_value_cansleep(sensor->reset, 1);
@@ -3009,6 +3012,12 @@ static int ov8865_probe(struct i2c_client *client)
goto error_endpoint;
}
+ sensor->privacy_led = devm_gpiod_get_optional(dev, "privacy-led", GPIOD_OUT_LOW);
+ if (IS_ERR(sensor->privacy_led)) {
+ ret = PTR_ERR(sensor->privacy_led);
+ goto error_endpoint;
+ }
+
/* External Clock */
sensor->extclk = devm_clk_get(dev, NULL);
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/ov8865.c | 9 +++++++++ 1 file changed, 9 insertions(+)