Re: [PATCH RESEND2 net-next 0/8] net: stmmac: qcom-ethqos: further serdes reorganisation
From: Vladimir Oltean <olteanv@gmail.com>
Date: 2026-03-01 00:14:59
Also in:
linux-arm-kernel, linux-arm-msm, linux-phy
Subsystem:
arm/qualcomm mailing list, generic phy framework, the rest · Maintainers:
Vinod Koul, Linus Torvalds
On Sat, Feb 28, 2026 at 08:31:11AM -0800, Jakub Kicinski wrote:
On Fri, 27 Feb 2026 16:55:56 -0800 Jakub Kicinski wrote:quoted
On Sat, 28 Feb 2026 00:11:29 +0000 Russell King (Oracle) wrote:quoted
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.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?
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:
diff --git a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
index 5b1c82459c12..4ea3dce7719f 100644
--- a/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c
+++ b/drivers/phy/qualcomm/phy-qcom-sgmii-eth.c@@ -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.