Re: [PATCH v3 1/4] media: i2c: ov9282: Fix reset-gpio logical state

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Mon, Dec 15, 2025 at 11:19:51AM +0100, Loic Poulain wrote:
> On Mon, Dec 15, 2025 at 10:40 AM Sakari Ailus wrote:
> > On Mon, Dec 15, 2025 at 10:35:15AM +0100, Loic Poulain wrote:
> > > On Mon, Nov 17, 2025 at 6:30 PM Sakari Ailus wrote:
> > > > On Fri, Nov 14, 2025 at 02:38:19PM +0100, Loic Poulain wrote:
> > > > > Ensure reset state is low in the power-on state and high in the
> > > > > power-off state (assert reset). Note that the polarity is abstracted
> > > > > by the GPIO subsystem, so the logic level reflects the intended reset
> > > > > behavior.
> > > >
> > > > That's an interesting approach to fix DTS gone systematically wrong.
> > > >
> > > > I was thinking of the drivers that have this issue, too, but I would have
> > > > introduced a new GPIO under a different name (many sensors use "enable",
> > > > too). Any thoughts?
> > >
> > > Apologies for missing your point earlier. We can’t really name it
> > > enable, as it performs the opposite function and that would be
> > > confusing in the device tree description. A property like reset2 would
> > > be more accurate, but I suspect such a binding wouldn’t be acceptable
> > > from a device tree/bindings perspective.
> >
> > Many sensor datasheets document a pin called "xshutdown" or alike. That's
> > not exactly "reset" or "enable" but it can be mapped to either and this can
> > be seen in the existing bindings. The polarity is effectively the opposite,
> > yes, but does that matter?
> 
> I assume naming a pin 'xshutdown' or 'xreset' indicates that its
> polarity is inverted at the driver level, the driver interprets the
> shutdown or reset function as being active when the logical level is 0
> (low), as they actually incorrectly do for the 'reset' gpio.
> 
> From the driver’s perspective, this naming convention is acceptable;
> however, it causes the devicetree description to slightly diverge from
> the datasheet and leaves the reset property effectively inverted (and
> therefore incorrect).
> 
> Honestly, in this specific case, the simplest solution would be to fix
> the driver, since there is currently no upstream devicetree using this
> sensor. That would technically break backward compatibility for any
> out-of-tree DTS (if they exist), but those would have been incorrect
> in the first place.

I would either fix the driver, or update the DT bindings to indicate the
polarity should be inverted due to a historical mistake.

I don't think this patch is right. The polarity in DT is meant to
describe board-level inversion of the GPIO, so you can't consider that
ACTIVE_HIGH is a DT bug and print a warning.

> But yes, this seems like a good opportunity to discuss and define a
> more general approach that can be applied to other drivers with
> similar polarity or naming issues.
> 
> Krzysztof, any thoughts?

-- 
Regards,

Laurent Pinchart