Re: [PATCH v7 3/3] media: i2c: og0ve1b: Add support for OmniVision OG0VA1B

[Wenmeng Liu]

On 9/28/2026 10:03 AM, arthgirard wrote:
> From: Arthur Girard <mailarthurgirard@xxxxxxxxx>
>
> Hi Wenmeng,
>
> On Tue, Sep 15, 2026 at 02:54:14PM +0800, Wenmeng Liu wrote:
> > Add an og0ve1b_sensor_data entry describing the OG0VA1B together with
>
> The OG0VA1B is also the IR sensor on some x86 laptops with Intel IPU6.
> I tried this series on an HP Spectre x360 14-eu0xxx (Meteor Lake),
> where the sensor is ACPI device OVTI00AB: 1 lane, 19.2 MHz clock, same
> as your og0va1b_data. On top of v7 applied to 7.2.7 it needed three
> small things to work:
>
> 1. An ACPI match for OVTI00AB pointing at og0va1b_data.
>
> 2. An ipu-bridge entry, IPU_SENSOR_CONFIG("OVTI00AB", 1, 480000000),
>     so the IPU6 creates the graph endpoint.
>
> 3. -EPROBE_DEFER instead of -EINVAL in og0ve1b_check_hwcfg() when
>     fwnode_graph_get_next_endpoint() returns NULL. The driver can probe
>     before ipu-bridge has created the endpoint, and on one boot out of a
>     handful it lost that race and failed for good.
>
> With those, the 640x480 Y10 mode streams fine through the IPU6 ISYS and
> the images look right. I've been using it for face authentication.
>
> None of this is needed for your DT use case, so I don't want to hold the
> series up. I can send the three as follow-up patches once it's merged,
> unless you'd rather fold the ACPI match and the deferral into v8.

Hi Arthur,

Thanks for testing this on real hardware, and for tracking down the
probe ordering issue.

All three points are specific to ACPI support, which I can't test
locally. Point 3 isn't reachable on its own either -- the driver only
has an OF match table, so it can't bind to OVTI00AB until point 1 is
in place. That makes 1 and 3 one logical change rather than two.

So I'd prefer to keep the ACPI support as a follow-up after this series
is merged.

Hi Sakari,
is there anything else you would like addressed, or is it OK to apply?


Thanks,
Wenmeng