On Tue, Jan 13, 2026 at 08:24:49PM +0100, Maxime Chevallier wrote:

Hi Russell,

quoted

Traditionally, we've represented the SerDes using drivers/phy rather
than the drivers/net/phy infrastructure, mainly because implementations
hvaen't provided anything like an 802.3 PHY register set, but moreover
because the SerDes tends to be generic across ethernet, PCIe, USB, SATA
etc (basically, anything that is a high speed balanced pair serial
communication) and thus the "struct phy" from drivers/phy can be used
by any of these subsystems.

True, and I completely agree with that. The reason I didn't touch that
when porting to phylink is that the device I'm using, that has a
Motorola/Freescale/NXP MPC832x, doesn't have that TBI/RTBI block, so I
can't test that at all should we move to a more modern SerDes driver
(modern w.r.t when this driver was written) :(

Over the last few days, I've been adding "generic" stmmac SerDes
support (which basically means not in the platform glue) to replace
the qcom-ethqos stuff, and while doing so, the thought did cross my
mind whether I should be adding that to phylink rather than stmmac.

stmmac's "I can't reset without all the clocks running" makes it
rather special though, but we already have phylink_rx_clk_stop_block()
to guarantee that the PHY itself won't stop its receive clock when
entering LPI, so phylink already knows when the clock is required
(although with a slight abuse of the names of these functions.)

Given that the two qcom-ethqos patches I sent last night failed to
build (oops) I may change the patch order... it does need the stmmac
PCS work to be merged first though.

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