netdev - Re: [RFC net-next 2/5] net: phylink: add separate pcs operations structure

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: <20200319150652.GA27807@lunn.ch>
Date:   Thu, 19 Mar 2020 16:06:52 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [RFC net-next 2/5] net: phylink: add separate pcs operations
 structure

> Oh, I forgot to mention on the library point - that's what has already
> been created in:
> 
> "net: phylink: pcs: add 802.3 clause 45 helpers"
> "net: phylink: pcs: add 802.3 clause 22 helpers"
> 
> which add library implementations for the pcs_get_state(), pcs_config()
> and pcs_an_restart() methods.
> 
> What remains is vendor specific - for pcs_link_up(), there is no
> standard, since it requires fiddling with vendor specific registers to
> program, e.g. the speed in SGMII mode when in-band is not being used.
> The selection between different PCS is also vendor specific.
> 
> It would have been nice to use these helpers for Marvell DSA switches
> too, but the complexities of DSA taking a multi-layered approach rather
> than a library approach, plus the use of paging makes it very
> difficult.
> 
> So, basically on the library point, "already considered and
> implemented".

Hi Russell

The 6390X family of switches has two PCSs, one for 1000BaseX/SGMII and
a second one for 10GBaseR. So at some point there is going to be a
mux, but maybe it will be internal to mv88e6xxx and not shareable. Or
internal to DSA, and shareable between DSA drivers. We will see.

     Andrew