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 E146125F7A5 for ; Sat, 30 May 2026 06:58:33 +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=1780124317; cv=none; b=Jb/3GPZKlDXtvGtkLQDXOrGTHXYthK0IDuIINm0C7qpTq9/6H8k7TTy8m4SIfABdC0Vox/5spTQUhqNyQMeXWHVrbEv+v29FkWZS56UUEgUVum5CLPpHLxX3mR4UvHArgmeBF8lzJoJxv7llJ9BVxZsqS0pbcGBvvCPKiyeyA4M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780124317; c=relaxed/simple; bh=9GC+nvGm089STHURZhvaw1HjQysmJhqOGo43lkNVNv8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=lbaXWj9qXkUPyNfXFa8MQl6mwVdlmN6MedzrNN7OfS1cOdFZLTSPD9QVDLpjX/X7tLH1RlOFk3sXueZ41vlXuKNWqK1KonivJNYfwhJWn1scfj/56pRpmomIhAyjhINlHsjaQuBpUdvXb1wjeoakE3ET2x18yfceVXo+hFZrKIE= 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=JJo2ZKhA; 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="JJo2ZKhA" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-02.galae.net (Postfix) with ESMTPS id 67BBA1A374A; Sat, 30 May 2026 06:58:32 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 25CF86073B; Sat, 30 May 2026 06:58:32 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id EFDE810888650; Sat, 30 May 2026 08:58:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1780124310; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:content-language:in-reply-to:references; bh=x9nvez9wtVVvGLqRBtzT4pg4jyQA0HGsCNg6shTRZ2Y=; b=JJo2ZKhA0uokfeXNVjofcZHDUYsQgQthaxmQgCg8Y95pPFO0HquRnlwhANKY4Mp9p8N8ZJ 200KH6nCYqa9PEf+uWsv4GPHNuNaoVeLQ42oPjIj9dl/27J4yFo2f6BFvCB/euPkPhdQAD PixPXEPmFSFTrZXg5PijWJmaFodDTj3+3EQ1fev8nHoe/5IRVmtqBd7aPrr0zkauvSyAJO 26Cv2a6wEjxs0cCqV8HM1ceXWJMWDJ74K7o8AAWyHQHBQSR2V/3A4xAd8+pyk8dn3CaUyG tVRkokIZJo+wSw+qLJkAcp56YKb2PWo+Gl+NcEkxBkYTJuUJyHhR+IIMcL7/Fw== Message-ID: <4a919501-b3f2-489a-ac9d-a7f8709abf6e@bootlin.com> Date: Sat, 30 May 2026 08:58:25 +0200 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: [PATCH net-next v11 02/10] net: phy: phy_link_topology: Track ports in phy_link_topology To: davem@davemloft.net, Andrew Lunn , Jakub Kicinski , Eric Dumazet , Paolo Abeni , Russell King , Heiner Kallweit Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, thomas.petazzoni@bootlin.com, Christophe Leroy , Herve Codina , Florian Fainelli , Vladimir Oltean , =?UTF-8?Q?K=C3=B6ry_Maincent?= , =?UTF-8?Q?Marek_Beh=C3=BAn?= , Oleksij Rempel , =?UTF-8?Q?Nicol=C3=B2_Veronese?= , Simon Horman , mwojtas@chromium.org, Romain Gantois , Daniel Golle , Dimitri Fedrau , Frank Wunderlich References: <20260521121040.1199622-1-maxime.chevallier@bootlin.com> <20260521121040.1199622-3-maxime.chevallier@bootlin.com> Content-Language: en-US From: Maxime Chevallier In-Reply-To: <20260521121040.1199622-3-maxime.chevallier@bootlin.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Last-TLS-Session-Version: TLSv1.3 On 5/21/26 14:10, Maxime Chevallier wrote: > phy_port is aimed at representing the various physical interfaces of a > net_device. They can be controlled by various components in the link, > such as the Ethernet PHY, the Ethernet MAC, and SFP module, etc. > > Let's therefore make so we keep track of all the ports connected to a > netdev in phy_link_topology. The only ports added for now are phy-driven > ports. > > Reviewed-by: Andrew Lunn > Signed-off-by: Maxime Chevallier > --- > drivers/net/phy/phy_link_topology.c | 53 +++++++++++++++++++++++++++++ > include/linux/phy_link_topology.h | 18 ++++++++++ > include/linux/phy_port.h | 2 ++ > net/core/dev.c | 1 + > 4 files changed, 74 insertions(+) > > diff --git a/drivers/net/phy/phy_link_topology.c b/drivers/net/phy/phy_link_topology.c > index fdfafd951905..207128303ca2 100644 > --- a/drivers/net/phy/phy_link_topology.c > +++ b/drivers/net/phy/phy_link_topology.c > @@ -7,6 +7,7 @@ > */ > > #include > +#include > #include > #include > #include > @@ -22,6 +23,9 @@ static int netdev_alloc_phy_link_topology(struct net_device *dev) > xa_init_flags(&topo->phys, XA_FLAGS_ALLOC1); > topo->next_phy_index = 1; > > + xa_init_flags(&topo->ports, XA_FLAGS_ALLOC1); > + topo->next_port_index = 1; > + > dev->link_topo = topo; > > return 0; > @@ -44,12 +48,45 @@ static struct phy_link_topology *phy_link_topo_get_or_alloc(struct net_device *d > return dev->link_topo; > } > > +int phy_link_topo_add_port(struct net_device *dev, struct phy_port *port) > +{ > + struct phy_link_topology *topo; > + int ret; > + > + topo = phy_link_topo_get_or_alloc(dev); > + if (IS_ERR(topo)) > + return PTR_ERR(topo); > + > + /* Attempt to re-use a previously allocated port_id */ > + if (port->id) > + ret = xa_insert(&topo->ports, port->id, port, GFP_KERNEL); Sashiko says : " If this port is moved to a different netdev (which has a separate topology), and its old port->id happens to be in use by another port in the new topology, will xa_insert() return -EBUSY? Since there is no fallback to xa_alloc_cyclic() on -EBUSY and the stale ID is never reset to 0 upon removal, does this permanently prevent the port from attaching to the new topology? " So we can't move a port to another netdev, the closest thing we can conceivably to is unbind/rebind a net_device while the phy_device stays alive. Even then, we'll be re-adding this ports to a fresh topology, so no collision risk here. We don't re-set the port id to 0 upon removal on purpose, as implied by the comment we try to reuse the id, as a much more common case is that we attach/detach the phy_device that controls this port during .ndo_open/close, and we don't want the port id to change at each link flap Maxime