search for: port_fdb_del

...e interfaces). So this breaks those drivers > which don't implement DSA_FDB_FLAG_DYNAMIC but do set > ds->assisted_learning_on_cpu_port > to true. I am not sure I understand you entirely. From my standpoint I see it as so: that until now any fdb entry coming to port_fdb_add() (or port_fdb_del()) are seen as static entries. And this changes nothing with respect to those static entries as how drivers handle them. When the new dynamic flag is true, all drivers will ignore it in patch #3, so basically nothing will change by that. Then in patch #5 the dynamic flag is handled by the mv88e...

...ost addresses on LAG ports still require regular FDB ops, * since the CPU port isn't in a LAG. */ if (dp->lag && !host_addr) { if (!ds->ops->lag_fdb_add || !ds->ops->lag_fdb_del) return -EOPNOTSUPP; } else { if (!ds->ops->port_fdb_add || !ds->ops->port_fdb_del) return -EOPNOTSUPP; } What you should be doing is you should be using the pahole tool to find a good place for a new unsigned long field in struct dsa_switch, and add a new field ds->supported_fdb_flags. You should extend the early checking from dsa_slave_fdb_event() and exit without doing...

On Tue, Jan 17, 2023 at 07:57:11PM +0100, Hans J. Schultz wrote: > Dynamic FDB flag needs to be propagated through the DSA layer to be > added to drivers. > Use a u16 for fdb flags for future use, so that other flags can also be > sent the same way without having to change function interfaces. > > Signed-off-by: Hans J. Schultz <netdev at kapio-technology.com> > ---