Question: MII media mux for external PHY/SFP combo ports

Question: MII media mux for external PHY/SFP combo ports

[git]

Hi Maxime,

Sorry for the duplicate email. The previous copy was rejected by the list because it contained HTML (default mode in Proton Mail).
This is a plain-text resend.

I am working on upstream support for the Banana Pi BPI-R4 Pro 8X and
would like guidance before writing any board-specific mux code.

The board [1] has two independent RJ45/SFP combo connectors. Each has
one SerDes lane, a GPIO-controlled passive external mux, one AS21010P
copper PHY endpoint, and one SFP cage endpoint. One mux is connected
to an MT7988 MAC. The other is connected to an MxL86252 DSA user port.

The downstream policy selects SFP when a module is present and copper
when the cage is empty. Each combo must keep one logical network port,
its MAC address, and its bridge/VLAN configuration across a media
transition. Switching either combo must not affect the other combo or
the remaining switch ports.

I have downstream reference code [3,4], but it polls MOD_DEF0 and
replaces driver-private MediaTek or DSA phylink state. I am treating it
only as bring-up evidence.

The phy_port documentation [2] added by commit 62518b5b3d8e describes
external MII mux topologies and identifies an MII mux framework as
future work.

Does runtime MII/media mux follow-up work already exist or is it
planned? If not, is phy_port the right starting point for a generic
design that covers both MAC and DSA consumers?

I can provide the exact DTS topology, downstream references, and a board
for copper/SFP hot-plug, traffic, and concurrent-combo testing.

[1] https://docs.banana-pi.org/en/BPI-R4_Pro/BananaPi_BPI-R4_Pro
[2] https://patch.msgid.link/20260108080041.553250-15-maxime.chevallier@bootlin.com
[3] https://github.com/BPI-SINOVOIP/BPI-R4PRO-8X-OPENWRT-V24.10.0-Master-Devel/blob/56e0e77adad258ba05782fee8f94f00d17b0b991/target/linux/mediatek/files-6.6/drivers/net/dsa/mxl862xx/mxl862xx.c#L3696-L3738
[4] https://github.com/frank-w/BPI-Router-Linux/blob/6aa3b285d8f88267e5f3f403000c88a08b61f851/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L5430-L5508

Thanks,
Pavel Kirbai

Re: Question: MII media mux for external PHY/SFP combo ports

[Maxime Chevallier]

Hi Pavel,

On 7/19/26 04:12, git@elinell1337.me wrote:
> Hi Maxime,
> 
> Sorry for the duplicate email. The previous copy was rejected by the list because it contained HTML (default mode in Proton Mail).
> This is a plain-text resend.
> 
> I am working on upstream support for the Banana Pi BPI-R4 Pro 8X and
> would like guidance before writing any board-specific mux code.

It's still an ongoing topic for me, I'm iterating on the prerequisite for
proper MUX support that is phy_port (i.e. expose the ports of the mux
to users), the next series will be about muxes :) Depending on when the
current phy_port gets accepted, I expect that mux support will start being
upstreamed in a few weeks from now, I'll make sure to CC you.

In terms of testing, I have :
 - Combo-ports where both SFP and RJ45 are connected to the same PHY
 - Combo-ports behind a DSA switch (a Marvell 6190x)
 - Combo-ports with a mii MUX driven by gpio (turris omnia)
 - Dual-port RJ45 with 2 PHYs

> 
> The board [1] has two independent RJ45/SFP combo connectors. Each has
> one SerDes lane, a GPIO-controlled passive external mux, one AS21010P
> copper PHY endpoint, and one SFP cage endpoint. One mux is connected
> to an MT7988 MAC. The other is connected to an MxL86252 DSA user port.
> 
> The downstream policy selects SFP when a module is present and copper
> when the cage is empty. Each combo must keep one logical network port,
> its MAC address, and its bridge/VLAN configuration across a media
> transition. Switching either combo must not affect the other combo or
> the remaining switch ports.
> 
> I have downstream reference code [3,4], but it polls MOD_DEF0 and
> replaces driver-private MediaTek or DSA phylink state. I am treating it
> only as bring-up evidence.
> 
> The phy_port documentation [2] added by commit 62518b5b3d8e describes
> external MII mux topologies and identifies an MII mux framework as
> future work.
> 
> Does runtime MII/media mux follow-up work already exist or is it
> planned? If not, is phy_port the right starting point for a generic
> design that covers both MAC and DSA consumers?

Yes it'll cover both, the new DT binding will be generic, and the SW
support for MUX registration will be done directly by phylink. What
will be needed it the logic to drive the MUX

> 
> I can provide the exact DTS topology, downstream references, and a board
> for copper/SFP hot-plug, traffic, and concurrent-combo testing.
I'll CC you for the next iterations, what really helps if you need that
going forward is review and testing of the code.

Next revision will go out next week, and hopefully I can start sending
the mii mux work soon after :)

Maxime