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]

Date:   Mon, 13 Jan 2020 16:50:18 +0200
From:   Vladimir Oltean <olteanv@...il.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
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

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.

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

Thanks,
-Vladimir