netdev - upstream Linux support for Ethernet combo ports via external mux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z6qHi1bQZEnYUDp7@makrotopia.org>
Date: Mon, 10 Feb 2025 23:11:07 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Bo-Cun Chen <bc-bocun.chen@...iatek.com>,
	Chad Monroe <chad.monroe@...ran.com>,
	John Crispin <john@...ozen.org>, maxime.chevallier@...tlin.com,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	Vladimir Oltean <olteanv@...il.com>, Andrew Lunn <andrew@...n.ch>,
	Heiner Kallweit <hkallweit1@...il.com>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	"Chester A. Unal" <chester.a.unal@...nc9.com>,
	Daniel Golle <daniel@...rotopia.org>,
	"David S. Miller" <davem@...emloft.net>,
	Jakub Kicinski <kuba@...nel.org>,
	linux-mediatek@...ts.infradead.org,
	Matthias Brugger <matthias.bgg@...il.com>, netdev@...r.kernel.org
Subject: upstream Linux support for Ethernet combo ports via external mux

Hi,

Looking for ways to support a passive SerDes mux in vanilla Linux I
found Maxime's slides "Multi-port and Multi-PHY Ethernet interfaces"[1].

The case I want to support is probably quite common nowadays but isn't
covered there nor implemented in Linux.

 +----------------------------+
 |            SoC             |
 |    +-----------------+     |
 |    |       MAC       |     |
 |    +----+-------+----+     |
 |         |  PCS  |   +------+
 |         +---=---+   | GPIO |
 +-------------=-------+---=--+
              |            |
           +---=---+       |
           |  Mux  <-------+
           +-=---=-+
             |   |
            /     \
     +-----=-+   +-=-----+
     |  PHY  |   |  SFP  |
     +-------+   +-------+

So other than it was when SoCs didn't have built-in PCSs, now the SFP is
not connected to the PHY, but there is an additional mux IC controlled
by the SoC to connect the serialized MII either to the PHY (in case no
SFP is inserted) or to the SFP (in case a module is inserted).

MediaTek came up with a vendor-specific solution[2] for that which works
well -- but obviously it would be much nicer to have generic, vendor-
agnostic support for such setups in phylink, ideally based on the
existing gpio-mux driver.

So I imagine something like a generic phylink-mux, controlled by hooking
to the module_insert and module_remove remove SFP ops (assuming the
moddef0 signal is connected...).

Before I get my hands dirty, please join my line of thought for one
moment, so we can agree on a sketch:

Does everyone agree that phylink would be the right place to do this?

DT bindings could look like this (option A):
 ...
    mux: mux-controller {
        compatible = "gpio-mux";
        #mux-control-cells = <0>;

        mux-gpios = <&pio 7 GPIO_ACTIVE_HIGH>;
    };

    mux0: mii-mux {
        compatible = "mii-mux";
        mux-controls = <&mux>;
        #address-cells = <1>;
        #size-cells = <0>;

        channel@0 {
            reg = <0>;
            sfp = <&sfp0>;
            managed = "in-band-status";
            module-presence-controls-mux;
        };

        channel@1 {
            reg = <1>;
            phy-handle = <&phy0>;
            phy-connection-type = "sgmii";
        };
    };
  };

  soc {
      ethernet@...40000 {
          mii-mux = <&mux0>;
      };
  };

or like this (option B):
 ...
    mux: mux-controller {
        compatible = "gpio-mux";
        #mux-control-cells = <0>;

        mux-gpios = <&pio 7 GPIO_ACTIVE_HIGH>;
    };
  };

  soc {
      ethernet@...40000 {
          sfp = <&sfp0>;
          phy = <&phy0>;
          phy-connection-type = "sgmii";
          mux-controls = <&mux>;
      };
  };

Obviously option A is more expressive, but also more complex, and I'm
not 100% sure if all that complexity is really needed in practise.
However, for "better safe than sorry" reasons I'd opt for option A,
unless anyone comes up with a better idea.

Let me know what you think.

Cheers

Daniel

[1]: https://netdevconf.org/0x17/docs/netdev-0x17-paper2-talk-slides/multi-port-multi-phy-interfaces.pdf
[2]: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk-openwrt-feeds/+/refs/heads/master/autobuild/unified/global/24.10/files/target/linux/mediatek/patches-6.6/999-2708-net-ethernet-mtk_eth_soc-support-ethernet-passive-mu.patch