On 2022-08-29 09:40, Ido Schimmel wrote:

On Sun, Aug 28, 2022 at 02:00:29PM +0200, netdev@kapio-technology.com 
wrote:

quoted

On 2022-08-27 20:21, Ido Schimmel wrote:

quoted

"locked on learning on" is counter intuitive and IMO very much a
misconfiguration that we should have disallowed when the "locked" option
was introduced. It is my understanding that the only reason we are even
talking about it is because mv88e6xxx needs it for MAB for some reason.

As the way mv88e6xxx implements "learning off" is to remove port 
association
for ingress packets on a port, but that breaks many other things such 
as
refreshing ATU entries and violation interrupts, so it is needed and 
the
question is then what is the worst to have 'learning on' on a locked 
port or
to have the locked port enabling learning in the driver silently?

Opinions seem to differ. Note that even on locked ports without MAB, 
port
association on ingress is still needed in future as I have a dynamic 
ATU
patch set coming, that uses age out violation and hardware refreshing 
to let
the hardware keep the dynamic entries as long as the authorized 
station is
sending, but will age the entry out if the station keeps silent for 
the
ageing time. But that patch set is dependent on this patch set, and I 
don't
think I can send it before this is accepted...

# bridge link set dev swp1 learning on locked on
# bridge link set dev swp2 learning on locked on

As we must think in how most drivers work, which I am not knowledgeable 
of, I think that it is probably the best to think of the way mv88e6xxx 
works as an outlier.
If that is true, then I think the best option is to go with:
#bridge link set dev $swp1 learning off locked on
#bridge link set dev $swp2 learning off locked on

Then the cleanup side will just be:
#bridge link set dev $swp1 locked off
#bridge link set dev $swp2 locked off

The state 'learning off' is then consistent with the behavior of both 
the bridge and driver after the cleanup.