Date: Mon, 3 Nov 2025 11:43:23 +0000
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>
Cc: Vladimir Oltean <olteanv@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Alexis =?iso-8859-1?Q?Lothor=E9?= <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>,
	Yu-Chun Lin <eleanor15x@gmail.com>
Subject: Re: [PATCH net-next 0/3] net: stmmac: phylink PCS conversion part 3
 (dodgy stuff)
Message-ID: <aQiVWydDsRaMz8ua@shell.armlinux.org.uk>
References: <aQExx0zXT5SvFxAk@oss.qualcomm.com>
 <aQHc6SowbWsIA1A5@shell.armlinux.org.uk>
 <aQNmM5+cptKllTS8@oss.qualcomm.com>
 <aQOB_yCzCmAVM34V@shell.armlinux.org.uk>
 <aQOCpG_gjJlnm0A1@shell.armlinux.org.uk>
 <aQhusPX0Hw9ZuLNR@oss.qualcomm.com>
 <aQh7Zj10C7QcDoqn@shell.armlinux.org.uk>
 <aQiBjYNtJks2/mrw@oss.qualcomm.com>
 <20251103104820.3fcksk27j34zu6cg@skbuf>
 <aQiP46tKUHGwmiTo@oss.qualcomm.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <aQiP46tKUHGwmiTo@oss.qualcomm.com>
Sender: Russell King (Oracle) <linux@armlinux.org.uk>

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!