From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f44.google.com (mail-wm1-f44.google.com [209.85.128.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 29EEC2C2374 for ; Mon, 23 Mar 2026 21:15:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774300542; cv=none; b=TLh0ygXvRTaUsvXS3rpRH1HixYwTf4yQLqp8D/Xyx6jj4GTMTl/xXzP1Xrf153NhMds6uktVxatXPBVV5SWJP6R2t5BGTyRiz5UndDg9lHMn90FYK+pMHrVrqOMaI2uQLTyv9+TY4nO+DEx4OR/paJ3wIGR3AWNVOkq/GRxd0Ug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774300542; c=relaxed/simple; bh=E+01s+1EWSp0rlCHpf0q/EgMSfxcqEyde0Qk59jffh8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=FAh/VmDVwnLGXijN+b3NlQNf3vKU4nvDF14hs/P7XIwisoF9Usfdu30WjtQblqKAfWMqS9eN3ugvWVEwsMWtfhDDXm5S4hji/ScVnO00FdjjrAAwPiyDUskU5TdjQJfKgS2whBKKZCdClfbko7gXs7khm4/g4jgee1Fq1LE/phc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=MyFCE8Ky; arc=none smtp.client-ip=209.85.128.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="MyFCE8Ky" Received: by mail-wm1-f44.google.com with SMTP id 5b1f17b1804b1-483ad568d68so6643955e9.2 for ; Mon, 23 Mar 2026 14:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774300539; x=1774905339; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=LbSGCR20NLc8Fhkr8w8sK+fxvVVcKe9jGCCUsUyT7mY=; b=MyFCE8KyHQgbng3c8PHxuzHtIl8EsUCwMI9oWEh82tUGhLTBWkZ4PvLI3jzfqzqJXg 7BT+f5XNhDXc7VlG6pm0md01mfCOGDSuDA0QY77GTfMHXhPMLa9yuTHizd6TM0Xr1Oi2 69T2/PNTz1GxJkmwyiLoIz9b5fO+heUMOj/xkIows0c4jF54Vo7fWKoMtiiR1Yt4coOs 3W0fU/i4H8n2JrswqtrCDGObJVG+FPGrz59B1xJgExVCuLAlraGfy5yG7gTWvlE++xlC N/+6znUZgFTSKe4twmaY9La5s/Ef5mSbdzt48jjVsD5XhAJy4MzU9dy+GOXVXhDGS5rF JnBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774300539; x=1774905339; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=LbSGCR20NLc8Fhkr8w8sK+fxvVVcKe9jGCCUsUyT7mY=; b=nJ30oA+/ovDcS/CO8GTrLJOrmFy+6Vzfsq0jb6tppdppeHOGLdSEEHoV6RbQnwGCR9 WTdOtbeWQVUxyzi/A2rUzLvD8FOotAN19PEuyatIyFZYYGVB7kTFFSLsA2cHMvnI0NW+ DdU/lCkzYXiwyCP44Fj4iSVsBy0RIXf/7daPRE1q34Sht3ifKqCGoB1f5KJhHdtTV+xi 0zq2ohb7bhyOZ9Gym52arbP6HOC46EXGtVxMqUxQ6MUdeZWP6V3lWF8ESgqQ3xDUT8mE PrXJ7/cXWy0JmUWSI6x56xrZVluTYDIFnUJS7krQqnVvvm2ITJ+Pr9ELD86uyGyfNjRL y8xA== X-Forwarded-Encrypted: i=1; AJvYcCUB/1MSBveskumi/x9RpNQiiFXInY/iPubPYSNhRJW3PwyrXVPernJDR4fKRDwero48MhtT7Zrbz8plw6A=@vger.kernel.org X-Gm-Message-State: AOJu0YxcmjUxg03bQ3LQUy0uee/h9Xvq8ZkfJ2oi8x0JsccpgUGowqm9 gAvEAaB5qEOF1ucO5kMIot/uKEFXCjv9yJSBSEAPfRUllIi5hUCz6ckB X-Gm-Gg: ATEYQzwns3LPN509CKLNZHUrIlVad0mxV5L3V5+ti5Yq26gR0UUWy7pB9aRdbOYPBWW ghjk77qlvVcJFoh/9VSD8ZR7u5bPT+xycLUmXQP3i0RgzkBgBJkUGtK9CNwll/B5LR8dzzS52Ev hBnrElojPEOr1vhnBbklJURj5bdfLH86FkgaRpehSgZsK/giFhPjV2CfWih07WeSsD2elVAH1jY 3zrs3YIzPZeJKvEnuilSLcetQNYzdQO2xai5by4efRR9H82kMEq7NPPbEipHnQr4DC3Dc9deSVI V6eUDWcIf4TUXaQyyGI1eAv0H6JQnkbGba51LsYi2/hrSm7wa2E+pfFFHM9rs9uAejhugPSUOmT VhdPigHoZymIRO2Vv2wimPHQEUffAa3uAQbzXl2OzOR1MbW6bqcp1ge2th7XUo3oV/zS1gT96SY C5qf6RLpf6Yvj1+0qehafLMAl1fg== X-Received: by 2002:a05:600c:1f0e:b0:471:ab1:18f5 with SMTP id 5b1f17b1804b1-486fee2dcfdmr106265015e9.7.1774300539351; Mon, 23 Mar 2026 14:15:39 -0700 (PDT) Received: from skbuf ([2a02:2f04:d50a:b400:653e:51cc:7cba:e6df]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4871102369fsm1726375e9.6.2026.03.23.14.15.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 14:15:38 -0700 (PDT) Date: Mon, 23 Mar 2026 23:15:36 +0200 From: Vladimir Oltean To: Daniel Golle 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: <20260323211536.iqopuy2zxd75pfbh@skbuf> 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: On Mon, Mar 23, 2026 at 04:45:18PM +0000, Daniel Golle wrote: > That means the driver *does* have to track a mapping between DSA > bridges and hardware/firmware bridges on that specific switch somehow. That's correct. From DSA's perspective, it's not an mxlbridge, it's just a bridge with at least one DSA switch port under it, which is given a kernel-wide identifier. The ports can hold a single reference to the common bridge, but the common bridge cannot hold a single back-reference to individual ports. And holding multiple references would severely complicate the implementation. Even if you don't implement accelerated cross-switch bridging, you can still have two mxl ports belonging to different switches that are both put by the user under the same bridge. And both switch driver instances would want to allocate a potentially different bridge ID, and surely maintain a different portmap, for that same bridge. > 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/ The API was intended so that you could either use the bridge.num directly, transform it through some linear formula or as an index into a privately maintained array of data structures with switch-specific meaning. I didn't question why you maintain a parallel list of dynamically allocated mxlbridge structures instead of just having an array of MXL862XX_MAX_BRIDGES * sizeof(u16) for the bridge identifiers, plus maintain a separate portmap instead of walking through the DSA data structures, but now that Paolo brought it up: why? I see in v6 you're halfway there with the conversion, you got rid of the portmap and you could just use the array for the rest.