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] [day] [month] [year] [list]

Message-ID: <20200120113935.GC25745@shell.armlinux.org.uk>
Date:   Mon, 20 Jan 2020 11:39:35 +0000
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Jose Abreu <Jose.Abreu@...opsys.com>
Cc:     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 20, 2020 at 11:07:23AM +0000, Jose Abreu wrote:
> From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> Date: Jan/20/2020, 10:50:20 (UTC+00:00)
> 
> > On Mon, Jan 20, 2020 at 10:31:17AM +0000, Jose Abreu wrote:
> > > From: Russell King - ARM Linux admin <linux@...linux.org.uk>
> > > Date: Jan/13/2020, 14:18:17 (UTC+00:00)
> > > 
> > > > 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.
> > > 
> > > So, I think for my particular setup (that has no "real" PHY) we can have 
> > > something like this in SW PoV:
> > > 
> > > stmmac -> xpcs -> SW-PHY / Fixed PHY
> > > 
> > > - stmmac + xpcs state would be handled by phylink (MAC side)
> > > - SW-PHY / Fixed PHY state would be handled by phylink (PHY side)
> > > 
> > > This would need updates for Fixed PHY to support >1G speeds.
> > 
> > You don't want to do that if you have 1G SFPs.  Yes, you *can* do it
> > and make it work, but you miss out completely on the fact that the
> > link is supposed to be negotiated across the SFP link for 1G speeds,
> > and then you're into the realms of having to provide users ways to
> > edit the DT and reboot if the parameters at the link partner change.
> 
> You may have missed my answer to Andrew so I'll quote it here:
> 
> ---
> [...]
> 
> My current setup is this:
> 
> Host PC x86 -> PCI -> XGMAC -> XPCS -> SERDES 10G-BASE-R -> QSFP+
> 
> The only piece that needs configuration besides XGMAC is the XPCS hereby 
> 
> I "called" it a PHY [...]
> ---

I didn't miss this.

> So, besides not having a DT based setup to test changes, I also don't have 
> access to SFP bus neither SERDES ... As you suggested, I would like to 
> integrate XPCS with PHYLINK in stmmac but I'm not entirely sure on how to 
> implement the remaining connections as the connect_phy() callbacks will 
> fail because the only MMD device in the bus will be XPCS. That's why I 
> suggested the Fixed PHY approach ...

Having access to the SFP or not is not that relevent to the data link.
Generally, the SFP is not like a PHY, and doesn't take part in the
link negotiation unless it happens to contain a copper PHY.

Also, please, do not use fixed-phy support with phylink.  phylink
implements a replacement for that, where it supports fixed-links
without needing the fixed-phy stuff.  This is far more flexible
than fixed-phy which is restricted to the capabilities of clause 22
PHYs only.

To make fixed-phy support modes beyond clause 22 PHY capabilities
would need clause 45 register set emulation by swphy and a
corresponding clause 45 phylib driver; clause 45 annoyingly does
not define the 1G negotiation registers in the standard register
set, so every PHY vendor implements that using their own vendor
specific solution.

This is why phylink implements its own solution without using
fixed-phy (which I wish could be removed some day).

I would strongly recommend supporting the XPCS natively and not
via phylib.  Consider the case:

Host PC x86 -> PCI -> XGMAC -> XPCS -> SERDES 10G-BASE-R -> PHY -> RJ45

You can only have one phylib PHY attached to a network device via
connect_phy(); that is a restriction in the higher net layers.  If you
use phylib for the XPCS, how do you attach the PHY to the setup and
configure it?

Also, using a PHY via connect_phy() negates using fixed-link mode in
phylink, the two have always been exclusive.

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