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: <90ce74ef-446c-9efd-7be4-43d180ceef85@gmail.com>
Date:   Fri, 4 Jan 2019 07:26:19 +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 31.12.18 18:43, Andrew Lunn wrote:
> 
> The Marvell documentation is not public. I would have to check, but
> i think there is a bit which tells you. But as Florian pointed out,
> this can be indirectly controlled from software, in that a PHY which
> is configured down will never get link, in the same way an SFP with
> its receiver disabled will never get link. So software to enable one
> or the other would work.
> 
>> 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.
> 
> Yes, that seems a sensible restriction.
> 

I might be able come up with a re-work of phylink.c, such that it can 
manage two independent link configurations, and reconfigure the MAC upon 
a switch. The actual switching would be modeled in the various existing 
callbacks, based on a board-specific recipe (for the moment 
sfp-module-present or first-link). ethtool will probably just see the 
"active" link (i.e. the PHY/SFP connected to the MAC).

As far as I can see, this would make both the Omnia SFP and the Marvell 
switches work as they were designed, without any interface change.

Additional userspace-driven control could be added at a later time, if 
it turns out to be necessary.