[RFC PATCH] media: cvs: do not announce host privacy LED ownership on SVP7xxx

[RFC PATCH] media: cvs: do not announce host privacy LED ownership on SVP7xxx

[Konrad Papaj]

The quirk entry for the Synaptics SVP7xxx bridge (06CB:0701) sets
ICVS_HOST_PRIV_CTRL, which makes cvs_configure_dev_caps() add
ICVS_HOST_ID_PRIVACY_LED to the host id sent to the CVS firmware via
ICVS_SET_DEV_HOST_ID, i.e. it tells the device that the host gates the
privacy LED.

On the Dell Pro 14 Plus PB14250 the host has no privacy LED to gate:

 - the only enabled INT3472 device (INT3472:0c) belongs to the IR
   camera HIMX1092:00 and registers HIMX1092_00::ir_flood_led.  The
   remaining INT3472 devices are disabled, so the LED lookup done by
   v4l2_subdev_get_privacy_led() finds nothing for the RGB sensor;

 - the _CRS of \_SB.PC00.CVSS declares four GPIO resources (wake
   0x00D4, rst 0x0037, req 0x0000, resp 0x0007), none of which is an
   LED;

 - the platform's own privacy hardware reports [Camera Shutter]
   [unsupported].

The indicator therefore stays dark for the whole duration of RGB
streaming.  The firmware stops driving it once the host claims it, and
the host has nothing to drive.

Measured on the affected machine with 30 s of continuous streaming,
800 frames captured in both runs:

  quirks 0x7a (ICVS_HOST_PRIV_CTRL set)      indicator dark
  quirks 0x3a (ICVS_HOST_PRIV_CTRL removed)  indicator lit

Camera operation is unaffected: the sensor and CVS bind as before, the
media graph is unchanged and libcamera still enumerates the camera.

This is sent as an RFC because the quirk is keyed on the bridge
VID/PID, while the presence of a host-driven privacy LED is a board
property.  Dropping the flag unconditionally would regress designs
that use the same Synaptics bridge and do wire the LED to the host.
Announcing ICVS_HOST_ID_PRIVACY_LED only when a host-side LED is
actually available, or keying this flag on DMI, both look more correct
to me, but I do not know which Intel intends.

Signed-off-by: Konrad Papaj <konrad.papaj@gmail.com>
---
Tested on:
  Dell Inc. Dell Pro 14 Plus PB14250, BIOS 2.7.4
  Intel(R) Core(TM) Ultra 7 265U
  IPU6 8086:7d19, subsystem 1028:0ce8
  Synaptics SVP7500 bridge, USB 06cb:0701, bcdDevice 84.95
  CVS INTC10E0:00 on i2c-15, sensor OVTI05C1:00 (OV05C10) on i2c-16
  kernel 7.2.8-200.fc44.x86_64 (Fedora 44)
  libcamera 0.7.1, "simple" pipeline handler + ipa_soft_simple

Disclosure: the OV05C10 sensor driver is not upstream, so the sensor on
this machine is driven by an out-of-tree ov05c10 module built from
intel/ipu6-drivers with local fixes.  The LED behaviour reported here is
independent of that: the indicator is gated by CVS firmware based on
ICVS_SET_DEV_HOST_ID, and the quirk flag was the only variable changed
between the two measurements in the commit message.

Reproduction:
  1. boot with the in-tree intel_cvs, confirm "Quirks: 0x7a" in dmesg
  2. stream from the RGB camera for 30 s, indicator stays dark
  3. apply this patch, confirm "Quirks: 0x3a"
  4. repeat the 30 s stream, indicator is lit for the duration

 drivers/media/i2c/cvs/core.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/i2c/cvs/core.c b/drivers/media/i2c/cvs/core.c
index fe9e59a..fafa2dc 100644
--- a/drivers/media/i2c/cvs/core.c
+++ b/drivers/media/i2c/cvs/core.c
@@ -70,7 +70,6 @@ static const struct icvs_device_quirk cvs_quirk_table[] = {
 	},	/* Lattice NX33 */
 	{ 0x06CB, 0x0701, ICVS_SKIP_FW_RESET |
 			  ICVS_HOST_SENSOR_PWR_CTRL |
-			  ICVS_HOST_PRIV_CTRL |
 			  ICVS_FW_BUF_SIZE_256 |
 			  ICVS_FW_HEADER_SIZE_256
 	},	/* Synaptics SVP7xxx */
-- 
2.56.0