From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29F28C43603 for ; Fri, 20 Dec 2019 10:06:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id ED33D2465E for ; Fri, 20 Dec 2019 10:06:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="hmNDsrcT" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727209AbfLTKG1 (ORCPT ); Fri, 20 Dec 2019 05:06:27 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:34806 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727129AbfLTKG1 (ORCPT ); Fri, 20 Dec 2019 05:06:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=as6IYqvOwKnH4gVYbLvmr3OksXVTViVqoOiYR3nLmvE=; b=hmNDsrcTVknj3kMDP0UCFSAoV+ RFtmlaTTJJyTlSca604hHzHP+cBr5N4IQTWVE5VjvvBXIPVBYFpkII9IXVYOTebr0QOc78mERvWrG 8G/245hWZbp5c46AKG/RmKY+UNcs8jOcRIcGXCeNTPonUMZF/4ovd119+IbDc3J9Xv94=; Received: from andrew by vps0.lunn.ch with local (Exim 4.93) (envelope-from ) id 1iiFAn-0007He-MV; Fri, 20 Dec 2019 11:06:17 +0100 Date: Fri, 20 Dec 2019 11:06:17 +0100 From: Andrew Lunn To: "Madalin Bucur (OSS)" Cc: Russell King - ARM Linux admin , "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 Message-ID: <20191220100617.GE24174@lunn.ch> References: <1576768881-24971-2-git-send-email-madalin.bucur@oss.nxp.com> <20191219172834.GC25745@shell.armlinux.org.uk> <20191219190308.GE25745@shell.armlinux.org.uk> <20191219214930.GG25745@shell.armlinux.org.uk> <20191220091642.GJ25745@shell.armlinux.org.uk> <20191220092900.GB24174@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: devicetree-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Fri, Dec 20, 2019 at 09:39:08AM +0000, Madalin Bucur (OSS) wrote: > > -----Original Message----- > > From: Andrew Lunn > > Sent: Friday, December 20, 2019 11:29 AM > > To: Russell King - ARM Linux admin > > Cc: Madalin Bucur (OSS) ; 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