Re: [PATCH net-next 5/6] net: phy: dp83869: Support SGMII SFP modules

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Tue, Jul 02, 2024 at 03:21:09PM +0200, Andrew Lunn wrote:
> The SFP PHY is however a PHY which phylib is managing. And you have
> phylink on top of that, which knows about both PHYs. Architecturally,
> i really think phylink should be dealing with all this
> configuration.
> 
> The MAC driver has told phylink its pause capabilities.
> phylink_bringup_phy() will tell phylib these capabilities by calling
> phy_support_asym_pause(). Why does this not work for the SFP PHY?
> 
> phylink knows when the SFP PHY is plugged in, and knows if the link is
> admin up. It should be starting the state machine, not the PHY.

phylink only knows about SFPs that are directly connected to the
MAC/PCS. It has no knowledge of SFPs that are behind a PHY (like
on the Macchiatobin with 88x3310 PHYs.)

Due to the structure of the networking layer, I don't see how we
could sanely make stacked PHYs work - we expect the ethtool APIs
to target the media PHY, but in the case of a platform such as
Macchiatobin, we potentially have _two_ media facing PHYs on one
network interface. There's the 88x3310 which has its own RJ45
socket, and then if one plugs in a copper SFP, you get another
media-facing PHY with its own RJ45 socket. Which PHY should
ethtool ksettings_set interact with?

The ethtool API wasn't designed for this kind of thing!

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