From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-02.galae.net (smtpout-02.galae.net [185.246.84.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7B1F322083 for ; Sat, 11 Jul 2026 08:42:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.84.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783759343; cv=none; b=hVWPjp0tDPNNVXuJjU6aokEQcw+4vgPR/Ssm4mFvmIjW+e8euDIb5dEHib4NAna0bMRH2lPp+NN8MTGX7JIGOiky2VX1ENnn5VDtj6fcHGvwSJhLnxAjbvzgUcq2I43qrpB23K0w+L7tbTTpBJbGhZWqc6hsSfquDhyIV5HTKXo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783759343; c=relaxed/simple; bh=iS1c4hvGH/LXlRadNhieKEoeuzlGxODr9gWM+1BYuVo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fUUqUVInVOZZyDIaGWlErUtG0Qo9IUjgPOLbJLQQKL0fJbIKBrpLSSIpNQCvDrvbJUC6qAIcOo/avdum/ofaT5MugLX3Q3ciqmItoo4c3F7iDkF+/9Xz243f5KKBf7tyZEypsx3eszD52Y56QwFp4Q9nuLZ3+tQWSizIrsaaa4U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=m2w7Nr04; arc=none smtp.client-ip=185.246.84.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="m2w7Nr04" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id D289D1A0F61; Sat, 11 Jul 2026 08:42:11 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 991DC60343; Sat, 11 Jul 2026 08:42:11 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 7447411BD1CD7; Sat, 11 Jul 2026 10:42:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1783759330; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=SK7W81fF4n3/gbjdgCeCa6t2meM8xhrSq1ENEJSgQ7Q=; b=m2w7Nr04oCpdms+SFBCUOFxzClexX1LAeYhPa5uaP0r2R2b2Lj/L1WcsYyA55z1O/HCYco ULWtj4Ydbn1/X1ixFpAXNWKIZE8YWXWAg2+M3+IWBn+dIl/M9pWEcYkTQLp9r+VOhO9sDw CXFLcoYDI1Tp7Ndv/7wVRFcXXfBnqNb5z9Dim1EgqzH5s/MzyZE0DlqiDXgO1RUsYdlMQ3 MEr5KbJONSDdDJGvPIxs4d/fDDynJWDZU/03+pLT2rE1NT/EhzSVmheKMJqOTm8GfcSpEc chGBhofORDkhmwpqnjeIaL/DFzQ4mCm7qAi3lP67nA7Dedh6Pjw0L3FB8v4oMA== Message-ID: Date: Sat, 11 Jul 2026 10:42:05 +0200 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Ethtool is missing C2C link modes To: David Laight , Andrew Lunn Cc: "D H, Siddaraju" , Michal Kubecek , "netdev@vger.kernel.org" , "Chintalapalle, Balaji" , "Das, Shubham" , "Srinivasan, Vijay" , "Samudrala, Sridhar" , "Keller, Jacob E" , "Nguyen, Anthony L" , "singhai.anjali55@gmail.com" , "Brandeburg, Jesse" References: <20260711073128.7f94e0ac@pumpkin> Content-Language: en-US From: Maxime Chevallier In-Reply-To: <20260711073128.7f94e0ac@pumpkin> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 Hi, On 7/11/26 08:31, David Laight wrote: > On Sat, 11 Jul 2026 00:54:00 +0200 > Andrew Lunn wrote: > >> On Fri, Jul 10, 2026 at 09:45:43PM +0000, D H, Siddaraju wrote: >>> Hello Linux Ethernet team, Maxime, Andrew & Michal, >>> >>> The IEEE AUI chip-to-chip (C2C) is the accepted standard for connecting >>> chips that handle subfunctions within the OSI physical layer. Just to >>> pick, the C2C is widely used when connecting Ethernet SoCs with retimers >>> and PCS SerDes terminated external-phys to offload PHY sublayer functions. >> >> It cannot be that widely used if Linux does not support it yet :-) > > It also seems like something that is fixed for a physical board. > So while a common MAC driver would need to be told how to configure > its output, the user wouldn't be changing the value so it would > be more of a DT parameter than an ethtool one. > > ... >> Also, an architecture question... >> >> It sounds like you use this between the MAC and the PCS. The PCS can >> then be connected to a PHY, and the PHY then has a line side. (I'm >> being a bit loose with the terms here, i should probably be saying >> PMA, PMD etc.) >> >> Should ethtool be saying: >> >> Settings for eth0: >> Supported ports: [ TP MII ] >> Supported link modes: 25000baseC2C >> >> or should it be reporting: >> >> Settings for eth0: >> Supported ports: [ TP MII ] >> Supported link modes: 25000baseSR >> >> I _think_ ethtool reports the media, not some intermediary format. > > You'd want to use ethtool to set the final link parameters of the > external phy? > So I think you's still want to be able to select (say) 100MHDX > for a TP link. > > Remember the history. > The parameter was originally used to select between the the AUI, COAX and TP > connectors on a 10M ethernet card. > Then the internal TP gained extra speeds. > We then get MII for external 10M and 100M PHY, later RGMII for external Ge PHY. > But you rarely get boards (not MAC chips) that have a choice of interfaces > any more. Note that there's ongoing work[1] to better support nics with multiple connectors, which also includes reporting what the 'media-side' of a MAC / PHY can do : [1]: https://lore.kernel.org/netdev/20260701110427.143945-1-maxime.chevallier@bootlin.com/#t Taking the example of a combo-port (SFP + RJ45), it would look like that : ethtool --show-ports eth1 Port for eth1: Port id: 1 Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full 10000baseT/Full 2500baseT/Full 5000baseT/Full Port type: mdi Port for eth1: Port id: 2 Supported MII interfaces : 10gbase-r Port type: sfp or even # ethtool --show-ports eth3 Port for eth3: Port id: 1 Supported MII interfaces : sgmii, 1000base-x, 2500base-x Port type: sfp Now, with this infrastucture also comes the ability to list the media-side interfaces that are not MDI but rather MII. The main goal is combo-port support, but also media-converters, e.g. things like : MAC ------ PHY ------- rgmii sgmii (for now, the ongoing series focus on supporting this through SFP, but extending that to other link types is something I'd like to achieve) As Andrew says, when you use "ethtool ethX", the list you get is the media-side modes that you can use at the connector, so it's an aggregated list of the MDI that are usable based on the MAC, PCS, PHY you're using (MAC and PCS would limit speed/encoding, PHY defines the actual MDI modes) For the C2C modes, it's not clear to me if these are MDI modes, i.e: ETHTOOL_LINK_MODE_25000baseC2C Or a phy_interface_t, i.e: PHY_INTERFACE_MODE_25GAUI We already have XAUI and RXAUI as phy_interface_t as of today, so it looks like we don't want an ethool linkmode for that but rather a phy_interface_t Maxime