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
next prev parent 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: linkBe 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.