netdev - Re: [RFC] phylink: support for devices with MAC sharing SFP cage & PHY (e.g. Turris Omnia)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20181230224121.GA30388@lunn.ch>
Date:   Sun, 30 Dec 2018 23:41:21 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     Klaus Kudielka <klaus.kudielka@...il.com>, netdev@...r.kernel.org,
        Heiner Kallweit <hkallweit1@...il.com>,
        Russell King <linux@...linux.org.uk>,
        Uwe Kleine-König <uwe@...ine-koenig.org>,
        Tomas Hlavacek <tmshlvck@...il.com>
Subject: Re: [RFC] phylink: support for devices with MAC sharing SFP cage &
 PHY (e.g. Turris Omnia)

On Sun, Dec 30, 2018 at 02:35:32PM -0800, Florian Fainelli wrote:
> Le 12/30/18 à 1:51 AM, Andrew Lunn a écrit :
> > On Sun, Dec 30, 2018 at 09:25:53AM +0100, Klaus Kudielka wrote:
> >> Hello,
> > 
> > Hi Klaus
> > 
> > Thanks for reposting on the correct list.
> > 
> >> Apart from the 88E1514 PHY specified for eth2, the device also
> >> features an SFP cage, which uses the same SGMII of the Armada
> >> 385 SoC (a 2:1 multiplexer is driven by the MOD_DEF0 signal).
> > 
> > Some of the Marvell Ethernet switches have a similar setup. Some ports
> > have both an internal PHY and a SERDES port which can be connected to
> > an SFP cage. Whichever gets link first is connected to the MAC.  I can
> > also imagine a slightly different setup to what you have, the MUX is
> > controlled via a GPIO, not MOD_DEF0, so again, you want both active
> > until one gets link, although SFP LOS is not very reliable for this.
> > 
> > So we need a generic solution to this. In your case, the PHY should be
> > configured down when the SFP is present, but then made active when the
> > SFP is unplugged. For the Marvell switch, we need both SFP and PHY
> > active until one gets a link, and then the other configured down. So
> > it sounds like we need some board specific code involved to implement
> > the board specific parts.
> 
> There are at least two user space configuration knobs that we could
> extend to support dynamically switching between copper and fiber interface:
> 
> ethtool -s <iface> port tp|mii|fiber..
> 
> or
> 
> devlink port type eth media copper|sfp
> 
> Would that work here?

Hi Florian

I don't think so for the Turris Omnia. There is no software control
over this, the multiplexor is directly controlled via the SFP
hardware.

For the Marvel switch, it probably is an option. We have software
control of the two 'PHYS', so can control which is up and can get
link.

	Andrew