[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20250111024742.3680902-1-kuba@kernel.org>
Date: Fri, 10 Jan 2025 18:47:42 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: davem@...emloft.net
Cc: netdev@...r.kernel.org,
edumazet@...gle.com,
pabeni@...hat.com,
andrew+netdev@...n.ch,
horms@...nel.org,
Jakub Kicinski <kuba@...nel.org>,
mkl@...gutronix.de,
mailhol.vincent@...adoo.fr,
linux-can@...r.kernel.org
Subject: [PATCH net-next] can: grcan: move napi_enable() from under spin lock
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@...nel.org>
---
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@...gutronix.de
CC: mailhol.vincent@...adoo.fr
CC: linux-can@...r.kernel.org
---
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
Powered by blists - more mailing lists