mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Chen Minqiang <ptpt52@gmail.com>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	AngeloGioacchino Del Regno
	<angelogioacchino.delregno@collabora.com>,
	"Chester A. Unal" <chester.a.unal@arinc9.com>,
	Daniel Golle <daniel@makrotopia.org>,
	DENG Qingfang <dqfext@gmail.com>,
	Sean Wang <sean.wang@mediatek.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-mediatek@lists.infradead.org, netdev@vger.kernel.org
Subject: Re: [PATCH v3 1/2] ARM64: dts: mediatek: fix MT7531 reset GPIO polarity on multiple boards
Date: Sun, 30 Nov 2025 02:00:41 +0100	[thread overview]
Message-ID: <893308f9-18c0-4489-81be-e233d50d16da@lunn.ch> (raw)
In-Reply-To: <20251129234603.2544-1-ptpt52@gmail.com>

On Sun, Nov 30, 2025 at 07:46:02AM +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.
> 
> 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.

So, the real question is, are the regressions you are going to cause
by breaking backwards compatibility worth it? 

What happens if we don't fix this? Does anything break if we leave it
as it is?

I personally think it be better to just document the issue in the
device tree binding.

	Andrew

      parent reply	other threads:[~2025-11-30  1:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-29 23:46 Chen Minqiang
2025-11-29 23:46 ` [PATCH v3 2/2] net: dsa: mt7530: Use GPIO polarity to generate correct reset sequence Chen Minqiang
2025-11-30  1:11   ` Andrew Lunn
2025-11-30  8:07     ` Vladimir Oltean
2025-11-30 20:17       ` Andrew Lunn
2025-12-01  7:48         ` Krzysztof Kozlowski
2025-12-02 11:52           ` Frank Wunderlich
2025-12-02 12:20             ` Daniel Golle
2025-12-04 13:16               ` Vladimir Oltean
2025-12-04 13:50                 ` Daniel Golle
2025-12-04 15:45                   ` Vladimir Oltean
2025-12-04 14:49                 ` Krzysztof Kozlowski
2025-12-04 16:02                   ` Vladimir Oltean
2025-12-04 16:48                     ` Krzysztof Kozlowski
2025-12-04 17:11                       ` Vladimir Oltean
2025-12-04 17:23                         ` Krzysztof Kozlowski
2025-12-04 17:32                           ` Krzysztof Kozlowski
2025-12-04 20:47                             ` Russell King (Oracle)
2025-12-04 17:45                           ` Russell King (Oracle)
2025-12-04 18:21                             ` Vladimir Oltean
2025-12-04 15:22                 ` Andrew Lunn
2025-12-04 15:37                   ` Vladimir Oltean
2025-12-04 15:50                     ` Andrew Lunn
2025-12-04 15:52                     ` Krzysztof Kozlowski
2025-12-04 16:33                       ` Vladimir Oltean
2025-11-30  8:22   ` Vladimir Oltean
2025-12-01  7:50   ` Krzysztof Kozlowski
2025-11-30  1:00 ` Andrew Lunn [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=893308f9-18c0-4489-81be-e233d50d16da@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=chester.a.unal@arinc9.com \
    --cc=conor+dt@kernel.org \
    --cc=daniel@makrotopia.org \
    --cc=dqfext@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=ptpt52@gmail.com \
    --cc=robh@kernel.org \
    --cc=sean.wang@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®