Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 18 Aug 2022 22:51:51 +0300
From:   Vladimir Oltean <olteanv@gmail.com>
To:     Sean Anderson <sean.anderson@seco.com>
Cc:     netdev@vger.kernel.org, Andrew Lunn <andrew@lunn.ch>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Paolo Abeni <pabeni@redhat.com>,
        Eric Dumazet <edumazet@google.com>,
        Alexandru Marginean <alexandru.marginean@nxp.com>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 02/11] net: phy: Add 1000BASE-KX interface mode
Message-ID: <20220818195151.3aeaib54xjdhk3ch@skbuf>
References: <20220725153730.2604096-1-sean.anderson@seco.com>
 <20220725153730.2604096-3-sean.anderson@seco.com>
 <20220818165303.zzp57kd7wfjyytza@skbuf>
 <8a7ee3c9-3bf9-cfd1-67ab-bb11c1a0c82a@seco.com>
 <35779736-8787-f4cb-4160-4ff35946666d@seco.com>
 <20220818171255.ntfdxasulitkzinx@skbuf>
 <cfe3d910-adee-a3bf-96e2-ce1c10109e58@seco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <cfe3d910-adee-a3bf-96e2-ce1c10109e58@seco.com>
Precedence: bulk

On Thu, Aug 18, 2022 at 01:28:19PM -0400, Sean Anderson wrote:
> That's not what's documented:
> 
> > ``PHY_INTERFACE_MODE_10GBASER``
> >     This is the IEEE 802.3 Clause 49 defined 10GBASE-R protocol used with
> >     various different mediums. Please refer to the IEEE standard for a
> >     definition of this.
> > 
> >     Note: 10GBASE-R is just one protocol that can be used with XFI and SFI.
> >     XFI and SFI permit multiple protocols over a single SERDES lane, and
> >     also defines the electrical characteristics of the signals with a host
> >     compliance board plugged into the host XFP/SFP connector. Therefore,
> >     XFI and SFI are not PHY interface types in their own right.
> > 
> > ``PHY_INTERFACE_MODE_10GKR``
> >     This is the IEEE 802.3 Clause 49 defined 10GBASE-R with Clause 73
> >     autonegotiation. Please refer to the IEEE standard for further
> >     information.
> > 
> >     Note: due to legacy usage, some 10GBASE-R usage incorrectly makes
> >     use of this definition.
> 
> so indeed you get a new phy interface mode when you add c73 AN. The
> clarification only applies to *incorrect* usage.

I challenge you to the following thought experiment. Open clause 73 from
IEEE 802.3, and see what is actually exchanged through auto-negotiation.
You'll discover that the *use* of the 10GBase-KR operating mode is
*established* through clause 73 AN (the Technology Ability field).

So what sense does it make to define 10GBase-KR as "10Base-R with clause 73 AN"
as the document you've quoted does? None whatsoever. The K in KR stands
for bacKplane, and typical of this type of PMD are the signaling and
link training procedures described in the previous clause, 72.
Clause 73 AN is not something that is a property of 10GBase-KR, but
something that exists outside of it.

So if clause 73 *establishes* the use of 10GBase-KR (or 1000Base-KX or
others) through autonegotiation, then what sense does it have to put
phy-mode = "1000base-kx" in the device tree? Does it mean "use C73 AN",
or "don't use it, I already know what operating mode I want to use"?

If it means "use C73 AN", then what advertisement do you use for the
Technology Ability field? There's a priority resolution function for
C73, just like there is one for C28/C40 for the twisted pair medium (aka
that thing that allows you to fall back to the highest supported common
link speed). So why would you populate just one bit in Technology
Ability based on DT, if you can potentially support multiple operating
modes? And why would you even create your advertisement based on the
device tree, for that matter? Twisted pair PHYs don't do this.