On Sat, 14 Nov 2020 21:42:04 +0000
Russell King - ARM Linux admin <linux@xxxxxxxxxxxxxxx> 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
