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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6344bdfd-c22c-45a1-854d-59091dfeda97@kernel.org>
Date: Thu, 4 Dec 2025 16:52:53 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>
Cc: Daniel Golle <daniel@...rotopia.org>, Frank Wunderlich <frankwu@....de>,
 Chen Minqiang <ptpt52@...il.com>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Matthias Brugger <matthias.bgg@...il.com>,
 AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
 "Chester A. Unal" <chester.a.unal@...nc9.com>,
 DENG Qingfang <dqfext@...il.com>, Sean Wang <sean.wang@...iatek.com>,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-mediatek@...ts.infradead.org, netdev@...r.kernel.org
Subject: Re: [PATCH v3 2/2] net: dsa: mt7530: Use GPIO polarity to generate
 correct reset sequence

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