linux-kernel - Re: [PATCH net-next] net: phy: qcom: qca808x: Add .get_rate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aMgsiDS5tFeqJsKD@shell.armlinux.org.uk>
Date: Mon, 15 Sep 2025 16:11:04 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Mohd Ayaan Anwar <mohd.anwar@....qualcomm.com>
Cc: andrew@...n.ch, Heiner Kallweit <hkallweit1@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	netdev@...r.kernel.org, linux-arm-msm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: phy: qcom: qca808x: Add .get_rate_matching
 support

On Mon, Sep 15, 2025 at 08:24:26PM +0530, Mohd Ayaan Anwar wrote:
> On Mon, Sep 15, 2025 at 01:09:39PM +0100, Russell King (Oracle) wrote:
> > This shows that the PHY supports SGMII (4) and 2500base-X (23). However,
> > as we only validate 2500base-X, this suggests stmmac doesn't support
> > switching between SGMII and 2500base-X.
> > 
> > What *exactly* is the setup with stmmac here? Do you have an external
> > PCS to support 2500base-X, or are you using the stmmac internal PCS?
> 
> Internal PCS. But it's not really pure 2500base-X...
> I found an older thread for this exact MAC core [0], and it looks like
> we have an overclocked SGMII, i.e., 2500base-X without in-band
> signalling.
> 
> Just wondering if registering a `.get_interfaces` callback in
> `dwmac-qcom-ethqos.c` and doing something like the following will be
> helpful?
> 
> case PHY_INTERFACE_MODE_2500BASEX:
> 	__set_bit(PHY_INTERFACE_MODE_2500BASEX, interfaces);
> 	fallthrough;
> case PHY_INTERFACE_MODE_SGMII:
> 	__set_bit(PHY_INTERFACE_MODE_SGMII, interfaces);
> 	break;
> ...
> 
> This should ensure that both SGMII and 2500base-X are validated,
> allowing switching between them.

So, this is something that has never worked with this hardware setup.
I don't think we should rush to make it work. The stmmac internal
PCS code is a mess, bypassing phylink. I had a patch series which
addressed this a while back but it went nowhere, but I guess this is
an opportunity to say "look, we need to get this sorted properly".

I suspect this isn't going to be simple - stmmac does _not_ use
phylink properly (I've been doing lots of cleanups to this driver
over the last year or so to try and make the code more
understandable so I can start addressing this deficiency) and
there's still lots of work to be done. The way the "platform glue"
drivers work is far from ideal, especially when it comes to
switching interfaces.

I'll try to post the stmmac PCS cleanup series in the coming few
days, and it would be useful if you could give it whatever
testing you can.

Thanks.

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