net: stmmac: qcom-ethqos: further serdes reorganisation

Signed-off-by Russell King (Oracle) <[email protected]>

---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 22 +++++++++----------
 1 file changed, 11 insertions(+), 11 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c +11 ~~-11~~

index ad5b5d950fff..57cbe800f652 100644
@@ -591,14 +591,6 @@ static void ethqos_configure_rgmii(struct qcom_ethqos *ethqos,
 	ethqos_rgmii_macro_init(ethqos, speed);
 }
 
-static void ethqos_set_serdes_speed(struct qcom_ethqos *ethqos, int speed)
-{
-	if (ethqos->serdes_speed != speed) {
-		phy_set_speed(ethqos->serdes_phy, speed);
-		ethqos->serdes_speed = speed;
-	}
-}
-
 static void ethqos_pcs_set_inband(struct stmmac_priv *priv, bool enable)
 {
 	stmmac_pcs_ctrl_ane(priv, enable, 0);

@@ -683,15 +675,23 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
 				    phy_interface_t interface)
 {
 	struct qcom_ethqos *ethqos = priv;
+	int speed, ret = 0;
 
 	qcom_ethqos_set_sgmii_loopback(ethqos, false);
 
+	speed = SPEED_UNKNOWN;
 	if (interface == PHY_INTERFACE_MODE_SGMII)
-		ethqos_set_serdes_speed(ethqos, SPEED_1000);
+		speed = SPEED_1000;
 	else if (interface == PHY_INTERFACE_MODE_2500BASEX)
-		ethqos_set_serdes_speed(ethqos, SPEED_2500);
+		speed = SPEED_2500;
 
-	return 0;
+	if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
+		ret = phy_set_speed(ethqos->serdes_phy, speed);
+		if (ret == 0)
+			ethqos->serdes_speed = speed;
+	}
+
+	return ret;
 }
 
 static int ethqos_clks_config(void *priv, bool enabled)

Signature · 1 line

2.47.3

Russell King (Oracle)

2026-02-26 23:09 UTC #2 lore raw

PATCH 2/8 phy: qcom-sgmii-eth: add .set_mode() and .validate() methods

qcom-sgmii-eth is an Ethernet SerDes supporting only Ethernet mode using SGMII, 1000BASE-X and 2500BASE-X.

Add an implementation of the .set_mode() method, which can be used instead of or as well as the .set_speed() method. The Ethernet interface modes mentioned above all have a fixed data rate, so setting the mode is sufficient to fully specify the operating parameters.

Add an implementation of the .validate() method, which will be necessary to allow discovery of the SerDes capabilities for platform independent SerDes support in the stmmac network driver.

Reviewed-by Bartosz Golaszewski <[email protected]>

Acked-by Vinod Koul <[email protected]>

Signed-off-by Russell King (Oracle) <[email protected]>

---
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 43 +++++++++++++++++++++++
 1 file changed, 43 insertions(+)

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +43 -0

index 5b1c82459c12..4ea3dce7719f 100644
@@ -7,6 +7,7 @@
 #include <linux/ethtool.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/phy.h>
 #include <linux/phy/phy.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>

@@ -286,6 +287,37 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
 	return 0;
 }
 
+static int qcom_dwmac_sgmii_phy_speed(enum phy_mode mode, int submode)
+{
+	if (mode != PHY_MODE_ETHERNET)
+		return -EINVAL;
+
+	if (submode == PHY_INTERFACE_MODE_SGMII ||
+	    submode == PHY_INTERFACE_MODE_1000BASEX)
+		return SPEED_1000;
+
+	if (submode == PHY_INTERFACE_MODE_2500BASEX)
+		return SPEED_2500;
+
+	return -EINVAL;
+}
+
+static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
+					 int submode)
+{
+	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
+	int speed;
+
+	speed = qcom_dwmac_sgmii_phy_speed(mode, submode);
+	if (speed < 0)
+		return speed;
+
+	if (speed != data->speed)
+		data->speed = speed;
+
+	return qcom_dwmac_sgmii_phy_calibrate(phy);
+}
+
 static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
 {
 	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);

@@ -296,10 +328,21 @@ static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
 	return qcom_dwmac_sgmii_phy_calibrate(phy);
 }
 
+static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
+					 int submode,
+					 union phy_configure_opts *opts)
+{
+	int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
+
+	return ret < 0 ? ret : 0;
+}
+
 static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
 	.power_on	= qcom_dwmac_sgmii_phy_power_on,
 	.power_off	= qcom_dwmac_sgmii_phy_power_off,
+	.set_mode	= qcom_dwmac_sgmii_phy_set_mode,
 	.set_speed	= qcom_dwmac_sgmii_phy_set_speed,
+	.validate	= qcom_dwmac_sgmii_phy_validate,
 	.calibrate	= qcom_dwmac_sgmii_phy_calibrate,
 	.owner		= THIS_MODULE,
 };

Signature · 1 line

2.47.3

Russell King (Oracle)

2026-02-26 23:09 UTC #3 lore raw

PATCH 3/8 net: stmmac: qcom-ethqos: convert to use phy_set_mode_ext()

qcom-sgmii-eth now accepts the phy_set_mode*() calls to configure the SerDes, taking a PHY interface mode rather than a speed. This allows the elimination of the interface mode to speed conversion in ethqos_mac_finish_serdes().

Signed-off-by Russell King (Oracle) <[email protected]>

---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c        | 23 ++++++++-----------
 1 file changed, 10 insertions(+), 13 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c +10 ~~-13~~

index 57cbe800f652..8913f6f02b9e 100644
@@ -105,7 +105,7 @@ struct qcom_ethqos {
 
 	struct clk *link_clk;
 	struct phy *serdes_phy;
-	int serdes_speed;
+	phy_interface_t serdes_mode;
 	phy_interface_t phy_mode;
 
 	const struct ethqos_emac_por *rgmii_por;

@@ -653,7 +653,8 @@ static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
 		return ret;
 	}
 
-	ret = phy_set_speed(ethqos->serdes_phy, ethqos->serdes_speed);
+	ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
+			       ethqos->serdes_mode);
 	if (ret) {
 		phy_power_off(ethqos->serdes_phy);
 		phy_exit(ethqos->serdes_phy);

@@ -675,20 +676,16 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
 				    phy_interface_t interface)
 {
 	struct qcom_ethqos *ethqos = priv;
-	int speed, ret = 0;
+	int ret = 0;
 
 	qcom_ethqos_set_sgmii_loopback(ethqos, false);
 
-	speed = SPEED_UNKNOWN;
-	if (interface == PHY_INTERFACE_MODE_SGMII)
-		speed = SPEED_1000;
-	else if (interface == PHY_INTERFACE_MODE_2500BASEX)
-		speed = SPEED_2500;
-
-	if (speed != SPEED_UNKNOWN && speed != ethqos->serdes_speed) {
-		ret = phy_set_speed(ethqos->serdes_phy, speed);
+	if (interface == PHY_INTERFACE_MODE_SGMII ||
+	    interface == PHY_INTERFACE_MODE_2500BASEX) {
+		ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
+				       interface);
 		if (ret == 0)
-			ethqos->serdes_speed = speed;
+			ethqos->serdes_mode = interface;
 	}
 
 	return ret;

@@ -819,7 +816,6 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 		return dev_err_probe(dev, PTR_ERR(ethqos->serdes_phy),
 				     "Failed to get serdes phy\n");
 
-	ethqos->serdes_speed = SPEED_1000;
 	ethqos_set_clk_tx_rate(ethqos, NULL, plat_dat->phy_interface,
 			       SPEED_1000);

@@ -843,6 +839,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 		plat_dat->host_dma_width = data->dma_addr_width;
 
 	if (ethqos->serdes_phy) {
+		ethqos->serdes_mode = PHY_INTERFACE_MODE_SGMII;
 		plat_dat->serdes_powerup = qcom_ethqos_serdes_powerup;
 		plat_dat->serdes_powerdown  = qcom_ethqos_serdes_powerdown;
 	}

Signature · 1 line

2.47.3

Russell King (Oracle)

2026-02-26 23:09 UTC #4 lore raw

PATCH 4/8 phy: qcom-sgmii-eth: remove .set_speed() implementation

Now that the qcom-ethqos driver has migrated to use phy_set_mode_ext() rather than phy_set_speed() to configure the SerDes, the support for phy_set_speed() is now obsolete. Remove support for this method.

Using the MAC speed for the SerDes is never correct due to the PCS encoding. For SGMII and 2500BASE-X, the PCS uses 8B10B encoding, and so:

MAC rate * PCS output bits / PCS input bits = SerDes rate

   1000M   *       10        /       8        = 1250M
   2500M   *       10        /       8        = 3125M

Signed-off-by Russell King (Oracle) <[email protected]>

---
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 11 -----------
 1 file changed, 11 deletions(-)

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +0 ~~-11~~

index 4ea3dce7719f..dcfdb7d0e8ea 100644
@@ -318,16 +318,6 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
 	return qcom_dwmac_sgmii_phy_calibrate(phy);
 }
 
-static int qcom_dwmac_sgmii_phy_set_speed(struct phy *phy, int speed)
-{
-	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
-
-	if (speed != data->speed)
-		data->speed = speed;
-
-	return qcom_dwmac_sgmii_phy_calibrate(phy);
-}
-
 static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
 					 int submode,
 					 union phy_configure_opts *opts)

@@ -341,7 +331,6 @@ static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
 	.power_on	= qcom_dwmac_sgmii_phy_power_on,
 	.power_off	= qcom_dwmac_sgmii_phy_power_off,
 	.set_mode	= qcom_dwmac_sgmii_phy_set_mode,
-	.set_speed	= qcom_dwmac_sgmii_phy_set_speed,
 	.validate	= qcom_dwmac_sgmii_phy_validate,
 	.calibrate	= qcom_dwmac_sgmii_phy_calibrate,
 	.owner		= THIS_MODULE,

Signature · 1 line

2.47.3

Vladimir Oltean

Reviewed-by on v1 4/8

2026-02-27 15:39 UTC #5 lore raw

Re: [PATCH RESEND2 net-next 4/8] phy: qcom-sgmii-eth: remove .set_speed() implementation

Quoted 8 lines · Russell King (Oracle)

Now that the qcom-ethqos driver has migrated to use phy_set_mode_ext() rather than phy_set_speed() to configure the SerDes, the support for phy_set_speed() is now obsolete. Remove support for this method.
Using the MAC speed for the SerDes is never correct due to the PCS encoding. For SGMII and 2500BASE-X, the PCS uses 8B10B encoding, and so:

Quoted 7 lines

MAC rate * PCS output bits / PCS input bits = SerDes rate
   1000M   *       10        /       8        = 1250M
   2500M   *       10        /       8        = 3125M
Tested-by Mohd Ayaan Anwar <[email protected]>
Signed-off-by Russell King (Oracle) <[email protected]>
---

Russell King (Oracle)

2026-02-26 23:09 UTC #6 lore raw

PATCH 5/8 phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings

As established in the previous commit, using SPEED_1000 and SPEED_2500 does not make sense for a SerDes due to the PCS encoding that is used over the SerDes link, which inflates the data rate at the SerDes. Thus, the use of these constants in a SerDes driver is incorrect.

Since qcom-sgmii-eth no longer implements phy_set_speed(), but instead uses the PHY interface mode passed via the .set_mode() method, convert the driver to use the PHY interface mode internally to decide whether to configure the SerDes for 1.25Gbps or 3.125Gbps mode.

Signed-off-by Russell King (Oracle) <[email protected]>

---
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 41 ++++++++++++-----------
 1 file changed, 21 insertions(+), 20 deletions(-)

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +21 ~~-20~~

index dcfdb7d0e8ea..58ff15601206 100644
@@ -29,7 +29,7 @@
 struct qcom_dwmac_sgmii_phy_data {
 	struct regmap *regmap;
 	struct clk *refclk;
-	int speed;
+	phy_interface_t interface;
 };
 
 static void qcom_dwmac_sgmii_phy_init_1g(struct regmap *regmap)

@@ -223,15 +223,18 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
 	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
 	struct device *dev = phy->dev.parent;
 
-	switch (data->speed) {
-	case SPEED_10:
-	case SPEED_100:
-	case SPEED_1000:
+	switch (data->interface) {
+	case PHY_INTERFACE_MODE_SGMII:
+	case PHY_INTERFACE_MODE_1000BASEX:
+		/* 1.25Gbps mode */
 		qcom_dwmac_sgmii_phy_init_1g(data->regmap);
 		break;
-	case SPEED_2500:
+	case PHY_INTERFACE_MODE_2500BASEX:
+		/* 3.125Gbps mode */
 		qcom_dwmac_sgmii_phy_init_2p5g(data->regmap);
 		break;
+	default:
+		return -EINVAL;
 	}
 
 	if (qcom_dwmac_sgmii_phy_poll_status(data->regmap,

@@ -287,17 +290,15 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
 	return 0;
 }
 
-static int qcom_dwmac_sgmii_phy_speed(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
 {
 	if (mode != PHY_MODE_ETHERNET)
 		return -EINVAL;
 
 	if (submode == PHY_INTERFACE_MODE_SGMII ||
-	    submode == PHY_INTERFACE_MODE_1000BASEX)
-		return SPEED_1000;
-
-	if (submode == PHY_INTERFACE_MODE_2500BASEX)
-		return SPEED_2500;
+	    submode == PHY_INTERFACE_MODE_1000BASEX ||
+	    submode == PHY_INTERFACE_MODE_2500BASEX)
+		return submode;
 
 	return -EINVAL;
 }

@@ -306,14 +307,14 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
 					 int submode)
 {
 	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
-	int speed;
+	int interface;
 
-	speed = qcom_dwmac_sgmii_phy_speed(mode, submode);
-	if (speed < 0)
-		return speed;
+	interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
+	if (interface < 0)
+		return interface;
 
-	if (speed != data->speed)
-		data->speed = speed;
+	if (interface != data->interface)
+		data->interface = interface;
 
 	return qcom_dwmac_sgmii_phy_calibrate(phy);
 }

@@ -322,7 +323,7 @@ static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
 					 int submode,
 					 union phy_configure_opts *opts)
 {
-	int ret = qcom_dwmac_sgmii_phy_speed(mode, submode);
+	int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
 
 	return ret < 0 ? ret : 0;
 }

@@ -356,7 +357,7 @@ static int qcom_dwmac_sgmii_phy_probe(struct platform_device *pdev)
 	if (!data)
 		return -ENOMEM;
 
-	data->speed = SPEED_10;
+	data->interface = PHY_INTERFACE_MODE_SGMII;
 
 	base = devm_platform_ioremap_resource(pdev, 0);
 	if (IS_ERR(base))

Signature · 1 line

2.47.3

Vladimir Oltean

Reviewed-by on v1 5/8

2026-02-27 15:40 UTC #7 lore raw

Re: [PATCH RESEND2 net-next 5/8] phy: qcom-sgmii-eth: use PHY interface mode for SerDes settings

Quoted 5 lines · Russell King (Oracle)

As established in the previous commit, using SPEED_1000 and SPEED_2500 does not make sense for a SerDes due to the PCS encoding that is used over the SerDes link, which inflates the data rate at the SerDes. Thus, the use of these constants in a SerDes driver is incorrect.

Quoted 8 lines

Since qcom-sgmii-eth no longer implements phy_set_speed(), but instead uses the PHY interface mode passed via the .set_mode() method, convert the driver to use the PHY interface mode internally to decide whether to configure the SerDes for 1.25Gbps or 3.125Gbps mode.
Tested-by Mohd Ayaan Anwar <[email protected]>
Signed-off-by Russell King (Oracle) <[email protected]>
---

Russell King (Oracle)

2026-02-26 23:09 UTC #8 lore raw

PATCH 6/8 phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()

Now that qcom_dwmac_sgmii_phy_interface() only serves to validate the passed interface mode, combine it with qcom_dwmac_sgmii_phy_validate(), and use qcom_dwmac_sgmii_phy_validate() to validate the mode in qcom_dwmac_sgmii_phy_set_mode().

Signed-off-by Russell King (Oracle) <[email protected]>

---
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 27 +++++++++--------------
 1 file changed, 10 insertions(+), 17 deletions(-)

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +10 ~~-17~~

index 58ff15601206..6332ff291fdf 100644
@@ -290,7 +290,9 @@ static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)
 	return 0;
 }
 
-static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
+static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
+					 int submode,
+					 union phy_configure_opts *opts)
 {
 	if (mode != PHY_MODE_ETHERNET)
 		return -EINVAL;

@@ -298,7 +300,7 @@ static int qcom_dwmac_sgmii_phy_interface(enum phy_mode mode, int submode)
 	if (submode == PHY_INTERFACE_MODE_SGMII ||
 	    submode == PHY_INTERFACE_MODE_1000BASEX ||
 	    submode == PHY_INTERFACE_MODE_2500BASEX)
-		return submode;
+		return 0;
 
 	return -EINVAL;
 }

@@ -307,27 +309,18 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
 					 int submode)
 {
 	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
-	int interface;
+	int ret;
 
-	interface = qcom_dwmac_sgmii_phy_interface(mode, submode);
-	if (interface < 0)
-		return interface;
+	ret = qcom_dwmac_sgmii_phy_validate(phy, mode, submode, NULL);
+	if (ret)
+		return ret;
 
-	if (interface != data->interface)
-		data->interface = interface;
+	if (submode != data->interface)
+		data->interface = submode;
 
 	return qcom_dwmac_sgmii_phy_calibrate(phy);
 }
 
-static int qcom_dwmac_sgmii_phy_validate(struct phy *phy, enum phy_mode mode,
-					 int submode,
-					 union phy_configure_opts *opts)
-{
-	int ret = qcom_dwmac_sgmii_phy_interface(mode, submode);
-
-	return ret < 0 ? ret : 0;
-}
-
 static const struct phy_ops qcom_dwmac_sgmii_phy_ops = {
 	.power_on	= qcom_dwmac_sgmii_phy_power_on,
 	.power_off	= qcom_dwmac_sgmii_phy_power_off,

Signature · 1 line

2.47.3

Vladimir Oltean

Reviewed-by on v1 6/8

2026-02-27 15:42 UTC #9 lore raw

Re: [PATCH RESEND2 net-next 6/8] phy: qcom-sgmii-eth: remove qcom_dwmac_sgmii_phy_interface()

Quoted 8 lines · Russell King (Oracle)

Now that qcom_dwmac_sgmii_phy_interface() only serves to validate the passed interface mode, combine it with qcom_dwmac_sgmii_phy_validate(), and use qcom_dwmac_sgmii_phy_validate() to validate the mode in qcom_dwmac_sgmii_phy_set_mode().
Tested-by Mohd Ayaan Anwar <[email protected]>
Signed-off-by Russell King (Oracle) <[email protected]>
---

Russell King (Oracle)

2026-02-26 23:10 UTC #10 lore raw

PATCH 7/8 phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()

Allow any order of the .power_on() and .set_mode*() methods as per the recent discussion. This means phy_power_on() with this SerDes will now restore the previous setup without requiring a subsequent phy_set_mode*() call.

Signed-off-by Russell King (Oracle) <[email protected]>

---
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +13 -1

index 6332ff291fdf..f48faa2929a6 100644
@@ -271,8 +271,17 @@ static int qcom_dwmac_sgmii_phy_calibrate(struct phy *phy)
 static int qcom_dwmac_sgmii_phy_power_on(struct phy *phy)
 {
 	struct qcom_dwmac_sgmii_phy_data *data = phy_get_drvdata(phy);
+	int ret;
+
+	ret = clk_prepare_enable(data->refclk);
+	if (ret < 0)
+		return ret;
 
-	return clk_prepare_enable(data->refclk);
+	ret = qcom_dwmac_sgmii_phy_calibrate(phy);
+	if (ret < 0)
+		clk_disable_unprepare(data->refclk);
+
+	return ret;
 }
 
 static int qcom_dwmac_sgmii_phy_power_off(struct phy *phy)

@@ -318,6 +327,9 @@ static int qcom_dwmac_sgmii_phy_set_mode(struct phy *phy, enum phy_mode mode,
 	if (submode != data->interface)
 		data->interface = submode;
 
+	if (phy->power_count == 0)
+		return 0;
+
 	return qcom_dwmac_sgmii_phy_calibrate(phy);
 }

Signature · 1 line

2.47.3

Vladimir Oltean

Reviewed-by on v1 7/8

2026-02-27 15:37 UTC #11 lore raw

Re: [PATCH RESEND2 net-next 7/8] phy: qcom-sgmii-eth: relax order of .power_on() vs .set_mode*()

Quoted 8 lines · Russell King (Oracle)

Allow any order of the .power_on() and .set_mode*() methods as per the recent discussion. This means phy_power_on() with this SerDes will now restore the previous setup without requiring a subsequent phy_set_mode*() call.
Tested-by Mohd Ayaan Anwar <[email protected]>
Signed-off-by Russell King (Oracle) <[email protected]>
---

Russell King (Oracle)

2026-02-26 23:10 UTC #12 lore raw

PATCH 8/8 net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()

The call to phy_set_mode_ext() after phy_power_on() was a work-around for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on phy_power_on() but did not configure the PHY. Now that the SerDes driver fully configures the SerDes at phy_power_on(), there is no need to call phy_set_mode_ext() immediately afterwards.

This also means we no longer need to record the previous operating mode of the driver - this is up to the SerDes driver. In any case, the only thing that we care about is the SerDes provides the necessary clocks to the stmmac core to allow it to reset at this point. The actual mode is irrelevant at this point as the correct mode will be configured in ethqos_mac_finish_serdes() just before the network device is brought online.

Reviewed-by Mohd Ayaan Anwar <[email protected]>

Signed-off-by Russell King (Oracle) <[email protected]>

---
 .../stmicro/stmmac/dwmac-qcom-ethqos.c         | 18 ++----------------
 1 file changed, 2 insertions(+), 16 deletions(-)

drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c +2 ~~-16~~

index 8913f6f02b9e..cb1c074c2053 100644
@@ -105,7 +105,6 @@ struct qcom_ethqos {
 
 	struct clk *link_clk;
 	struct phy *serdes_phy;
-	phy_interface_t serdes_mode;
 	phy_interface_t phy_mode;
 
 	const struct ethqos_emac_por *rgmii_por;

@@ -648,17 +647,8 @@ static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
 		return ret;
 
 	ret = phy_power_on(ethqos->serdes_phy);
-	if (ret) {
-		phy_exit(ethqos->serdes_phy);
-		return ret;
-	}
-
-	ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
-			       ethqos->serdes_mode);
-	if (ret) {
-		phy_power_off(ethqos->serdes_phy);
+	if (ret)
 		phy_exit(ethqos->serdes_phy);
-	}
 
 	return ret;
 }

@@ -681,12 +671,9 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
 	qcom_ethqos_set_sgmii_loopback(ethqos, false);
 
 	if (interface == PHY_INTERFACE_MODE_SGMII ||
-	    interface == PHY_INTERFACE_MODE_2500BASEX) {
+	    interface == PHY_INTERFACE_MODE_2500BASEX)
 		ret = phy_set_mode_ext(ethqos->serdes_phy, PHY_MODE_ETHERNET,
 				       interface);
-		if (ret == 0)
-			ethqos->serdes_mode = interface;
-	}
 
 	return ret;
 }

@@ -839,7 +826,6 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
 		plat_dat->host_dma_width = data->dma_addr_width;
 
 	if (ethqos->serdes_phy) {
-		ethqos->serdes_mode = PHY_INTERFACE_MODE_SGMII;
 		plat_dat->serdes_powerup = qcom_ethqos_serdes_powerup;
 		plat_dat->serdes_powerdown  = qcom_ethqos_serdes_powerdown;
 	}

Signature · 1 line

2.47.3

Vladimir Oltean

Reviewed-by on v1 8/8

2026-02-27 15:31 UTC #13 lore raw

Re: [PATCH RESEND2 net-next 8/8] net: stmmac: qcom-ethqos: remove phy_set_mode_ext() after phy_power_on()

Quoted 14 lines · Russell King (Oracle)

The call to phy_set_mode_ext() after phy_power_on() was a work-around for the qcom-sgmii-eth SerDes driver that only re-enabled its clocks on phy_power_on() but did not configure the PHY. Now that the SerDes driver fully configures the SerDes at phy_power_on(), there is no need to call phy_set_mode_ext() immediately afterwards.
This also means we no longer need to record the previous operating mode of the driver - this is up to the SerDes driver. In any case, the only thing that we care about is the SerDes provides the necessary clocks to the stmmac core to allow it to reset at this point. The actual mode is irrelevant at this point as the correct mode will be configured in ethqos_mac_finish_serdes() just before the network device is brought online.

Quoted 4 lines

Reviewed-by Mohd Ayaan Anwar <[email protected]>
Tested-by Mohd Ayaan Anwar <[email protected]>
Signed-off-by Russell King (Oracle) <[email protected]>
---

Jakub Kicinski

maintainer

2026-02-27 01:26 UTC #14 lore raw

Quoted 1 line · On Thu, 26 Feb 2026 23:07:16 +0000 Russell King (Oracle) wrote:

Subject: [PATCH RESEND2 net-next 0/8] net: stmmac: qcom-ethqos: further serdes reorganisation

The only exception to the 24h rule is if a reviewer _asks_ you to repost ASAP. Maintainers also wait, there are no exceptions. Please don't do this again. Having to deal with multi-tier system of privileges and rules will make our (maintainers) job even more miserable than it already is.

Vladimir Oltean

2026-02-27 15:48 UTC #15 lore raw

Quoted 15 lines · Russell King (Oracle)

This is part 2 of the qcom-ethqos series, part 1 has now been merged.
This part of the series focuses on the generic PHY driver, but these changes have dependencies on the ethernet driver, hence why it will need to go via net-next. Furthermore, subsequent changes depend on these patches.
The underlying ideas here are:
- get rid of the driver using phy_set_speed() with SPEED_1000 and SPEED_2500 which makes no sense for an ethernet SerDes due to the PCS 8B10B data encoding, which inflates the data rate at the SerDes compared to the MAC. This is replaced with phy_set_mode_ext().
- allow phy_power_on() / phy_set_mode*() to be called in any order.

Quoted 11 lines

Mohd has tested this series, but it would be great to get acks/reviews from the generic PHY maintainers.

 .../ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c    | 31 +++--------
 drivers/phy/qualcomm/phy-qcom-sgmii-eth.c          | 62 +++++++++++++++++-----
 2 files changed, 57 insertions(+), 36 deletions(-)

Signature · 2 lines

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Reiterating Vinod's request to netdev maintainers from here, just because it's easy to get lost in the multiple patch versions:
https://lore.kernel.org/netdev/aaGgWUpM2A5y11Wh@vaman/

Can we please get a tag to pull into linux-phy when this gets merged in net-next? I'm also working on a patch set for phy-next which will conflict with this series.

Russell King (Oracle)

author

2026-02-28 00:11 UTC #16 lore raw

In reply to Vladimir Oltean

Quoted 9 lines · Russell King (Oracle)

This is part 2 of the qcom-ethqos series, part 1 has now been merged.
This part of the series focuses on the generic PHY driver, but these changes have dependencies on the ethernet driver, hence why it will need to go via net-next. Furthermore, subsequent changes depend on these patches.
The underlying ideas here are:

Quoted 8 lines

- get rid of the driver using phy_set_speed() with SPEED_1000 and SPEED_2500 which makes no sense for an ethernet SerDes due to the PCS 8B10B data encoding, which inflates the data rate at the SerDes compared to the MAC. This is replaced with phy_set_mode_ext().
- allow phy_power_on() / phy_set_mode*() to be called in any order.
Mohd has tested this series, but it would be great to get acks/reviews from the generic PHY maintainers.

So, PW says "changes requested" - please let me know what changes have been requested.

The AI review for patch 7 says:

This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.

Should this commit include:

Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")

which is _wrong_, this isn't a bug fix.

So, in light of AI review being incorrect, my comment about re-sending due to the AI review is no longer relevant, and no changes are required. The only thing that's necessary is to have Vinod's ack added to patches 4, 5, 6 and 7, as he gave them against the very first posting of these on Wednesday. This is despite waiting the required 24h before sending the first resend.

Signature · 2 lines

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Jakub Kicinski

maintainer

2026-02-28 00:55 UTC #17 lore raw

Quoted 9 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:

The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.

Quoted 5 lines

Should this commit include:
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.

Yes, that's what I thought but then I saw the other thread..

Quoted 2 lines

So, in light of AI review being incorrect, my comment about re-sending due to the AI review is no longer relevant, and no changes are required.

Okay.

pw-bot: new

Quoted 4 lines

The only thing that's necessary is to have Vinod's ack added to patches 4, 5, 6 and 7, as he gave them against the very first posting of these on Wednesday. This is despite waiting the required 24h before sending the first resend.

Jakub Kicinski

maintainer

2026-02-28 16:31 UTC #18 lore raw

Quoted 10 lines · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:

Quoted 9 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:
The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.

Quoted 7 lines

Quoted 5 lines
Should this commit include:
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.
Yes, that's what I thought but then I saw the other thread..

Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?

Could you, perhaps, send us a PR with this on top of Linus's tree (a resolution of the inevitable conflict with net-next would be helpful too).

Or do we give up on the tag?

Vladimir Oltean

2026-03-01 00:14 UTC #19 lore raw

Quoted 19 lines · Jakub Kicinski

Quoted 10 lines · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:
Quoted 9 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:
The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.
Quoted 7 lines
Quoted 5 lines
Should this commit include:
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.
Yes, that's what I thought but then I saw the other thread..

Quoted 8 lines

Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?
Could you, perhaps, send us a PR with this on top of Linus's tree (a resolution of the inevitable conflict with net-next would be helpful too).
Or do we give up on the tag?

Actually, I think it's mainly me who wants a stable tag. I'm working on a series for phy-next which will conflict with this hunk from Russell's patch 1:

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +1 -0

index 5b1c82459c12..4ea3dce7719f 100644
@@ -7,6 +7,7 @@
 #include <linux/ethtool.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/phy.h>
 #include <linux/phy/phy.h> // this gets renamed to <linux/phy/phy-provider.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>

If there's no other way to provide a stable tag other than on v7.0-rc1 (like for example a snapshot of current net-next/main), which I didn't know wouldn't be possible, then I think going with the route of fewer/ more trivial merge conflicts makes sense.

Jakub Kicinski

maintainer

2026-03-01 00:32 UTC #20 lore raw

Quoted 5 lines · On Sun, 1 Mar 2026 02:14:53 +0200 Vladimir Oltean wrote:

Quoted 5 lines
Quoted 1 line
Yes, that's what I thought but then I saw the other thread..
Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?

Quoted 7 lines

Quoted 5 lines
Could you, perhaps, send us a PR with this on top of Linus's tree (a resolution of the inevitable conflict with net-next would be helpful too).
Or do we give up on the tag?
Actually, I think it's mainly me who wants a stable tag.

Ah :)

Quoted 8 lines

I'm working on a series for phy-next which will conflict with this hunk from Russell's patch 1:
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +0 -0
index 5b1c82459c12..4ea3dce7719f 100644

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c line 13

Quoted 7 lines

drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +1 -0

@@ -7,6 +7,7 @@
 #include <linux/ethtool.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/phy.h>
 #include <linux/phy/phy.h> // this gets renamed to <linux/phy/phy-provider.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>

That's not too bad.. if that's the extent of the conflict (which is probably hard to predict at rc2?) we could let linux-next handle it. Of course assuming Vinod is okay with us merging Russell's entire series.

Quoted 4 lines

If there's no other way to provide a stable tag other than on v7.0-rc1 (like for example a snapshot of current net-next/main), which I didn't know wouldn't be possible, then I think going with the route of fewer/ more trivial merge conflicts makes sense.

To be clear, it's only about having a common ancestor, I wasn't actually planning on making y'all a tag. I'd just apply the series on top of v7.0-rc1 and merge them in. Then anyone can tag the relevant commit in net-next or use as a base for their own work.

I haven't looked how bad the conflict would be if Russell's work was rebased on Linus's tree. If the delta is not too bad, and we can just resolve the merge conflict when pulling it into net-next. That's probably the cleanest.

I don't recall us ever making a "dirty tag" on net-next which would propagate few 100s of netdev patches into someone else's tree :S IDK how Linus would react. It's the least good option IMO.

Vladimir Oltean

2026-03-01 12:08 UTC #21 lore raw

Quoted 18 lines · Jakub Kicinski

Quoted 8 lines
I'm working on a series for phy-next which will conflict with this hunk from Russell's patch 1:
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +0 -0
index 5b1c82459c12..4ea3dce7719f 100644
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c line 13
Quoted 7 lines
drivers/phy/qualcomm/phy-qcom-sgmii-eth.c +1 -0
@@ -7,6 +7,7 @@
 #include <linux/ethtool.h>
 #include <linux/module.h>
 #include <linux/of.h>
+#include <linux/phy.h>
 #include <linux/phy/phy.h> // this gets renamed to <linux/phy/phy-provider.h>
 #include <linux/platform_device.h>
 #include <linux/regmap.h>
That's not too bad.. if that's the extent of the conflict (which is probably hard to predict at rc2?) we could let linux-next handle it.

Yeah, I can't predict the future beyond that.

Quoted 13 lines

Of course assuming Vinod is okay with us merging Russell's entire series.
Quoted 4 lines
If there's no other way to provide a stable tag other than on v7.0-rc1 (like for example a snapshot of current net-next/main), which I didn't know wouldn't be possible, then I think going with the route of fewer/ more trivial merge conflicts makes sense.
To be clear, it's only about having a common ancestor, I wasn't actually planning on making y'all a tag. I'd just apply the series on top of v7.0-rc1 and merge them in. Then anyone can tag the relevant commit in net-next or use as a base for their own work.

Quoted 4 lines

I haven't looked how bad the conflict would be if Russell's work was rebased on Linus's tree. If the delta is not too bad, and we can just resolve the merge conflict when pulling it into net-next. That's probably the cleanest.

I don't think applying the current series on top of v7.0-rc1 would be a good idea. It depends upon this series in a very non-trivial way, basically building upon it:
https://patchwork.kernel.org/project/netdevbpf/list/?series=1056390&state=*

For example, that previous series introduces ethqos_mac_finish_serdes()
- absent in v7.0-rc1 - and this series modifies it (in current net-next/main, it is calling phy_set_speed(), and after this series, it is calling phy_set_mode_ext()).

By comparison, the merge conflict with me renaming <linux/phy/phy.h> would be smaller.

Quoted 3 lines

I don't recall us ever making a "dirty tag" on net-next which would propagate few 100s of netdev patches into someone else's tree :S IDK how Linus would react. It's the least good option IMO.

Just for my curiosity, what difference would it make to him?

Jakub Kicinski

maintainer

2026-03-02 23:29 UTC #22 lore raw

Quoted 5 lines · On Sun, 1 Mar 2026 14:08:24 +0200 Vladimir Oltean wrote:

Quoted 3 lines
I don't recall us ever making a "dirty tag" on net-next which would propagate few 100s of netdev patches into someone else's tree :S IDK how Linus would react. It's the least good option IMO.
Just for my curiosity, what difference would it make to him?

The PHY PR will contain a bunch of networking code.

Russell King (Oracle)

author

2026-03-01 13:42 UTC #23 lore raw

Quoted 27 lines · Vladimir Oltean

Quoted 26 lines · Jakub Kicinski
Quoted 10 lines · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:
Quoted 9 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:
The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.
Quoted 7 lines
Quoted 5 lines
Should this commit include:
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.
Yes, that's what I thought but then I saw the other thread..
Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?
Could you, perhaps, send us a PR with this on top of Linus's tree (a resolution of the inevitable conflict with net-next would be helpful too).

Quoted 5 lines

Quoted 1 line
Or do we give up on the tag?
Actually, I think it's mainly me who wants a stable tag. I'm working on a series for phy-next which will conflict with this hunk from Russell's patch 1:

Is this because of the issues I raised with the quality of generic PHY API implementation by drivers?

Signature · 2 lines

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Vladimir Oltean

2026-03-01 14:10 UTC #24 lore raw

Quoted 28 lines · Russell King (Oracle)

Quoted 27 lines · Vladimir Oltean
Quoted 26 lines · Jakub Kicinski
Quoted 10 lines · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:
Quoted 9 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:
The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.
Quoted 7 lines
Quoted 5 lines
Should this commit include:
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.
Yes, that's what I thought but then I saw the other thread..
Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?
Could you, perhaps, send us a PR with this on top of Linus's tree (a resolution of the inevitable conflict with net-next would be helpful too).

Quoted 8 lines

Quoted 5 lines
Quoted 1 line
Or do we give up on the tag?
Actually, I think it's mainly me who wants a stable tag. I'm working on a series for phy-next which will conflict with this hunk from Russell's patch 1:
Is this because of the issues I raised with the quality of generic PHY API implementation by drivers?

I don't think the issue you are referring to is so much a "quality" one as it is a "lack of requirements" one, but to answer - not necessarily. Eventually I'll get to Ethernet Generic PHY interop too, but I saw as first actionable step to clearly delineate what is PHY provider API from what is PHY consumer API, in an attempt to stop PHY consumers from poking inside struct phy.

To improve the interop situation, apart from patching drivers, I plan to introduce a new CONFIG_GENERIC_PHY_EXPERIMENTAL (meaning: enable for development, don't enable for production, but drivers required to work with EXPERIMENTAL turned on) which would make a few changes:
- make the .validate() function pointer be a required dependency for .set_mode().
- call .validate() before calling .set_mode(), and reject the call if the mode and submode don't pass validation
- swap the power state before calling .set_mode(), and restore it afterwards

Some of these changes do need that consumer/provider API separation I was talking about. For example, consumers should not look at the power count of the PHY (some of them currently do; not to mention they do this without proper locking). They should only concern themselves with whether *they* powered the PHY up themselves.

Russell King (Oracle)

author

2026-03-01 13:39 UTC #25 lore raw

In reply to Jakub Kicinski

Quoted 13 lines · Jakub Kicinski

Quoted 12 lines · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:
Quoted 11 lines · On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:
The AI review for patch 7 says:
This commit fixes a bug but lacks a Fixes: tag. The commit modifies behavior introduced in 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods") by making phy_power_on() call qcom_dwmac_sgmii_phy_calibrate() to restore the previous setup, and by making qcom_dwmac_sgmii_phy_set_mode() check if the PHY is powered on before attempting calibration.
Should this commit include:

Quoted 8 lines

Quoted 5 lines
Quoted 3 lines
Fixes 360000820ae2 ("phy: qcom-sgmii-eth: add .set_mode() and .validate() methods")
which is _wrong_, this isn't a bug fix.
Yes, that's what I thought but then I saw the other thread..
Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?

The problem will be that this series has dependencies on the first batch of qcom-ethqos patches, particularly:
cd0aa6515350 ("net: stmmac: pass interface mode into fix_mac_speed() method")
b560938163db ("net: stmmac: qcom-ethqos: pass phy interface mode to configs")
fb42f19e671f ("net: stmmac: qcom-ethqos: move SerDes speed configuration")

which enables the change in the third patch of this series - and without the third patch, none of the following patches in this series can be applied.

I'm not sure what to suggest either.

Signature · 2 lines

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

Jakub Kicinski

maintainer

2026-03-02 23:57 UTC #26 lore raw

Quoted 16 lines · On Sun, 1 Mar 2026 13:39:25 +0000 Russell King (Oracle) wrote:

Quoted 5 lines · Jakub Kicinski
Quoted 1 line · On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:
Yes, that's what I thought but then I saw the other thread..
Trying to apply this now but stmmac parts don't apply on Linus's tree, and Vinod wants a tag :( What do we do?
The problem will be that this series has dependencies on the first batch of qcom-ethqos patches, particularly:
cd0aa6515350 ("net: stmmac: pass interface mode into fix_mac_speed() method")
b560938163db ("net: stmmac: qcom-ethqos: pass phy interface mode to configs")
fb42f19e671f ("net: stmmac: qcom-ethqos: move SerDes speed configuration")

Quoted 5 lines

which enables the change in the third patch of this series - and without the third patch, none of the following patches in this series can be applied.
I'm not sure what to suggest either.

Alright, I think the best we can do here is to merge patch 2 in a "stable tag" way. The rest will have to go via net-next.

I applied patch 2, Russell please rebase the rest on net-next and repost. Patch 2 should disappear. I don't want to merge it now as is without an explicit nod from Vinod. He did ask for a tag and we won't provide one.

Vinod / Vladimir, to merge the "stable tag" of patch 2:

tag_name=phy-qcom-sgmii-eth-add-set_mode-and-validate-methods
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git tag $tag_name 0e8147f4da00
git merge $tag_name
git tag -d $tag_name

I think this should work.

Vladimir Oltean

2026-03-09 15:44 UTC #27 lore raw

Quoted 10 lines · Jakub Kicinski

Alright, I think the best we can do here is to merge patch 2 in a "stable tag" way. The rest will have to go via net-next.
I applied patch 2, Russell please rebase the rest on net-next and repost. Patch 2 should disappear. I don't want to merge it now as is without an explicit nod from Vinod. He did ask for a tag and we won't provide one.
Vinod / Vladimir, to merge the "stable tag" of patch 2:

Quoted 7 lines

tag_name=phy-qcom-sgmii-eth-add-set_mode-and-validate-methods
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git tag $tag_name 0e8147f4da00
git merge $tag_name
git tag -d $tag_name
I think this should work.

Thanks for the anonymous tag. I think you mean sha1sum 4ff5801f45b494ad8251a16ec06c9f303ed3b9a0, not 0e8147f4da00.

Jakub Kicinski

maintainer

2026-03-09 23:51 UTC #28 lore raw

Quoted 17 lines · On Mon, 9 Mar 2026 17:44:32 +0200 Vladimir Oltean wrote:

Quoted 16 lines · Jakub Kicinski
Alright, I think the best we can do here is to merge patch 2 in a "stable tag" way. The rest will have to go via net-next.
I applied patch 2, Russell please rebase the rest on net-next and repost. Patch 2 should disappear. I don't want to merge it now as is without an explicit nod from Vinod. He did ask for a tag and we won't provide one.
Vinod / Vladimir, to merge the "stable tag" of patch 2:
tag_name=phy-qcom-sgmii-eth-add-set_mode-and-validate-methods
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git tag $tag_name 0e8147f4da00
git merge $tag_name
git tag -d $tag_name

Quoted 4 lines

Quoted 1 line
I think this should work.
Thanks for the anonymous tag. I think you mean sha1sum 4ff5801f45b494ad8251a16ec06c9f303ed3b9a0, not 0e8147f4da00.

Ah, I guess I misunderstood what Linus once told me. I thought the signed tag remain in the history once merged even if no longer named.

Anyway, I pushed the tag to kuba/linux.git phy-qcom-sgmii-eth-add-set_mode-and-validate-methods if you prefer the real / signed thing. I don't like having these random tags in netdev trees.

[email protected]

2026-03-03 00:00 UTC #29 lore raw