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> --- 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. 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); -- 2.47.1
