Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI

From: Andrew Lunn <andrew@lunn.ch>
To: "Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>
Cc: Russell King - ARM Linux admin <linux@armlinux.org.uk>,
	"antoine.tenart@free-electrons.com" 
	<antoine.tenart@free-electrons.com>,
	"jaz@semihalf.com" <jaz@semihalf.com>,
	"baruch@tkos.co.il" <baruch@tkos.co.il>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
Date: Fri, 20 Dec 2019 11:06:17 +0100	[thread overview]
Message-ID: <20191220100617.GE24174@lunn.ch> (raw)
In-Reply-To: <VI1PR04MB55679B12D4E7C9EC05FE0D9AEC2D0@VI1PR04MB5567.eurprd04.prod.outlook.com>

On Fri, Dec 20, 2019 at 09:39:08AM +0000, Madalin Bucur (OSS) wrote:
> > -----Original Message-----
> > From: Andrew Lunn <andrew@lunn.ch>
> > Sent: Friday, December 20, 2019 11:29 AM
> > To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> > Cc: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>; antoine.tenart@free-
> > electrons.com; jaz@semihalf.com; baruch@tkos.co.il; davem@davemloft.net;
> > netdev@vger.kernel.org; f.fainelli@gmail.com; hkallweit1@gmail.com;
> > shawnguo@kernel.org; devicetree@vger.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