On Fri, Aug 01, 2025 at 03:02:14PM +0100, Russell King (Oracle) wrote:

It looks like the SerDes driver is managed by the MAC (it validates
each mode against the serdes PHY driver's validate function - serdes
being mac_dev->fman_mac->serdes. If this SerDes doesn't exist, then
only mac_dev->phy_if is supported.

So, I don't think there's any need for the Lynx to reach out to the
SerDes in mainline as it currently stands.

As the SerDes also dictates which modes and is managed by fman, I'd
suggest for mainline that the code needs to implement the following
pseudocode:

	config->supported_interfaces = mac_support |
				(pcs->supported_interfaces &
				serdes_supported_interfaces);

rather than the simple "or pcs->supported_interfaces into the
supported bitmap" that we can do in other drivers.

The PCS needs to reach out to the SerDes lane in the more developed
downstream code due to the need to manage the lane (software-driven link
training according to 802.3 clause 72) for backplane link modes. The
AN/LT block is grouped together with the PCS, not with the MAC.

This design decision also makes it so that the other non-critical lane
management tasks (initialization, power management, figure out supported
interface modes, reconfiguration upon major reconfig) are done only once
in a central place (the PCS driver) rather than replicated at the
following PCS consumer sites (MAC drivers), which all need these features,
preferably with a unified behavior:
- drivers/net/dsa/ocelot/seville_vsc9953.c
- drivers/net/dsa/ocelot/felix_vsc9959.c
- drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c
- drivers/net/ethernet/freescale/fman/fman_memac.c
- drivers/net/ethernet/freescale/enetc/enetc_pf.c

So, in downstream, yes, the MAC acquires the SerDes lane using
devm_of_phy_optional_get(), but it just passes it to the PCS and lets it
do the above.