Re: [PATCH wireless-next 1/2] wifi: wfx: fix possible device hang during init

On Monday 31 August 2026 21:23:41 Central European Summer Time sashiko-bot@kernel.org wrote:
[...]

commit b2aaae6022fa921df221babdf79ea3e5f12e766f
Author: Jérôme Pouiller [off-list ref]

wifi: wfx: fix possible device hang during init

This patch modifies the device initialization sequence to limit data
polling to out-of-band IRQ setups. It attempts to prevent a hardware lockup
that occurs if an IRQ fires while the host is reading the control register.

quoted

diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
index dda36e41eed13..da30e8f481ada 100644
--- a/drivers/net/wireless/silabs/wfx/main.c
+++ b/drivers/net/wireless/silabs/wfx/main.c

[ ... ]

quoted

@@ -374,12 +373,19 @@ int wfx_probe(struct wfx_dev *wdev)
      if (err)
              goto bh_unregister;

-     wfx_bh_poll_irq(wdev);
+     if (wdev->poll_irq) {
+             wfx_bh_poll_irq(wdev);
+     } else {
+             err = wdev->hwbus_ops->irq_subscribe(wdev->hwbus_priv);
+             if (err)
+                     goto bh_unregister;
+     }
+
      err = wait_for_completion_timeout(&wdev->firmware_ready, 1 * HZ);

[Severity: High]
The commit message states that the IRQ is subscribed before the first
exchange with the device. However, looking at wfx_probe(), the code just
above this snippet calls wfx_init_device(), which conducts the first
exchanges and unmasks device-side interrupts.

Since irq_subscribe() is only called after wfx_init_device() finishes, is
there a race window here?

If the device asserts the firmware-ready interrupt during this gap before
the host OS registers the IRQ handler, could the edge be permanently lost
(e.g., on SPI platforms using edge-triggered interrupts)? This seems like it
could cause the subsequent wait_for_completion_timeout() to timeout and
hang the initialization.

hmm... Indeed, maybe. I will sent a v2.



-- 
Jérôme Pouiller