[PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

Hi,

This series is currently the last of the phylink PCS conversion for
stmmac. This series contains changes that will cause potential breakage,
so I suggest to netdev maintainers that it is only applied if there is
a significant response from testers using the PCS.

Paritcularly, dwmac-qcom-ethqos.c users need to test this, since this
platform glue driver manipulates the PCS state. Patch 2 is designed to
print a warning to the kernel log if this glue driver calls
stmmac_pcs_ctrl_ane() to set the AN state differently to how phylink
has set it. If this happens, we need to do some pre-work to prevent
these prints.

 .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  7 +++++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  7 +++++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c   | 29 +++++++++++++++++++---
 drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h   |  8 +++++-
 4 files changed, 44 insertions(+), 7 deletions(-)

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

[PATCH net-next 1/3] net: stmmac: configure AN control according to phylink

[Russell King (Oracle)]

Provide phylink with the autonegotiation capabilities for this PCS, and
configure the PCS's AN settings according to phylink's requested
requirements.

This may cause regressions.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
 .../net/ethernet/stmicro/stmmac/stmmac_pcs.c  | 23 +++++++++++++++++--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
index e2f531c11986..77d38936d898 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
@@ -2,6 +2,15 @@
 #include "stmmac.h"
 #include "stmmac_pcs.h"
 
+static unsigned int dwmac_integrated_pcs_inband_caps(struct phylink_pcs *pcs,
+						     phy_interface_t interface)
+{
+	if (interface != PHY_INTERFACE_MODE_SGMII)
+		return 0;
+
+	return LINK_INBAND_ENABLE | LINK_INBAND_DISABLE;
+}
+
 static int dwmac_integrated_pcs_enable(struct phylink_pcs *pcs)
 {
 	struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
@@ -32,13 +41,23 @@ static int dwmac_integrated_pcs_config(struct phylink_pcs *pcs,
 				       bool permit_pause_to_mac)
 {
 	struct stmmac_pcs *spcs = phylink_pcs_to_stmmac_pcs(pcs);
-
-	dwmac_ctrl_ane(spcs->base, 0, 1, spcs->priv->hw->reverse_sgmii_enable);
+	void __iomem *an_control = spcs->base + GMAC_AN_CTRL(0);
+	u32 ctrl;
+
+	ctrl = readl(an_control) & ~(GMAC_AN_CTRL_ANE | GMAC_AN_CTRL_SGMRAL);
+	if (spcs->priv->hw->reverse_sgmii_enable)
+		ctrl |= GMAC_AN_CTRL_SGMRAL | GMAC_AN_CTRL_ANE;
+	else if (neg_mode == PHYLINK_PCS_NEG_INBAND_ENABLED)
+		ctrl |= GMAC_AN_CTRL_ANE;
+	else
+		ctrl |= GMAC_AN_CTRL_SGMRAL;
+	writel(ctrl, an_control);
 
 	return 0;
 }
 
 static const struct phylink_pcs_ops dwmac_integrated_pcs_ops = {
+	.pcs_inband_caps = dwmac_integrated_pcs_inband_caps,
 	.pcs_enable = dwmac_integrated_pcs_enable,
 	.pcs_disable = dwmac_integrated_pcs_disable,
 	.pcs_get_state = dwmac_integrated_pcs_get_state,
-- 
2.47.3

[PATCH net-next 2/3] net: stmmac: report PCS configuration changes

[Russell King (Oracle)]

Report if/when qcom-ethqos changes the PCS configuration. With phylink
now setting the PCS configuration, there should be no need for drivers
to change this.

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
index cda93894168e..e42a98162c2b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
@@ -109,6 +109,7 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
 				  bool srgmi_ral)
 {
 	u32 value = readl(ioaddr + GMAC_AN_CTRL(reg));
+	u32 old = value;
 
 	/* Enable and restart the Auto-Negotiation */
 	if (ane)
@@ -122,6 +123,10 @@ static inline void dwmac_ctrl_ane(void __iomem *ioaddr, u32 reg, bool ane,
 	if (srgmi_ral)
 		value |= GMAC_AN_CTRL_SGMRAL;
 
+	if (old != value)
+		pr_warn("dwmac: PCS configuration changed from phylink by glue, please report: 0x%08x -> 0x%08x\n",
+			old, value);
+
 	writel(value, ioaddr + GMAC_AN_CTRL(reg));
 }
 #endif /* __STMMAC_PCS_H__ */
-- 
2.47.3

[PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces

[Russell King (Oracle)]

Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 7 ++++++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c    | 7 ++++++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c     | 6 ++++--
 drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h     | 3 ++-
 4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index a2ae136d2c0e..0d85902bafd0 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -24,12 +24,17 @@
 
 static int dwmac1000_pcs_init(struct stmmac_priv *priv)
 {
+	phy_interface_t mode;
+
 	if (!priv->dma_cap.pcs)
 		return 0;
 
+	mode = PHY_INTERFACE_MODE_SGMII;
+
 	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
 					  GMAC_INT_DISABLE_PCSLINK |
-					  GMAC_INT_DISABLE_PCSAN);
+					  GMAC_INT_DISABLE_PCSAN,
+					  &mode, 1);
 }
 
 static void dwmac1000_core_init(struct mac_device_info *hw,
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index a4282fd7c3c7..af9a336a32e6 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -24,11 +24,16 @@
 
 static int dwmac4_pcs_init(struct stmmac_priv *priv)
 {
+	phy_interface_t mode;
+
 	if (!priv->dma_cap.pcs)
 		return 0;
 
+	mode = PHY_INTERFACE_MODE_SGMII;
+
 	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
-					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE);
+					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
+					  &mode, 1);
 }
 
 static void dwmac4_core_init(struct mac_device_info *hw,
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
index 77d38936d898..5293c52cf7af 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c
@@ -65,7 +65,8 @@ static const struct phylink_pcs_ops dwmac_integrated_pcs_ops = {
 };
 
 int stmmac_integrated_pcs_init(struct stmmac_priv *priv, unsigned int offset,
-			       u32 int_mask)
+			       u32 int_mask, const phy_interface_t *modes,
+			       int num)
 {
 	struct stmmac_pcs *spcs;
 
@@ -78,7 +79,8 @@ int stmmac_integrated_pcs_init(struct stmmac_priv *priv, unsigned int offset,
 	spcs->int_mask = int_mask;
 	spcs->pcs.ops = &dwmac_integrated_pcs_ops;
 
-	__set_bit(PHY_INTERFACE_MODE_SGMII, spcs->pcs.supported_interfaces);
+	while (num--)
+		__set_bit(*modes++, spcs->pcs.supported_interfaces);
 
 	priv->integrated_pcs = spcs;
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
index e42a98162c2b..36da4dab4f8f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h
@@ -63,7 +63,8 @@ phylink_pcs_to_stmmac_pcs(struct phylink_pcs *pcs)
 }
 
 int stmmac_integrated_pcs_init(struct stmmac_priv *priv, unsigned int offset,
-			       u32 int_mask);
+			       u32 int_mask, const phy_interface_t *modes,
+			       int num);
 
 /**
  * dwmac_pcs_isr - TBI, RTBI, or SGMII PHY ISR
-- 
2.47.3

Re: [PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces

[Maxime Chevallier]

Hello Russell,

On 25/10/2025 22:48, Russell King (Oracle) wrote:
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>

Maybe this needs a commit log, even a small one ? :(

Maxime

Re: [PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces

[Russell King (Oracle)]

On Tue, Oct 28, 2025 at 11:16:00AM +0100, Maxime Chevallier wrote:
> Hello Russell,
> 
> On 25/10/2025 22:48, Russell King (Oracle) wrote:
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> 
> Maybe this needs a commit log, even a small one ? :(

Thanks for giving Jakub a reason to mark this "changes required." :D
I'm not really expecting this to be merged as-is. So why didn't I
post it as RFC? Too many people see "RFC" as a sign to ignore the
patch series. Some people claim that "RFC" means it isn't ready and
thus isn't worth reviewing/testing/etc. I say to those people... I
can learn their game and work around their behaviour.

Yes, it will need a better commit log, but what I'm much much more
interested in is having people who are using the integrated PCS (in
SGMII mode as that's all we support) to test this, especially
dwmac-qcom-ethqos folk.

The 2.5G support was submitted by Sneh Shah, and my attempts to make
contact have resulted in no response.

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

Re: [PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces

[Russell King (Oracle)]

On Tue, Oct 28, 2025 at 10:35:00AM +0000, Russell King (Oracle) wrote:
> Thanks for giving Jakub a reason to mark this "changes required." :D
> I'm not really expecting this to be merged as-is. So why didn't I
> post it as RFC? Too many people see "RFC" as a sign to ignore the
> patch series. Some people claim that "RFC" means it isn't ready and
> thus isn't worth reviewing/testing/etc. I say to those people... I
> can learn their game and work around their behaviour.
> 
> Yes, it will need a better commit log, but what I'm much much more
> interested in is having people who are using the integrated PCS (in
> SGMII mode as that's all we support) to test this, especially
> dwmac-qcom-ethqos folk.
> 
> The 2.5G support was submitted by Sneh Shah, and my attempts to make
> contact have resulted in no response.

I should add - I'm expecting dwmac-qcom-ethqos to reveal that we need
to include 2500BASE-X for the PCS, and possibly 1000BASE-X as well
(which in dwmac terms uses the TBI interface to a platform integrator
provided serdes block.)

The most important thing is for people with the hardware that would be
affected by these patches to test. However, I'm expecting no testing
feedback from such people based on experience - it seems stmmac is rife
for "throw code over the wall into mainline and run away" behaviour. :(

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

Re: [PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces

[Maxime Chevallier]

On 28/10/2025 11:35, Russell King (Oracle) wrote:
> On Tue, Oct 28, 2025 at 11:16:00AM +0100, Maxime Chevallier wrote:
>> Hello Russell,
>>
>> On 25/10/2025 22:48, Russell King (Oracle) wrote:
>>> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>>
>> Maybe this needs a commit log, even a small one ? :(
> 
> Thanks for giving Jakub a reason to mark this "changes required." :D
> I'm not really expecting this to be merged as-is. So why didn't I
> post it as RFC? Too many people see "RFC" as a sign to ignore the
> patch series. Some people claim that "RFC" means it isn't ready and
> thus isn't worth reviewing/testing/etc. I say to those people... I
> can learn their game and work around their behaviour.

Yeah this series needs to be tested and discussed, I am rounding up all
my stmmac platforms in my ever-growing pile of HW as I'm building my
own test farm, but all the glue stmmac boards I have are the ones that
are fairly well maintained (imx-dwmac, dwmac-stm32, sdwmac-socfpga...).
I don't have any stmmac that use the integrated PCS :(

> 
> Yes, it will need a better commit log, but what I'm much much more
> interested in is having people who are using the integrated PCS (in
> SGMII mode as that's all we support) to test this, especially
> dwmac-qcom-ethqos folk.

Let's hope we can get some test indeed :/ 

Maxime

> The 2.5G support was submitted by Sneh Shah, and my attempts to make
> contact have resulted in no response.
> 

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

Hi Russell,

On Sat, Oct 25, 2025 at 09:47:37PM +0100, Russell King (Oracle) wrote:
> Hi,
> 
> This series is currently the last of the phylink PCS conversion for
> stmmac. This series contains changes that will cause potential breakage,
> so I suggest to netdev maintainers that it is only applied if there is
> a significant response from testers using the PCS.
> 
> Paritcularly, dwmac-qcom-ethqos.c users need to test this, since this
> platform glue driver manipulates the PCS state. Patch 2 is designed to
> print a warning to the kernel log if this glue driver calls
> stmmac_pcs_ctrl_ane() to set the AN state differently to how phylink
> has set it. If this happens, we need to do some pre-work to prevent
> these prints.
> 
>  .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  7 +++++-
>  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  7 +++++-
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c   | 29 +++++++++++++++++++---
>  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h   |  8 +++++-
>  4 files changed, 44 insertions(+), 7 deletions(-)
> 

Thank you for the recent stmmac cleanup patches. I apologize for the
late reply. I had limited time to test due to some urgent tasks at work.
This is a long email, please bear with me.

I have the following devices on which I try to test whatever I can (both
of them have the same GMAC core with an integrated PCS, both use
phy-mode="2500base-x"):
  - Qualcomm QCS9100 Ride R3 (2xAQR115C PHYs)
  - Qualcomm IQ8 EVK (QCA808X PHY) - this is the same board for which I
    had posted [1] to resolve its issue with advertising only 2.5G

# Patch Series: net: stmmac: phylink PCS conversion
I tested this series soon after it got merged to net-next, probably when
I tested out the hwif.c cleanups. A summary:
  - QCS9100 Ride R3 - no issues found.
  - IQ8 EVK - same behavior as without this patch, i.e. 2.5G was working
    fine, other speeds aren't advertised.

However, this might have been expected as both boards are using
2500Base-X whereas the integrated PCS changes are limited to SGMII.
*Sidenote*: I was able to get 2.5G and lower speeds to work on the IQ8
EVK after adding an additional case for 2500Base-X on top of your patch.

# Patch Series (current): net: stmmac: phylink PCS conversion part 3
(dodgy stuff)
  - QCS9100 Ride R3 - functionality seems to be fine (again, probably
    due to the changes only affecting SGMII mode). However, the warning
    added in patch 2 comes up whenever there's a speed change (I added
    an additional WARN_ON to check the sequence):
  	[   61.663685] qcom-ethqos 23000000.ethernet eth0: Link is Down
	[   66.235461] dwmac: PCS configuration changed from phylink by glue, please report: 0x00001000 -> 0x00000000
	[   66.245488] ------------[ cut here ]------------
	[   66.250240] WARNING: CPU: 0 PID: 71 at drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h:130 dwmac4_ctrl_ane+0x68/0x84 [stmmac]
	[   66.369320] CPU: 0 UID: 0 PID: 71 Comm: kworker/u33:2 Tainted: G        W           6.18.0-rc2-00357-g6c595c926e8f-dirty #1 PREEMPT
	[   66.381547] Tainted: [W]=WARN
	[   66.384608] Hardware name: Qualcomm Technologies, Inc. Lemans Ride Rev3 (DT)
	[   66.391848] Workqueue: events_power_efficient phylink_resolve
	[   66.397770] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	[   66.404920] pc : dwmac4_ctrl_ane+0x68/0x84 [stmmac]
	[   66.409949] lr : dwmac4_ctrl_ane+0x68/0x84 [stmmac]
	[   66.414975] sp : ffff80008124bc20
	[   66.418387] x29: ffff80008124bc20 x28: 0000000000000001 x27: 0000000000000000
	[   66.425720] x26: 0000000000000001 x25: 0000000000000001 x24: 0000000008032000
	[   66.433053] x23: ffff0000b1148a00 x22: 0000000008032000 x21: 00000000000009c4
	[   66.440386] x20: ffff8000847300e0 x19: 0000000000000000 x18: 00000000ffffffff
	[   66.447719] x17: 657220657361656c x16: 70202c65756c6720 x15: 7962206b6e696c79
	[   66.455053] x14: 6870206d6f726620 x13: 3030303030303030 x12: ffffc6e220a06cf0
	[   66.462386] x11: 0000000000000486 x10: 0000000000000018 x9 : ffffc6e220a06cf0
	[   66.469718] x8 : 00000000ffffefff x7 : ffffc6e220a5ecf0 x6 : 0000000000000000
	[   66.477051] x5 : ffff000ec7437408 x4 : 0000000000000001 x3 : 0000000000000000
	[   66.484384] x2 : 0000000000000000 x1 : ffff0000812a8000 x0 : 000000000000005e
	[   66.491718] Call trace:
	[   66.494245]  dwmac4_ctrl_ane+0x68/0x84 [stmmac] (P)
	[   66.499273]  ethqos_configure_sgmii+0x114/0x1c0 [dwmac_qcom_ethqos]
	[   66.505711]  ethqos_fix_mac_speed+0x6c/0xec [dwmac_qcom_ethqos]
	[   66.511795]  stmmac_mac_link_up+0xd4/0x370 [stmmac]
	[   66.516823]  phylink_resolve+0x150/0x604
	[   66.520861]  process_one_work+0x148/0x28c
	[   66.524999]  worker_thread+0x2d8/0x3d8
	[   66.528855]  kthread+0x134/0x208
	[   66.532181]  ret_from_fork+0x10/0x20
	[   66.535870] ---[ end trace 0000000000000000 ]---
	[   66.540750] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx

  - IQ8 EVK - I will try to test it soon and share the results.

Would it be helpful to change the phy-mode to SGMII for some further testing?

	Ayaan
---
[1] https://lore.kernel.org/netdev/20250914-qca808x_rate_match-v1-1-0f9e6a331c3b@oss.qualcomm.com/T/#u

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Wed, Oct 29, 2025 at 02:42:39AM +0530, Mohd Ayaan Anwar wrote:
> Hi Russell,
> 
> On Sat, Oct 25, 2025 at 09:47:37PM +0100, Russell King (Oracle) wrote:
> > Hi,
> > 
> > This series is currently the last of the phylink PCS conversion for
> > stmmac. This series contains changes that will cause potential breakage,
> > so I suggest to netdev maintainers that it is only applied if there is
> > a significant response from testers using the PCS.
> > 
> > Paritcularly, dwmac-qcom-ethqos.c users need to test this, since this
> > platform glue driver manipulates the PCS state. Patch 2 is designed to
> > print a warning to the kernel log if this glue driver calls
> > stmmac_pcs_ctrl_ane() to set the AN state differently to how phylink
> > has set it. If this happens, we need to do some pre-work to prevent
> > these prints.
> > 
> >  .../net/ethernet/stmicro/stmmac/dwmac1000_core.c   |  7 +++++-
> >  drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c  |  7 +++++-
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.c   | 29 +++++++++++++++++++---
> >  drivers/net/ethernet/stmicro/stmmac/stmmac_pcs.h   |  8 +++++-
> >  4 files changed, 44 insertions(+), 7 deletions(-)
> > 
> 
> Thank you for the recent stmmac cleanup patches. I apologize for the
> late reply. I had limited time to test due to some urgent tasks at work.
> This is a long email, please bear with me.

Thanks for the feedback.

> I have the following devices on which I try to test whatever I can (both
> of them have the same GMAC core with an integrated PCS, both use
> phy-mode="2500base-x"):
>   - Qualcomm QCS9100 Ride R3 (2xAQR115C PHYs)
>   - Qualcomm IQ8 EVK (QCA808X PHY) - this is the same board for which I
>     had posted [1] to resolve its issue with advertising only 2.5G
> 
> # Patch Series: net: stmmac: phylink PCS conversion
> I tested this series soon after it got merged to net-next, probably when
> I tested out the hwif.c cleanups. A summary:
>   - QCS9100 Ride R3 - no issues found.
>   - IQ8 EVK - same behavior as without this patch, i.e. 2.5G was working
>     fine, other speeds aren't advertised.

Great.

> However, this might have been expected as both boards are using
> 2500Base-X whereas the integrated PCS changes are limited to SGMII.
> *Sidenote*: I was able to get 2.5G and lower speeds to work on the IQ8
> EVK after adding an additional case for 2500Base-X on top of your patch.
> 
> # Patch Series (current): net: stmmac: phylink PCS conversion part 3
> (dodgy stuff)
>   - QCS9100 Ride R3 - functionality seems to be fine (again, probably
>     due to the changes only affecting SGMII mode). However, the warning
>     added in patch 2 comes up whenever there's a speed change (I added
>     an additional WARN_ON to check the sequence):
>   	[   61.663685] qcom-ethqos 23000000.ethernet eth0: Link is Down
> 	[   66.235461] dwmac: PCS configuration changed from phylink by glue, please report: 0x00001000 -> 0x00000000

That's clearing ANE, turning off AN. This will be because we're not
using the PCS code for 2500base-X.

Can you try:

1. in stmmac_check_pcs_mode(), as a hack, add:

	if (priv->dma_cap.pcs && interface == PHY_INTERFACE_MODE_2500BASEX)
		priv->hw->pcs = STMMAC_PCS_SGMII;

2. with part 3 added, please change dwmac4_pcs_init() to:

	phy_interface_t modes[] = {
		PHY_INTERFACE_MODE_SGMII,
		PHY_INTERFACE_MODE_2500BASEX,
	};
	...
	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
					  modes, ARRAY_SIZE(modes));

This will cause the integrated PCS to also be used for 2500BASE-X.

3. modify dwmac_integrated_pcs_inband_caps() to return
   LINK_INBAND_DISABLE for PHY_INTERFACE_MODE_2500BASEX.

This should result in the warning going away for you.

I'm not suggesting that this is a final solution.

Please note, however, that the stmmac driver does not support on-the-fly
reconfiguration of the PHY-side interface as it stands (and questionable
whether it ever will do.) The hardware samples phy_intf_sel inputs to
the core at reset (including, I believe, software reset) which
configures the core to use the appropriate PHY interface. Performing
any kind of reset is very disruptive to the core - likely even causes
the PTP timekeeping block to be reset. In my opinion, PHYs that switch
their host-side interface were not considered when this IP was
designed.

To get stmmac's driver to a state where it _can_ do this if desired is
going to take a massive amount of work due to all these glue drivers.

I do have patches which introduce a new callback into platform drivers
to set the phy_intf_sel inputs from the core code... but that's some
way off before it can be merged (too many other patches I need to get
in first.)

I haven't noticed qcom-ethqos using a register field that corresponds
with the phy_intf_sel inputs, so even in that series, this driver
doesn't get converted.

Thanks.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

Hi Russell,
On Wed, Oct 29, 2025 at 09:22:49AM +0000, Russell King (Oracle) wrote:
> > # Patch Series (current): net: stmmac: phylink PCS conversion part 3
> > (dodgy stuff)
> >   - QCS9100 Ride R3 - functionality seems to be fine (again, probably
> >     due to the changes only affecting SGMII mode). However, the warning
> >     added in patch 2 comes up whenever there's a speed change (I added
> >     an additional WARN_ON to check the sequence):
> >   	[   61.663685] qcom-ethqos 23000000.ethernet eth0: Link is Down
> > 	[   66.235461] dwmac: PCS configuration changed from phylink by glue, please report: 0x00001000 -> 0x00000000
> 
> That's clearing ANE, turning off AN. This will be because we're not
> using the PCS code for 2500base-X.
> 
> Can you try:
> 
> 1. in stmmac_check_pcs_mode(), as a hack, add:
> 
> 	if (priv->dma_cap.pcs && interface == PHY_INTERFACE_MODE_2500BASEX)
> 		priv->hw->pcs = STMMAC_PCS_SGMII;
> 
> 2. with part 3 added, please change dwmac4_pcs_init() to:
> 
> 	phy_interface_t modes[] = {
> 		PHY_INTERFACE_MODE_SGMII,
> 		PHY_INTERFACE_MODE_2500BASEX,
> 	};
> 	...
> 	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
> 					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
> 					  modes, ARRAY_SIZE(modes));
> 
> This will cause the integrated PCS to also be used for 2500BASE-X.
> 
> 3. modify dwmac_integrated_pcs_inband_caps() to return
>    LINK_INBAND_DISABLE for PHY_INTERFACE_MODE_2500BASEX.
> 
> This should result in the warning going away for you.
> 
> I'm not suggesting that this is a final solution.

Here are my observations (with phylink logs if it helps):

1. Link up at 2.5G
[    8.429331] qcom-ethqos 23000000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[    8.436610] qcom-ethqos 23000000.ethernet:   DWMAC4/5
[   10.395163] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
[   10.407759] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[   10.418507] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=343)
[   10.428003] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
[   10.461072] qcom-ethqos 23000000.ethernet eth0: Enabling Safety Features
[   10.478201] qcom-ethqos 23000000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[   10.487449] qcom-ethqos 23000000.ethernet eth0: registered PTP clock
[   10.494010] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
[   10.494014] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
[   10.494018] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
[   10.494021] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
[   10.494024] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
[   10.508824] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[   15.099693] qcom-ethqos 23000000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
[   15.122160] dwmac: PCS configuration changed from phylink by glue, please report: 0x00041000 -> 0x00040000
[   15.140458] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
[   15.140939] stmmac_pcs: Link Up

As I understand it, the glue layer disables ANE at 2.5G.

2. Link up at 1G:
[    6.261112] qcom-ethqos 23000000.ethernet: User ID: 0x20, Synopsys ID: 0x52
[    6.261116] qcom-ethqos 23000000.ethernet:   DWMAC4/5
[    9.051693] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
[    9.061261] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[    9.061266] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=305)
[    9.061269] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
[    9.080324] qcom-ethqos 23000000.ethernet eth0: Enabling Safety Features
[    9.114550] qcom-ethqos 23000000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[    9.123870] qcom-ethqos 23000000.ethernet eth0: registered PTP clock
[    9.130412] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
[    9.138726] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
[    9.138729] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
[    9.138731] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
[    9.164930] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
[    9.194764] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[   12.542771] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
[   12.553890] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
[   12.561617] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
[   12.570220] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
[   12.578367] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
[   12.599545] stmmac_pcs: ANE process completed
[   12.607910] dwmac: PCS configuration changed from phylink by glue, please report: 0x00041000 -> 0x00041200
[   12.616188] stmmac_pcs: Link Up
[   12.634351] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[   12.639575] stmmac_pcs: ANE process completed
[   12.647498] stmmac_pcs: Link Up

This is probably fine since Bit(9) is self-clearing and its value just
after this is 0x00041000.

> 
> Please note, however, that the stmmac driver does not support on-the-fly
> reconfiguration of the PHY-side interface as it stands (and questionable
> whether it ever will do.) The hardware samples phy_intf_sel inputs to
> the core at reset (including, I believe, software reset) which
> configures the core to use the appropriate PHY interface. Performing
> any kind of reset is very disruptive to the core - likely even causes
> the PTP timekeeping block to be reset. In my opinion, PHYs that switch
> their host-side interface were not considered when this IP was
> designed.
> 
> To get stmmac's driver to a state where it _can_ do this if desired is
> going to take a massive amount of work due to all these glue drivers.
> 
> I do have patches which introduce a new callback into platform drivers
> to set the phy_intf_sel inputs from the core code... but that's some
> way off before it can be merged (too many other patches I need to get
> in first.)
> 
> I haven't noticed qcom-ethqos using a register field that corresponds
> with the phy_intf_sel inputs, so even in that series, this driver
> doesn't get converted.

True, I think qcom-ethqos's behaviour is different than other glue
drivers. For both SGMII and 2500Base-X, it uses the same
ethqos_configure_sgmii() function which is just changing the SerDes
speed and PCS and depending on the current speed.

	Ayaan

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Thu, Oct 30, 2025 at 06:50:51PM +0530, Mohd Ayaan Anwar wrote:
> Hi Russell,
> On Wed, Oct 29, 2025 at 09:22:49AM +0000, Russell King (Oracle) wrote:
> > > # Patch Series (current): net: stmmac: phylink PCS conversion part 3
> > > (dodgy stuff)
> > >   - QCS9100 Ride R3 - functionality seems to be fine (again, probably
> > >     due to the changes only affecting SGMII mode). However, the warning
> > >     added in patch 2 comes up whenever there's a speed change (I added
> > >     an additional WARN_ON to check the sequence):
> > >   	[   61.663685] qcom-ethqos 23000000.ethernet eth0: Link is Down
> > > 	[   66.235461] dwmac: PCS configuration changed from phylink by glue, please report: 0x00001000 -> 0x00000000
> > 
> > That's clearing ANE, turning off AN. This will be because we're not
> > using the PCS code for 2500base-X.
> > 
> > Can you try:
> > 
> > 1. in stmmac_check_pcs_mode(), as a hack, add:
> > 
> > 	if (priv->dma_cap.pcs && interface == PHY_INTERFACE_MODE_2500BASEX)
> > 		priv->hw->pcs = STMMAC_PCS_SGMII;
> > 
> > 2. with part 3 added, please change dwmac4_pcs_init() to:
> > 
> > 	phy_interface_t modes[] = {
> > 		PHY_INTERFACE_MODE_SGMII,
> > 		PHY_INTERFACE_MODE_2500BASEX,
> > 	};
> > 	...
> > 	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
> > 					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
> > 					  modes, ARRAY_SIZE(modes));
> > 
> > This will cause the integrated PCS to also be used for 2500BASE-X.
> > 
> > 3. modify dwmac_integrated_pcs_inband_caps() to return
> >    LINK_INBAND_DISABLE for PHY_INTERFACE_MODE_2500BASEX.
> > 
> > This should result in the warning going away for you.
> > 
> > I'm not suggesting that this is a final solution.
> 
> Here are my observations (with phylink logs if it helps):
> 
> 1. Link up at 2.5G
> [    8.429331] qcom-ethqos 23000000.ethernet: User ID: 0x20, Synopsys ID: 0x52
> [    8.436610] qcom-ethqos 23000000.ethernet:   DWMAC4/5
> [   10.395163] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
> [   10.407759] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
> [   10.418507] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=343)
> [   10.428003] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
> [   10.461072] qcom-ethqos 23000000.ethernet eth0: Enabling Safety Features
> [   10.478201] qcom-ethqos 23000000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
> [   10.487449] qcom-ethqos 23000000.ethernet eth0: registered PTP clock
> [   10.494010] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
> [   10.494014] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
> [   10.494018] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
> [   10.494021] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
> [   10.494024] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> [   10.508824] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [   15.099693] qcom-ethqos 23000000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
> [   15.122160] dwmac: PCS configuration changed from phylink by glue, please report: 0x00041000 -> 0x00040000
> [   15.140458] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
> [   15.140939] stmmac_pcs: Link Up
> 
> As I understand it, the glue layer disables ANE at 2.5G.

Please try again, this time with snps,ps-speed removed from the DT
description for the interface. This property was a buggy attempt at
reverse-SGMII, and incorrectly produced a warning if not specified
when the integrated PCS was being used. The "bug" in the attempt
with this was a typo in each MAC core driver, where specifying this
set the TE (transmit enable) bit rather than the TC (transmit
configuration) bit in the MAC control register. All the rest of the
setup for reverse-SGMII mode was in place, but this bug made the
entire thing useless.

The "invalid port speed" warning that results if this property is
not set to 10, 100 or 1000 is another bug - only if this warning
is printed will the "normal" mode be selected.

Since the PCS series 1 and 2 have been merged into net-next, it
will be safe to submit patches removing these properties from your
DT files, without fear of this warning appearing.

> 2. Link up at 1G:
> [    6.261112] qcom-ethqos 23000000.ethernet: User ID: 0x20, Synopsys ID: 0x52
> [    6.261116] qcom-ethqos 23000000.ethernet:   DWMAC4/5
> [    9.051693] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
> [    9.061261] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
> [    9.061266] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=305)
> [    9.061269] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
> [    9.080324] qcom-ethqos 23000000.ethernet eth0: Enabling Safety Features
> [    9.114550] qcom-ethqos 23000000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
> [    9.123870] qcom-ethqos 23000000.ethernet eth0: registered PTP clock
> [    9.130412] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
> [    9.138726] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
> [    9.138729] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
> [    9.138731] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
> [    9.164930] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> [    9.194764] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> [   12.542771] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
> [   12.553890] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
> [   12.561617] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
> [   12.570220] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
> [   12.578367] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
> [   12.599545] stmmac_pcs: ANE process completed
> [   12.607910] dwmac: PCS configuration changed from phylink by glue, please report: 0x00041000 -> 0x00041200
> [   12.616188] stmmac_pcs: Link Up
> [   12.634351] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> [   12.639575] stmmac_pcs: ANE process completed
> [   12.647498] stmmac_pcs: Link Up
> 
> This is probably fine since Bit(9) is self-clearing and its value just
> after this is 0x00041000.

Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
but the PHY says to the MAC "this is how I'm operating" and the MAC says
"okay". Nothing more.

I'm afraid the presence of snps,ps-speed, this disrupts the test.

> > I haven't noticed qcom-ethqos using a register field that corresponds
> > with the phy_intf_sel inputs, so even in that series, this driver
> > doesn't get converted.
> 
> True, I think qcom-ethqos's behaviour is different than other glue
> drivers. For both SGMII and 2500Base-X, it uses the same
> ethqos_configure_sgmii() function which is just changing the SerDes
> speed and PCS and depending on the current speed.

Right, so it leaves the SGMIIRAL block in place, hoping that it
will be operating with no symbol replication.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > 
> > This is probably fine since Bit(9) is self-clearing and its value just
> > after this is 0x00041000.
> 
> Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
> but the PHY says to the MAC "this is how I'm operating" and the MAC says
> "okay". Nothing more.
> 
> I'm afraid the presence of snps,ps-speed, this disrupts the test.

Note also that testing a 10M link, 100M, 1G and finally 100M again in
that order would also be interesting given my question about the RGMII
register changes that configure_sgmii does.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

On Thu, Oct 30, 2025 at 03:22:12PM +0000, Russell King (Oracle) wrote:
> On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > > 
> > > This is probably fine since Bit(9) is self-clearing and its value just
> > > after this is 0x00041000.
> > 
> > Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
> > but the PHY says to the MAC "this is how I'm operating" and the MAC says
> > "okay". Nothing more.
> > 
> > I'm afraid the presence of snps,ps-speed, this disrupts the test.
> 
> Note also that testing a 10M link, 100M, 1G and finally 100M again in
> that order would also be interesting given my question about the RGMII
> register changes that configure_sgmii does.
> 

Despite several attempts, I couldn't get 10M to work. There is a link-up
but the data path is broken. I checked the net-next tip and it's broken
there as well.

Oddly enough, configure_sgmii is called with its speed argument set to
1000:
[   12.305488] qcom-ethqos 23040000.ethernet eth0: phy link up sgmii/10Mbps/Half/pause/off/nolpi
[   12.315233] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/sgmii
[   12.322965] qcom-ethqos 23040000.ethernet eth0: interface sgmii inband modes: pcs=00 phy=03
[   12.331586] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/sgmii
[   12.339738] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/pause adv=0000000,00000000,00000000,00000000 pause=00
[   12.355113] qcom-ethqos 23040000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
[   12.363196] qcom-ethqos 23040000.ethernet eth0: Link is Up - 10Mbps/Half - flow control off

Nevertheless, I manually updated RGMII_CONFIG_SGMII_CLK_DVDR to 0x31 and
did not observe any issues with 100M and 1G (and 10M was still broken).

I tried to dig around for information about the particular register
update and found basically the same thing as Konrad.
1. B(18:10) - RGMII_CONFIG_SGMII_CLK_DVDR - It defines programming value
for Divider 20. This field is used for 10Mbs mode operation in RMII and
set value of 9'd 19.
2. The programming guide for this IOMACRO core mentions that the field
needs to be set to 0x31 for 10M link.

I am inclined to believe that the register description is a typo (as the
reset value of this field is anyways 0x13). The 0x31 value is
recommended for only 10M. For other speeds, it mentions the default
value of 0x13.

However, that does raise the question of why setting the field to 0x31
is not impacting 100M/1G. I will try to investigate more on this. But
right now I am trying to prioritize on verifying 100M/1G/2.5G links as
those should be more common. After that, there's still the issue of IQ8
only advertising support for 2.5G.

	Ayaan

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 02:28:24PM +0530, Mohd Ayaan Anwar wrote:
> On Thu, Oct 30, 2025 at 03:22:12PM +0000, Russell King (Oracle) wrote:
> > On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > > > 
> > > > This is probably fine since Bit(9) is self-clearing and its value just
> > > > after this is 0x00041000.
> > > 
> > > Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
> > > but the PHY says to the MAC "this is how I'm operating" and the MAC says
> > > "okay". Nothing more.
> > > 
> > > I'm afraid the presence of snps,ps-speed, this disrupts the test.
> > 
> > Note also that testing a 10M link, 100M, 1G and finally 100M again in
> > that order would also be interesting given my question about the RGMII
> > register changes that configure_sgmii does.
> > 
> 
> Despite several attempts, I couldn't get 10M to work. There is a link-up
> but the data path is broken. I checked the net-next tip and it's broken
> there as well.
> 
> Oddly enough, configure_sgmii is called with its speed argument set to
> 1000:
> [   12.305488] qcom-ethqos 23040000.ethernet eth0: phy link up sgmii/10Mbps/Half/pause/off/nolpi
> [   12.315233] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/sgmii
> [   12.322965] qcom-ethqos 23040000.ethernet eth0: interface sgmii inband modes: pcs=00 phy=03
> [   12.331586] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/sgmii
> [   12.339738] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/pause adv=0000000,00000000,00000000,00000000 pause=00
> [   12.355113] qcom-ethqos 23040000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
> [   12.363196] qcom-ethqos 23040000.ethernet eth0: Link is Up - 10Mbps/Half - flow control off

If you have "rate matching" enabled (signified by "pause" in the mode=
part of phylink_mac_config), then the MAC gets told the maximum speed for
the PHY interface, which for Cisco SGMII is 1G. This is intentional to
support PHYs that _really_ do use rate matching. Your PHY isn't using it,
and rate matching for SGMII is pointless.

Please re-run testing with phy-mode = "sgmii" which you've tested
before without your rate-matching patch to the PHY driver, so the
system knows the _correct_ parameters for these speeds.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

On Mon, Nov 03, 2025 at 09:52:38AM +0000, Russell King (Oracle) wrote:
> On Mon, Nov 03, 2025 at 02:28:24PM +0530, Mohd Ayaan Anwar wrote:
> > On Thu, Oct 30, 2025 at 03:22:12PM +0000, Russell King (Oracle) wrote:
> > > On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > > > > 
> > > > > This is probably fine since Bit(9) is self-clearing and its value just
> > > > > after this is 0x00041000.
> > > > 
> > > > Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
> > > > but the PHY says to the MAC "this is how I'm operating" and the MAC says
> > > > "okay". Nothing more.
> > > > 
> > > > I'm afraid the presence of snps,ps-speed, this disrupts the test.
> > > 
> > > Note also that testing a 10M link, 100M, 1G and finally 100M again in
> > > that order would also be interesting given my question about the RGMII
> > > register changes that configure_sgmii does.
> > > 
> > 
> > Despite several attempts, I couldn't get 10M to work. There is a link-up
> > but the data path is broken. I checked the net-next tip and it's broken
> > there as well.
> > 
> > Oddly enough, configure_sgmii is called with its speed argument set to
> > 1000:
> > [   12.305488] qcom-ethqos 23040000.ethernet eth0: phy link up sgmii/10Mbps/Half/pause/off/nolpi
> > [   12.315233] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/sgmii
> > [   12.322965] qcom-ethqos 23040000.ethernet eth0: interface sgmii inband modes: pcs=00 phy=03
> > [   12.331586] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/sgmii
> > [   12.339738] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/pause adv=0000000,00000000,00000000,00000000 pause=00
> > [   12.355113] qcom-ethqos 23040000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
> > [   12.363196] qcom-ethqos 23040000.ethernet eth0: Link is Up - 10Mbps/Half - flow control off
> 
> If you have "rate matching" enabled (signified by "pause" in the mode=
> part of phylink_mac_config), then the MAC gets told the maximum speed for
> the PHY interface, which for Cisco SGMII is 1G. This is intentional to
> support PHYs that _really_ do use rate matching. Your PHY isn't using it,
> and rate matching for SGMII is pointless.
> 
> Please re-run testing with phy-mode = "sgmii" which you've tested
> before without your rate-matching patch to the PHY driver, so the
> system knows the _correct_ parameters for these speeds.
> 
Sorry, I forgot to mention that all the recent testing is being done on
QCS9100 Ride R3 which has the AQR115C PHY.

My rate-matching patch was for IQ8 which has the QCA808X PHY. I am
putting its testing on hold until we sort everything out on QCS9100
first.

So, for AQR115C, what should be the way forward? It has support for rate
matching. For 10M should I remove its .get_rate_matching callback?

	Ayaan

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 03:48:53PM +0530, Mohd Ayaan Anwar wrote:
> My rate-matching patch was for IQ8 which has the QCA808X PHY. I am
> putting its testing on hold until we sort everything out on QCS9100
> first.
> 
> So, for AQR115C, what should be the way forward? It has support for rate
> matching. For 10M should I remove its .get_rate_matching callback?

Yes, AQR115C has support for rate matching, but it depends how the
firmware is configured. Different firmwares for this PHY default to
different settings for this.

Some operate at a fixed speed on the host interface and do rate
matching. Others don't. The registers in the PHY can be reprogrammed
to change this behaviour and the PHY reset to change the provisioned
firmware's behaviour, but mainline doesn't have that code.

If you enable debugging in drivers/net/phy/aquantia/aquantia_main.c,
then aqr_gen2_read_global_syscfg() will print its configuration for
each speed via:

	"Media speed %d uses host interface %s with %s\n"

messages. Unfortunately, aqr_gen2_get_rate_matching() does not take
account of this configuration, and just assumes they're all the
same (reporting rate adaption for 2500BASE-X and 10GBASE-R interfaces.)

One thing occurs to me is maybe your PHY firmware is provisioned for
rate adaption with the 2500BASE-X interface for 1G and 100M speeds,
but for 10M, it's using SGMII. The above messages will tell us.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Vladimir Oltean]

On Mon, Nov 03, 2025 at 03:48:53PM +0530, Mohd Ayaan Anwar wrote:
> On Mon, Nov 03, 2025 at 09:52:38AM +0000, Russell King (Oracle) wrote:
> > On Mon, Nov 03, 2025 at 02:28:24PM +0530, Mohd Ayaan Anwar wrote:
> > > On Thu, Oct 30, 2025 at 03:22:12PM +0000, Russell King (Oracle) wrote:
> > > > On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > > > > > 
> > > > > > This is probably fine since Bit(9) is self-clearing and its value just
> > > > > > after this is 0x00041000.
> > > > > 
> > > > > Yes, and bit 9 doesn't need to be set at all. SGMII isn't "negotiation"
> > > > > but the PHY says to the MAC "this is how I'm operating" and the MAC says
> > > > > "okay". Nothing more.
> > > > > 
> > > > > I'm afraid the presence of snps,ps-speed, this disrupts the test.
> > > > 
> > > > Note also that testing a 10M link, 100M, 1G and finally 100M again in
> > > > that order would also be interesting given my question about the RGMII
> > > > register changes that configure_sgmii does.
> > > > 
> > > 
> > > Despite several attempts, I couldn't get 10M to work. There is a link-up
> > > but the data path is broken. I checked the net-next tip and it's broken
> > > there as well.
> > > 
> > > Oddly enough, configure_sgmii is called with its speed argument set to
> > > 1000:
> > > [   12.305488] qcom-ethqos 23040000.ethernet eth0: phy link up sgmii/10Mbps/Half/pause/off/nolpi
> > > [   12.315233] qcom-ethqos 23040000.ethernet eth0: major config, requested phy/sgmii
> > > [   12.322965] qcom-ethqos 23040000.ethernet eth0: interface sgmii inband modes: pcs=00 phy=03
> > > [   12.331586] qcom-ethqos 23040000.ethernet eth0: major config, active phy/outband/sgmii
> > > [   12.339738] qcom-ethqos 23040000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/pause adv=0000000,00000000,00000000,00000000 pause=00
> > > [   12.355113] qcom-ethqos 23040000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
> > > [   12.363196] qcom-ethqos 23040000.ethernet eth0: Link is Up - 10Mbps/Half - flow control off
> > 
> > If you have "rate matching" enabled (signified by "pause" in the mode=
> > part of phylink_mac_config), then the MAC gets told the maximum speed for
> > the PHY interface, which for Cisco SGMII is 1G. This is intentional to
> > support PHYs that _really_ do use rate matching. Your PHY isn't using it,
> > and rate matching for SGMII is pointless.
> > 
> > Please re-run testing with phy-mode = "sgmii" which you've tested
> > before without your rate-matching patch to the PHY driver, so the
> > system knows the _correct_ parameters for these speeds.
> > 
> Sorry, I forgot to mention that all the recent testing is being done on
> QCS9100 Ride R3 which has the AQR115C PHY.
> 
> My rate-matching patch was for IQ8 which has the QCA808X PHY. I am
> putting its testing on hold until we sort everything out on QCS9100
> first.
> 
> So, for AQR115C, what should be the way forward? It has support for rate
> matching. For 10M should I remove its .get_rate_matching callback?
> 
> 	Ayaan

As Russell partially pointed out, there are several assumptions in the
Aquantia PHY driver and in phylink, three of them being that:
- rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
  PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
- if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
  pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
  that interface
- if rate matching is used, the PHY is configured to use it for all
  media speeds <= phylink_interface_max_speed(link_state.interface)

Those assumptions are not validated very well against the ground truth
from the PHY provisioning, so the next step would be for us to see that
directly.

Please turn this print from aqr_gen2_read_global_syscfg() into something
visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():

		phydev_dbg(phydev,
			   "Media speed %d uses host interface %s with %s\n",
			   syscfg->speed, phy_modes(syscfg->interface),
			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
			   "unrecognized rate adaptation type");

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> 
> As Russell partially pointed out, there are several assumptions in the
> Aquantia PHY driver and in phylink, three of them being that:
> - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
>   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
>   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
>   that interface
> - if rate matching is used, the PHY is configured to use it for all
>   media speeds <= phylink_interface_max_speed(link_state.interface)
> 
> Those assumptions are not validated very well against the ground truth
> from the PHY provisioning, so the next step would be for us to see that
> directly.
> 
> Please turn this print from aqr_gen2_read_global_syscfg() into something
> visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> 
> 		phydev_dbg(phydev,
> 			   "Media speed %d uses host interface %s with %s\n",
> 			   syscfg->speed, phy_modes(syscfg->interface),
> 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> 			   "unrecognized rate adaptation type");

Thanks. Looks like rate adaptation is only provisioned for 10M, which
matches my observation where phylink passes the exact speeds for
100/1000/2500 but 1000 for 10M.

[    9.449107] Aquantia AQR115C stmmac-0:08: Media speed 10 uses host interface sgmii with rate adaptation through flow control
[    9.462025] Aquantia AQR115C stmmac-0:08: Media speed 100 uses host interface sgmii with no rate adaptation
[    9.479897] Aquantia AQR115C stmmac-0:08: Media speed 1000 uses host interface sgmii with no rate adaptation
[    9.499634] Aquantia AQR115C stmmac-0:08: Media speed 2500 uses host interface 2500base-x with no rate adaptation
[    9.516342] Aquantia AQR115C stmmac-0:08: Media speed 5000 uses host interface 10gbase-r with rate adaptation through flow control
[    9.534045] Aquantia AQR115C stmmac-0:08: Media speed 10000 uses host interface 10gbase-r with no rate adaptation
[    9.587889] qcom-ethqos 23040000.ethernet eth0: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=304)

	Ayaan

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 04:50:03PM +0530, Mohd Ayaan Anwar wrote:
> On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> > 
> > As Russell partially pointed out, there are several assumptions in the
> > Aquantia PHY driver and in phylink, three of them being that:
> > - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
> >   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> > - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
> >   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
> >   that interface
> > - if rate matching is used, the PHY is configured to use it for all
> >   media speeds <= phylink_interface_max_speed(link_state.interface)
> > 
> > Those assumptions are not validated very well against the ground truth
> > from the PHY provisioning, so the next step would be for us to see that
> > directly.
> > 
> > Please turn this print from aqr_gen2_read_global_syscfg() into something
> > visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> > 
> > 		phydev_dbg(phydev,
> > 			   "Media speed %d uses host interface %s with %s\n",
> > 			   syscfg->speed, phy_modes(syscfg->interface),
> > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> > 			   "unrecognized rate adaptation type");
> 
> Thanks. Looks like rate adaptation is only provisioned for 10M, which
> matches my observation where phylink passes the exact speeds for
> 100/1000/2500 but 1000 for 10M.

Hmm, I wonder what the PHY is doing for that then. stmmac will be
programmed to read the Cisco SGMII in-band control word, and use
that to determine whether symbol replication for slower speeds is
being used.

If AQR115C is indicating 10M in the in-band control word, but is
actually operating the link at 1G speed, things are not going to
work, and I would say the PHY is broken to be doing that. The point
of the SGMII in-band control word is to tell the MAC about the
required symbol replication on the link for transmitting the slower
data rates over the link.

stmmac unfortunately doesn't give access to the raw Cisco SGMII
in-band control word. However, reading register 0xf8 bits 31:16 for
dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
1 = 100M, 0 = 10M.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Vladimir Oltean]

[-- Attachment #1: Type: text/plain, Size: 4620 bytes --]

On Mon, Nov 03, 2025 at 11:43:23AM +0000, Russell King (Oracle) wrote:
> On Mon, Nov 03, 2025 at 04:50:03PM +0530, Mohd Ayaan Anwar wrote:
> > On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> > > 
> > > As Russell partially pointed out, there are several assumptions in the
> > > Aquantia PHY driver and in phylink, three of them being that:
> > > - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
> > >   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> > > - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
> > >   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
> > >   that interface
> > > - if rate matching is used, the PHY is configured to use it for all
> > >   media speeds <= phylink_interface_max_speed(link_state.interface)
> > > 
> > > Those assumptions are not validated very well against the ground truth
> > > from the PHY provisioning, so the next step would be for us to see that
> > > directly.
> > > 
> > > Please turn this print from aqr_gen2_read_global_syscfg() into something
> > > visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> > > 
> > > 		phydev_dbg(phydev,
> > > 			   "Media speed %d uses host interface %s with %s\n",
> > > 			   syscfg->speed, phy_modes(syscfg->interface),
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> > > 			   "unrecognized rate adaptation type");
> > 
> > Thanks. Looks like rate adaptation is only provisioned for 10M, which
> > matches my observation where phylink passes the exact speeds for
> > 100/1000/2500 but 1000 for 10M.
> 
> Hmm, I wonder what the PHY is doing for that then. stmmac will be
> programmed to read the Cisco SGMII in-band control word, and use
> that to determine whether symbol replication for slower speeds is
> being used.
> 
> If AQR115C is indicating 10M in the in-band control word, but is
> actually operating the link at 1G speed, things are not going to
> work, and I would say the PHY is broken to be doing that. The point
> of the SGMII in-band control word is to tell the MAC about the
> required symbol replication on the link for transmitting the slower
> data rates over the link.
> 
> stmmac unfortunately doesn't give access to the raw Cisco SGMII
> in-band control word. However, reading register 0xf8 bits 31:16 for
> dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
> information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
> 1 = 100M, 0 = 10M.

It might be Linux who is forcing the AQR115C into the nonsensical
behaviour of advertising 10M in the SGMII control word while
simultanously forcing the PHY MII to operate at 1G with flow control
for the 10M media speed.

We don't control the latter, but we do control the former:
aqr_gen2_config_inband(), if given modes == LINK_INBAND_ENABLE, will
enable in-band for all media speeds that use PHY_INTERFACE_MODE_SGMII.
Regardless of how the PHY was provisioned for each media speed, and
especially regardless of rate matching settings, this function will
uniformly set the same in-band enabled/disabled setting for all media
speeds using the same host interface.

If dwmac_integrated_pcs_inband_caps(), as per Russell's patch 1/3,
reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE, and if
aqr_gen2_inband_caps() also reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE,
then we're giving phylink_pcs_neg_mode() all the tools it needs to shoot
itself in the foot, and select LINK_INBAND_ENABLE.

The judgement call in the Aquantia PHY driver was mine, as documented in
commit 5d59109d47c0 ("net: phy: aquantia: report and configure in-band
autoneg capabilities"). The idea being that the configuration would have
been unsupportable anyway given the question that the framework asks:
"does the PHY use in-band for SGMII, or does it not?"

Assuming the configuration at 10Mbps wasn't always broken, there's only
one way to know how it was supposed to work: more dumping of the initial
provisioning, prior to our modification in aqr_gen2_config_inband().
Ayaan, please re-print the same info with this new untested patch applied.
I am going to assume that in-band autoneg isn't enabled in the unmodified
provisioning, at least for 10M.

Russell's request for the integrated PCS status is also a good parallel
confirmation that yes, we've entered a mode where the PHY advertises
SGMII replication at 10M.

[-- Attachment #2: 0001-net-phy-aquantia-add-inband-setting-to-the-aqr_gen2_.patch --]
[-- Type: text/x-diff, Size: 1972 bytes --]

From b91162e5dae8e20b477999c4f2fcdb98c219d663 Mon Sep 17 00:00:00 2001
From: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Mon, 3 Nov 2025 14:03:55 +0200
Subject: [PATCH] net: phy: aquantia: add inband setting to the
 aqr_gen2_read_global_syscfg() print

Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
---
 drivers/net/phy/aquantia/aquantia_main.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/aquantia/aquantia_main.c b/drivers/net/phy/aquantia/aquantia_main.c
index 41f3676c7f1e..f06b7b51bb7d 100644
--- a/drivers/net/phy/aquantia/aquantia_main.c
+++ b/drivers/net/phy/aquantia/aquantia_main.c
@@ -839,6 +839,7 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
 
 	for (i = 0; i < AQR_NUM_GLOBAL_CFG; i++) {
 		struct aqr_global_syscfg *syscfg = &priv->global_cfg[i];
+		bool inband;
 
 		syscfg->speed = aqr_global_cfg_regs[i].speed;
 
@@ -849,6 +850,7 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
 
 		serdes_mode = FIELD_GET(VEND1_GLOBAL_CFG_SERDES_MODE, val);
 		rate_adapt = FIELD_GET(VEND1_GLOBAL_CFG_RATE_ADAPT, val);
+		inband = FIELD_GET(VEND1_GLOBAL_CFG_AUTONEG_ENA, val);
 
 		switch (serdes_mode) {
 		case VEND1_GLOBAL_CFG_SERDES_MODE_XFI:
@@ -896,12 +898,13 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
 		}
 
 		phydev_dbg(phydev,
-			   "Media speed %d uses host interface %s with %s\n",
+			   "Media speed %d uses host interface %s with %s, inband %s\n",
 			   syscfg->speed, phy_modes(syscfg->interface),
 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
-			   "unrecognized rate adaptation type");
+			   "unrecognized rate adaptation type",
+			   str_enabled_disabled(inband));
 	}
 
 	return 0;
-- 
2.43.0

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

On Mon, Nov 03, 2025 at 02:13:53PM +0200, Vladimir Oltean wrote:
> On Mon, Nov 03, 2025 at 11:43:23AM +0000, Russell King (Oracle) wrote:
> > On Mon, Nov 03, 2025 at 04:50:03PM +0530, Mohd Ayaan Anwar wrote:
> > > On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> > > > 
> > > > As Russell partially pointed out, there are several assumptions in the
> > > > Aquantia PHY driver and in phylink, three of them being that:
> > > > - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
> > > >   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> > > > - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
> > > >   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
> > > >   that interface
> > > > - if rate matching is used, the PHY is configured to use it for all
> > > >   media speeds <= phylink_interface_max_speed(link_state.interface)
> > > > 
> > > > Those assumptions are not validated very well against the ground truth
> > > > from the PHY provisioning, so the next step would be for us to see that
> > > > directly.
> > > > 
> > > > Please turn this print from aqr_gen2_read_global_syscfg() into something
> > > > visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> > > > 
> > > > 		phydev_dbg(phydev,
> > > > 			   "Media speed %d uses host interface %s with %s\n",
> > > > 			   syscfg->speed, phy_modes(syscfg->interface),
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> > > > 			   "unrecognized rate adaptation type");
> > > 
> > > Thanks. Looks like rate adaptation is only provisioned for 10M, which
> > > matches my observation where phylink passes the exact speeds for
> > > 100/1000/2500 but 1000 for 10M.
> > 
> > Hmm, I wonder what the PHY is doing for that then. stmmac will be
> > programmed to read the Cisco SGMII in-band control word, and use
> > that to determine whether symbol replication for slower speeds is
> > being used.
> > 
> > If AQR115C is indicating 10M in the in-band control word, but is
> > actually operating the link at 1G speed, things are not going to
> > work, and I would say the PHY is broken to be doing that. The point
> > of the SGMII in-band control word is to tell the MAC about the
> > required symbol replication on the link for transmitting the slower
> > data rates over the link.
> > 
> > stmmac unfortunately doesn't give access to the raw Cisco SGMII
> > in-band control word. However, reading register 0xf8 bits 31:16 for
> > dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
> > information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
> > 1 = 100M, 0 = 10M.
> 
> It might be Linux who is forcing the AQR115C into the nonsensical
> behaviour of advertising 10M in the SGMII control word while
> simultanously forcing the PHY MII to operate at 1G with flow control
> for the 10M media speed.
> 
> We don't control the latter, but we do control the former:
> aqr_gen2_config_inband(), if given modes == LINK_INBAND_ENABLE, will
> enable in-band for all media speeds that use PHY_INTERFACE_MODE_SGMII.
> Regardless of how the PHY was provisioned for each media speed, and
> especially regardless of rate matching settings, this function will
> uniformly set the same in-band enabled/disabled setting for all media
> speeds using the same host interface.
> 
> If dwmac_integrated_pcs_inband_caps(), as per Russell's patch 1/3,
> reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE, and if
> aqr_gen2_inband_caps() also reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE,
> then we're giving phylink_pcs_neg_mode() all the tools it needs to shoot
> itself in the foot, and select LINK_INBAND_ENABLE.
> 
> The judgement call in the Aquantia PHY driver was mine, as documented in
> commit 5d59109d47c0 ("net: phy: aquantia: report and configure in-band
> autoneg capabilities"). The idea being that the configuration would have
> been unsupportable anyway given the question that the framework asks:
> "does the PHY use in-band for SGMII, or does it not?"
> 
> Assuming the configuration at 10Mbps wasn't always broken, there's only
> one way to know how it was supposed to work: more dumping of the initial
> provisioning, prior to our modification in aqr_gen2_config_inband().
> Ayaan, please re-print the same info with this new untested patch applied.
> I am going to assume that in-band autoneg isn't enabled in the unmodified
> provisioning, at least for 10M.
> 
> Russell's request for the integrated PCS status is also a good parallel
> confirmation that yes, we've entered a mode where the PHY advertises
> SGMII replication at 10M.

> From b91162e5dae8e20b477999c4f2fcdb98c219d663 Mon Sep 17 00:00:00 2001
> From: Vladimir Oltean <vladimir.oltean@nxp.com>
> Date: Mon, 3 Nov 2025 14:03:55 +0200
> Subject: [PATCH] net: phy: aquantia: add inband setting to the
>  aqr_gen2_read_global_syscfg() print
> 
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
>  drivers/net/phy/aquantia/aquantia_main.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/phy/aquantia/aquantia_main.c b/drivers/net/phy/aquantia/aquantia_main.c
> index 41f3676c7f1e..f06b7b51bb7d 100644
> --- a/drivers/net/phy/aquantia/aquantia_main.c
> +++ b/drivers/net/phy/aquantia/aquantia_main.c
> @@ -839,6 +839,7 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
>  
>  	for (i = 0; i < AQR_NUM_GLOBAL_CFG; i++) {
>  		struct aqr_global_syscfg *syscfg = &priv->global_cfg[i];
> +		bool inband;
>  
>  		syscfg->speed = aqr_global_cfg_regs[i].speed;
>  
> @@ -849,6 +850,7 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
>  
>  		serdes_mode = FIELD_GET(VEND1_GLOBAL_CFG_SERDES_MODE, val);
>  		rate_adapt = FIELD_GET(VEND1_GLOBAL_CFG_RATE_ADAPT, val);
> +		inband = FIELD_GET(VEND1_GLOBAL_CFG_AUTONEG_ENA, val);
>  
>  		switch (serdes_mode) {
>  		case VEND1_GLOBAL_CFG_SERDES_MODE_XFI:
> @@ -896,12 +898,13 @@ static int aqr_gen2_read_global_syscfg(struct phy_device *phydev)
>  		}
>  
>  		phydev_dbg(phydev,
> -			   "Media speed %d uses host interface %s with %s\n",
> +			   "Media speed %d uses host interface %s with %s, inband %s\n",
>  			   syscfg->speed, phy_modes(syscfg->interface),
>  			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
>  			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
>  			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> -			   "unrecognized rate adaptation type");
> +			   "unrecognized rate adaptation type",
> +			   str_enabled_disabled(inband));
>  	}
>  
>  	return 0;
> -- 
> 2.43.0
> 

Here are the logs when I boot up with a 10M link:

[   10.743044] Aquantia AQR115C stmmac-0:08: Media speed 10 uses host interface sgmii with rate adaptation through flow control, inband enabled
[   10.757965] Aquantia AQR115C stmmac-0:08: Media speed 100 uses host interface sgmii with no rate adaptation, inband enabled
[   10.769857] Aquantia AQR115C stmmac-0:08: Media speed 1000 uses host interface sgmii with no rate adaptation, inband enabled
[   10.781840] Aquantia AQR115C stmmac-0:08: Media speed 2500 uses host interface 2500base-x with no rate adaptation, inband disabled
[   10.794346] Aquantia AQR115C stmmac-0:08: Media speed 5000 uses host interface 10gbase-r with rate adaptation through flow control, inband disabled
[   10.808358] Aquantia AQR115C stmmac-0:08: Media speed 10000 uses host interface 10gbase-r with no rate adaptation, inband disabled
[   10.827242] qcom-ethqos 23040000.ethernet eth1: PHY stmmac-0:08 uses interfaces 4,23,27, validating 23
[   10.836812] qcom-ethqos 23040000.ethernet eth1:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
[   10.836817] qcom-ethqos 23040000.ethernet eth1: PHY [stmmac-0:08] driver [Aquantia AQR115C] (irq=318)
[   10.836819] qcom-ethqos 23040000.ethernet eth1: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
[   10.851865] qcom-ethqos 23040000.ethernet eth1: Enabling Safety Features
[   10.882611] qcom-ethqos 23040000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported
[   10.895207] qcom-ethqos 23040000.ethernet eth1: registered PTP clock
[   10.902334] qcom-ethqos 23040000.ethernet eth1: configuring for phy/2500base-x link mode
[   10.910654] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/2500base-x
[   10.918790] qcom-ethqos 23040000.ethernet eth1: has pcs = true
[   10.924787] qcom-ethqos 23040000.ethernet eth1: interface 2500base-x inband modes: pcs=01 phy=00
[   10.933809] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/2500base-x
[   10.942388] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
[   10.966344] qcom-ethqos 23040000.ethernet eth1: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
[   12.819779] qcom-ethqos 23040000.ethernet eth1: phy link up sgmii/10Mbps/Half/pause/off/nolpi
[   12.825947] stmmac_pcs: Link Down
[   12.829539] qcom-ethqos 23040000.ethernet eth1: major config, requested phy/sgmii
[   12.831998] stmmac_pcs: Link Down
[   12.839683] qcom-ethqos 23040000.ethernet eth1: has pcs = true
[   12.843123] stmmac_pcs: Link Down
[   12.849121] qcom-ethqos 23040000.ethernet eth1: interface sgmii inband modes: pcs=03 phy=03
[   12.852546] stmmac_pcs: Link Down
[   12.861109] qcom-ethqos 23040000.ethernet eth1: major config, active phy/outband/sgmii
[   12.864535] stmmac_pcs: Link Down
[   12.872724] qcom-ethqos 23040000.ethernet eth1: phylink_mac_config: mode=phy/sgmii/pause adv=0000000,00000000,00000000,00000000 pause=00
[   12.876094] stmmac_pcs: Link Down
[   12.891394] qcom-ethqos 23040000.ethernet eth1: ethqos_configure_sgmii : Speed = 1000
[   12.892094] stmmac_pcs: Link Down
[   12.900109] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
[   12.903555] stmmac_pcs: Link Up
[   12.913473] qcom-ethqos 23040000.ethernet eth1: Link is Up - 10Mbps/Half - flow control off
[   12.916679] stmmac_pcs: Link Down
[   12.928659] stmmac_pcs: ANE process completed
[   12.933133] stmmac_pcs: Link Up

Although unrelated, I found it weird that the link comes up in half
duplex mode for 10M. To enable full duplex, I have to manually do it via
ethtool. I will try to connect a different link partner tomorrow, just
to rule out any issues on the other end.

	Ayaan

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 08:17:20PM +0530, Mohd Ayaan Anwar wrote:
> Here are the logs when I boot up with a 10M link:
> 
> Media speed 10 uses host interface sgmii with rate adaptation through flow control, inband enabled

As I say, this is broken, and this comes from how the PHY firmware
was provisioned in the Marvell toolset for the PHY.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 02:13:53PM +0200, Vladimir Oltean wrote:
> > stmmac unfortunately doesn't give access to the raw Cisco SGMII
> > in-band control word. However, reading register 0xf8 bits 31:16 for
> > dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
> > information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
> > 1 = 100M, 0 = 10M.
> 
> It might be Linux who is forcing the AQR115C into the nonsensical
> behaviour of advertising 10M in the SGMII control word while
> simultanously forcing the PHY MII to operate at 1G with flow control
> for the 10M media speed.

There's another factor in play here: the dwmac-qcom-ethqos glue driver
forces the configuration of the stmmac integrated PCS irrespective of
what phylink wants (whether or not patch 1 is being used.) That is,
for 1G, 100M and 10M, the SGMII in-band control word must be sent by
the PHY, and it must accurately indicate the symbol replication via
the speed bits. If this is not the case, then the stmmac PCS block will
not behave correctly.

So, if the PHY says in the SGMII configuration word that its operating
at 10M, but is internally rate-adapting to 1G and sending the packet
with no symbol replication, that is outside what the stmmac PCS block
will cope with.

> We don't control the latter, but we do control the former:
> aqr_gen2_config_inband(), if given modes == LINK_INBAND_ENABLE, will
> enable in-band for all media speeds that use PHY_INTERFACE_MODE_SGMII.
> Regardless of how the PHY was provisioned for each media speed, and
> especially regardless of rate matching settings, this function will
> uniformly set the same in-band enabled/disabled setting for all media
> speeds using the same host interface.
> 
> If dwmac_integrated_pcs_inband_caps(), as per Russell's patch 1/3,
> reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE, and if
> aqr_gen2_inband_caps() also reports LINK_INBAND_ENABLE | LINK_INBAND_DISABLE,
> then we're giving phylink_pcs_neg_mode() all the tools it needs to shoot
> itself in the foot, and select LINK_INBAND_ENABLE.
> 
> The judgement call in the Aquantia PHY driver was mine, as documented in
> commit 5d59109d47c0 ("net: phy: aquantia: report and configure in-band
> autoneg capabilities"). The idea being that the configuration would have
> been unsupportable anyway given the question that the framework asks:
> "does the PHY use in-band for SGMII, or does it not?"

From the kernel messages provided, the PCS is reporting no
capabilities, but as you say, the PHY is reporting
LINK_INBAND_ENABLE | LINK_INBAND_DISABLE. The mode that phylink is
using is "phy/outband/sgmii" - so what _should_ be no in-band
signalling. However, note what I said above - for 1G, 100M and 10M,
qcom-ethqos does this:

	ethqos_pcs_set_inband(priv, true);

in its fix_mac_speed() hook, which translates to:

	stmmac_pcs_ctrl_ane(priv, true, 0);

which eventually gets through to:

	dwmac_ctrl_ane(priv, offset, true, false);

This sets GMAC_AN_CTRL_ANE | GMAC_AN_CTRL_RAN but not
GMAC_AN_CTRL_SGMRAL. This means "autoneg enable" "restart autoneg" and
!SGMRAL means that the SGMII rate adaption block operates according to
the link speed received from the PHY.

At this point, I'm not sure whether I should just rip out the
stmmac_pcs_ctrl_ane() stuff from dwmac-qcom-ethqos.c - I've been
operating on the assumption that this is working code. Maybe that's
a false assumption, and its been broken since a818bd12538c ("net:
stmmac: dwmac-qcom-ethqos: Add support for 2.5G SGMII").

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

On Mon, Nov 03, 2025 at 11:43:23AM +0000, Russell King (Oracle) wrote:
> On Mon, Nov 03, 2025 at 04:50:03PM +0530, Mohd Ayaan Anwar wrote:
> > On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> > > 
> > > As Russell partially pointed out, there are several assumptions in the
> > > Aquantia PHY driver and in phylink, three of them being that:
> > > - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
> > >   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> > > - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
> > >   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
> > >   that interface
> > > - if rate matching is used, the PHY is configured to use it for all
> > >   media speeds <= phylink_interface_max_speed(link_state.interface)
> > > 
> > > Those assumptions are not validated very well against the ground truth
> > > from the PHY provisioning, so the next step would be for us to see that
> > > directly.
> > > 
> > > Please turn this print from aqr_gen2_read_global_syscfg() into something
> > > visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> > > 
> > > 		phydev_dbg(phydev,
> > > 			   "Media speed %d uses host interface %s with %s\n",
> > > 			   syscfg->speed, phy_modes(syscfg->interface),
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> > > 			   "unrecognized rate adaptation type");
> > 
> > Thanks. Looks like rate adaptation is only provisioned for 10M, which
> > matches my observation where phylink passes the exact speeds for
> > 100/1000/2500 but 1000 for 10M.
> 
> Hmm, I wonder what the PHY is doing for that then. stmmac will be
> programmed to read the Cisco SGMII in-band control word, and use
> that to determine whether symbol replication for slower speeds is
> being used.
> 
> If AQR115C is indicating 10M in the in-band control word, but is
> actually operating the link at 1G speed, things are not going to
> work, and I would say the PHY is broken to be doing that. The point
> of the SGMII in-band control word is to tell the MAC about the
> required symbol replication on the link for transmitting the slower
> data rates over the link.
> 
> stmmac unfortunately doesn't give access to the raw Cisco SGMII
> in-band control word. However, reading register 0xf8 bits 31:16 for
> dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
> information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
> 1 = 100M, 0 = 10M.
> 

This is dwmac4 and I got the following values with devmem at different
link speeds:
1. 10M:		0x00080000  => Bit 2:1 = 0
2. 100M:	0x000A0000  => Bit 2:1 = 1
3. 1G: 		0x000D0000  => Bit 2:1 = 2

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Mon, Nov 03, 2025 at 05:47:35PM +0530, Mohd Ayaan Anwar wrote:
> On Mon, Nov 03, 2025 at 11:43:23AM +0000, Russell King (Oracle) wrote:
> > On Mon, Nov 03, 2025 at 04:50:03PM +0530, Mohd Ayaan Anwar wrote:
> > > On Mon, Nov 03, 2025 at 12:48:20PM +0200, Vladimir Oltean wrote:
> > > > 
> > > > As Russell partially pointed out, there are several assumptions in the
> > > > Aquantia PHY driver and in phylink, three of them being that:
> > > > - rate matching is only supported for PHY_INTERFACE_MODE_10GBASER and
> > > >   PHY_INTERFACE_MODE_2500BASEX (thus not PHY_INTERFACE_MODE_SGMII)
> > > > - if phy_get_rate_matching() returns RATE_MATCH_NONE for an interface,
> > > >   pl->phy_state.rate_matching will also be RATE_MATCH_NONE when using
> > > >   that interface
> > > > - if rate matching is used, the PHY is configured to use it for all
> > > >   media speeds <= phylink_interface_max_speed(link_state.interface)
> > > > 
> > > > Those assumptions are not validated very well against the ground truth
> > > > from the PHY provisioning, so the next step would be for us to see that
> > > > directly.
> > > > 
> > > > Please turn this print from aqr_gen2_read_global_syscfg() into something
> > > > visible in dmesg, i.e. by replacing phydev_dbg() with phydev_info():
> > > > 
> > > > 		phydev_dbg(phydev,
> > > > 			   "Media speed %d uses host interface %s with %s\n",
> > > > 			   syscfg->speed, phy_modes(syscfg->interface),
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_NONE ? "no rate adaptation" :
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_PAUSE ? "rate adaptation through flow control" :
> > > > 			   syscfg->rate_adapt == AQR_RATE_ADAPT_USX ? "rate adaptation through symbol replication" :
> > > > 			   "unrecognized rate adaptation type");
> > > 
> > > Thanks. Looks like rate adaptation is only provisioned for 10M, which
> > > matches my observation where phylink passes the exact speeds for
> > > 100/1000/2500 but 1000 for 10M.
> > 
> > Hmm, I wonder what the PHY is doing for that then. stmmac will be
> > programmed to read the Cisco SGMII in-band control word, and use
> > that to determine whether symbol replication for slower speeds is
> > being used.
> > 
> > If AQR115C is indicating 10M in the in-band control word, but is
> > actually operating the link at 1G speed, things are not going to
> > work, and I would say the PHY is broken to be doing that. The point
> > of the SGMII in-band control word is to tell the MAC about the
> > required symbol replication on the link for transmitting the slower
> > data rates over the link.
> > 
> > stmmac unfortunately doesn't give access to the raw Cisco SGMII
> > in-band control word. However, reading register 0xf8 bits 31:16 for
> > dwmac4, or register 0xd8 bits 15:0 for dwmac1000 will give this
> > information. In that bitfield, bits 2:1 give the speed. 2 = 1G,
> > 1 = 100M, 0 = 10M.
> > 
> 
> This is dwmac4 and I got the following values with devmem at different
> link speeds:
> 1. 10M:		0x00080000  => Bit 2:1 = 0
> 2. 100M:	0x000A0000  => Bit 2:1 = 1
> 3. 1G: 		0x000D0000  => Bit 2:1 = 2

So this suggests it's sending the in-band configuration word, and it
indicates the negotiated speed. If the PHY really is using "rate
adaption" as in "making the packet look like 1G and using pause frames
to pace the transmitter" then that means symbol replication won't be
used by the PHY on the SGMII link. However, stmmac's PCS will be
using symbol replication, because the PHY is telling it to.

This suggests that having rate adaption enabled in the AQR115C PHY
and using SGMII with in-band is broken, and I can't think of any
PCS that would work with such a configuration.

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

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Mohd Ayaan Anwar]

Hello Russell,
On Thu, Oct 30, 2025 at 03:19:27PM +0000, Russell King (Oracle) wrote:
> > > Can you try:
> > > 
> > > 1. in stmmac_check_pcs_mode(), as a hack, add:
> > > 
> > > 	if (priv->dma_cap.pcs && interface == PHY_INTERFACE_MODE_2500BASEX)
> > > 		priv->hw->pcs = STMMAC_PCS_SGMII;
> > > 
> > > 2. with part 3 added, please change dwmac4_pcs_init() to:
> > > 
> > > 	phy_interface_t modes[] = {
> > > 		PHY_INTERFACE_MODE_SGMII,
> > > 		PHY_INTERFACE_MODE_2500BASEX,
> > > 	};
> > > 	...
> > > 	return stmmac_integrated_pcs_init(priv, GMAC_PCS_BASE,
> > > 					  GMAC_INT_PCS_LINK | GMAC_INT_PCS_ANE,
> > > 					  modes, ARRAY_SIZE(modes));
> > > 
> > > This will cause the integrated PCS to also be used for 2500BASE-X.
> > > 
> > > 3. modify dwmac_integrated_pcs_inband_caps() to return
> > >    LINK_INBAND_DISABLE for PHY_INTERFACE_MODE_2500BASEX.
> > > 
> > > This should result in the warning going away for you.
> > > 
> > > I'm not suggesting that this is a final solution.
> <snip>
> Please try again, this time with snps,ps-speed removed from the DT
> description for the interface. This property was a buggy attempt at
> reverse-SGMII, and incorrectly produced a warning if not specified
> when the integrated PCS was being used. The "bug" in the attempt
> with this was a typo in each MAC core driver, where specifying this
> set the TE (transmit enable) bit rather than the TC (transmit
> configuration) bit in the MAC control register. All the rest of the
> setup for reverse-SGMII mode was in place, but this bug made the
> entire thing useless.
> 

I finally got some time to test out 100M/1G/2.5G with all these changes
on the QCS9100 Ride R3 board (AQR115C PHY, qcom-ethqos).

Apart from this patch series, I incorporated the following changes:
1. Hacks suggested to have the PCS code work for 2500Base-X.
2. Removed snps,ps-speed from DT.
3. Picked [PATCH net-next v2] net: stmmac: qcom-ethqos: remove
MAC_CTRL_REG modification.

Apologies for the lengthy email- I’ve included phylink logs for all
five points for completeness.

*Observations:*

1. 2.5G Link up - no warning about the PCS configuration getting changed
by glue. Data path works fine.

	[   10.342908] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
	[   10.352486] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
	[   10.363215] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=365)
	[   10.372690] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
	[   10.428389] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
	[   10.436717] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
	[   10.444870] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
	[   10.453913] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
	[   10.462506] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
	[   10.485700] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
	[   15.131941] qcom-ethqos 23000000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
	[   15.143632] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 2500
	[   15.153226] stmmac_pcs: Link Up
	[   15.153274] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx


2. 1G Link up - Warning (PCS configuration changed from phylink by glue,
please report: 0x00040000 -> 0x00041200). Data path works fine.

	[   10.420439] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
	[   10.430023] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
	[   10.440749] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=365)
	[   10.450223] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
	[   10.506829] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
	[   10.515147] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
	[   10.523291] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
	[   10.532328] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
	[   10.540919] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
	[   10.563437] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
	[   13.912074] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
	[   13.919074] stmmac_pcs: Link Up
	< a *bunch* of "stmmac_pcs: Link Down" prints, more details in 4.>
	[   14.948996] stmmac_pcs: Link Up
	[   14.949149] stmmac_pcs: Link Down
	[   14.949169] stmmac_pcs: Link Up
	[   14.949301] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
	[   14.949317] stmmac_pcs: Link Down
	[   14.949326] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
	[   14.949331] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
	[   14.949335] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
	[   14.952026] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
	[   14.952033] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
	[   14.952057] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
	[   15.035977] stmmac_pcs: ANE process completed
	[   15.035978] stmmac_pcs: Link Down
	[   15.036004] stmmac_pcs: Link Up


3. 100M Link up - Warning (PCS configuration changed from phylink by
glue, please report: 0x00040000 -> 0x00041200). Data path works fine.

	[   20.273135] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
	[   20.282703] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
	[   20.293413] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=340)
	[   20.302877] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
	[   20.358642] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
	[   20.366973] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
	[   20.381114] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
	[   20.390144] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
	[   20.398720] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
	[   20.418477] stmmac_pcs: Link Down
	[   20.421912] stmmac_pcs: Link Down
	[   20.426255] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/100Mbps/Full/none/rx/tx/nolpi
	[   20.440795] stmmac_pcs: Link Down
	[   23.095229] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/100Mbps/Full/none/rx/tx/nolpi
	[   23.101362] stmmac_pcs: Link Down
	[   23.106527] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
	[   23.107624] stmmac_pcs: Link Down
	[   23.118707] stmmac_pcs: Link Down
	[   23.124703] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
	[   23.128141] stmmac_pcs: Link Down
	[   23.136699] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
	[   23.140126] stmmac_pcs: Link Down
	[   23.148232] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
	[   23.151657] stmmac_pcs: Link Down
	[   23.166924] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 100
	[   23.167584] stmmac_pcs: Link Down
	[   23.175511] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
	[   23.178944] stmmac_pcs: Link Up
	[   23.188862] qcom-ethqos 23000000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
	[   23.192097] stmmac_pcs: Link Down
	[   23.204346] stmmac_pcs: ANE process completed
	[   23.208828] stmmac_pcs: Link Up

4. Sometimes after toggling the interface or even during boot-up, the
console gets flooded with "stmmac_pcs: Link Down" prints. For e.g.,

	// Interface toggled
	< a bunch of "stmmac_pcs: Link Down" prints>
	[  549.898750] stmmac_pcs: Link Down
	[  549.902186] stmmac_pcs: Link Down
	[  549.905628] stmmac_pcs: Link Down
	[  549.909069] stmmac_pcs: Link Down
	[  549.912509] stmmac_pcs: Link Down
	[  549.915948] stmmac_pcs: Link Down
	[  549.919391] stmmac_pcs: Link Down
	[  549.922858] stmmac_pcs: Link Down
	[  549.924140] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 2500
	[  549.926304] stmmac_pcs: Link Down
	[  549.934349] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
	[  549.937746] stmmac_pcs: Link Up

   ethtool stats reveal an unusually high number of interrupts (I have
   seen this number go as high as about 16000 when booting up with a 1G
   link)
	     irq_pcs_ane_n: 0
	     irq_pcs_link_n: 1998	

5. Switching between 100M/1G/2.5G link is a bit of a mixed bag.
Sometimes it works, sometimes the data path breaks and needs an
interface toggle to be functional again. I don't necessarily think that
it's due to the speed specific configurations done by configure_sgmii as
that shouldn't impact switching between 1G and 2.5G, or even the switch
from 1G/2.5G to 100M.

While this is *broken* on net-next as well, the current patch series
allowed me to notice a peculiar behavior - it looks like sometimes the
PCS link doesn't come up:
	
	[   55.491996] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
	[   55.501622] qcom-ethqos 23000000.ethernet eth0: Link is Down
	[   58.907705] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
	[   58.913724] stmmac_pcs: Link Down
	[   58.919947] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
	[   58.927656] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
	[   58.936256] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
	[   58.944409] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
	[   58.958298] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
	[   58.967448] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
	[   58.977392] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx


Since 5 is unrelated to this series (I'll try to debug it separately),
let me know if you'd like me to run any other experiments for 2, 3, and
4.

> The "invalid port speed" warning that results if this property is
> not set to 10, 100 or 1000 is another bug - only if this warning
> is printed will the "normal" mode be selected.
> 
> Since the PCS series 1 and 2 have been merged into net-next, it
> will be safe to submit patches removing these properties from your
> DT files, without fear of this warning appearing.
> 

Thanks for the explanation. I see the incorrect use of snps,ps-speed in
the DT of a couple of more boards that use the same MAC core. Would it
be okay to add your Suggested-by when submitting the fix patches?

	Ayaan

Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)

[Russell King (Oracle)]

On Wed, Nov 05, 2025 at 09:16:10PM +0530, Mohd Ayaan Anwar wrote:
> Hello Russell,
> 
> I finally got some time to test out 100M/1G/2.5G with all these changes
> on the QCS9100 Ride R3 board (AQR115C PHY, qcom-ethqos).
> 
> Apart from this patch series, I incorporated the following changes:
> 1. Hacks suggested to have the PCS code work for 2500Base-X.
> 2. Removed snps,ps-speed from DT.
> 3. Picked [PATCH net-next v2] net: stmmac: qcom-ethqos: remove
> MAC_CTRL_REG modification.
> 
> Apologies for the lengthy email- I’ve included phylink logs for all
> five points for completeness.

That's fine, thanks.

> *Observations:*
> 
> 1. 2.5G Link up - no warning about the PCS configuration getting changed
> by glue. Data path works fine.
> 
> 	[   10.342908] qcom-ethqos 23000000.ethernet eth0: PHY stmmac-0:00 uses interfaces 4,23,27, validating 23
> 	[   10.352486] qcom-ethqos 23000000.ethernet eth0:  interface 23 (2500base-x) rate match pause supports 0-7,9,13-14,47
> 	[   10.363215] qcom-ethqos 23000000.ethernet eth0: PHY [stmmac-0:00] driver [Aquantia AQR115C] (irq=365)
> 	[   10.372690] qcom-ethqos 23000000.ethernet eth0: phy: 2500base-x setting supported 0000000,00000000,00008000,000062ff advertising 0000000,00000000,00008000,000062ff
> 	[   10.428389] qcom-ethqos 23000000.ethernet eth0: configuring for phy/2500base-x link mode
> 	[   10.436717] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/2500base-x
> 	[   10.444870] qcom-ethqos 23000000.ethernet eth0: interface 2500base-x inband modes: pcs=01 phy=00
> 	[   10.453913] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
> 	[   10.462506] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> 	[   10.485700] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> 	[   15.131941] qcom-ethqos 23000000.ethernet eth0: phy link up 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
> 	[   15.143632] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 2500
> 	[   15.153226] stmmac_pcs: Link Up
> 	[   15.153274] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
> 
> 
> 2. 1G Link up - Warning (PCS configuration changed from phylink by glue,
> please report: 0x00040000 -> 0x00041200). Data path works fine.
> 
...
> 	[   10.532328] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
> 	[   10.540919] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> 	[   10.563437] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/Unknown/Unknown/none/off/nolpi
> 	[   13.912074] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
> 	[   13.919074] stmmac_pcs: Link Up
> 	< a *bunch* of "stmmac_pcs: Link Down" prints, more details in 4.>
> 	[   14.948996] stmmac_pcs: Link Up
> 	[   14.949149] stmmac_pcs: Link Down
> 	[   14.949169] stmmac_pcs: Link Up

This is showing that the link state is flapping, which I guess is caused
by the PHY having switched to 1.25Mbaud SGMII but still being programmed
for 3.125Mbaud for 2.5G rate.

> 	[   14.949301] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
> 	[   14.949317] stmmac_pcs: Link Down
> 	[   14.949326] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
> 	[   14.949331] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
> 	[   14.949335] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
> 	[   14.952026] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
> 	[   14.952033] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
> 	[   14.952057] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> 	[   15.035977] stmmac_pcs: ANE process completed
> 	[   15.035978] stmmac_pcs: Link Down
> 	[   15.036004] stmmac_pcs: Link Up

Since we are using phy/outband mode (see "major config, active") this
means we're not expecting to use in-band, so the PCS has in-band
disabled by the PCS code, but then re-enabled by the glue code.

One thing which occurs to me though is that dwmac_ctrl_ane() doesn't
clear GMAC_AN_CTRL_SGMRAL when srgmi_ral is false, which means its
taking the speed information from the PS and FES bits in the MAC
control register.

Now, the question is, what happens if the call to
ethqos_pcs_set_inband() / stmmac_pcs_ctrl_ane() are omitted? Does
traffic still flow over the interface?

> 3. 100M Link up - Warning (PCS configuration changed from phylink by
> glue, please report: 0x00040000 -> 0x00041200). Data path works fine.
> 
...
> 	[   20.390144] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/2500base-x
> 	[   20.398720] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/2500base-x/none adv=0000000,00000000,00000000,00000000 pause=00
> 	[   20.418477] stmmac_pcs: Link Down
> 	[   20.421912] stmmac_pcs: Link Down
> 	[   20.426255] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/100Mbps/Full/none/rx/tx/nolpi
> 	[   20.440795] stmmac_pcs: Link Down
> 	[   23.095229] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/100Mbps/Full/none/rx/tx/nolpi
> 	[   23.101362] stmmac_pcs: Link Down
> 	[   23.106527] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
> 	[   23.107624] stmmac_pcs: Link Down
> 	[   23.118707] stmmac_pcs: Link Down
> 	[   23.124703] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
> 	[   23.128141] stmmac_pcs: Link Down
> 	[   23.136699] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
> 	[   23.140126] stmmac_pcs: Link Down
> 	[   23.148232] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
> 	[   23.151657] stmmac_pcs: Link Down
> 	[   23.166924] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 100
> 	[   23.167584] stmmac_pcs: Link Down
> 	[   23.175511] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
> 	[   23.178944] stmmac_pcs: Link Up
> 	[   23.188862] qcom-ethqos 23000000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> 	[   23.192097] stmmac_pcs: Link Down
> 	[   23.204346] stmmac_pcs: ANE process completed
> 	[   23.208828] stmmac_pcs: Link Up

It would be interesting to see how this behaves as well without the
call to ethqos_pcs_set_inband() / stmmac_pcs_ctrl_ane().

> 4. Sometimes after toggling the interface or even during boot-up, the
> console gets flooded with "stmmac_pcs: Link Down" prints. For e.g.,
> 
> 	// Interface toggled
> 	< a bunch of "stmmac_pcs: Link Down" prints>
> 	[  549.898750] stmmac_pcs: Link Down
> 	[  549.902186] stmmac_pcs: Link Down
> 	[  549.905628] stmmac_pcs: Link Down
> 	[  549.909069] stmmac_pcs: Link Down
> 	[  549.912509] stmmac_pcs: Link Down
> 	[  549.915948] stmmac_pcs: Link Down
> 	[  549.919391] stmmac_pcs: Link Down
> 	[  549.922858] stmmac_pcs: Link Down
> 	[  549.924140] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 2500
> 	[  549.926304] stmmac_pcs: Link Down
> 	[  549.934349] qcom-ethqos 23000000.ethernet eth0: Link is Up - 2.5Gbps/Full - flow control rx/tx
> 	[  549.937746] stmmac_pcs: Link Up
> 
>    ethtool stats reveal an unusually high number of interrupts (I have
>    seen this number go as high as about 16000 when booting up with a 1G
>    link)
> 	     irq_pcs_ane_n: 0
> 	     irq_pcs_link_n: 1998	

Some PCS have this, caused by spuriously detecting what they think is a
valid signal but isn't. We don't enable comma detection for SGMII, but
maybe that would help avoid this? It depends how the serdes is
implemented. The alternative is that we may need to disable the IRQ
(we're not really using it for anything in this mode, as we're using
outband mode.)

> 5. Switching between 100M/1G/2.5G link is a bit of a mixed bag.
> Sometimes it works, sometimes the data path breaks and needs an
> interface toggle to be functional again. I don't necessarily think that
> it's due to the speed specific configurations done by configure_sgmii as
> that shouldn't impact switching between 1G and 2.5G, or even the switch
> from 1G/2.5G to 100M.

Maybe this is the lack of comma detect being enabled - what I read in
the databook, dwmac expects the external serdes to do comman detection
when enabled. It appears that the ECD bit just toggles an output to
the implementation's serdes to tell it to enable this, but it's
entirely possible that an implementation doesn't need this control.
It's something worth trying though.

> While this is *broken* on net-next as well, the current patch series
> allowed me to notice a peculiar behavior - it looks like sometimes the
> PCS link doesn't come up:
> 	
> 	[   55.491996] qcom-ethqos 23000000.ethernet eth0: phy link down 2500base-x/2.5Gbps/Full/none/rx/tx/nolpi
> 	[   55.501622] qcom-ethqos 23000000.ethernet eth0: Link is Down
> 	[   58.907705] qcom-ethqos 23000000.ethernet eth0: phy link up sgmii/1Gbps/Full/none/rx/tx/nolpi
> 	[   58.913724] stmmac_pcs: Link Down
> 	[   58.919947] qcom-ethqos 23000000.ethernet eth0: major config, requested phy/sgmii
> 	[   58.927656] qcom-ethqos 23000000.ethernet eth0: interface sgmii inband modes: pcs=03 phy=03
> 	[   58.936256] qcom-ethqos 23000000.ethernet eth0: major config, active phy/outband/sgmii
> 	[   58.944409] qcom-ethqos 23000000.ethernet eth0: phylink_mac_config: mode=phy/sgmii/none adv=0000000,00000000,00000000,00000000 pause=03
> 	[   58.958298] qcom-ethqos 23000000.ethernet eth0: ethqos_configure_sgmii : Speed = 1000
> 	[   58.967448] dwmac: PCS configuration changed from phylink by glue, please report: 0x00040000 -> 0x00041200
> 	[   58.977392] qcom-ethqos 23000000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
> 
> 
> Since 5 is unrelated to this series (I'll try to debug it separately),
> let me know if you'd like me to run any other experiments for 2, 3, and
> 4.

As mentioned above, ECD may help. If the serdes needs this signal
enabled to perform command detection and word synchronisation, not
enabling it is likely to result in the PCS receiving unaligned words
that it can't make sense of.

> > The "invalid port speed" warning that results if this property is
> > not set to 10, 100 or 1000 is another bug - only if this warning
> > is printed will the "normal" mode be selected.
> > 
> > Since the PCS series 1 and 2 have been merged into net-next, it
> > will be safe to submit patches removing these properties from your
> > DT files, without fear of this warning appearing.
> > 
> 
> Thanks for the explanation. I see the incorrect use of snps,ps-speed in
> the DT of a couple of more boards that use the same MAC core. Would it
> be okay to add your Suggested-by when submitting the fix patches?

Yes please, and definitely! Thanks!

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