Re: [RFC] RJ45 to SFP auto-sensing and switching in mux-ed single-mac devices (XOR RJ/SFP)

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

On Tue, Aug 29, 2023 at 05:12:48PM +0200, Nicolò Veronese wrote:
> Hi,
> 
> I and some folks in CC are working to properly port all the
>  functions of a Zyxel ex5601-t0 to OpenWrt.
> 
> The manufacturer decided to use a single SerDes connected
>  to both an SPF cage and an RJ45 phy. A simple GPIO is
>  used to control a 2 Channel 2:1 MUX to switch the two SGMII pairs
>  between the RJ45 and the SFP.
> 
>   ┌─────┐  ┌──────┐   ┌─────────┐
>   │     │  │      │   │         │
>   │     │  │      ├───┤ SFP     │
>   │     │  │      │   └─────────┘
>   │     │  │      │
>   │ MAC ├──┤ MUX  │   ┌─────────┐
>   │     │  │      │   │         │
>   │     │  │      │   │ RJ45    │
>   │     │  │      ├───┤ 2.5G PHY│
>   │     │  │      │   │         │
>   └─────┘  └───▲──┘   └─────────┘
>                │
>   MUX-GPIO ────┘

This is do-able in software, but is far from a good idea.

Yes, it would be possible to "disconnect" the RJ45 PHY from the netdev,
and switch to the SFP and back again. It would be relatively easy for
phylink to do that. What phylink would need to do is to keep track of
the SFP PHY and netdev-native PHY independently, and multiplex between
the two. It would also have to manage the netdev->phydev pointer.
Any changes to this must be done under the rtnl lock.

So technically it's possible. However, there is no notification to
userspace when such a change may occur. There's also the issue that
userspace may be in the process of issuing ethtool commands that are
affecting one of the PHYs. While holding the rtnl lock will block
those calls, a change between the PHY and e.g. a PHY on the SFP
would cause the ethtool command to target a different PHY from what
was the original target.

To solve that sanely, every PHY-based ethtool probably needs a way
to specify which PHY the command is intended for, but then there's
the question of how userspace users react to that - because it's
likely more than just modifying the ethtool utility, ethtool
commands are probably used from many programs.

IMHO, it needs a bit of thought beyond "what can we do to support a
mux".

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