netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
To: "Russell King (Oracle)" <linux@armlinux.org.uk>
Cc: "Andrew Lunn" <andrew@lunn.ch>,
	"Heiner Kallweit" <hkallweit1@gmail.com>,
	"Alexandre Torgue" <alexandre.torgue@foss.st.com>,
	"Alexis Lothoré" <alexis.lothore@bootlin.com>,
	"Andrew Lunn" <andrew+netdev@lunn.ch>,
	"Boon Khai Ng" <boon.khai.ng@altera.com>,
	"Daniel Machon" <daniel.machon@microchip.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Furong Xu" <0x1207@gmail.com>,
	"Jacob Keller" <jacob.e.keller@intel.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Jan Petrous (OSS)" <jan.petrous@oss.nxp.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-stm32@st-md-mailman.stormreply.com,
	"Maxime Chevallier" <maxime.chevallier@bootlin.com>,
	"Maxime Coquelin" <mcoquelin.stm32@gmail.com>,
	netdev@vger.kernel.org, "Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"Yu-Chun Lin" <eleanor15x@gmail.com>
Subject: Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff)
Date: Thu, 30 Oct 2025 18:50:51 +0530	[thread overview]
Message-ID: <aQNmM5+cptKllTS8@oss.qualcomm.com> (raw)
In-Reply-To: <aQHc6SowbWsIA1A5@shell.armlinux.org.uk>

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

  reply	other threads:[~2025-10-30 13:21 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-25 20:47 [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff) Russell King (Oracle)
2025-10-25 20:48 ` [PATCH net-next 1/3] net: stmmac: configure AN control according to phylink Russell King (Oracle)
2025-10-25 20:48 ` [PATCH net-next 2/3] net: stmmac: report PCS configuration changes Russell King (Oracle)
2025-10-25 20:48 ` [PATCH net-next 3/3] net: stmmac: add support specifying PCS supported interfaces Russell King (Oracle)
2025-10-28 10:16   ` Maxime Chevallier
2025-10-28 10:35     ` Russell King (Oracle)
2025-10-28 10:40       ` Russell King (Oracle)
2025-10-28 11:26       ` Maxime Chevallier
2025-10-28 21:12 ` [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3 (dodgy stuff) Mohd Ayaan Anwar
2025-10-29  9:22   ` Russell King (Oracle)
2025-10-30 13:20     ` Mohd Ayaan Anwar [this message]
2025-10-30 15:19       ` Russell King (Oracle)
2025-10-30 15:22         ` Russell King (Oracle)
2025-11-03  8:58           ` Mohd Ayaan Anwar
2025-11-03  9:52             ` Russell King (Oracle)
2025-11-03 10:18               ` Mohd Ayaan Anwar
2025-11-03 10:47                 ` Russell King (Oracle)
2025-11-03 10:48                 ` Vladimir Oltean
2025-11-03 11:20                   ` Mohd Ayaan Anwar
2025-11-03 11:43                     ` Russell King (Oracle)
2025-11-03 12:13                       ` Vladimir Oltean
2025-11-03 14:47                         ` Mohd Ayaan Anwar
2025-11-03 17:15                           ` Russell King (Oracle)
2025-11-03 17:02                         ` Russell King (Oracle)
2025-11-03 12:17                       ` Mohd Ayaan Anwar
2025-11-03 17:13                         ` Russell King (Oracle)
2025-11-05 15:46         ` Mohd Ayaan Anwar
2025-11-05 18:12           ` Russell King (Oracle)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aQNmM5+cptKllTS8@oss.qualcomm.com \
    --to=mohd.anwar@oss.qualcomm.com \
    --cc=0x1207@gmail.com \
    --cc=alexandre.torgue@foss.st.com \
    --cc=alexis.lothore@bootlin.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=boon.khai.ng@altera.com \
    --cc=daniel.machon@microchip.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eleanor15x@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=jacob.e.keller@intel.com \
    --cc=jan.petrous@oss.nxp.com \
    --cc=kuba@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-stm32@st-md-mailman.stormreply.com \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=mcoquelin.stm32@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).