[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7aacc2c2-50d0-4a08-9800-dc4a572dffcb@lunn.ch>
Date: Thu, 4 Dec 2025 16:22:10 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Daniel Golle <daniel@...rotopia.org>, Frank Wunderlich <frankwu@....de>,
Krzysztof Kozlowski <krzk@...nel.org>,
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
> 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
Powered by blists - more mailing lists