From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pidgin.makrotopia.org (pidgin.makrotopia.org [185.142.180.65]) (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 BF2F93C1980; Mon, 23 Mar 2026 16:45:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.142.180.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774284338; cv=none; b=b8DRBkeMaxf8UWg01n0bTJ4U/8w7/7wHmDgmM4HK4hhyde/DzAAbhnMssWhASA7pn3646Jm6kKJcs4TNqsh8UmHDH0IXY9yI6hrJS3pffZnpUYStlxbFOpjjVWgvGCucHfD4lzxeVx7gmXBIq+MeBx6wioD9GOZUv+wW+ln0M80= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774284338; c=relaxed/simple; bh=RdyaqyK9LYtMwNW/xDt1lbRE2JftZYrsHRh38HarS6Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MnRldXfPOP24UoPYKgilTXIhDbjq5rtlxka0xHX7pEMG8wEBDhx+ym0ALugLamVu0JuCPn9T9F4L08DSKohH8as5+tOXdAtHzYjp4nAjOrmGzcDOoyBO55T/ShQH0ejyceHSmZFR54lMVEUZ2S5RwxNQHLB59aKq24whWleCplA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org; spf=pass smtp.mailfrom=makrotopia.org; arc=none smtp.client-ip=185.142.180.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=makrotopia.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=makrotopia.org Received: from local by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.99) (envelope-from ) id 1w4iP3-000000000Ek-2HPG; Mon, 23 Mar 2026 16:45:21 +0000 Date: Mon, 23 Mar 2026 16:45:18 +0000 From: Daniel Golle To: Vladimir Oltean Cc: Andrew Lunn , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Russell King , netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Frank Wunderlich , Chad Monroe , Cezary Wilmanski , Liang Xu , "Benny (Ying-Tsan) Weng" , Jose Maria Verdu Munoz , Avinash Jayaraman , John Crispin Subject: Re: [PATCH net-next v6 2/4] net: dsa: add bridge member iteration macro and port mask helper Message-ID: References: <20260323163104.a2d2hbs7jfgsptj3@skbuf> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260323163104.a2d2hbs7jfgsptj3@skbuf> On Mon, Mar 23, 2026 at 06:31:04PM +0200, Vladimir Oltean wrote: > On Mon, Mar 23, 2026 at 02:29:41AM +0000, Daniel Golle wrote: > > I wasn't aware of the similar and equally named function in > > yt921x.c[1] > > Yeah, I did request from the beginning for it to be moved to > include/net/dsa.h, but I didn't follow through with the request (I guess > I forgot): > https://lore.kernel.org/netdev/20250825212357.3acgen2qezuy533y@skbuf/ > > > Patchwork CI has loudly uncovered it and I've learned my lesson to > > always test an all-y build when changing even the most innocent > > looking things which technically may affect other drivers. > > Since all DSA drivers are all in the same folder, technically you may be > excused if you just enable all those when working on infra, instead of > allyesconfig. > > > I'll move that function as-is, in a dedicated commit, to > > include/net/dsa.h as an inline function instead of the helper > > suggested here. > > > > A second commit will introduce the new helper macro > > dsa_switch_for_each_bridge_member (modified to use (struct net_device > > *) as parameter instead of (struct dsa_bridge *), and make use of it > > in dsa_bridge_ports(). > > > > I'm also planning to introduce dsa_bridge_for_each_member macro in > > addition to that which works on (struct dsa_bridge *) and uses > > dsa_switch_for_each_bridge_member. > > I don't like the dsa_bridge_for_each_member() name. You are likely > not considering cross-chip bridging, where a bridge spans multiple > dsa_switch structures. That is also a serious reason why your > bridge->priv design is not viable (two switches can't lay their eggs > in the same basket without overwriting each other). That means the driver *does* have to track a mapping between DSA bridges and hardware/firmware bridges on that specific switch somehow. Or is there another existing structure in DSA I'm not aware of and which could be used to implement Paolo's suggestion: https://lore.kernel.org/netdev/fe46d64b-1b12-48b6-b663-e7d5122b7b8a@redhat.com/