Hi Hans, On Mon, Nov 28, 2022 at 10:44:03PM +0100, Hans de Goede wrote: > Hi All, > > While working on the earlier discussed changes for dealing with > the privacy LED for "discrete" INT3472 ACPI devices I was wondering > "how are we dealing with the privacy LED when the INT3472 ACPI device > is a tps68470?". > > Well it turns out we were not dealing with this at all, leading to > the privacy LED on the back of the Surface Go series not lighting up > when the back camera is on. The tps68470 on ACPI was originally only supported via the OP region interface and on all of those systems the privacy LED was hard wired. So the LED outputs were not supported. Thanks for adding them. > > This series fixes this, it consists of: > > Patches 1-2: 2 small bugfixes to the gpio-tps68470 code > Patch3: Add support for the indicator LED outputs on the tps68470 as GPIOs > Patch4: Add support for a privacy LED to the ov8865 sensor driver > Patch5: Add gpio-lookup table entry for the privacy LED. > > There is one small issue here, I believe that patches 1-3 need to land before > 4 + 5 do. Once 4 + 5 have landed the ov8865 driver will try to get a > GPIO with pin number 10 from the gpio-tps68470 provider and without patch 3, > that will fail because only pins 0-9 exist until patch 3 lands. > > The easiest way to avoid this issue would be for me to merge patches 1-3 + > 5 through the pdx86 tree. GPIO subsystem maintainers, may I have your ack > for this ? > > Note patch 4 is not a problem without patch 5, it uses gpiod_get_optional, > so as long as there is no lookup entry for a "privacy-led" GPIO it is > a no-op. For the patches: Reviewed-by: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx> Although I'd still like to see another, better scaling solution for controlling privacy LEDs. -- Kind regards, Sakari Ailus
