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:   Fri, 20 Dec 2019 11:06:17 +0100
From:   Andrew Lunn <andrew@...n.ch>
To:     "Madalin Bucur (OSS)" <madalin.bucur@....nxp.com>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        "antoine.tenart@...e-electrons.com" 
        <antoine.tenart@...e-electrons.com>,
        "jaz@...ihalf.com" <jaz@...ihalf.com>,
        "baruch@...s.co.il" <baruch@...s.co.il>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

On Fri, Dec 20, 2019 at 09:39:08AM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: Friday, December 20, 2019 11:29 AM
> > To: Russell King - ARM Linux admin <linux@...linux.org.uk>
> > Cc: Madalin Bucur (OSS) <madalin.bucur@....nxp.com>; antoine.tenart@...e-
> > electrons.com; jaz@...ihalf.com; baruch@...s.co.il; davem@...emloft.net;
> > netdev@...r.kernel.org; f.fainelli@...il.com; hkallweit1@...il.com;
> > shawnguo@...nel.org; devicetree@...r.kernel.org
> > Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
> > 
> > > How does this help us when we can't simply change the existing usage?
> > > We can update the DT but we can't free up the usage of "10gbase-kr".
> > 
> > Agreed. Code needs to keep on interpreting "10gbase-kr" as any 10G
> > link. If we ever have a true 10gbase-kr, 802.3ap, one meter of copper
> > and two connectors, we are going to have to add a new mode to
> > represent true 10gbase-kr.
> > 
> > 	Andrew
> 
> Hi, actually we do have that. What would be the name of the new mode
> representing true 10GBase-KR that we will need to add when we upstream
> support for that?

Ah!

This is going to be messy.

Do you really need to differentiate? What seems to make 802.3ap
different is the FEC, autoneg and link training. Does you hardware
support this? Do you need to know you are supposed to be using 802.3ap
in order to configure these features?

What are we going to report to user space? 10gbase-kr, or
10gbase-kr-true? How do we handle the mess this makes with firmware
based cards which correctly report
ETHTOOL_LINK_MODE_10000baseKR_Full_BIT to user space?

What do we currently report to user space? Is it possible for us to
split DT from user space? DT says 10gbase-kr-true but to user space we
say ETHTOOL_LINK_MODE_10000baseKR_Full_BIT?

I think in order to work through these issues, somebody probably needs
the hardware, and the desire to see it working. So it might actually
be you who makes a proposal how we sort this out, with help from
Russell and I.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ