[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Yb+nsFxIeM9RkjPc@lunn.ch>
Date: Sun, 19 Dec 2021 22:44:16 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Alvin Šipraga <ALSI@...g-olufsen.dk>
Cc: Luiz Angelo Daros de Luca <luizluca@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
"vivien.didelot@...il.com" <vivien.didelot@...il.com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"olteanv@...il.com" <olteanv@...il.com>,
"arinc.unal@...nc9.com" <arinc.unal@...nc9.com>
Subject: Re: [PATCH net-next v2 07/13] net: dsa: realtek: add new mdio
interface for drivers
> > +int realtek_mdio_read_reg(struct realtek_priv *priv, u32 addr, u32 *data)
> > +{
> > + u32 phy_id = priv->phy_id;
> > + struct mii_bus *bus = priv->bus;
> > +
> > + BUG_ON(in_interrupt());
>
> Again, please don't use BUG here - just make sure this never happens (it
> looks OK to me). There is a separate warning in mutex_lock which may
> print a stacktrace if the kernel is configured to do so.
I did not look at the full patch. But if this is a standard MDIO
driver, there is no way we are in interrupt context. The MDIO layer
takes a mutex to prevent parallel operations.
Also, if you really do want to put a test here, it is better to make
use of the kernel infrastructure. might_sleep() if the correct way to
do this.
Andrew
Powered by blists - more mailing lists