[RFC,net-next] dt-bindings: ethernet-controller: document signal multiplexer

There are devices where the MAC signals from the ethernet controller are
not directly connected to an ethernet PHY or a SFP cage, but to a
multiplexer, so that the device can switch between the endpoints.

For example on Turris Omnia the WAN controller is connected to a SerDes
switch, which multiplexes the SerDes lanes between SFP cage and ethernet
PHY, depending on whether a SFP module is present (MOD_DEF0 GPIO from
the SFP cage).

Document how to describe such a situation for an ethernet controller in
the device tree bindings.

Example usage could then look like:
  &eth2 {
    status = "okay";
    phys = <&comphy5 2>;
    buffer-manager = <&bm>;
    bm,pool-long = <2>;
    bm,pool-short = <3>;

    signal-multiplexer {
      compatible = "gpio-signal-multiplexer";
      gpios = <&pcawan 4 GPIO_ACTIVE_LOW>;

      endpoint@0 {
        phy-mode = "sgmii";
	phy-handle = <&phy1>;
      };

      endpoint@1 {
        sfp = <&sfp>;
	phy-mode = "sgmii";
	managed = "in-band-status";
      };
    };
  };

Signed-off-by: Marek Behún <kabel@kernel.org>
---
I wonder if this is the proper way to do this.

We already have framework for multiplexers in Linux, in drivers/mux.
But as I understand it, that framework is meant to be used when the
multiplexer state is to be set by kernel, while here it is possible
that the multiplexer state can be (and on Turris Omnia is) set by
the user plugging a SFP module into the SFP cage.

We theoretically could add a method for getting mux state into the mux
framework and state notification support. But using the mux framework
to solve this case in phylink would be rather complicated, especially
since mux framework is abstract, and if the multiplexer state is
determined by the MOD_DEF0 GPIO, which is also used by SFP code, the
implementation would get rather complicate in phylink...

I wonder whether driver implementation complexity should play a role
when proposing device tree bindings :-)

Some thoughts?
---
 .../bindings/net/ethernet-controller.yaml     | 60 +++++++++++++++++++
 1 file changed, 60 insertions(+)

On Thu, Jul 01, 2021 at 02:53:47AM +0200, Marek Behún wrote:
> There are devices where the MAC signals from the ethernet controller are
> not directly connected to an ethernet PHY or a SFP cage, but to a
> multiplexer, so that the device can switch between the endpoints.
> 
> For example on Turris Omnia the WAN controller is connected to a SerDes
> switch, which multiplexes the SerDes lanes between SFP cage and ethernet
> PHY, depending on whether a SFP module is present (MOD_DEF0 GPIO from
> the SFP cage).

At the moment, i don't think phylink supports this. It does not have a
way to dynamically switch PHY. If the SFP disappears, you probably
want to configure the PHY, so that it is up, autoneg started,
etc. When the SFP reappears, the PHY needs to be configured down, the
SFP probably needs its TX GPIO line set active, etc. None of this
currently exists.

The Marvell switches have something similar but different. Which ever
gets link first, SFP or PHY gets the data path. In this case, you
probably want phylink to configure both the SFP and the PHY, and then
wait and see what happens. The hardware will then set the mux when one
of them gets link. phylink should then configure the other
down. Again, non of this exists at the moment.

I would imaging a similar binding could be used for these two
conditions. But until we get the needed code, it is hard for me to
say. So i think i would prefer to wait until we do have code.

I also wonder how wise it is to put this into the generic ethernet
controller binding. Muxing based on MOD_DEF0 i expect to be very
rare. Muxing based on first port having link seems more likely. But
both i expect are pretty unusual. So i would be tempted to make it a
standalone binding, which can be imported into an MAC binding which
actually needs it. Or it actually becomes part of the phylink
binding, since this all appears to be PHY related, not MAC.

	  Andrew

On Fri, 2 Jul 2021 02:55:54 +0200
Andrew Lunn <andrew@lunn.ch> wrote:

> On Thu, Jul 01, 2021 at 02:53:47AM +0200, Marek Behún wrote:
> > There are devices where the MAC signals from the ethernet controller are
> > not directly connected to an ethernet PHY or a SFP cage, but to a
> > multiplexer, so that the device can switch between the endpoints.
> > 
> > For example on Turris Omnia the WAN controller is connected to a SerDes
> > switch, which multiplexes the SerDes lanes between SFP cage and ethernet
> > PHY, depending on whether a SFP module is present (MOD_DEF0 GPIO from
> > the SFP cage).  
> 
> At the moment, i don't think phylink supports this. It does not have a
> way to dynamically switch PHY. If the SFP disappears, you probably
> want to configure the PHY, so that it is up, autoneg started,
> etc. When the SFP reappears, the PHY needs to be configured down, the
> SFP probably needs its TX GPIO line set active, etc. None of this
> currently exists.

Of course this is not supported by phylink: it can't be, since we don't
even have a binding description :) I am figuring out how to do correct
binding while working on implementing this into phylink.

> The Marvell switches have something similar but different. Which ever
> gets link first, SFP or PHY gets the data path. In this case, you
> probably want phylink to configure both the SFP and the PHY, and then
> wait and see what happens. The hardware will then set the mux when one
> of them gets link. phylink should then configure the other
> down. Again, non of this exists at the moment.
> 
> I would imaging a similar binding could be used for these two
> conditions. But until we get the needed code, it is hard for me to
> say. So i think i would prefer to wait until we do have code.
> 

I now have an idea that might be sane for bindings, so next time I will
send the code as well.

> I also wonder how wise it is to put this into the generic ethernet
> controller binding. Muxing based on MOD_DEF0 i expect to be very
> rare. Muxing based on first port having link seems more likely. But
> both i expect are pretty unusual. So i would be tempted to make it a
> standalone binding, which can be imported into an MAC binding which
> actually needs it. Or it actually becomes part of the phylink
> binding, since this all appears to be PHY related, not MAC.
> 
> 	  Andrew

We'll see. Stay tuned for my patch series. :)

Marek