Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 30 Mar 2023 17:01:34 +0200
From:   =?UTF-8?B?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>
To:     Vladimir Oltean <olteanv@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        linux-renesas-soc@vger.kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org,
        Thomas Petazzoni <thomas.petazzoni@bootlin.com>,
        Herve Codina <herve.codina@bootlin.com>,
        =?UTF-8?B?TWlxdcOobA==?= Raynal <miquel.raynal@bootlin.com>,
        Milan Stevanovic <milan.stevanovic@se.com>,
        Jimmy Lalande <jimmy.lalande@se.com>,
        Pascal Eberhard <pascal.eberhard@se.com>,
        Alexis =?UTF-8?B?TG90aG9yw6k=?= <alexis.lothore@bootlin.com>
Subject: Re: [PATCH net-next 1/2] net: dsa: rzn1-a5psw: enable DPBU for CPU
 port and fix STP states
Message-ID: <20230330170134.2f0cd3d1@fixe.home>
In-Reply-To: <20230330145623.z5q44euny3zj3uat@skbuf>
References: <20230330083408.63136-1-clement.leger@bootlin.com>
        <20230330083408.63136-2-clement.leger@bootlin.com>
        <20230330104828.6badaaad@fixe.home>
        <20230330145623.z5q44euny3zj3uat@skbuf>
Organization: Bootlin
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Le Thu, 30 Mar 2023 17:56:23 +0300,
Vladimir Oltean <olteanv@gmail.com> a =C3=A9crit :

> On Thu, Mar 30, 2023 at 10:48:28AM +0200, Cl=C3=A9ment L=C3=A9ger wrote:
> > Actually, after leaving a bridge, it seems like the DSA core put the
> > port in STP DISABLED state. Which means it will potentially leave that
> > port with TX disable... Since this TX enable is applying not only on
> > bridge port but also on standalone port, it seems like this also needs
> > to be reenabled in bridge_leave(). =20
>=20
> That's... not true? dsa_port_switchdev_unsync_attrs() has:
>=20
> 	/* Port left the bridge, put in BR_STATE_DISABLED by the bridge layer,
> 	 * so allow it to be in BR_STATE_FORWARDING to be kept functional
> 	 */
> 	dsa_port_set_state_now(dp, BR_STATE_FORWARDING, true);
>=20
> a dump_stack() could help explain what's going on in your system?

Indeed, I was referring to the messages displayed by the STP setp state
function (br0: port 2(lan1) entered disabled state). But the DSA core
indeed calls the stp_set_state() to enable forwarding which then
reenables the Tx path so I guess we are all good with this series.
Sorry for that.

--=20
Cl=C3=A9ment L=C3=A9ger,
Embedded Linux and Kernel engineer at Bootlin
https://bootlin.com