Message ID | 20231221180047.1924733-1-maxime.chevallier@bootlin.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:2483:b0:fb:cd0c:d3e with SMTP id q3csp586121dyi; Thu, 21 Dec 2023 10:01:54 -0800 (PST) X-Google-Smtp-Source: AGHT+IHkUVgCvrkFbl4yxTcQBELwddRctyhmkxIRvswGFciy5NfNEJuQ/WWuwm2JLFwxB5KWp2Vc X-Received: by 2002:a05:6a00:179d:b0:6d8:c7f:230d with SMTP id s29-20020a056a00179d00b006d80c7f230dmr64151pfg.53.1703181713851; Thu, 21 Dec 2023 10:01:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703181713; cv=none; d=google.com; s=arc-20160816; b=HU0Pm8Tz2G9yeFf2UIPBnSDfm67yiLooiBQMraNKHh1N4zDWwTPcJ4/CC5hnIuF1Hb ZZKWT04H1Su0B6hHazU6FlGowyKphwFX3W8fVM08wIF5HIkunWUb2i1mNorzAqBO7JbN qP/9TIwe9Psxm6jWYKug3f5Rv3lJxNgWxKWfp5js96N3kidvc0qZ2DSRIIB0UBTCy3nt EGetS6PWg7BV4LhD9PBF6t6tCDuWYc5VLoXBGmalYlu7Q1R7DzcHt/VtZ93mnvBraDkI U80kHpKhdWsVmmgBTNW6bjHauj22n9fXn4x8vc5hfWASyobOBrcyL3fM8QdwlEkZz6d7 sgiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=pLfUBXSK8a7cGIdBEXRdpdqUEl/s96oL7RSSS90KpDU=; fh=d3Krop4IPE3x6nBOvh3GY5QHg6bS91zVnQiH59I3hyM=; b=v1X6DLECbwsvpMqS52v7WmNKVhHHLpwat4qEvyqANPx9MSBV9lnFDNDXTK4Ge0U342 v94c5N8gNQHDKKOHwxnEyjL0+aOH7RT0H9vBlvuNznp0lR1GFIzdj9nLw40sjDXQSltv /KmaFJFx2KrogVrQSsyJ0P/PhwazGpwlPlzqFn09zuFyegdJ1uFpT47TETfUFjwdexkl XuIhQaY2tBqAQsayjJlJf9Q2gBiJ72RYQpNIl6Z0NpcZrUwJLE16okrIKiqYIXwzDiKT JmAMtU4SZ3RH2qGxuvO8Ib9yFNMGEFxCXTPN0gIqz5bH4VANRPkh8pkNCeFyUB+GS47S P3YA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=VVQVgJMQ; spf=pass (google.com: domain of linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [2604:1380:45e3:2400::1]) by mx.google.com with ESMTPS id a25-20020a62e219000000b006d52b0c27c2si1863883pfi.373.2023.12.21.10.01.53 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 Dec 2023 10:01:53 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=VVQVgJMQ; spf=pass (google.com: domain of linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-8885-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 98DFA289159 for <ouuuleilei@gmail.com>; Thu, 21 Dec 2023 18:01:53 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A69A65191; Thu, 21 Dec 2023 18:01:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="VVQVgJMQ" X-Original-To: linux-kernel@vger.kernel.org Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (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 4D48D6280B; Thu, 21 Dec 2023 18:00:53 +0000 (UTC) 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 Received: by mail.gandi.net (Postfix) with ESMTPSA id 588621C0002; Thu, 21 Dec 2023 18:00:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1703181652; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=pLfUBXSK8a7cGIdBEXRdpdqUEl/s96oL7RSSS90KpDU=; b=VVQVgJMQqrmyuC4x4YX5NgTvjic7GtS3r5Czbrg59f66MoRrtUKwgSN6qoNdxFHpgDwAmi LMtx4pZ5TSltivhbRWFmGZ7xZFfxBSk15qJ14OHfwKjgDaSu/zK7Q9TeH2mU+ydtIPBAPj d/SC8miSB+d+03JJuIZHMVcnCh04piZXX3LXjVFYjy8J5nvDnfd7J/iz74sSVWMQVJN6I4 dR1nCwGjlTNrz6WTJvSti3NBy2Dz8Sb3rtiQ2TBnimArttJB2Bo/Qc+bqWH1JHf8Xdo5bH 4jOk9sj7sqJ62PZnesPmHzUZtBRKlCv9AW5FQILjwBX6hw/yYpkR8AarsAeCqw== From: Maxime Chevallier <maxime.chevallier@bootlin.com> To: davem@davemloft.net Cc: Maxime Chevallier <maxime.chevallier@bootlin.com>, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Andrew Lunn <andrew@lunn.ch>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Russell King <linux@armlinux.org.uk>, linux-arm-kernel@lists.infradead.org, Christophe Leroy <christophe.leroy@csgroup.eu>, Herve Codina <herve.codina@bootlin.com>, Florian Fainelli <f.fainelli@gmail.com>, Heiner Kallweit <hkallweit1@gmail.com>, Vladimir Oltean <vladimir.oltean@nxp.com>, =?utf-8?q?K=C3=B6ry_Maincent?= <kory.maincent@bootlin.com>, Jesse Brandeburg <jesse.brandeburg@intel.com>, Jonathan Corbet <corbet@lwn.net>, =?utf-8?q?Marek_Beh=C3=BAn?= <kabel@kernel.org>, Piergiorgio Beruto <piergiorgio.beruto@gmail.com>, Oleksij Rempel <o.rempel@pengutronix.de>, =?utf-8?q?Nicol=C3=B2_Veronese?= <nicveronese@gmail.com>, Simon Horman <horms@kernel.org> Subject: [PATCH net-next v5 00/13] Introduce PHY listing and link_topology tracking Date: Thu, 21 Dec 2023 19:00:33 +0100 Message-ID: <20231221180047.1924733-1-maxime.chevallier@bootlin.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-GND-Sasl: maxime.chevallier@bootlin.com X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785915468583455877 X-GMAIL-MSGID: 1785915468583455877 |
Series |
Introduce PHY listing and link_topology tracking
|
|
Message
Maxime Chevallier
Dec. 21, 2023, 6 p.m. UTC
Hello everyone, Here's a V5 of the multi-PHY support series. At a glance, besides some minor fixes and R'd-by from Andrew, one of the thing this series does is remove the ASSERT_RTNL() from the topo_add_phy/del_phy operations. These operations will take a PHY device and put it into the list of devices associated to a netdevice. The main thing to protect here is the list itself, but since we use xarrays, my naive understanding of it is that it contains its own protection scheme. There shouldn't be a need for more locking, as the insertion/deletion paths are already hooked into the PHY connection to a netdev, or disconnection from it. Now for the rest of the cover : As a remainder, this ongoing work aims ultimately at supporting complex link topologies that involve multiplexing multiple PHYs/SFPs on a single netdevice. As a first step, it's required that we are able to enumerate the PHYs on a given ethernet interface. By just doing so, we also improve already-existing use-cases, namely the copper SFP modules support when a media-converter is used (as we have 2 PHYs on the link, but only one is referenced by net_device.phydev, which is used on a variety of netlink commands). The series is architectured as follows : - The first patch adds the notion of phy_link_topology, which tracks all PHYs attached to a netdevice. - Patches 2, 3 and 4 adds some plumbing into SFP and phylib to be able to connect the dots when building the topology tree, to know which PHY is connected to which SFP bus, trying not to be too invasive on phylib. - Patch 5 allows passing a PHY_INDEX to ethnl commands. I'm uncertain about this, as there are at least 4 netlink commands ( 5 with the one introduced in patch 7 ) that targets PHYs directly or indirectly, which to me makes it worth-it to have a generic way to pass a PHY index to commands, however the approach taken may be too generic. - Patch 6 is the netlink spec update + ethtool-user.c|h autogenerated code update (the autogenerated code triggers checkpatch warning though) - Patch 7 introduces a new netlink command set to list PHYs on a netdevice. It implements a custom DUMP and GET operation to allow filtered dumps, that lists all PHYs on a given netdevice. I couldn't use most of ethnl's plumbing though. - Patch 8 is the netlink spec update + ethtool-user.c|h update for that new command - Patch 8,9,10 and 11 updates the PLCA, strset, cable-test and pse netlink commands to use the user-provided PHY instead of net_device.phydev. - Finally patch 12 adds some documentation for this whole work. Examples ======== Here's a short overview of the kind of operations you can have regarding the PHY topology. These tests were performed on a MacchiatoBin, which has 3 interfaces : eth0 and eth1 have the following layout: MAC - PHY - SFP eth2 has this more classic topology : MAC - PHY - RJ45 finally eth3 has the following topology : MAC - SFP When performing a dump with all interfaces down, we don't get any result, as no PHY has been attached to their respective net_device : # ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get None The following output is with eth0, eth2 and eth3 up, but no SFP module inserted in none of the interfaces : # ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get [{'downstream-sfp-name': 'sfp-eth0', 'drvname': 'mv88x3310', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 0, 'index': 1, 'name': 'f212a600.mdio-mii:00', 'upstream-type': 'mac'}, {'drvname': 'Marvell 88E1510', 'header': {'dev-index': 4, 'dev-name': 'eth2'}, 'id': 21040593, 'index': 1, 'name': 'f212a200.mdio-mii:00', 'upstream-type': 'mac'}] And now is a dump operation with a copper SFP in the eth0 port : # ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml --dump phy-get [{'downstream-sfp-name': 'sfp-eth0', 'drvname': 'mv88x3310', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 0, 'index': 1, 'name': 'f212a600.mdio-mii:00', 'upstream-type': 'mac'}, {'drvname': 'Marvell 88E1111', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 21040322, 'index': 2, 'name': 'i2c:sfp-eth0:16', 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'}, 'upstream-type': 'phy'}, {'drvname': 'Marvell 88E1510', 'header': {'dev-index': 4, 'dev-name': 'eth2'}, 'id': 21040593, 'index': 1, 'name': 'f212a200.mdio-mii:00', 'upstream-type': 'mac'}] -- Note that this shouldn't actually work as the 88x3310 PHY doesn't allow a 1G SFP to be connected to its SFP interface, and I don't have a 10G copper SFP, so for the sake of the demo I applied the following modification, which of courses gives a non-functionnal link, but the PHY attach still works, which is what I want to demonstrate : @@ -488,7 +488,7 @@ static int mv3310_sfp_insert(void *upstream, const struct sfp_eeprom_id *id) if (iface != PHY_INTERFACE_MODE_10GBASER) { dev_err(&phydev->mdio.dev, "incompatible SFP module inserted\n"); - return -EINVAL; + //return -EINVAL; } return 0; } Finally an example of the filtered DUMP operation that Jakub suggested in V1 : # ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \ # --dump phy-get --json '{"header" : {"dev-name" : "eth0"}}' [{'downstream-sfp-name': 'sfp-eth0', 'drvname': 'mv88x3310', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 0, 'index': 1, 'name': 'f212a600.mdio-mii:00', 'upstream-type': 'mac'}, {'drvname': 'Marvell 88E1111', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 21040322, 'index': 2, 'name': 'i2c:sfp-eth0:16', 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'}, 'upstream-type': 'phy'}] And a classic GET operation allows querying a single PHY's info : # ./cli.py --spec specs/ethtool.yaml --schema genetlink-legacy.yaml \ # --do phy-get --json '{"header" : {"dev-name" : "eth0", "phy-index" : 2}}' {'drvname': 'Marvell 88E1111', 'header': {'dev-index': 2, 'dev-name': 'eth0'}, 'id': 21040322, 'index': 2, 'name': 'i2c:sfp-eth0:16', 'upstream': {'index': 1, 'sfp-name': 'sfp-eth0'}, 'upstream-type': 'phy'} Changed in V5: - Removed the RTNL assertion in the topology ops - Made the phy_topo_get_phy inline - Fixed the PSE-PD multi-PHY support by re-adding a wrongly dropped check - Fixed some typos in the documentation - Fixed reverse xmas trees Changes in V4: - Dropped the RFC flag - Made the net_device integration independent to having phylib enabled - Removed the autogenerated ethtool-user code for the YNL specs Changes in V3: - Added RTNL assertions where needed - Fixed issues in the DUMP code for PHY_GET, which crashed when running it twice in a row - Added the documentation, and moved in-source docs around - renamed link_topology to phy_link_topology Changes in V2: - Added the DUMP operation - Added much more information in the reported data, to be able to reconstruct precisely the topology tree - renamed phy_list to link_topology Maxime Chevallier (13): net: phy: Introduce ethernet link topology representation net: sfp: pass the phy_device when disconnecting an sfp module's PHY net: phy: add helpers to handle sfp phy connect/disconnect net: sfp: Add helper to return the SFP bus name net: ethtool: Allow passing a phy index for some commands netlink: specs: add phy-index as a header parameter net: ethtool: Introduce a command to list PHYs on an interface netlink: specs: add ethnl PHY_GET command set net: ethtool: plca: Target the command to the requested PHY net: ethtool: pse-pd: Target the command to the requested PHY net: ethtool: cable-test: Target the command to the requested PHY net: ethtool: strset: Allow querying phy stats by index Documentation: networking: document phy_link_topology Documentation/netlink/specs/ethtool.yaml | 68 ++++ Documentation/networking/ethtool-netlink.rst | 51 +++ Documentation/networking/index.rst | 1 + .../networking/phy-link-topology.rst | 121 +++++++ MAINTAINERS | 2 + drivers/net/phy/Makefile | 2 +- drivers/net/phy/at803x.c | 2 + drivers/net/phy/marvell-88x2222.c | 2 + drivers/net/phy/marvell.c | 2 + drivers/net/phy/marvell10g.c | 2 + drivers/net/phy/phy_device.c | 55 ++++ drivers/net/phy/phy_link_topology.c | 66 ++++ drivers/net/phy/phylink.c | 3 +- drivers/net/phy/sfp-bus.c | 15 +- include/linux/netdevice.h | 4 +- include/linux/phy.h | 6 + include/linux/phy_link_topology.h | 67 ++++ include/linux/phy_link_topology_core.h | 19 ++ include/linux/sfp.h | 8 +- include/uapi/linux/ethtool.h | 16 + include/uapi/linux/ethtool_netlink.h | 30 ++ net/core/dev.c | 3 + net/ethtool/Makefile | 2 +- net/ethtool/cabletest.c | 12 +- net/ethtool/netlink.c | 33 ++ net/ethtool/netlink.h | 12 +- net/ethtool/phy.c | 306 ++++++++++++++++++ net/ethtool/plca.c | 13 +- net/ethtool/pse-pd.c | 9 +- net/ethtool/strset.c | 15 +- 30 files changed, 912 insertions(+), 35 deletions(-) create mode 100644 Documentation/networking/phy-link-topology.rst create mode 100644 drivers/net/phy/phy_link_topology.c create mode 100644 include/linux/phy_link_topology.h create mode 100644 include/linux/phy_link_topology_core.h create mode 100644 net/ethtool/phy.c
Comments
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Thu, 21 Dec 2023 19:00:33 +0100 you wrote: > Hello everyone, > > Here's a V5 of the multi-PHY support series. > > At a glance, besides some minor fixes and R'd-by from Andrew, one of the > thing this series does is remove the ASSERT_RTNL() from the > topo_add_phy/del_phy operations. > > [...] Here is the summary with links: - [net-next,v5,01/13] net: phy: Introduce ethernet link topology representation https://git.kernel.org/netdev/net-next/c/02018c544ef1 - [net-next,v5,02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY https://git.kernel.org/netdev/net-next/c/9c5625f559ad - [net-next,v5,03/13] net: phy: add helpers to handle sfp phy connect/disconnect https://git.kernel.org/netdev/net-next/c/034fcc210349 - [net-next,v5,04/13] net: sfp: Add helper to return the SFP bus name https://git.kernel.org/netdev/net-next/c/dedd702a3579 - [net-next,v5,05/13] net: ethtool: Allow passing a phy index for some commands https://git.kernel.org/netdev/net-next/c/2ab0edb505fa - [net-next,v5,06/13] netlink: specs: add phy-index as a header parameter https://git.kernel.org/netdev/net-next/c/c29451aefcb4 - [net-next,v5,07/13] net: ethtool: Introduce a command to list PHYs on an interface https://git.kernel.org/netdev/net-next/c/63d5eaf35ac3 - [net-next,v5,08/13] netlink: specs: add ethnl PHY_GET command set https://git.kernel.org/netdev/net-next/c/95132a018f00 - [net-next,v5,09/13] net: ethtool: plca: Target the command to the requested PHY https://git.kernel.org/netdev/net-next/c/7db69ec9cfb8 - [net-next,v5,10/13] net: ethtool: pse-pd: Target the command to the requested PHY https://git.kernel.org/netdev/net-next/c/345237dbc1bd - [net-next,v5,11/13] net: ethtool: cable-test: Target the command to the requested PHY https://git.kernel.org/netdev/net-next/c/fcc4b105caa4 - [net-next,v5,12/13] net: ethtool: strset: Allow querying phy stats by index https://git.kernel.org/netdev/net-next/c/d078d480639a - [net-next,v5,13/13] Documentation: networking: document phy_link_topology https://git.kernel.org/netdev/net-next/c/32bb4515e344 You are awesome, thank you!
... and I haven't reviewed this yet. I guess it's now pointless to review. On Mon, Jan 01, 2024 at 06:40:27PM +0000, patchwork-bot+netdevbpf@kernel.org wrote: > Hello: > > This series was applied to netdev/net-next.git (main) > by David S. Miller <davem@davemloft.net>: > > On Thu, 21 Dec 2023 19:00:33 +0100 you wrote: > > Hello everyone, > > > > Here's a V5 of the multi-PHY support series. > > > > At a glance, besides some minor fixes and R'd-by from Andrew, one of the > > thing this series does is remove the ASSERT_RTNL() from the > > topo_add_phy/del_phy operations. > > > > [...] > > Here is the summary with links: > - [net-next,v5,01/13] net: phy: Introduce ethernet link topology representation > https://git.kernel.org/netdev/net-next/c/02018c544ef1 > - [net-next,v5,02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY > https://git.kernel.org/netdev/net-next/c/9c5625f559ad > - [net-next,v5,03/13] net: phy: add helpers to handle sfp phy connect/disconnect > https://git.kernel.org/netdev/net-next/c/034fcc210349 > - [net-next,v5,04/13] net: sfp: Add helper to return the SFP bus name > https://git.kernel.org/netdev/net-next/c/dedd702a3579 > - [net-next,v5,05/13] net: ethtool: Allow passing a phy index for some commands > https://git.kernel.org/netdev/net-next/c/2ab0edb505fa > - [net-next,v5,06/13] netlink: specs: add phy-index as a header parameter > https://git.kernel.org/netdev/net-next/c/c29451aefcb4 > - [net-next,v5,07/13] net: ethtool: Introduce a command to list PHYs on an interface > https://git.kernel.org/netdev/net-next/c/63d5eaf35ac3 > - [net-next,v5,08/13] netlink: specs: add ethnl PHY_GET command set > https://git.kernel.org/netdev/net-next/c/95132a018f00 > - [net-next,v5,09/13] net: ethtool: plca: Target the command to the requested PHY > https://git.kernel.org/netdev/net-next/c/7db69ec9cfb8 > - [net-next,v5,10/13] net: ethtool: pse-pd: Target the command to the requested PHY > https://git.kernel.org/netdev/net-next/c/345237dbc1bd > - [net-next,v5,11/13] net: ethtool: cable-test: Target the command to the requested PHY > https://git.kernel.org/netdev/net-next/c/fcc4b105caa4 > - [net-next,v5,12/13] net: ethtool: strset: Allow querying phy stats by index > https://git.kernel.org/netdev/net-next/c/d078d480639a > - [net-next,v5,13/13] Documentation: networking: document phy_link_topology > https://git.kernel.org/netdev/net-next/c/32bb4515e344 > > You are awesome, thank you! > -- > Deet-doot-dot, I am a bot. > https://korg.docs.kernel.org/patchwork/pwbot.html > > >
On Tue, 2 Jan 2024 11:57:09 +0000 Russell King (Oracle) wrote: > ... and I haven't reviewed this yet. I guess it's now pointless to > review. I guess the shutdown was only a partial success. Nobody cleaned out pending stuff on the 23rd, and old things got applied now before we even officially reopened :( It is what it is, please review anyway, we'll be reverting things which shouldn't have been applied..
Hi Russell, Jakub, On Tue, 2 Jan 2024 10:51:25 -0800 Jakub Kicinski <kuba@kernel.org> wrote: > On Tue, 2 Jan 2024 11:57:09 +0000 Russell King (Oracle) wrote: > > ... and I haven't reviewed this yet. I guess it's now pointless to > > review. > > I guess the shutdown was only a partial success. Nobody cleaned out > pending stuff on the 23rd, and old things got applied now before we > even officially reopened :( It is what it is, please review anyway, > we'll be reverting things which shouldn't have been applied.. I've submitted the ethtool counterpart of that work a few seconds ago : https://lore.kernel.org/netdev/20240103142950.235888-1-maxime.chevallier@bootlin.com/T/#m334b7cec4be1c78d399d0899a30d522ab57b4622 I think this could help in reviewing the overall design and identifying any glaring issue with this. Thanks, Maxime
On Wed, 3 Jan 2024 15:33:36 +0100 Maxime Chevallier wrote: > I think this could help in reviewing the overall design and identifying > any glaring issue with this. The netlink handling looks a bit wobbly to me. I commented best I could in the 20min I had to look at this code :( I think it'd be best to revert, if you don't mind, because reviewing incremental fixes will get even harder.
On 1/4/24 15:47, Jakub Kicinski wrote: > On Wed, 3 Jan 2024 15:33:36 +0100 Maxime Chevallier wrote: >> I think this could help in reviewing the overall design and identifying >> any glaring issue with this. > > The netlink handling looks a bit wobbly to me. > I commented best I could in the 20min I had to look at this code :( > I think it'd be best to revert, if you don't mind, because reviewing > incremental fixes will get even harder. +1
On Thu, 4 Jan 2024 15:50:40 -0800 Florian Fainelli wrote: > > The netlink handling looks a bit wobbly to me. > > I commented best I could in the 20min I had to look at this code :( > > I think it'd be best to revert, if you don't mind, because reviewing > > incremental fixes will get even harder. > > +1 Okay, let's say that the three of us - Florian, Russell and I are a quorum? :) Reverted.
Hi Jakub, On Thu, 4 Jan 2024 16:56:09 -0800 Jakub Kicinski <kuba@kernel.org> wrote: > On Thu, 4 Jan 2024 15:50:40 -0800 Florian Fainelli wrote: > > > The netlink handling looks a bit wobbly to me. > > > I commented best I could in the 20min I had to look at this code :( > > > I think it'd be best to revert, if you don't mind, because reviewing > > > incremental fixes will get even harder. > > > > +1 > > Okay, let's say that the three of us - Florian, Russell > and I are a quorum? :) Reverted. No worries, I'd rather make sure we get this right especially regarding the API. Thanks for taking a look, Maxime