[PATCH v3 2/2] net: dsa: mt7530: Use GPIO polarity to generate correct reset sequence

[Krzysztof Kozlowski]

On 04/12/2025 16:37, Vladimir Oltean wrote:
> On Thu, Dec 04, 2025 at 04:22:10PM +0100, Andrew Lunn wrote:
>>> If this is blocking progress for new device trees, can we just construct,
>>> using of_machine_is_compatible(), a list of all boards where the device
>>> tree defines incorrect reset polarity that shouldn't be trusted by the
>>> driver when driving the reset GPIO? If we do this, we can also leave
>>> those existing device trees alone.
>>
>> I've still not seen a good answer to my question, why not just leave
>> it 'broken', and document the fact.
>>
>> Does the fact it is inverted in both DT and the driver prevent us from
>> making some board work?
>>
>> Why do we need to fix this?
>>
>> Sometimes it is better to just leave it alone, if it is not hurting
>> anybody.
>>
>> 	Andrew
> 
> Frank said that the fact the driver expecting a wrong device tree is
> forcing him to keep introducing even more wrong device trees for new
> boards.


Yeah. BTW, you can also refer to one of my commits -
738455858a2d21b769f673892546cf8300c9fd78 - but also note that similar
work later combined with much more useful change of gpio->gpiod API was
rejected by Mark Brown on basis:

"No, the DT is supposed to be an ABI.  The point in having a domain
specific language with a compiler is to allow device trees to be
distributed independently of the kernel."

https://lore.kernel.org/all/9942c3a9-51d1-4161-8871-f6ec696cb4db@sirena.org.uk/

What's interesting, exactly the same commit for the same file, done by
different person (Peng), introducing the same issues without addressing
them, was then merged by Mark:
https://patch.msgid.link/20250324-wcd-gpiod-v2-2-773f67ce3b56@nxp.com
(commit c2d359b4acfbe847d3edcc25d3dc4e594daf9010)

so you know... it's all relative. :)

Best regards,
Krzysztof