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 C55252750ED; Wed, 25 Mar 2026 10:43:17 +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=1774435399; cv=none; b=OLQ1gGEJXY8zw3ZIUObFosDfgCRQp8z4NHS2zdbw03NDKt/29s/u5SVokc0AhgldP5cHvnVW9j6E+cvyRzFMG+Fdu/WS4t9QmS720Vopu8AGJ8PsXcWNo7dwcDCliYFOQiIVf0DJBZpz4Nq2ThtCgj+7oDVYTQfqPK8Vy3ZMfKM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774435399; c=relaxed/simple; bh=/KKBO46fIiQfZJaoULyevUqcMISDb643GiOSYMjvEiA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ntjHxJ6qEtws3xgHaskIOOzoJo1w9I68eND9aTcVmc1M9iyj3CE94m4DfscFwqTcnvZ12zegrbrkm+/QmnN/Oqr9hOgBJHj3YsBa/Iyq7ewTbV6RHT1njm5pSJCBV9dvSk7RQFogivSF4WCCluaV/2JW/ulJGttZ1Fpq2jkKEEg= 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 1w5Lhc-000000007kj-46hK; Wed, 25 Mar 2026 10:43:09 +0000 Date: Wed, 25 Mar 2026 10:43:05 +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> <20260325083427.eef2dmpv6lnyvlmn@skbuf> Precedence: bulk X-Mailing-List: netdev@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: <20260325083427.eef2dmpv6lnyvlmn@skbuf> On Wed, Mar 25, 2026 at 10:34:27AM +0200, Vladimir Oltean wrote: > On Tue, Mar 24, 2026 at 11:31:30PM +0000, Daniel Golle wrote: > > 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'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). > > > > dsa_bridge_for_each_local_member() ? > > > > dsa_switch_for_each_dsa_bridge_member() > > (but that's too close to dsa_switch_for_each_bridge_member imho) > > > > I was planning to have both, dsa_switch and dsa_bridge as parameters, > > of course, limiting the scope to a single dsa_switch. > > I'm not sure that we do need two iterators. Just > dsa_switch_for_each_bridge_member() should be fine. Just for convenience. In my case, all callers always have a reference to 'struct dsa_bridge *', so instead of having the callers dereference 'struct net_device *' from that, have a macro that does it for me.