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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 Jan 2020 10:50:20 +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 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.

Please, avoid fixed-links with SFPs where possible, and let's
implement things correctly.

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