All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
	"Andrew Lunn" <andrew@lunn.ch>,
	"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>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Marek Behún" <kabel@kernel.org>,
	"Piergiorgio Beruto" <piergiorgio.beruto@gmail.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Nicolò Veronese" <nicveronese@gmail.com>,
	"Simon Horman" <horms@kernel.org>
Subject: Re: [PATCH net-next v5 07/13] net: ethtool: Introduce a command to list PHYs on an interface
Date: Thu, 4 Jan 2024 15:34:01 -0800	[thread overview]
Message-ID: <20240104153401.08ff9809@kernel.org> (raw)
In-Reply-To: <20231221180047.1924733-8-maxime.chevallier@bootlin.com>

On Thu, 21 Dec 2023 19:00:40 +0100 Maxime Chevallier wrote:
> As we have the ability to track the PHYs connected to a net_device
> through the link_topology, we can expose this list to userspace. This
> allows userspace to use these identifiers for phy-specific commands and
> take the decision of which PHY to target by knowing the link topology.
> 
> Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
> devices on only one interface.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

> diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
> index 3ca6c21e74af..97ff787a7dd8 100644
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -2011,6 +2011,49 @@ The attributes are propagated to the driver through the following structure:
>  .. kernel-doc:: include/linux/ethtool.h
>      :identifiers: ethtool_mm_cfg
>  
> +PHY_GET
> +=======
> +
> +Retrieve information about a given Ethernet PHY sitting on the link. As there
> +can be more than one PHY, the DUMP operation can be used to list the PHYs
> +present on a given interface, by passing an interface index or name in
> +the dump request
> +
> +Request contents:
> +
> +  ====================================  ======  ==========================
> +  ``ETHTOOL_A_PHY_HEADER``              nested  request header
> +  ====================================  ======  ==========================
> +
> +Kernel response contents:
> +
> +  ===================================== ======  ==========================
> +  ``ETHTOOL_A_PHY_HEADER``              nested  request header
> +  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can

The fact that lines are longer than the ===== markings doesn't generate
warnings in htmldoc?

> +                                                be used for phy-specific requests
> +  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
> +  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
> +  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
> +                                                connected to
> +  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
> +                                                phy, this nest contains info on
> +                                                that connection
> +  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
> +                                                the name of the sfp bus

Is upstream / downstream clear to everyone / from the spec.
I guess it's scoped to the netdev so upstream means "towards 
the netdev MAC"?

> +  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
> +  ===================================== ======  ==========================
> +
> +When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
> +another PHY. Information on the parent PHY will be set in the
> +``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
> +
> +  =================================== ======  ==========================
> +  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
> +  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
> +                                                parent PHY through an SFP bus, the
> +                                                name of this sfp bus
> +  =================================== ======  ==========================

Why is this a nest?

>  Request translation
>  ===================

> +enum {
> +	ETHTOOL_A_PHY_UNSPEC,
> +	ETHTOOL_A_PHY_HEADER,			/* nest - _A_HEADER_* */
> +	ETHTOOL_A_PHY_INDEX,			/* u32 */
> +	ETHTOOL_A_PHY_DRVNAME,			/* string */
> +	ETHTOOL_A_PHY_NAME,			/* string */
> +	ETHTOOL_A_PHY_UPSTREAM_TYPE,		/* u8 */

The Documentation say it's a u32 as it should be, AFAICT.
But code and some comments use u8.

> +	ETHTOOL_A_PHY_UPSTREAM,			/* nest - _A_PHY_UPSTREAM_* */
> +	ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,	/* string */
> +	ETHTOOL_A_PHY_ID,			/* u32 */
> +
> +	/* add new constants above here */
> +	__ETHTOOL_A_PHY_CNT,
> +	ETHTOOL_A_PHY_MAX = (__ETHTOOL_A_PHY_CNT - 1)
> +};

> +++ b/net/ethtool/phy.c
> @@ -0,0 +1,306 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2023 Bootlin
> + *
> + */

Do you really need 4 lines for the copyright? :)


> +/* Caller holds rtnl */
> +static ssize_t
> +ethnl_phy_reply_size(const struct ethnl_req_info *req_base,
> +		     struct netlink_ext_ack *extack)
> +{
> +	struct phy_link_topology *topo;
> +	struct phy_device_node *pdn;
> +	struct phy_device *phydev;
> +	unsigned long index;
> +	size_t size;
> +
> +	ASSERT_RTNL();
> +
> +	topo = &req_base->dev->link_topo;
> +
> +	size = nla_total_size(0);

no comment on this one?

> +
> +	xa_for_each(&topo->phys, index, pdn) {

Why count all the PHYs, you only output one on doit, right?

> +		phydev = pdn->phy;
> +
> +		/* ETHTOOL_A_PHY_INDEX */
> +		size += nla_total_size(sizeof(u32));
> +
> +		/* ETHTOOL_A_DRVNAME */
> +		size += nla_total_size(strlen(phydev->drv->name) + 1);
> +
> +		/* ETHTOOL_A_NAME */
> +		size += nla_total_size(strlen(dev_name(&phydev->mdio.dev)) + 1);
> +
> +		/* ETHTOOL_A_PHY_UPSTREAM_TYPE */
> +		size += nla_total_size(sizeof(u8));
> +
> +		/* ETHTOOL_A_PHY_ID */
> +		size += nla_total_size(sizeof(u32));
> +
> +		if (phy_on_sfp(phydev)) {
> +			const char *upstream_sfp_name = sfp_get_name(pdn->parent_sfp_bus);
> +
> +			/* ETHTOOL_A_PHY_UPSTREAM_SFP_NAME */
> +			if (upstream_sfp_name)
> +				size += nla_total_size(strlen(upstream_sfp_name) + 1);
> +
> +			/* ETHTOOL_A_PHY_UPSTREAM_INDEX */
> +			size += nla_total_size(sizeof(u32));
> +		}
> +
> +		/* ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME */
> +		if (phydev->sfp_bus) {
> +			const char *sfp_name = sfp_get_name(phydev->sfp_bus);
> +
> +			if (sfp_name)
> +				size += nla_total_size(strlen(sfp_name) + 1);
> +		}
> +	}
> +
> +	return size;
> +}

> +static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
> +				   struct nlattr **tb)
> +{
> +	struct phy_link_topology *topo = &req_base->dev->link_topo;
> +	struct phy_req_info *req_info = PHY_REQINFO(req_base);
> +	struct phy_device_node *pdn;
> +
> +	if (!req_base->phydev)
> +		return 0;

The PHY INDEX should probably be a required attr, with 
GENL_REQ_ATTR_CHECK()? Without phydev being specified
what's the point?

> +	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
> +	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
> +
> +	return 0;
> +}

> +int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> +	struct net *net = sock_net(skb->sk);
> +	unsigned long ifindex = 1;

This doesn't look right, if dump gets full you gotta pick up
when previous call left off.

> +	struct net_device *dev;
> +	int ret = 0;
> +
> +	rtnl_lock();
> +
> +	if (ctx->phy_req_info->base.dev) {
> +		ret = ethnl_phy_dump_one_dev(skb, ctx->phy_req_info->base.dev, cb);
> +		ethnl_parse_header_dev_put(&ctx->phy_req_info->base);
> +		ctx->phy_req_info->base.dev = NULL;
> +	} else {
> +		for_each_netdev_dump(net, dev, ifindex) {
> +			ret = ethnl_phy_dump_one_dev(skb, dev, cb);
> +			if (ret)
> +				break;
> +		}
> +	}
> +	rtnl_unlock();
> +
> +	if (ret == -EMSGSIZE && skb->len)
> +		return skb->len;
> +	return ret;
> +}
> +


WARNING: multiple messages have this Message-ID (diff)
From: Jakub Kicinski <kuba@kernel.org>
To: Maxime Chevallier <maxime.chevallier@bootlin.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com,
	"Andrew Lunn" <andrew@lunn.ch>,
	"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>,
	"Köry Maincent" <kory.maincent@bootlin.com>,
	"Jesse Brandeburg" <jesse.brandeburg@intel.com>,
	"Jonathan Corbet" <corbet@lwn.net>,
	"Marek Behún" <kabel@kernel.org>,
	"Piergiorgio Beruto" <piergiorgio.beruto@gmail.com>,
	"Oleksij Rempel" <o.rempel@pengutronix.de>,
	"Nicolò Veronese" <nicveronese@gmail.com>,
	"Simon Horman" <horms@kernel.org>
Subject: Re: [PATCH net-next v5 07/13] net: ethtool: Introduce a command to list PHYs on an interface
Date: Thu, 4 Jan 2024 15:34:01 -0800	[thread overview]
Message-ID: <20240104153401.08ff9809@kernel.org> (raw)
In-Reply-To: <20231221180047.1924733-8-maxime.chevallier@bootlin.com>

On Thu, 21 Dec 2023 19:00:40 +0100 Maxime Chevallier wrote:
> As we have the ability to track the PHYs connected to a net_device
> through the link_topology, we can expose this list to userspace. This
> allows userspace to use these identifiers for phy-specific commands and
> take the decision of which PHY to target by knowing the link topology.
> 
> Add PHY_GET and PHY_DUMP, which can be a filtered DUMP operation to list
> devices on only one interface.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

> diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst
> index 3ca6c21e74af..97ff787a7dd8 100644
> --- a/Documentation/networking/ethtool-netlink.rst
> +++ b/Documentation/networking/ethtool-netlink.rst
> @@ -2011,6 +2011,49 @@ The attributes are propagated to the driver through the following structure:
>  .. kernel-doc:: include/linux/ethtool.h
>      :identifiers: ethtool_mm_cfg
>  
> +PHY_GET
> +=======
> +
> +Retrieve information about a given Ethernet PHY sitting on the link. As there
> +can be more than one PHY, the DUMP operation can be used to list the PHYs
> +present on a given interface, by passing an interface index or name in
> +the dump request
> +
> +Request contents:
> +
> +  ====================================  ======  ==========================
> +  ``ETHTOOL_A_PHY_HEADER``              nested  request header
> +  ====================================  ======  ==========================
> +
> +Kernel response contents:
> +
> +  ===================================== ======  ==========================
> +  ``ETHTOOL_A_PHY_HEADER``              nested  request header
> +  ``ETHTOOL_A_PHY_INDEX``               u32     the phy's unique index, that can

The fact that lines are longer than the ===== markings doesn't generate
warnings in htmldoc?

> +                                                be used for phy-specific requests
> +  ``ETHTOOL_A_PHY_DRVNAME``             string  the phy driver name
> +  ``ETHTOOL_A_PHY_NAME``                string  the phy device name
> +  ``ETHTOOL_A_PHY_UPSTREAM_TYPE``       u32     the type of device this phy is
> +                                                connected to
> +  ``ETHTOOL_A_PHY_UPSTREAM_PHY``        nested  if the phy is connected to another
> +                                                phy, this nest contains info on
> +                                                that connection
> +  ``ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME`` string  if the phy controls an sfp bus,
> +                                                the name of the sfp bus

Is upstream / downstream clear to everyone / from the spec.
I guess it's scoped to the netdev so upstream means "towards 
the netdev MAC"?

> +  ``ETHTOOL_A_PHY_ID``                  u32     the phy id if the phy is C22
> +  ===================================== ======  ==========================
> +
> +When ``ETHTOOL_A_PHY_UPSTREAM_TYPE`` is PHY_UPSTREAM_PHY, the PHY's parent is
> +another PHY. Information on the parent PHY will be set in the
> +``ETHTOOL_A_PHY_UPSTREAM_PHY`` nest, which has the following structure :
> +
> +  =================================== ======  ==========================
> +  ``ETHTOOL_A_PHY_UPSTREAM_INDEX``    u32     the PHY index of the upstream PHY
> +  ``ETHTOOL_A_PHY_UPSTREAM_SFP_NAME`` string  if this PHY is connected to it's
> +                                                parent PHY through an SFP bus, the
> +                                                name of this sfp bus
> +  =================================== ======  ==========================

Why is this a nest?

>  Request translation
>  ===================

> +enum {
> +	ETHTOOL_A_PHY_UNSPEC,
> +	ETHTOOL_A_PHY_HEADER,			/* nest - _A_HEADER_* */
> +	ETHTOOL_A_PHY_INDEX,			/* u32 */
> +	ETHTOOL_A_PHY_DRVNAME,			/* string */
> +	ETHTOOL_A_PHY_NAME,			/* string */
> +	ETHTOOL_A_PHY_UPSTREAM_TYPE,		/* u8 */

The Documentation say it's a u32 as it should be, AFAICT.
But code and some comments use u8.

> +	ETHTOOL_A_PHY_UPSTREAM,			/* nest - _A_PHY_UPSTREAM_* */
> +	ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME,	/* string */
> +	ETHTOOL_A_PHY_ID,			/* u32 */
> +
> +	/* add new constants above here */
> +	__ETHTOOL_A_PHY_CNT,
> +	ETHTOOL_A_PHY_MAX = (__ETHTOOL_A_PHY_CNT - 1)
> +};

> +++ b/net/ethtool/phy.c
> @@ -0,0 +1,306 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright 2023 Bootlin
> + *
> + */

Do you really need 4 lines for the copyright? :)


> +/* Caller holds rtnl */
> +static ssize_t
> +ethnl_phy_reply_size(const struct ethnl_req_info *req_base,
> +		     struct netlink_ext_ack *extack)
> +{
> +	struct phy_link_topology *topo;
> +	struct phy_device_node *pdn;
> +	struct phy_device *phydev;
> +	unsigned long index;
> +	size_t size;
> +
> +	ASSERT_RTNL();
> +
> +	topo = &req_base->dev->link_topo;
> +
> +	size = nla_total_size(0);

no comment on this one?

> +
> +	xa_for_each(&topo->phys, index, pdn) {

Why count all the PHYs, you only output one on doit, right?

> +		phydev = pdn->phy;
> +
> +		/* ETHTOOL_A_PHY_INDEX */
> +		size += nla_total_size(sizeof(u32));
> +
> +		/* ETHTOOL_A_DRVNAME */
> +		size += nla_total_size(strlen(phydev->drv->name) + 1);
> +
> +		/* ETHTOOL_A_NAME */
> +		size += nla_total_size(strlen(dev_name(&phydev->mdio.dev)) + 1);
> +
> +		/* ETHTOOL_A_PHY_UPSTREAM_TYPE */
> +		size += nla_total_size(sizeof(u8));
> +
> +		/* ETHTOOL_A_PHY_ID */
> +		size += nla_total_size(sizeof(u32));
> +
> +		if (phy_on_sfp(phydev)) {
> +			const char *upstream_sfp_name = sfp_get_name(pdn->parent_sfp_bus);
> +
> +			/* ETHTOOL_A_PHY_UPSTREAM_SFP_NAME */
> +			if (upstream_sfp_name)
> +				size += nla_total_size(strlen(upstream_sfp_name) + 1);
> +
> +			/* ETHTOOL_A_PHY_UPSTREAM_INDEX */
> +			size += nla_total_size(sizeof(u32));
> +		}
> +
> +		/* ETHTOOL_A_PHY_DOWNSTREAM_SFP_NAME */
> +		if (phydev->sfp_bus) {
> +			const char *sfp_name = sfp_get_name(phydev->sfp_bus);
> +
> +			if (sfp_name)
> +				size += nla_total_size(strlen(sfp_name) + 1);
> +		}
> +	}
> +
> +	return size;
> +}

> +static int ethnl_phy_parse_request(struct ethnl_req_info *req_base,
> +				   struct nlattr **tb)
> +{
> +	struct phy_link_topology *topo = &req_base->dev->link_topo;
> +	struct phy_req_info *req_info = PHY_REQINFO(req_base);
> +	struct phy_device_node *pdn;
> +
> +	if (!req_base->phydev)
> +		return 0;

The PHY INDEX should probably be a required attr, with 
GENL_REQ_ATTR_CHECK()? Without phydev being specified
what's the point?

> +	pdn = xa_load(&topo->phys, req_base->phydev->phyindex);
> +	memcpy(&req_info->pdn, pdn, sizeof(*pdn));
> +
> +	return 0;
> +}

> +int ethnl_phy_dumpit(struct sk_buff *skb, struct netlink_callback *cb)
> +{
> +	struct ethnl_phy_dump_ctx *ctx = (void *)cb->ctx;
> +	struct net *net = sock_net(skb->sk);
> +	unsigned long ifindex = 1;

This doesn't look right, if dump gets full you gotta pick up
when previous call left off.

> +	struct net_device *dev;
> +	int ret = 0;
> +
> +	rtnl_lock();
> +
> +	if (ctx->phy_req_info->base.dev) {
> +		ret = ethnl_phy_dump_one_dev(skb, ctx->phy_req_info->base.dev, cb);
> +		ethnl_parse_header_dev_put(&ctx->phy_req_info->base);
> +		ctx->phy_req_info->base.dev = NULL;
> +	} else {
> +		for_each_netdev_dump(net, dev, ifindex) {
> +			ret = ethnl_phy_dump_one_dev(skb, dev, cb);
> +			if (ret)
> +				break;
> +		}
> +	}
> +	rtnl_unlock();
> +
> +	if (ret == -EMSGSIZE && skb->len)
> +		return skb->len;
> +	return ret;
> +}
> +


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2024-01-04 23:34 UTC|newest]

Thread overview: 76+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-21 18:00 [PATCH net-next v5 00/13] Introduce PHY listing and link_topology tracking Maxime Chevallier
2023-12-21 18:00 ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 01/13] net: phy: Introduce ethernet link topology representation Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2024-01-04 23:12   ` Jakub Kicinski
2024-01-04 23:12     ` Jakub Kicinski
2024-01-05  2:21     ` Andrew Lunn
2024-01-05  2:21       ` Andrew Lunn
2024-01-05  9:29     ` Maxime Chevallier
2024-01-05  9:29       ` Maxime Chevallier
2024-01-05 15:34       ` Jakub Kicinski
2024-01-05 15:34         ` Jakub Kicinski
2023-12-21 18:00 ` [PATCH net-next v5 02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2024-01-03 15:20   ` Russell King (Oracle)
2024-01-03 15:20     ` Russell King (Oracle)
2024-01-03 17:45     ` Maxime Chevallier
2024-01-03 17:45       ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 03/13] net: phy: add helpers to handle sfp phy connect/disconnect Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 04/13] net: sfp: Add helper to return the SFP bus name Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 05/13] net: ethtool: Allow passing a phy index for some commands Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2024-01-04 23:15   ` Jakub Kicinski
2024-01-04 23:15     ` Jakub Kicinski
2024-01-05  9:30     ` Maxime Chevallier
2024-01-05  9:30       ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 06/13] netlink: specs: add phy-index as a header parameter Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 07/13] net: ethtool: Introduce a command to list PHYs on an interface Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2024-01-04 23:34   ` Jakub Kicinski [this message]
2024-01-04 23:34     ` Jakub Kicinski
2024-01-05  9:43     ` Maxime Chevallier
2024-01-05  9:43       ` Maxime Chevallier
2024-01-05 13:17       ` Andrew Lunn
2024-01-05 13:17         ` Andrew Lunn
2024-01-24 13:50         ` Maxime Chevallier
2024-01-24 13:50           ` Maxime Chevallier
2024-01-24 16:54           ` Andrew Lunn
2024-01-24 16:54             ` Andrew Lunn
2024-01-25  8:22             ` Maxime Chevallier
2024-01-25  8:22               ` Maxime Chevallier
2024-01-25 17:10               ` Andrew Lunn
2024-01-25 17:10                 ` Andrew Lunn
2024-01-05 15:39       ` Jakub Kicinski
2024-01-05 15:39         ` Jakub Kicinski
2023-12-21 18:00 ` [PATCH net-next v5 08/13] netlink: specs: add ethnl PHY_GET command set Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 09/13] net: ethtool: plca: Target the command to the requested PHY Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 10/13] net: ethtool: pse-pd: " Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 11/13] net: ethtool: cable-test: " Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 12/13] net: ethtool: strset: Allow querying phy stats by index Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2023-12-21 18:00 ` [PATCH net-next v5 13/13] Documentation: networking: document phy_link_topology Maxime Chevallier
2023-12-21 18:00   ` Maxime Chevallier
2024-01-01 18:40 ` [PATCH net-next v5 00/13] Introduce PHY listing and link_topology tracking patchwork-bot+netdevbpf
2024-01-01 18:40   ` patchwork-bot+netdevbpf
2024-01-02 11:57   ` Russell King (Oracle)
2024-01-02 11:57     ` Russell King (Oracle)
2024-01-02 18:51     ` Jakub Kicinski
2024-01-02 18:51       ` Jakub Kicinski
2024-01-03 14:33       ` Maxime Chevallier
2024-01-03 14:33         ` Maxime Chevallier
2024-01-04 23:47         ` Jakub Kicinski
2024-01-04 23:47           ` Jakub Kicinski
2024-01-04 23:50           ` Florian Fainelli
2024-01-04 23:50             ` Florian Fainelli
2024-01-05  0:56             ` Jakub Kicinski
2024-01-05  0:56               ` Jakub Kicinski
2024-01-05  9:00               ` Maxime Chevallier
2024-01-05  9:00                 ` Maxime Chevallier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240104153401.08ff9809@kernel.org \
    --to=kuba@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=christophe.leroy@csgroup.eu \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=f.fainelli@gmail.com \
    --cc=herve.codina@bootlin.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=jesse.brandeburg@intel.com \
    --cc=kabel@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=maxime.chevallier@bootlin.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicveronese@gmail.com \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.com \
    --cc=piergiorgio.beruto@gmail.com \
    --cc=thomas.petazzoni@bootlin.com \
    --cc=vladimir.oltean@nxp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.