Re: [PATCH net-next v2] net: phy: Add driver for Motorcomm yt8531 gigabit ethernet phy

[Andrew Lunn <andrew@lunn.ch>]

On Fri, Dec 02, 2022 at 01:34:16PM +0000, Russell King (Oracle) wrote:
> On Fri, Dec 02, 2022 at 02:27:43PM +0100, Andrew Lunn wrote:
> > > +static bool mdio_is_locked(struct phy_device *phydev)
> > > +{
> > > +	return mutex_is_locked(&phydev->mdio.bus->mdio_lock);
> > > +}
> > > +
> > > +#define ASSERT_MDIO(phydev) \
> > > +	WARN_ONCE(!mdio_is_locked(phydev), \
> > > +		  "MDIO: assertion failed at %s (%d)\n", __FILE__,  __LINE__)
> > > +
> > 
> > Hi Frank
> > 
> > You are not the only one who gets locking wrong. This could be used in
> > other drivers. Please add it to include/linux/phy.h,
> 
> That placement doesn't make much sense.
> 
> As I already said, we have lockdep checks in drivers/net/phy/mdio_bus.c,
> and if we want to increase their effectiveness, then that's the place
> that it should be done.

I was following the ASSERT_RTNL model, but that is used in quite deep
and complex call stacks, and it is useful to scatter the macro in lots
of places. PHY drivers are however very shallow, so yes, putting them
in mdio_bus.c makes a lot of sense.

> I don't see any point in using __FILE__ and __LINE__ in the above
> macro either. Firstly, WARN_ONCE() already includes the file and line,
> and secondly, the backtrace is more useful than the file and line where
> the assertion occurs especially if it's placed in mdio_bus.c

And PHY driver functions are simpler, there is a lot less inlining
going on, so the function name is probably all you need to know to
find where you messed up the locking. So i agree, they can be removed.

     Andrew