[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <52d3469e-104e-4950-802a-2b83cea8d726@lunn.ch>
Date: Thu, 20 Nov 2025 23:08:05 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Chen Minqiang <ptpt52@...il.com>
Cc: 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>,
Daniel Golle <daniel@...rotopia.org>,
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 v2 1/2] ARM64: dts: mediatek: fix MT7531 reset GPIO
polarity on multiple boards
On Fri, Nov 21, 2025 at 05:38:04AM +0800, Chen Minqiang wrote:
> The MT7531 reset pin is active-low, but several DTS files configured the
> reset-gpios property without GPIO_ACTIVE_LOW. This causes the reset GPIO
> to behave as active-high and prevents the switch from being properly reset.
>
> Update all affected DTS files to correctly use GPIO_ACTIVE_LOW so that
> the reset polarity matches the hardware design.
>
> Boards fixed:
> - mt7622-bananapi-bpi-r64
> - mt7622-rfb1
> - mt7986a-bananapi-bpi-r3
> - mt7986a-rfb
> - mt7986b-rfb
>
> Note: the previous DTS description used the wrong polarity but the
> driver also assumed the opposite polarity, resulting in a matched pair
> of bugs that worked together. Updating the DTS requires updating the
> driver at the same time; old kernels will not reset the switch correctly
> when used with this DTS.
Sometimes we need to live with issues like this, because of:
> Compatibility
> -------------
>
> Correcting the polarity creates intentional incompatibility:
>
> * New kernel + old DTS:
> The driver now expects active-low, but out-of-tree DTS still marks
> active-high, causing the reset sequence to invert.
>
> * Old kernel + new DTS:
> The old driver toggles reset assuming active-high, which now
> conflicts with the corrected active-low DTS.
>
> This was unavoidable because the original DTS was factually wrong.
> Out-of-tree DTS users must update their DTS together with the kernel.
So the real question is, does this actually harm anything? Do we see
any real issues?
Andrew
Powered by blists - more mailing lists