From: Jakub Kicinski <kuba@kernel.org>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: Charles Perry <charles.perry@microchip.com>,
netdev@vger.kernel.org, Conor Dooley <conor.dooley@microchip.com>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Claudiu Beznea <claudiu.beznea@tuxon.dev>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2] net: macb: set default_an_inband to true for SGMII
Date: Sat, 14 Mar 2026 09:08:14 -0700 [thread overview]
Message-ID: <20260314090814.290a056a@kernel.org> (raw)
In-Reply-To: <abUlANami1hWAfgf@shell.armlinux.org.uk>
On Sat, 14 Mar 2026 09:06:08 +0000 Russell King (Oracle) wrote:
> > I'm assuming this needs a respin now to account for the erronously
> > merged patch?
>
> It can be merged as well as the vitesse patch.
>
> The problem with the vitesse patch is it _would_ break for MACs that
> use phylink and always enable SGMII inband against phylink's
> instruction as the vitesse PHY comes up with SGMII inband enabled.
> Do we know of any MACs that are like that... well yes. There's at
> least one, the thorn of a driver, the poor implementation, known as
> stmmac. However, that wasn't the only one - the patch which caused
> this regression shows that macb also ignored phylink's wishes.
>
> Are there others? We don't know. This makes the vitesse patch
> potentially unsafe and potentially being reverted if problems are
> found during 7.1-rc.
>
> So, I think having both patches in gives to best approach for now -
> at least if the vitesse patch gets reverted, macb won't regress.
SG, thanks for explaining! I'll apply this after the weekend.
next prev parent reply other threads:[~2026-03-14 16:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 14:21 [PATCH net-next v2] net: macb: set default_an_inband to true for SGMII Charles Perry
2026-03-14 2:06 ` Jakub Kicinski
2026-03-14 9:06 ` Russell King (Oracle)
2026-03-14 16:08 ` Jakub Kicinski [this message]
2026-03-17 3:20 ` patchwork-bot+netdevbpf
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=20260314090814.290a056a@kernel.org \
--to=kuba@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=charles.perry@microchip.com \
--cc=claudiu.beznea@tuxon.dev \
--cc=conor.dooley@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=nicolas.ferre@microchip.com \
--cc=pabeni@redhat.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