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]
Message-ID: <20200120105020.GB25745@shell.armlinux.org.uk>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ