On 11/01/2025 at 11:47, Jakub Kicinski wrote: > I don't see any reason why napi_enable() needs to be under the lock, > only reason I could think of is if the IRQ also took this lock > but it doesn't. napi_enable() will soon need to sleep. > > Signed-off-by: Jakub Kicinski <kuba@xxxxxxxxxx> Acked-by: Vincent Mailhol <mailhol.vincent@xxxxxxxxxx> > --- > Marc, if this is correct is it okay for me to take via net-next > directly? I have a bunch of patches which depend on it. Even if the question is not addressed to me, I am personally fine if this directly goes into net-next. > CC: mkl@xxxxxxxxxxxxxx > CC: mailhol.vincent@xxxxxxxxxx > CC: linux-can@xxxxxxxxxxxxxxx > --- > drivers/net/can/grcan.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/net/can/grcan.c b/drivers/net/can/grcan.c > index cdf0ec9fa7f3..21a61b86f67d 100644 > --- a/drivers/net/can/grcan.c > +++ b/drivers/net/can/grcan.c > @@ -1073,9 +1073,10 @@ static int grcan_open(struct net_device *dev) > if (err) > goto exit_close_candev; > > + napi_enable(&priv->napi); > + > spin_lock_irqsave(&priv->lock, flags); > > - napi_enable(&priv->napi); > grcan_start(dev); > if (!(priv->can.ctrlmode & CAN_CTRLMODE_LISTENONLY)) > netif_start_queue(dev); Yours sincerely, Vincent Mailhol
