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

From: Bryan O'Donoghue

Date: Fri Oct 16 2026 - 16:44:45 EST


On 16/10/2026 17:16, George Neacsu wrote:
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/


Hmm if you use b4 to generate your series, the tooling will pull this type of thing in for you and reviewers like me.
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.

No its fine, I'll pull that series first. "Wouldn't survive reset" actually meant "I can't believe this works without powering on the rails" but the other series does that ;)

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?

No need

b4 prep --edit-deps # add: message-id: <20260831130312.26296-1-lsa.uz@xxxxx>

b4 prep; b4 send

Then dependencies should be represented and sucked in automagically.


Thanks,
George