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 3825A3A641C for ; Mon, 9 Mar 2026 14:16:56 +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=1773065819; cv=none; b=NVHRdSNTRixEzN3iD7RGcIX0MC+VCe6Hy0LliKlAj0Ow1MRLZ3Z0PKpbXnuzHHSggd+1+GIBuGYiCqmIeXw+4YkcGWR4/CokYDIm9tT8P87I0wQasBp7dCQutx7Py0QNbvvOQjbITzhu+s2mAFb0XgoPNTqDrpe4FZdPgd9e/+A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773065819; c=relaxed/simple; bh=8liySUEDGYrpUI1rMgWcIxLKUNWyHE5MJ7BpW1iSeNo=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=L93pY3ip0ObwPXhAJzqFCx4EmAJukyd1xxa+bZVkB2ZZqGPONm5Jjdd1XtskgK+1Y7f1Op4jxp3Qfe+NmnxJoNk4mzwpbHUEpz95g3Suxq9xmbvhzE0ZBiky7Sp01zen8+nm/n+xwMt3f3ZzIoIoQXW32nQXYktvM3geug0aUNE= 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=X5Pq2wBX; 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="X5Pq2wBX" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 9F6251A2D5D; Mon, 9 Mar 2026 14:16:54 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 6CE825FFB8; Mon, 9 Mar 2026 14:16:54 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B71C910369A24; Mon, 9 Mar 2026 15:16:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1773065813; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=B6Sfd+3RAw+T1+wBoUFyStbgtRDwov9ZbOCNeaAw/iE=; b=X5Pq2wBXmLmNdseOmRz8sJ1oQbGCKF/UO0qIGck3B8QYoU4lPzZnRkCriDP+scGSrLw0p8 1hh3Q4mDb3f5VbnqPjfcqncqGVvwY36KjcSr/N30fE7lQDnXVTK+YF8qci7NGGN8OBEAL8 IgO+lbuiq5tfdzHj3RZjKzNHNYGtugJWUyY3nEOk1TpeVzwgdbZwP4sEIBD9zqTXOXuZTP prlcO0ODgdF0rLSeU4eeWUzlaC0cmUOsoFQzutXbtad10TnqyGPAsxV0tsg3kNMCPbBf1W ZIHKEKCP90/uerxYc/VjRKkLl9xAcVAUz06AEQ0Z1LuMkhmy9sXl7kDqIaGqDQ== Message-ID: <456697d6-c0d8-4edf-abd2-85062f4b25ab@bootlin.com> Date: Mon, 9 Mar 2026 15:16:45 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC net-next v2 1/6] ethtool: Add loopback netlink UAPI definitions To: =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= , netdev@vger.kernel.org, Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Saeed Mahameed , Tariq Toukan , Leon Romanovsky , Andrew Lunn Cc: Andrew Lunn , Michael Chan , Hariprasad Kelam , Ido Schimmel , Danielle Ratson , linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, Russell King References: <20260308124016.3134012-1-bjorn@kernel.org> <20260308124016.3134012-2-bjorn@kernel.org> From: Maxime Chevallier Content-Language: en-US In-Reply-To: <20260308124016.3134012-2-bjorn@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Hi, On 08/03/2026 13:40, Björn Töpel wrote: > Add the netlink YAML spec and auto-generated UAPI header for a unified > loopback interface covering MAC, PCS, PHY, and pluggable module > components. > > Each loopback point is described by a nested entry attribute > containing: > > - component where in the path (MAC, PCS, PHY, MODULE) > - name subsystem label, e.g. "cmis-host" or "cmis-media" > - id optional instance selector (e.g. PHY id, port id) > - supported bitmask of supported directions > - direction NEAR_END, FAR_END, or 0 (disabled) > > Signed-off-by: Björn Töpel > --- > Documentation/netlink/specs/ethtool.yaml | 115 ++++++++++++++++++ > .../uapi/linux/ethtool_netlink_generated.h | 52 ++++++++ > 2 files changed, 167 insertions(+) > > diff --git a/Documentation/netlink/specs/ethtool.yaml b/Documentation/netlink/specs/ethtool.yaml > index 4707063af3b4..05ebad6ae4e0 100644 > --- a/Documentation/netlink/specs/ethtool.yaml > +++ b/Documentation/netlink/specs/ethtool.yaml > @@ -211,6 +211,39 @@ definitions: > name: discard > value: 31 > > + - > + name: loopback-component > + type: enum > + doc: | > + Loopback component. Identifies where in the network path the > + loopback is applied. > + entries: > + - > + name: mac > + doc: MAC loopback > + - > + name: pcs > + doc: PCS loopback > + - > + name: phy > + doc: PHY loopback > + - > + name: module > + doc: Pluggable module (e.g. CMIS (Q)SFP) loopback Should we also add "serdes" ? > + - > + name: loopback-direction > + type: flags > + doc: | > + Loopback direction flags. Used as a bitmask in supported, and as > + a single value in direction. > + entries: > + - > + name: near-end > + doc: Near-end loopback; host-loop-host > + - > + name: far-end > + doc: Far-end loopback; line-loop-line > + > attribute-sets: > - > name: header > @@ -1903,6 +1936,60 @@ attribute-sets: > name: link > type: nest > nested-attributes: mse-snapshot > + - > + name: loopback-entry > + doc: Per-component loopback configuration entry. > + attr-cnt-name: __ethtool-a-loopback-entry-cnt > + attributes: > + - > + name: unspec > + type: unused > + value: 0 > + - > + name: component > + type: u32 > + enum: loopback-component > + doc: Loopback component > + - > + name: id > + type: u32 > + doc: | > + Optional component instance identifier. Required for PHY, > + optional for MODULE, omitted for MAC and PCS. it doesn't have to be required for PHY. The current idea is that if you don't pass any PHY index when issueing a PHY-targetting command, then it means you're targetting net_device->phydev, that is the PHY device attached to the netdev (if any). I think we can keep that behaviour, as systems with multiple PHYs are not very common. > + - > + name: name > + type: string > + doc: | > + Subsystem-specific name for the loopback point within the > + component. We'll need to be careful about keeping this subsystem-specific and not driver-specific :) > + - > + name: supported > + type: u32 > + enum: loopback-direction > + enum-as-flags: true > + doc: Bitmask of supported loopback directions > + - > + name: direction > + type: u32 > + enum: loopback-direction > + doc: Current loopback direction, 0 means disabled no need for an u32 for 3 different values I think :) Maxime