Hi Russell,

On 13/01/2026 21:03, Russell King (Oracle) wrote:

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

quoted

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.

You mean controlling the generic PHY (phy_power_on / off,
phy_set_mode_ext and so on) from phylink instead of the MAC driver, like
we also do in mvneta / mvpp2 ?

That would also interest the Meta folks working on fbnic I guess :)

Maxime