On Tue, Jun 28, 2022 at 02:26:43PM +0200, Hans S wrote:
> > Dumb question: if you only flush the locked entries at fast age if the
> > port is locked, then what happens with the existing locked entries if
> > the port becomes unlocked before an FDB flush takes place?
> > Shouldn't mv88e6xxx_port_set_lock() call mv88e6xxx_atu_locked_entry_flush()
> > too?
>
> That was my first thought too, but the way the flags are handled with the mask etc, does so that
> mv88e6xxx_port_set_lock() is called when other flags change. It could be done by the transition
> from locked->unlocked by checking if the port is locked already.
Why does mv88e6xxx_port_set_lock() get called when other flags change?
> On the other hand, the timers will timeout and the entries will be removed anyhow.
> > > +static void mv88e6xxx_atu_locked_entry_timer_work(struct atu_locked_entry *ale)
> >
> > Please find a more adequate name for this function.
>
> Any suggestions?
Not sure. It depends on whether you leave just the logic to delete a
locked ATU entry, or also the switchdev FDB_DEL_TO_BRIDGE notifier.
In any case, pick a name that reflects what it does. Something with
locked_entry_delete() can't be too wrong.
> > From the discussion with Ido and Nikolay I get the impression that
> > you're not doing the right thing here either, notifying a
> > SWITCHDEV_FDB_DEL_TO_BRIDGE from what is effectively the
> > SWITCHDEV_FDB_DEL_TO_DEVICE handler (port_fdb_del).
>
> Hmm, my experience tells me that much is opposite the normal
> conventions when dealing with
> locked ports, as there was never switchdev notifications from the
> driver to the bridge before, but
> that is needed to keep ATU and FDB entries in sync.
On delete you mean? So the bridge signals switchdev a deletion of a
locked FDB entry (as I pointed out, this function gets indirectly called
from port_fdb_del), but it won't get deleted until switchdev signals it
back, is what you're saying?
> > Why is the rtnl_unlock() outside the switch statement but the rtnl_lock() inside?
> > Not to mention, the dsa_port_to_bridge_port() call needs to be under rtnl_lock().
>
> Just a small optimization as I also have another case of the switch
> (only one switch case if
> you didn't notice) belonging to the next patch set regarding dynamic
> ATU entries.
What kind of optimization are you even talking about? Please get rid of
coding patterns like this, sorry.
> > Please, no "if (chiplock) mutex_lock()" hacks. Just lockdep_assert_held(&chip->reg_lock),
> > which serves both for documentation and for validation purposes, ensure
> > the lock is always taken at the caller (which in this case is super easy)
> > and move on.
>
> As I am calling the function in if statement checks, it would make
> that code more messy, while with
> this approach the function can be called from anywhere. I also looked
> at having two functions, with
> one being a wrapper function taking the lock and calling the other...
There are many functions in mv88e6xxx that require the reg_lock to be
held, there's nothing new or special here.
> >
> > > +
> > > + if (mv88e6xxx_port_read(chip, port, MV88E6XXX_PORT_CTL0, ®))
> > > + goto out;
> >
> > It would be good to actually propagate the error to the caller and
> > "locked" via a pass-by-reference bool pointer argument, not just say
> > that I/O errors mean that the port is unlocked.
>
> Again the wish to be able to call it from if statement checks,.
>
> > > + reg &= MV88E6XXX_PORT_ASSOC_VECTOR_PAV_MASK;
> > > + if (locked) {
> > > + reg |= MV88E6XXX_PORT_ASSOC_VECTOR_IGNORE_WRONG |
> > > + MV88E6XXX_PORT_ASSOC_VECTOR_LOCKED_PORT |
> > > + MV88E6XXX_PORT_ASSOC_VECTOR_INT_AGE_OUT |
> > > + MV88E6XXX_PORT_ASSOC_VECTOR_HOLD_AT_1;
> >
> > I'd suggest aligning these macros vertically.
>
> They are according to the Linux kernel coding standard wrt indentation afaik.
Compare:
reg |= MV88E6XXX_PORT_ASSOC_VECTOR_IGNORE_WRONG |
MV88E6XXX_PORT_ASSOC_VECTOR_LOCKED_PORT |
MV88E6XXX_PORT_ASSOC_VECTOR_INT_AGE_OUT |
MV88E6XXX_PORT_ASSOC_VECTOR_HOLD_AT_1;
with:
reg |= MV88E6XXX_PORT_ASSOC_VECTOR_IGNORE_WRONG |
MV88E6XXX_PORT_ASSOC_VECTOR_LOCKED_PORT |
MV88E6XXX_PORT_ASSOC_VECTOR_INT_AGE_OUT |
MV88E6XXX_PORT_ASSOC_VECTOR_HOLD_AT_1;
