Multi-PHYs and multiple-ports bonding support

[Russell King (Oracle)]

On Mon, Oct 17, 2022 at 10:51:00AM +0200, Maxime Chevallier wrote:
> 2) Changes in Phylink
> 
> This might be the tricky part, as we need to track several ports,
> possibly connected to different PHYs, to get their state. For now, I
> haven't prototyped any of this yet.

The problem is _way_ larger than phylink. It's a fundamental throughout
the net layer that there is one-PHY to one-MAC relationship. Phylink
just adopts this because it is the established norm, and trying to fix
it is rather rediculous without a use case.

See code such as the ethtool code, where the MAC and associated layers
are# entirely bypassed with all the PHY-accessing ethtool commands and
the commands are passed directly to phylib for the PHY registered
against the netdev.

We do have use cases though - consider a setup such as the mcbin with
the 3310 in SGMII mode on the fibre link and a copper PHY plugged in
with its own PHY - a stacked PHY situation (we don't support this
right now.) Which PHY should the MII ioctls, ethtool, and possibly the
PTP timestamp code be accessing with a copper SFP module plugged in?

This needs to be solved for your multi-PHY case, because you need to
deal with programming e.g. the link advertisement in both PHYs, not
just one - and with the above model, you have no choice which PHY gets
the call, it's always going to be the one registered with the netdev.

The point I'm making is that you're suggesting this is a phylink issue,
but it isn't, it's a generic networking layering bypass issue. If the
net code always forwarded the ethtool etc stuff to the MAC and let the
MAC make appropriate decisions about how these were handled, then we
would have a properly layered approach where each layer can decide
how a particular interface is implemented - to cope with situations
such as the one you describe.

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