Re: [PATCH 2/2] media: i2c: ov13858: Add device tree support

[George Neacsu]

Hi Bryan,

On 16/10/2026 17:06, Bryan O'Donoghue wrote:
> You describe regulators, clocks and resets in the yaml file which then
> don't appear to be supported in this result code ?
>
> - regulator_bulk_;
> - clock_bulk_
> - reset gpio optional
>
> I don't think this driver would survive suspend/resume.

The power handling comes from a prerequisite: this series applies on
top of Sergey's "media: i2c: ov13858: add regulator, clock and reset
GPIO handling" v3, as the cover letter says, but that is easy to miss
from 2/2 alone:
https://lore.kernel.org/all/20260831130312.26296-1-lsa.uz@xxxxx/

With it, the driver gets the three supplies with
devm_regulator_bulk_get(), enables and disables the clock it already
takes with devm_v4l2_sensor_clk_get(), and takes an optional reset
GPIO. Power on and power off are the runtime PM callbacks through
DEFINE_RUNTIME_DEV_PM_OPS(), which also routes system sleep through
pm_runtime_force_suspend() and pm_runtime_force_resume(). So the binding
describes what the driver handles once both are applied. On its own,
2/2 only adds the OF match and the endpoint checks.

I cannot claim it survives system suspend on the Snapdragon model,
though. System suspend is still an open problem on the Surface Pro 11
under Linux and has not been validated, so I cannot exercise that path
here yet. What I can test is the
runtime PM path, which is where the supplies, clock and reset are
switched: the sensor powering off between sessions and back on for the
next stream. I will run repeated open, stream, close cycles and report
the result. Sergey, if suspend works on the Intel model, a suspend and
resume test there would cover the rest.

To make the dependency visible, I can carry Sergey's patch as 1/3 of
the next version, with his authorship. Sergey, would that be all right
with you, or would you rather post v4 yourself?

Thanks,
George