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

[Bryan O'Donoghue <bod@kernel.org>]

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@pm.me/


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@pm.me>

b4 prep; b4 send

Then dependencies should be represented and sucked in automagically.

> 
> Thanks,
> George