[PATCH AUTOSEL 6.17] hinic3: Fix missing napi->dev in netif_queue_set_napi

[Sasha Levin <sashal@kernel.org>]

From: Fan Gong <gongfan1@huawei.com>

[ Upstream commit 4404f6af810829588a51968959c6b85574109c13 ]

As netif_queue_set_napi checks napi->dev, if it doesn't have it and
it will warn_on and return. So we should use netif_napi_add before
netif_queue_set_napi because netif_napi_add has "napi->dev = dev".

Co-developed-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Zhu Yikai <zhuyikai1@h-partners.com>
Signed-off-by: Fan Gong <gongfan1@huawei.com>
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/a17a5a087350eaf2e081dcd879779ca2c69b0908.1757653621.git.zhuyikai1@h-partners.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES – The patch fixes a real bug that every hinic3 user will hit, and it
does so with a minimal, obviously-correct change.

- `drivers/net/ethernet/huawei/hinic3/hinic3_irq.c:45-50` now calls
  `netif_napi_add()` before `netif_queue_set_napi()`. Before this change
  the calls were reversed, so the queue registration happened while
  `napi->dev` was still NULL.
- `net/core/dev.c:7159-7166` shows `netif_queue_set_napi()` emits
  `WARN_ON_ONCE(napi && !napi->dev)` and returns early. That warning
  fires on every queue bring-up in current kernels because
  `qp_add_napi()` tried to attach the queue first, and the association
  silently failed.
- Because the helper bails out, the driver leaves
  `rxq->napi`/`txq->napi` unset, meaning busy-polling, queue
  diagnostics, and any code using `netif_queue_get_napi()` lose the
  mapping, on top of the user-visible WARN splat. `netif_napi_add()` is
  precisely where `napi->dev` becomes valid (`net/core/dev.c:7440`), so
  executing it first is required.
- The fix is a one-line reordering with no side effects or dependencies,
  so the regression risk is negligible while the benefit is immediate.

Given the always-on warning and missing queue-to-NAPI wiring, this is a
good and safe candidate for stable backporting.

 drivers/net/ethernet/huawei/hinic3/hinic3_irq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
index 8b92eed25edfe..aba1a1d579c50 100644
--- a/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
+++ b/drivers/net/ethernet/huawei/hinic3/hinic3_irq.c
@@ -42,11 +42,11 @@ void qp_add_napi(struct hinic3_irq_cfg *irq_cfg)
 {
 	struct hinic3_nic_dev *nic_dev = netdev_priv(irq_cfg->netdev);
 
+	netif_napi_add(nic_dev->netdev, &irq_cfg->napi, hinic3_poll);
 	netif_queue_set_napi(irq_cfg->netdev, irq_cfg->irq_id,
 			     NETDEV_QUEUE_TYPE_RX, &irq_cfg->napi);
 	netif_queue_set_napi(irq_cfg->netdev, irq_cfg->irq_id,
 			     NETDEV_QUEUE_TYPE_TX, &irq_cfg->napi);
-	netif_napi_add(nic_dev->netdev, &irq_cfg->napi, hinic3_poll);
 	napi_enable(&irq_cfg->napi);
 }
 
-- 
2.51.0