mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mieczyslaw Nalewaj <namiltd@yahoo.com>
To: "Luiz Angelo Daros de Luca" <luizluca@gmail.com>,
	"Andrew Lunn" <andrew@lunn.ch>,
	"Vladimir Oltean" <olteanv@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Simon Horman" <horms@kernel.org>,
	"Linus Walleij" <linusw@kernel.org>,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>,
	"Yury Norov" <yury.norov@gmail.com>,
	"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
	"Russell King" <linux@armlinux.org.uk>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Yury Norov <ynorov@nvidia.com>,
	Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
Subject: Re: [net-next PATCH v4 5/8] net: dsa: realtek: rtl8365mb: add VLAN support
Date: Sun, 17 May 2026 09:01:40 +0200	[thread overview]
Message-ID: <e9edd482-28dd-4222-8df2-822da29f0f53@yahoo.com> (raw)
In-Reply-To: <20260516-realtek_forward-v4-5-8b6d6a1eefdc@gmail.com>

On 5/16/2026 5:46 AM, Luiz Angelo Daros de Luca wrote:
> From: Alvin Šipraga <alsi@bang-olufsen.dk>
> 
> Realtek RTL8365MB switches (a.k.a. RTL8367C family) use two different
> structures for VLANs:
> 
> - VLAN4K: A full table with 4096 entries defining port membership and
>   tagging.
> - VLANMC: A smaller table with 32 entries used primarily for PVID
>   assignment.
> 
> In this hardware, a port's PVID must point to an index in the VLANMC
> table rather than a VID directly. Since the VLANMC table is limited to
> 32 entries, the driver implements a dynamic allocation scheme to
> maximize resource usage:
> 
> - VLAN4K is treated by the driver as the source of truth for membership.
> - A VLANMC entry is only allocated when a port is configured to use a
>   specific VID as its PVID.
> - VLANMC entries are deleted when no longer needed as a PVID by any port.
> 
> Although VLANMC has a members field, the switch only checks membership
> in the VLAN4K table. However, when a corresponding VLAN entry also exists
> in VLANMC, this driver keeps both membership configurations in sync.
> 
> VLANMC index 0, although a valid entry, is reserved in this driver as a
> neutral PVID value for ports not using a specific PVID.
> 
> In the subsequent RTL8367D switch family, VLANMC table was
> removed and PVID assignment was delegated to a dedicated set of
> registers.
> 
> All ports start isolated, forwarding exclusively to CPU ports, and
> with VLAN transparent, ignoring VLAN membership. Once a member in a
> bridge, the port isolation is expanded to include the bridge members.
> When that bridge enables VLAN filtering, the VLAN transparent feature is
> disabled, letting the switch filter based on VLAN setup.
> 
> The use of FIELD_PREP for reconstructing LO/HI values was suggested by
> Yury Norov.
> 
> Fix for vlan_setup and vlan_filtering was suggested by Abdulkader
> Alrezej.
> 
> Suggested-by: Yury Norov <ynorov@nvidia.com>
> Suggested-by: Abdulkader Alrezej <abdulkader.alrezej@gmail.com>
> Co-developed-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
> Reviewed-by: Linus Walleij <linusw@kernel.org>
> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
> [...]
> @@ -1196,6 +1258,195 @@ static void rtl8365mb_port_stp_state_set(struct dsa_switch *ds, int port,
>  			   val << RTL8365MB_MSTI_CTRL_PORT_STATE_OFFSET(port));
>  }
>  
> +static int rtl8365mb_port_set_transparent(struct realtek_priv *priv,
> +					  int igr_port, int egr_port,
> +					  bool enable)
> +{
> +	dev_dbg(priv->dev, "%s transparent VLAN from %d to %d\n",
> +		enable ? "Enable" : "Disable", igr_port, egr_port);
> +
> +	/* "Transparent" between the two ports means that packets forwarded by
> +	 * igr_port and egressed on egr_port will not be filtered by the usual
> +	 * VLAN membership settings.
> +	 */
> +	return regmap_update_bits(priv->map,
> +			RTL8365MB_VLAN_EGRESS_TRANSPARENT_REG(egr_port),
> +			BIT(igr_port), enable ? BIT(igr_port) : 0);
> +}
> +
> +static int rtl8365mb_port_set_ingress_filtering(struct realtek_priv *priv,
> +						int port, bool enable)
> +{
> +	/* Ingress filtering enabled: Discard VLAN-tagged frames if the port is
> +	 * not a member of the VLAN with which the packet is associated.
> +	 * Untagged packets will also be discarded unless the port has a PVID
> +	 * programmed. Priority-tagged frames are treated as untagged frames.
> +	 *
> +	 * Ingress filtering disabled: Accept all tagged and untagged frames.
> +	 */
> +	return regmap_update_bits(priv->map, RTL8365MB_VLAN_INGRESS_REG,
> +			RTL8365MB_VLAN_INGRESS_FILTER_PORT_EN_MASK(port),
> +			enable ?
> +			RTL8365MB_VLAN_INGRESS_FILTER_PORT_EN_MASK(port) :
> +			0);
> +}
> +
> +static int
> +rtl8365mb_port_set_vlan_egress_mode(struct realtek_priv *priv, int port,
> +				    enum rtl8365mb_vlan_egress_mode mode)
> +{
> +	u32 val;
> +
> +	val = FIELD_PREP(RTL8365MB_PORT_MISC_CFG_VLAN_EGRESS_MODE_MASK, mode);
> +	return regmap_update_bits(priv->map,
> +			RTL8365MB_PORT_MISC_CFG_REG(port),
> +			RTL8365MB_PORT_MISC_CFG_VLAN_EGRESS_MODE_MASK, val);
> +}
> +
> +static int rtl8365mb_port_vlan_filtering(struct dsa_switch *ds, int port,
> +					 bool vlan_filtering,
> +					 struct netlink_ext_ack *extack)
> +{
> +	enum rtl8365mb_vlan_egress_mode mode;
> +	struct realtek_priv *priv = ds->priv;
> +	struct dsa_port *dp;
> +	int ret;
> +
> +	dev_dbg(priv->dev, "port %d: %s VLAN filtering\n", port,
> +		vlan_filtering ? "enable" : "disable");
> +
> +	/* When vlan filter is enable/disabled in a bridge, this function is
> +	 * called for all member ports. We need to enable/disable ingress
> +	 * VLAN membership check.
> +	 */
> +	ret = rtl8365mb_port_set_ingress_filtering(priv, port, vlan_filtering);
> +	if (ret)
> +		return ret;
> +
> +	/* However, we also enable/disable egress filtering because the switch
> +	 * still consider the egress interface VLAN membership to forward the
> +	 * traffic. We enable/disable that check disabling/enabling transparent
> +	 * VLAN between the ingress port and all other available ports.
> +	 */
> +	dsa_switch_for_each_available_port(dp, ds) {
> +		/* port isolation will still keep traffic inside the bridge */
> +		ret = rtl8365mb_port_set_transparent(priv, port, dp->index,
> +						     !vlan_filtering);
> +		if (ret)
> +			goto undo_transparent;
> +	}
> +
> +	/* When VLAN filtering is disabled, preserve frames exactly as received.
> +	 * Otherwise, the VLAN egress pipeline may still alter tag state
> +	 * according to VLAN membership and untag configuration.
> +	 */
> +	if (vlan_filtering)
> +		mode = RTL8365MB_VLAN_EGRESS_MODE_ORIGINAL;
> +	else
> +		mode = RTL8365MB_VLAN_EGRESS_MODE_REAL_KEEP;
> +
> +	ret = rtl8365mb_port_set_vlan_egress_mode(priv, port, mode);
> +	if (ret)
> +		goto undo_transparent;
> +
> +	return ret;
> +
> +undo_transparent:
> +	/* It will also try to undo the failed port if the error happened
> +	 * inside the transparent VLAN loop but that might be inocuous.
> +	 */
> +	dsa_switch_for_each_port_continue_reverse(dp, ds) {
> +		if (dsa_port_is_unused((dp)))

- typo inocuous - innocuous
- redundant inner parens around dp in dsa_port_is_dsa((dp))


  parent reply	other threads:[~2026-05-17  7:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-16  3:46 [net-next PATCH v4 0/8] net: dsa: realtek: rtl8365mb: bridge offloading and " Luiz Angelo Daros de Luca
2026-05-16  3:46 ` [net-next PATCH v4 1/8] net: dsa: realtek: rtl8365mb: use ERR_PTR Luiz Angelo Daros de Luca
2026-05-16 15:33   ` Mieczyslaw Nalewaj
2026-05-16  3:46 ` [net-next PATCH v4 2/8] net: dsa: realtek: rtl8365mb: use dsa helpers for port iteration Luiz Angelo Daros de Luca
2026-05-16 15:32   ` Mieczyslaw Nalewaj
2026-05-17  6:53   ` Mieczyslaw Nalewaj
2026-05-16  3:46 ` [net-next PATCH v4 3/8] net: dsa: realtek: rtl8365mb: prepare for multiple source files Luiz Angelo Daros de Luca
2026-05-16  3:46 ` [net-next PATCH v4 4/8] net: dsa: realtek: rtl8365mb: add table lookup interface Luiz Angelo Daros de Luca
2026-05-16 15:31   ` Mieczyslaw Nalewaj
2026-05-16  3:46 ` [net-next PATCH v4 5/8] net: dsa: realtek: rtl8365mb: add VLAN support Luiz Angelo Daros de Luca
2026-05-16 15:31   ` Mieczyslaw Nalewaj
2026-05-17  7:01   ` Mieczyslaw Nalewaj [this message]
2026-05-16  3:46 ` [net-next PATCH v4 6/8] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave} Luiz Angelo Daros de Luca
2026-05-16 15:30   ` Mieczyslaw Nalewaj
2026-05-16  3:46 ` [net-next PATCH v4 7/8] net: dsa: realtek: rtl8365mb: add FDB support Luiz Angelo Daros de Luca
2026-05-16  5:48   ` Mieczyslaw Nalewaj
2026-05-16 12:47     ` Luiz Angelo Daros de Luca
2026-05-16 15:29       ` Mieczyslaw Nalewaj
2026-05-18  4:38   ` Luiz Angelo Daros de Luca
2026-05-16  3:46 ` [net-next PATCH v4 8/8] net: dsa: realtek: rtl8365mb: add bridge port flags Luiz Angelo Daros de Luca

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=e9edd482-28dd-4222-8df2-822da29f0f53@yahoo.com \
    --to=namiltd@yahoo.com \
    --cc=abdulkader.alrezej@gmail.com \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linusw@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linux@rasmusvillemoes.dk \
    --cc=luizluca@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=pabeni@redhat.com \
    --cc=ynorov@nvidia.com \
    --cc=yury.norov@gmail.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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®