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

[Krzysztof Kozlowski <krzk@kernel.org>]

On 15/12/2025 11:19, Loic Poulain wrote:
> On Mon, Dec 15, 2025 at 10:40 AM Sakari Ailus
> <sakari.ailus@linux.intel.com> wrote:
>>
>> Hi Loic,
>>
>> On Mon, Dec 15, 2025 at 10:35:15AM +0100, Loic Poulain wrote:
>>> Hi Sakari,
>>>
>>> On Mon, Nov 17, 2025 at 6:30 PM Sakari Ailus
>>> <sakari.ailus@linux.intel.com> wrote:
>>>>
>>>> Hi Loic,
>>>>
>>>> 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.
> 
> 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?

You need to first CC me. You sent it to the special bulk email
address... Anyway, please be specific about the question.

I responded to earlier message that your claims in your comment in this
patch are clearly wrong, but what it is surprising me, it's second
approach this month people completely ignore existing and new DTS. Other
was MT7530 where author also claim all is fine, but actually both old
and new DTS were broken. Same here.



Best regards,
Krzysztof