[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1v1U5t-00000007Hvz-2Xky@rmk-PC.armlinux.org.uk>
Date: Wed, 24 Sep 2025 19:19:57 +0100
From: "Russell King (Oracle)" <rmk+kernel@...linux.org.uk>
To: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>
Cc: Abhishek Chauhan <quic_abchauha@...cinc.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>,
Alexis Lothore <alexis.lothore@...tlin.com>,
"Alexis Lothor__" <alexis.lothore@...tlin.com>,
Andrew Lunn <andrew+netdev@...n.ch>,
Boon Khai Ng <boon.khai.ng@...era.com>,
Choong Yong Liang <yong.liang.choong@...ux.intel.com>,
Daniel Machon <daniel.machon@...rochip.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Faizal Rahim <faizal.abdul.rahim@...ux.intel.com>,
Furong Xu <0x1207@...il.com>,
Huacai Chen <chenhuacai@...nel.org>,
Inochi Amaoto <inochiama@...il.com>,
Jacob Keller <jacob.e.keller@...el.com>,
Jakub Kicinski <kuba@...nel.org>,
"Jan Petrous (OSS)" <jan.petrous@....nxp.com>,
Jisheng Zhang <jszhang@...nel.org>,
Kees Cook <kees@...nel.org>,
Kunihiko Hayashi <hayashi.kunihiko@...ionext.com>,
Lad Prabhakar <prabhakar.mahadev-lad.rj@...renesas.com>,
Ley Foon Tan <leyfoon.tan@...rfivetech.com>,
linux-arm-kernel@...ts.infradead.org,
linux-arm-msm@...r.kernel.org,
linux-stm32@...md-mailman.stormreply.com,
Matthew Gerlach <matthew.gerlach@...era.com>,
Maxime Chevallier <maxime.chevallier@...tlin.com>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
netdev@...r.kernel.org,
Oleksij Rempel <o.rempel@...gutronix.de>,
Paolo Abeni <pabeni@...hat.com>,
Philipp Zabel <p.zabel@...gutronix.de>,
Rohan G Thomas <rohan.g.thomas@...era.com>,
Shenwei Wang <shenwei.wang@....com>,
Simon Horman <horms@...nel.org>,
Song Yoong Siang <yoong.siang.song@...el.com>,
Swathi K S <swathi.ks@...sung.com>,
Tiezhu Yang <yangtiezhu@...ngson.cn>,
Vinod Koul <vkoul@...nel.org>,
Vladimir Oltean <olteanv@...il.com>,
Vladimir Oltean <vladimir.oltean@....com>,
Yu-Chun Lin <eleanor15x@...il.com>
Subject: [PATCH RFC net-next 4/9] net: stmmac: remove PCS "mode" pause
handling
Remove the "we always autoneg pause" forcing when the stmmac driver
decides that a "PCS" is present, which blocks passing the ethtool
pause calls to phylink when using SGMII mode.
This prevents the pause results being reported when a PHY is attached
using SGMII mode, or the pause settings being changed in SGMII mode.
There is no reason to prevent this.
Signed-off-by: Russell King (Oracle) <rmk+kernel@...linux.org.uk>
---
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 13 ++-----------
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
index d89662b48087..c60cd948311e 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
@@ -424,11 +424,7 @@ stmmac_get_pauseparam(struct net_device *netdev,
{
struct stmmac_priv *priv = netdev_priv(netdev);
- if (priv->hw->pcs) {
- pause->autoneg = 1;
- } else {
- phylink_ethtool_get_pauseparam(priv->phylink, pause);
- }
+ phylink_ethtool_get_pauseparam(priv->phylink, pause);
}
static int
@@ -437,12 +433,7 @@ stmmac_set_pauseparam(struct net_device *netdev,
{
struct stmmac_priv *priv = netdev_priv(netdev);
- if (priv->hw->pcs) {
- pause->autoneg = 1;
- return 0;
- } else {
- return phylink_ethtool_set_pauseparam(priv->phylink, pause);
- }
+ return phylink_ethtool_set_pauseparam(priv->phylink, pause);
}
static u64 stmmac_get_rx_normal_irq_n(struct stmmac_priv *priv, int q)
--
2.47.3
Powered by blists - more mailing lists