Re: [PATCH mvebu-dt v2 4/6] ARM: dts: turris-omnia: add SFP node

["Marek Behún" <kabel@kernel.org>]

On Sat, 14 Nov 2020 21:42:04 +0000
Russell King - ARM Linux admin <linux@armlinux.org.uk> wrote:

> On Sat, Nov 14, 2020 at 10:36:09PM +0100, Andreas Färber wrote:
> > Hi Marek,
> > 
> > On 14.11.20 19:32, Marek Behún wrote:  
> > > Turris Omnia has a SFP cage that, together with WAN PHY is connected to  
> > 
> > "an SFP"
> > Comma missing after PHY (or drop before together).
> >   
> > > eth2 SerDes via a SerDes multiplexor. Describe the SFP cage, but leave
> > > it disabled. Until phylink has support for such multiplexor we will
> > > leave it to U-Boot to enable SFP and disable WAN PHY at boot time
> > > depending on whether a SFP module is present.  
> > 
> > multiplexor vs. multiplexer may be a British thing? Thunderbird
> > underlines it fwiw.  
> 
> Why doesn't someone who has a Turris Omnia come up with the support
> needed for this board, such as sending a patch to add support for
> this multiplexer?
> 

Russell, I have this planned, but it is a bit complicated.
We discussed this maybe 1 or 2 years ago.

The thing is that phylink does not support such a thing nor is there a
simple way to add such support to it.

One problem we discussed last time is the correct DT binding. Should it
be something like this?
  eth2 {
    phy-mode = "sgmii";

    multiplexer {
      gpio = <&mod_def0_gpio>;

      option@0 {
        reg = <0>;
        phy-handle = <&phy1>;
      };

      option@1 {
        reg = <1>;
        sfp = <&sfp>;
        managed = "in-band-status";
      };
    };
  };

But who should handle this? Phylink, SFP, or maybe this should be
handled generically in OF / fwnode subsystem? I.e. a change in GPIO
value could change device's properties/children?

Also the &mod_def0_gpio is already used by the sfp node. Can this
multiplexor node also refer to it?

Marek