The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: luizluca@gmail.com
Cc: Jakub Kicinski <kuba@kernel.org>,
	andrew@lunn.ch, olteanv@gmail.com, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
	linusw@kernel.org, alsi@bang-olufsen.dk, yury.norov@gmail.com,
	linux@rasmusvillemoes.dk, linux@armlinux.org.uk,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [net-next PATCH v3 6/8] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}
Date: Sun, 10 May 2026 10:34:51 -0700	[thread overview]
Message-ID: <20260510173451.3919869-1-kuba@kernel.org> (raw)
In-Reply-To: <20260506-realtek_forward-v3-6-1d87c5f85a3b@gmail.com>

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave}

This change implements hardware bridge offload for rtl8365mb by programming
per-port isolation masks and an EFID derived from the DSA bridge number.
The common helpers rtl83xx_port_bridge_join() and rtl83xx_port_bridge_leave()
are added for reuse across realtek drivers.

> diff --git a/drivers/net/dsa/realtek/rtl83xx.c b/drivers/net/dsa/realtek/rtl83xx.c
> index 2b9bd4462714..3ab91cd82743 100644
> --- a/drivers/net/dsa/realtek/rtl83xx.c
> +++ b/drivers/net/dsa/realtek/rtl83xx.c
> @@ -325,6 +325,120 @@ void rtl83xx_reset_deassert(struct realtek_priv *priv)
>  	gpiod_set_value(priv->reset, false);
>  }
>  
> +/**
> + * rtl83xx_port_bridge_join() - join a port to a bridge
> + * @ds: DSA switch instance
> + * @port: port index
> + * @bridge: bridge being joined
> + * @tx_forward_offload: if the switch can offload TX forwarding
> + * @extack: netlink extended ack for reporting errors
> + *
> + * This function handles joining a port to a bridge. It updates the port
> + * isolation masks and EFID.
> + *
> + * Context: Can sleep.
> + * Return: 0 on success, negative value for failure.
> + */
> +int rtl83xx_port_bridge_join(struct dsa_switch *ds, int port,
> +			     struct dsa_bridge bridge,
> +			     bool *tx_forward_offload,
> +			     struct netlink_ext_ack *extack)
> +{
> +	struct realtek_priv *priv = ds->priv;
> +	struct dsa_port *dp;
> +	u32 mask = 0;
> +	int ret;
> +
> +	if (!priv->ops->port_add_isolation)
> +		return -EOPNOTSUPP;
> +
> +	dev_dbg(priv->dev, "bridge %d join port %d\n", bridge.num, port);
> +
> +	/* Add this port to the isolation group of every other port
> +	 * offloading this bridge.
> +	 */
> +	dsa_switch_for_each_user_port(dp, ds) {
> +		/* Handle this port after */
> +		if (dp->index == port)
> +			continue;
> +
> +		/* Skip ports that are not in this bridge */
> +		if (!dsa_port_offloads_bridge(dp, &bridge))
> +			continue;
> +
> +		ret = priv->ops->port_add_isolation(priv, dp->index, BIT(port));
> +		if (ret)
> +			return ret;

[Medium]
If port_add_isolation() succeeds for one or more peer ports and then fails
for a subsequent peer, this returns without undoing the earlier updates.

Looking at dsa_port_bridge_join() in net/dsa/port.c, the failure path goes
to out_rollback which calls dsa_port_bridge_destroy() but does not dispatch
DSA_NOTIFIER_BRIDGE_LEAVE, so rtl83xx_port_bridge_leave() is not invoked to
revert the partial state.

Can peer ports end up retaining BIT(port) in their forwarding mask even
though port never successfully joined the bridge, leaving frames from
bridge members forwardable to a non-member?

> +
> +		mask |= BIT(dp->index);
> +	}
> +
> +	/* Add those ports to the isolation group of this port */
> +	ret = priv->ops->port_add_isolation(priv, port, mask);
> +	if (ret)
> +		return ret;

[Medium]
Similarly, if this call fails after peers have already been updated, the
peers keep BIT(port) set without any rollback. Should this path walk the
peers again and clear BIT(port) from the ones already modified before
returning the error?

> +
> +	/* Use the bridge number as the EFID for this port */
> +	if (priv->ops->port_set_efid) {
> +		ret = priv->ops->port_set_efid(priv, port, bridge.num);
> +		if (ret)
> +			return ret;

[Medium]
If port_set_efid() fails here, both the peer ports' isolation masks and
this port's isolation mask have already been updated to include the bridge
membership, but the function returns an error as if the join did not
happen. Should the isolation mask updates be reverted (and a plain EFID 0
restored where needed) before returning?

> +	}
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(rtl83xx_port_bridge_join, "REALTEK_DSA");
> +

[ ... ]

  parent reply	other threads:[~2026-05-10 17:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-07  2:58 [net-next PATCH v3 0/8] net: dsa: realtek: rtl8365mb: bridge offloading and VLAN support Luiz Angelo Daros de Luca
2026-05-07  2:58 ` [net-next PATCH v3 1/8] net: dsa: realtek: rtl8365mb: use ERR_PTR Luiz Angelo Daros de Luca
2026-05-10 15:23   ` Mieczyslaw Nalewaj
2026-05-07  2:58 ` [net-next PATCH v3 2/8] net: dsa: realtek: rtl8365mb: use dsa helpers for port iteration Luiz Angelo Daros de Luca
2026-05-10 15:23   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski
2026-05-10 17:35   ` Jakub Kicinski
2026-05-07  2:58 ` [net-next PATCH v3 3/8] net: dsa: realtek: rtl8365mb: prepare for multiple source files Luiz Angelo Daros de Luca
2026-05-10 15:23   ` Mieczyslaw Nalewaj
2026-05-07  2:58 ` [net-next PATCH v3 4/8] net: dsa: realtek: rtl8365mb: add table lookup interface Luiz Angelo Daros de Luca
2026-05-10 15:24   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski
2026-05-07  2:58 ` [net-next PATCH v3 5/8] net: dsa: realtek: rtl8365mb: add VLAN support Luiz Angelo Daros de Luca
2026-05-10 15:24   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski
2026-05-10 17:35   ` Jakub Kicinski
2026-05-07  2:58 ` [net-next PATCH v3 6/8] net: dsa: realtek: rtl8365mb: add port_bridge_{join,leave} Luiz Angelo Daros de Luca
2026-05-10 15:25   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski [this message]
2026-05-10 17:35   ` Jakub Kicinski
2026-05-07  2:58 ` [net-next PATCH v3 7/8] net: dsa: realtek: rtl8365mb: add FDB support Luiz Angelo Daros de Luca
2026-05-10 15:25   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski
2026-05-10 17:35   ` Jakub Kicinski
2026-05-11 15:00     ` Mieczyslaw Nalewaj
2026-05-07  2:58 ` [net-next PATCH v3 8/8] net: dsa: realtek: rtl8365mb: add bridge port flags Luiz Angelo Daros de Luca
2026-05-10 15:26   ` Mieczyslaw Nalewaj
2026-05-10 17:34   ` Jakub Kicinski
2026-05-10 17:34 ` [net-next PATCH v3 0/8] net: dsa: realtek: rtl8365mb: bridge offloading and VLAN support Jakub Kicinski
2026-05-11  4:58   ` Luiz Angelo Daros de Luca
2026-05-11  9:31     ` Linus Walleij

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=20260510173451.3919869-1-kuba@kernel.org \
    --to=kuba@kernel.org \
    --cc=alsi@bang-olufsen.dk \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@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=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