From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Daniel Golle <daniel@makrotopia.org>
Cc: Alexander Couzens <lynxis@fe80.eu>, Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@collabora.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
Subject: Re: [PATCH net-next] net: pcs: lynxi: fully reconfigure if link is down
Date: Thu, 17 Aug 2023 14:03:40 +0100 [thread overview]
Message-ID: <ZN4arCVzdszcIBX0@shell.armlinux.org.uk> (raw)
In-Reply-To: <e9831ec99acd5a8ab03c76fce87fa750c7041e60.1692273723.git.daniel@makrotopia.org>
On Thu, Aug 17, 2023 at 01:04:06PM +0100, Daniel Golle wrote:
> On MT7988 When switching from 10GBase-R/5GBase-R/USXGMII to one of the
> interface modes provided by mtk-pcs-lynxi we need to make sure to
> always perform a full configuration of the PHYA.
> As the idea behind not doing that was mostly to prevent an existing link
> going down without any need for it to do so. Hence we can just always
> perform a full confinguration in case the link is down.
And this is racy - because in the case with inband signalling, the link
can come up between reading the status and acting on it. It could even
be already up, but the link status indicates it is not. Lastly, reading
the BMSR has side effects: the link status bit latches low until a read.
Basically, do not read the BMSR here, it's buggy to read it any place
other than pcs_get_state.
I think what we need to do instead are:
1) mtk_mac_select_pcs() returns the SGMII PCS or NULL. Presumably this
is the driver which supports 10GBase-R/5GBase-R/USXGMII, and thus
this returns NULL for 10GBase-R/5GBase-R/USXGMII.
Phylink doesn't cater for mac_select_pcs() returning non-NULL for
some modes and NULL for others, mainly because the presence of a PCS
_used_ to cause phylink to change its behaviour (see
https://lore.kernel.org/netdev/YZRLQqLblRurUd4V@shell.armlinux.org.uk/).
That has now changed (we've got rid of the legacy stuff at last!) so
there is no technical reason not to now allow that.
Vladimir did have some arguments for not allowing it when we had the
phylink_set_pcs() interface:
https://lore.kernel.org/netdev/20211123181515.qqo7e4xbuu2ntwgt@skbuf/
I'm assuming that your requirement now provides sufficient
justification for allowing this.
There is one bug that does need fixing first:
phylink_change_inband_advert() checks pl->pcs->neg_mode without
first checking whether pl->pcs is non-NULL.
To allow this, phylink_major_config() needs:
pcs_changed = pcs && pl->pcs != pcs;
to become:
pcs_changed = pl->pcs != pcs;
2) with (1) solved, there are a couple of callbacks that can be used to
solve this - I think pcs_disable() is the one you want, which will
be called when we switch to a mode where _this_ PCS will no longer
be used (thus you can reset mpcs->interface to _NA, ready for when
it is next brought into use.)
Would that work for you?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2023-08-17 13:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-17 12:04 [PATCH net-next] net: pcs: lynxi: fully reconfigure if link is down Daniel Golle
2023-08-17 13:03 ` Russell King (Oracle) [this message]
2023-08-17 15:11 ` Daniel Golle
2023-08-17 13:13 ` Denis Kirjanov
2023-08-17 13:30 ` Russell King (Oracle)
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=ZN4arCVzdszcIBX0@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=angelogioacchino.delregno@collabora.com \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=lynxis@fe80.eu \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).