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]

Date:   Mon, 31 Dec 2018 12:24:18 +0100
From:   Klaus Kudielka <klaus.kudielka@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, Florian Fainelli <f.fainelli@...il.com>,
        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 30.12.18 10:51, Andrew Lunn wrote:

> 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.

This decision is taken by hardware? I am just wondering how the outcome
would be detected unambiguously by software. (Any documentation?)

> 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.

Okay, here the decision for the MUX would be taken by software.

> 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.

That would be the ideal solution for the Omnia.

> 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.

Such a "generic" solution would be restricted (per MAC) to a maximum of 
one SFP (fiber or copper), and one separate PHY, right? The main 
difference between boards would be the switching logic.

Klaus