netdev - Re: [RFC net-next] net: phy: Add basic support for Synopsys XPCS using a PHY driver

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: <20200113150946.GO25745@shell.armlinux.org.uk>
Date:   Mon, 13 Jan 2020 15:09:46 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     Jose Abreu <Jose.Abreu@...opsys.com>, Andrew Lunn <andrew@...n.ch>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Joao Pinto <Joao.Pinto@...opsys.com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC net-next] net: phy: Add basic support for Synopsys XPCS
 using a PHY driver

On Mon, Jan 13, 2020 at 04:50:18PM +0200, Vladimir Oltean wrote:
> Hi Russell,
> 
> On Mon, 13 Jan 2020 at 16:19, Russell King - ARM Linux admin
> <linux@...linux.org.uk> wrote:
> >
> > I've recently suggested a patch to phylink to add a generic helper to
> > read the state from a generic 802.3 clause 37 PCS, but I guess that
> > won't be sufficient for an XPCS.  However, it should give some clues
> > if you're intending to use phylink.
> >
> 
> I don't think the PCS implementations out there are sufficiently
> similar to be driven by a unified driver, and at least nothing
> mandates that for now. Although the configuration interface is MDIO
> with registers quasi-compliant to C22 or C45, many times bits in
> BMCR/BMSR are not implemented, you can't typically achieve full
> functionality [ sometimes not at all ] without writing to some
> vendor-specific registers, there might be errata workarounds that need
> to be implemented through PCS writes, often the PCS driver needs to be
> correlated with a MMIO region corresponding to that SerDes lane for
> stuff such as eye parameters.
> The code duplication isn't even all that bad.

That's opinion.

The PCS register set is defined in 802.3, and there are at least two
implementations I've come across that are compliant. I suspect there
are many more that are also compliant out there.

> _But_ I am not sure how PHYLINK comes into play here. A PHY driver
> should work with the plain PHY library too. Dealing with clause 73
> autoneg indicates to me that this is more than just a MAC PCS,
> therefore it shouldn't be tied in with PHYLINK.

I think you're looking at this wrong, or you have a misunderstanding
of where phylink sits in this.

phylink is there to help deal with SFPs, and to manage the MAC side
of the link which *includes* the MAC PCS, and interface that to
either a PHY or a SFP.  phylink has always assumed right from day
one that it will be talking to the MAC _and_ MAC PCS.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up