Re: [PATCH net-next v2 4/4] net: dsa: soce: Add basic support for SoC-e switch IP cores

[Vasilij Strassheim]

On Tue, 2026-09-15 at 14:56 +0200, Andrew Lunn wrote:
> > > After an unbind or rmmod, does the core keep inserting SDSA source-port
> > > tags into every frame delivered to the CPU port, with the tagger that
> > > would strip them gone?  As described in the commit message, the same bits
> > > also keep the user ports in CPU-directed operation:
> > > 
> > >     "Enabling this tagging feature of the switch, places all user ports
> > >     into CPU-directed operation"
> > > 
> > > so the switch would also stay locked out of normal port-to-port
> > > forwarding after the driver is removed.
> > 
> > Yes, I had not considered this use case. The tagging state currently
> > remains enabled after unbind or shutdown. In v3, I will add a .teardown
> > callback that clears both SOCE_TAG_ALL_FRAMES_ENABLE and
> > SOCE_CUSTOM_RULES_TAGGING_ENABLE, returning the switch to an unmanaged
> > state.
> 
> I would say the AI is wrong here. If you put the switch into unmanaged
> mode, and don't have anything performing spanning tree, your network
> could experience a broadcast storm and stop working. The .teardown
> should disable all the ports, leaving the network in a safe
> configuration.

This makes more sense. I see that other drivers use the .port_disable()
callback to deactivate the switch's ports in this case. I would prefer
to add this together with .port_enable(). This should be enough to have
a safe configuration for the network if the driver is unbound.

A global reset or deactivation would be nice for teardown, but there is
no such feature available. For the sake of completeness, I think it
would also be valid to reset the modified bits in teardown() as proposed
by AI.

By the way, there are two registers involved: One for port selection and
another for port control. I would rely on rtnl_lock() and avoid adding own
locking mechanisms since these registers are not used anywhere else.

> 
> 	Andrew

Thanks,
Vasilij