From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Chris Snook <chris.snook@gmail.com>, Felix Fietkau <nbd@nbd.name>,
Florian Fainelli <f.fainelli@gmail.com>,
John Crispin <john@phrozen.org>,
Mark Lee <Mark-MC.Lee@mediatek.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Sean Wang <sean.wang@mediatek.com>,
Vivien Didelot <vivien.didelot@gmail.com>,
Vladimir Oltean <olteanv@gmail.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Heiner Kallweit <hkallweit1@gmail.com>,
Jakub Kicinski <kuba@kernel.org>,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, netdev@vger.kernel.org
Subject: [PATCH net-next 0/5] net: phylink: introduce legacy mode flag
Date: Tue, 7 Dec 2021 15:51:53 +0000 [thread overview]
Message-ID: <Ya+DGaGmGgWrlVkW@shell.armlinux.org.uk> (raw)
Hi all,
In March 2020, phylink gained support to split the PCS support out of
the MAC callbacks. By doing so, a slight behavioural difference was
introduced when a PCS is present, specifically:
1) the call to mac_config() when the link comes up or advertisement
changes were eliminated
2) mac_an_restart() will never be called
3) mac_pcs_get_state() will never be called
The intention was to eventually remove this support once all phylink
users were converted. Unfortunately, this still hasn't happened - and
in some cases, it looks like it may never happen.
Through discussion with Sean Anderson, we now need to allow the PCS to
be optional for modern drivers, so we need a different way to identify
these legacy drivers - in that we wish to allow the "modern" behaviour
where mac_config() is not called on link-up events, even if there is
no PCS attached.
In order to do that, this series of patches introduce a
"legacy_pre_march2020" which is used to permit the old behaviour - in
other words, we get the old behaviour only when there is no PCS and
this flag is true. Otherwise, we get the new behaviour.
I decided to use the date of the change in the flag as just using
"legacy" or "legacy_driver" is too non-descript. An alternative could
be to use the git sha1 hash of the set of changes.
I believe I have added the legacy flag to all the drivers which use
legacy mode - that being the mtk_eth_soc ethernet driver, and many DSA
drivers - the ones which need the old behaviour are identified by
having non-NULL phylink_mac_link_state or phylink_mac_an_restart
methods in their dsa_switch_ops structure.
ag71xx and xilinx do not need the legacy flag. ag71xx is explained in
its own commit, and xilinx only updates the inband advertisement in
the mac_config() call, which is sufficient qualification to avoid it
being marked legacy.
drivers/net/ethernet/atheros/ag71xx.c | 13 -------------
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 ++++
drivers/net/phy/phylink.c | 12 ++++++------
include/linux/phylink.h | 20 ++++++++++++++++++++
net/dsa/port.c | 7 +++++++
5 files changed, 37 insertions(+), 19 deletions(-)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next reply other threads:[~2021-12-07 15:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 15:51 Russell King (Oracle) [this message]
2021-12-09 13:11 ` [PATCH net-next 1/5] net: phylink: add legacy_pre_march2020 indicator Russell King (Oracle)
2021-12-09 13:11 ` [PATCH net-next 2/5] net: dsa: mark DSA phylink as legacy_pre_march2020 Russell King (Oracle)
2021-12-09 13:11 ` [PATCH net-next 3/5] net: mtk_eth_soc: mark as a legacy_pre_march2020 driver Russell King (Oracle)
2021-12-09 13:11 ` [PATCH net-next 4/5] net: phylink: use legacy_pre_march2020 Russell King (Oracle)
2021-12-09 13:11 ` [PATCH net-next 5/5] net: ag71xx: remove unnecessary legacy methods Russell King (Oracle)
2021-12-09 20:00 ` [PATCH net-next 0/5] net: phylink: introduce legacy mode flag 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=Ya+DGaGmGgWrlVkW@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Mark-MC.Lee@mediatek.com \
--cc=andrew@lunn.ch \
--cc=chris.snook@gmail.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.com \
--cc=john@phrozen.org \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=nbd@nbd.name \
--cc=netdev@vger.kernel.org \
--cc=olteanv@gmail.com \
--cc=sean.wang@mediatek.com \
--cc=vivien.didelot@gmail.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).