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

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

[Jérôme Pouiller]

The WFxxx devices provide an SDIO interface. Besides the usual in-band
SDIO IRQ, they also support an out-of-band (OOB) IRQ line declared in the
Device Tree.

The OOB IRQ line is not usable until the device has been configured by
the PDS file. Therefore, since commit f00dc1d789e1c ("staging: wfx: poll
IRQ during init"), the driver polls the control register during the first
exchanges with the device instead of relying on an IRQ. To keep the code
simpler, this polling was applied unconditionally, including when an IRQ
was readily available (in-band SDIO IRQ and SPI).

Unfortunately, this polling is unsafe. Commit 57aa557f110d9 ("staging:
wfx: introduce a way to poll IRQ") already mentioned that an IRQ could be
lost if it fires while the host reads the control register. A recent
analysis shows the consequences are worse than documented: the device
itself gets stuck and stops answering subsequent commands. Only pulling
the reset pin and rebinding the device recovers it.

Since the polling only happens during the two first exchanges, the issue
is rare. It was caught by user while binding/rebinding the device in a loop
for a few hours.

Patch 1 restricts the polling to the case where it is actually required
(SDIO with OOB IRQ). The bus driver now tells wfx_probe() whether polling
is necessary; in every other case the IRQ is subscribed before the first
exchange and the racy path is never taken. This makes the vast majority
of the integrations safe.

The SDIO + OOB IRQ combination remains affected. There is no way to fix
it in software: polling is the only way to bootstrap that setup. Note that
nobody reported using it in the last 6 years.

Patch 2 documents this hardware limitation in the binding, so that new
designs do not pick this configuration.

v2:
  - Subscribe IRQ before wfx_init_device(). So it avoids possible race
    between IRQ enable and IRQ subscription (reported by sashiko-bot)

[Copilot generated the introduction letter and reviewed the code]


Jérôme Pouiller (2):
  wifi: wfx: fix possible device hang during init
  dt-bindings: net: wireless: wfx: discourage OOB IRQ with SDIO

 .../bindings/net/wireless/silabs,wfx.yaml     |  3 ++
 drivers/net/wireless/silabs/wfx/bh.c          |  6 ++--
 drivers/net/wireless/silabs/wfx/bus_sdio.c    |  1 +
 drivers/net/wireless/silabs/wfx/main.c        | 34 ++++++++++++-------
 4 files changed, 29 insertions(+), 15 deletions(-)

-- 
2.47.3

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

[Jérôme Pouiller]

The WFxxx device provides an SDIO interface. In addition to the usual
in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ
requires a specific initialization described in commit f00dc1d789e1c
("staging: wfx: poll IRQ during init"):

    When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
    IRQ) cannot be used before to configure it. Therefore, the first
    exchanges with the chip have to be done without the OOB IRQ.

    This patch allow to poll the data until the OOB IRQ is correctly
    setup. In order to keep the code simpler, this patch also poll data
    even if OOB IRQ is not used.

Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ")
announce some limitation about the data polling mechanism:

    This function [wfx_bh_poll_irq()] must used with care: if an IRQ
    fires while the host reads control register, the IRQ can be lost.

However, with last analysis, it seems it does not only impact the IRQ.
When this condition happen the hardware is lost and won't reply the next
commands. The only way to recover the error is to pull the reset pin and
bind the device again.

Currently wfx_bh_poll_irq() is only used during the two first exchanges
with the hardware. Therefore, it has been reported to only happen after
a few hours of bind/rebind in a loop. This explain why it has not been
reported before.

Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is
probably very marginal. The In-Band IRQ case also uses this function,
but only to simplify the code.

This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus
driver now tells wfx_probe() whether polling is necessary. When it is
not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first
exchange with the device and wfx_bh_poll_irq() is never called. When it
is (SDIO with OOB IRQ), the behavior is unchanged: the control register
is polled until the PDS file has configured the IRQ line.

To conclude, In-Band users are now safe. Users of OOB IRQ will be still
impacted by the bug, but there is nothing we can do (and nobody
complained during the last 6 years).

Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init")
Reported-by: Gerard Salvatella <gerard.salvatella@siemens.com>
Reported-by: Lukas Stockmann <lukas.stockmann@siemens.com>
Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
 drivers/net/wireless/silabs/wfx/bh.c       |  6 ++--
 drivers/net/wireless/silabs/wfx/bus_sdio.c |  1 +
 drivers/net/wireless/silabs/wfx/main.c     | 34 ++++++++++++++--------
 3 files changed, 26 insertions(+), 15 deletions(-)

diff --git a/drivers/net/wireless/silabs/wfx/bh.c b/drivers/net/wireless/silabs/wfx/bh.c
index 21dfdcf9cc273..0071659bc9c98 100644
--- a/drivers/net/wireless/silabs/wfx/bh.c
+++ b/drivers/net/wireless/silabs/wfx/bh.c
@@ -284,10 +284,10 @@ void wfx_bh_request_tx(struct wfx_dev *wdev)
 }
 
 /* If IRQ is not available, this function allow to manually poll the control register and simulate
- * an IRQ ahen an event happened.
+ * an IRQ when an event happened.
  *
- * Note that the device has a bug: If an IRQ raise while host read control register, the IRQ is
- * lost. So, use this function carefully (only duing device initialisation).
+ * Note that the device has a bug: If an IRQ raise while host read control register, the device is
+ * lost. Unfortunately, this is the only way to initialize the SDIO with out-of-band IRQ.
  */
 void wfx_bh_poll_irq(struct wfx_dev *wdev)
 {
diff --git a/drivers/net/wireless/silabs/wfx/bus_sdio.c b/drivers/net/wireless/silabs/wfx/bus_sdio.c
index ab0793b9908f4..1ca2cc262feb2 100644
--- a/drivers/net/wireless/silabs/wfx/bus_sdio.c
+++ b/drivers/net/wireless/silabs/wfx/bus_sdio.c
@@ -279,6 +279,7 @@ static int wfx_sdio_probe(struct sdio_func *func, const struct sdio_device_id *i
 		goto sdio_release;
 	}
 
+	bus->core->poll_irq = !!bus->of_irq;
 	ret = wfx_probe(bus->core);
 	if (ret)
 		goto sdio_release;
diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
index dda36e41eed13..4e99fe7e5bb78 100644
--- a/drivers/net/wireless/silabs/wfx/main.c
+++ b/drivers/net/wireless/silabs/wfx/main.c
@@ -362,7 +362,6 @@ int wfx_probe(struct wfx_dev *wdev)
 	 */
 	gpio_saved = wdev->pdata.gpio_wakeup;
 	wdev->pdata.gpio_wakeup = NULL;
-	wdev->poll_irq = true;
 
 	wdev->bh_wq = alloc_workqueue("wfx_bh_wq", WQ_HIGHPRI | WQ_PERCPU, 0);
 	if (!wdev->bh_wq)
@@ -370,16 +369,24 @@ int wfx_probe(struct wfx_dev *wdev)
 
 	wfx_bh_register(wdev);
 
+	if (!wdev->poll_irq) {
+		err = wdev->hwbus_ops->irq_subscribe(wdev->hwbus_priv);
+		if (err)
+			goto bh_unregister;
+	}
+
 	err = wfx_init_device(wdev);
 	if (err)
-		goto bh_unregister;
+		goto irq_unsubscribe;
+
+	if (wdev->poll_irq)
+		wfx_bh_poll_irq(wdev);
 
-	wfx_bh_poll_irq(wdev);
 	err = wait_for_completion_timeout(&wdev->firmware_ready, 1 * HZ);
 	if (err == 0) {
 		dev_err(wdev->dev, "timeout while waiting for startup indication\n");
 		err = -ETIMEDOUT;
-		goto bh_unregister;
+		goto irq_unsubscribe;
 	}
 
 	/* FIXME: fill wiphy::hw_version */
@@ -399,12 +406,12 @@ int wfx_probe(struct wfx_dev *wdev)
 		dev_err(wdev->dev, "unsupported firmware API version (expect 1 while firmware returns %d)\n",
 			wdev->hw_caps.api_version_major);
 		err = -EOPNOTSUPP;
-		goto bh_unregister;
+		goto irq_unsubscribe;
 	}
 
 	if (wdev->hw_caps.link_mode == SEC_LINK_ENFORCED) {
 		dev_err(wdev->dev, "chip require secure_link, but can't negotiate it\n");
-		goto bh_unregister;
+		goto irq_unsubscribe;
 	}
 
 	if (wdev->hw_caps.region_sel_mode) {
@@ -420,12 +427,14 @@ int wfx_probe(struct wfx_dev *wdev)
 	dev_dbg(wdev->dev, "sending configuration file %s\n", wdev->pdata.file_pds);
 	err = wfx_send_pdata_pds(wdev);
 	if (err < 0 && err != -ENOENT)
-		goto bh_unregister;
+		goto irq_unsubscribe;
 
-	wdev->poll_irq = false;
-	err = wdev->hwbus_ops->irq_subscribe(wdev->hwbus_priv);
-	if (err)
-		goto bh_unregister;
+	if (wdev->poll_irq) {
+		err = wdev->hwbus_ops->irq_subscribe(wdev->hwbus_priv);
+		if (err)
+			goto bh_unregister;
+		wdev->poll_irq = false;
+	}
 
 	err = wfx_hif_use_multi_tx_conf(wdev, true);
 	if (err)
@@ -474,7 +483,8 @@ int wfx_probe(struct wfx_dev *wdev)
 ieee80211_unregister:
 	ieee80211_unregister_hw(wdev->hw);
 irq_unsubscribe:
-	wdev->hwbus_ops->irq_unsubscribe(wdev->hwbus_priv);
+	if (!wdev->poll_irq)
+		wdev->hwbus_ops->irq_unsubscribe(wdev->hwbus_priv);
 bh_unregister:
 	wfx_bh_unregister(wdev);
 	destroy_workqueue(wdev->bh_wq);
-- 
2.47.3

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

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Uncanceled delayed work triggers Use-After-Free.
--

commit 0e92ce2797177a88d76cee72478042230234d0a4
Author: Jérôme Pouiller <jerome.pouiller@silabs.com>

wifi: wfx: fix possible device hang during init

This commit fixes a device hang by limiting the use of the data polling
mechanism to out-of-band SDIO IRQs. For in-band IRQs and SPI, the IRQ is
now subscribed before the first hardware exchange, avoiding the polling
workaround entirely.

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

[ ... ]

[Severity: High]
This is a pre-existing issue, but I noticed a potential use-after-free in the
driver cleanup path. When the device enters a high temperature state,
wfx_suspend_hot_dev() schedules cooling_timeout_work on the system workqueue
with a 10-second delay.

If the driver is unloaded or the device is removed before this timer expires,
the devres callback wfx_free_common() frees the wdev structure without
canceling the pending work:

drivers/net/wireless/silabs/wfx/main.c:wfx_free_common() {
    ...
    ieee80211_free_hw(wdev->hw);
    ...
}

Does the cleanup path need a call to cancel_delayed_work_sync() for
wdev->cooling_timeout_work to prevent the delayed work from dereferencing
the freed wdev pointer when it eventually executes?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260901083548.113131-1-jerome.pouiller@silabs.com?part=1

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

[Jérôme Pouiller]

On Tuesday 1 September 2026 10:50:11 Central European Summer Time sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> 
> Pre-existing issues:
> - [High] Uncanceled delayed work triggers Use-After-Free.
> --
> 
> commit 0e92ce2797177a88d76cee72478042230234d0a4
> Author: Jérôme Pouiller <jerome.pouiller@silabs.com>
> 
> wifi: wfx: fix possible device hang during init
> 
> This commit fixes a device hang by limiting the use of the data polling
> mechanism to out-of-band SDIO IRQs. For in-band IRQs and SPI, the IRQ is
> now subscribed before the first hardware exchange, avoiding the polling
> workaround entirely.
> 
> > diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> > index dda36e41eed13..4e99fe7e5bb78 100644
> > --- a/drivers/net/wireless/silabs/wfx/main.c
> > +++ b/drivers/net/wireless/silabs/wfx/main.c
> 
> [ ... ]
> 
> [Severity: High]
> This is a pre-existing issue, but I noticed a potential use-after-free in the
> driver cleanup path. When the device enters a high temperature state,
> wfx_suspend_hot_dev() schedules cooling_timeout_work on the system workqueue
> with a 10-second delay.
> 
> If the driver is unloaded or the device is removed before this timer expires,
> the devres callback wfx_free_common() frees the wdev structure without
> canceling the pending work:
> 
> drivers/net/wireless/silabs/wfx/main.c:wfx_free_common() {
>     ...
>     ieee80211_free_hw(wdev->hw);
>     ...
> }
> 
> Does the cleanup path need a call to cancel_delayed_work_sync() for
> wdev->cooling_timeout_work to prevent the delayed work from dereferencing
> the freed wdev pointer when it eventually executes?

To avoid confusion in reviews, I will fix that issue in another PR.


-- 
Jérôme Pouiller

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

[Sverdlin, Alexander]

Hi Jérôme!

Thanks for the patch! Just one pre-existing issue below:

On Tue, 2026-09-01 at 10:33 +0200, Jérôme Pouiller wrote:
> The WFxxx device provides an SDIO interface. In addition to the usual
> in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ
> requires a specific initialization described in commit f00dc1d789e1c
> ("staging: wfx: poll IRQ during init"):
> 
>     When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
>     IRQ) cannot be used before to configure it. Therefore, the first
>     exchanges with the chip have to be done without the OOB IRQ.
> 
>     This patch allow to poll the data until the OOB IRQ is correctly
>     setup. In order to keep the code simpler, this patch also poll data
>     even if OOB IRQ is not used.
> 
> Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ")
> announce some limitation about the data polling mechanism:
> 
>     This function [wfx_bh_poll_irq()] must used with care: if an IRQ
>     fires while the host reads control register, the IRQ can be lost.
> 
> However, with last analysis, it seems it does not only impact the IRQ.
> When this condition happen the hardware is lost and won't reply the next
> commands. The only way to recover the error is to pull the reset pin and
> bind the device again.
> 
> Currently wfx_bh_poll_irq() is only used during the two first exchanges
> with the hardware. Therefore, it has been reported to only happen after
> a few hours of bind/rebind in a loop. This explain why it has not been
> reported before.
> 
> Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is
> probably very marginal. The In-Band IRQ case also uses this function,
> but only to simplify the code.
> 
> This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus
> driver now tells wfx_probe() whether polling is necessary. When it is
> not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first
> exchange with the device and wfx_bh_poll_irq() is never called. When it
> is (SDIO with OOB IRQ), the behavior is unchanged: the control register
> is polled until the PDS file has configured the IRQ line.
> 
> To conclude, In-Band users are now safe. Users of OOB IRQ will be still
> impacted by the bug, but there is nothing we can do (and nobody
> complained during the last 6 years).
> 
> Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init")
> Reported-by: Gerard Salvatella <gerard.salvatella@siemens.com>
> Reported-by: Lukas Stockmann <lukas.stockmann@siemens.com>
> Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> ---
>  drivers/net/wireless/silabs/wfx/bh.c       |  6 ++--
>  drivers/net/wireless/silabs/wfx/bus_sdio.c |  1 +
>  drivers/net/wireless/silabs/wfx/main.c     | 34 ++++++++++++++--------
>  3 files changed, 26 insertions(+), 15 deletions(-)

[]

> diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> index dda36e41eed13..4e99fe7e5bb78 100644
> --- a/drivers/net/wireless/silabs/wfx/main.c
> +++ b/drivers/net/wireless/silabs/wfx/main.c
> @@ -399,12 +406,12 @@ int wfx_probe(struct wfx_dev *wdev)
>  		dev_err(wdev->dev, "unsupported firmware API version (expect 1 while firmware returns %d)\n",
>  			wdev->hw_caps.api_version_major);
>  		err = -EOPNOTSUPP;
> -		goto bh_unregister;
> +		goto irq_unsubscribe;
>  	}
>  
>  	if (wdev->hw_caps.link_mode == SEC_LINK_ENFORCED) {
>  		dev_err(wdev->dev, "chip require secure_link, but can't negotiate it\n");
> -		goto bh_unregister;
> +		goto irq_unsubscribe;
>  	}
>  
>  	if (wdev->hw_caps.region_sel_mode) {

At this point err still holds the (positive) return value from wait_for_completion_timeout,
so wfx_probe() would return a positive value (as failure).

But maybe it deserves a separate patch.

-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[Sverdlin, Alexander]

Hi Jérôme!

On Tue, 2026-09-01 at 12:43 +0200, Alexander Sverdlin wrote:
> Thanks for the patch! Just one pre-existing issue below:
> 
> On Tue, 2026-09-01 at 10:33 +0200, Jérôme Pouiller wrote:
> > The WFxxx device provides an SDIO interface. In addition to the usual
> > in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ
> > requires a specific initialization described in commit f00dc1d789e1c
> > ("staging: wfx: poll IRQ during init"):
> > 
> >     When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
> >     IRQ) cannot be used before to configure it. Therefore, the first
> >     exchanges with the chip have to be done without the OOB IRQ.
> > 
> >     This patch allow to poll the data until the OOB IRQ is correctly
> >     setup. In order to keep the code simpler, this patch also poll data
> >     even if OOB IRQ is not used.
> > 
> > Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ")
> > announce some limitation about the data polling mechanism:
> > 
> >     This function [wfx_bh_poll_irq()] must used with care: if an IRQ
> >     fires while the host reads control register, the IRQ can be lost.
> > 
> > However, with last analysis, it seems it does not only impact the IRQ.
> > When this condition happen the hardware is lost and won't reply the next
> > commands. The only way to recover the error is to pull the reset pin and
> > bind the device again.
> > 
> > Currently wfx_bh_poll_irq() is only used during the two first exchanges
> > with the hardware. Therefore, it has been reported to only happen after
> > a few hours of bind/rebind in a loop. This explain why it has not been
> > reported before.
> > 
> > Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is
> > probably very marginal. The In-Band IRQ case also uses this function,
> > but only to simplify the code.
> > 
> > This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus
> > driver now tells wfx_probe() whether polling is necessary. When it is
> > not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first
> > exchange with the device and wfx_bh_poll_irq() is never called. When it
> > is (SDIO with OOB IRQ), the behavior is unchanged: the control register
> > is polled until the PDS file has configured the IRQ line.
> > 
> > To conclude, In-Band users are now safe. Users of OOB IRQ will be still
> > impacted by the bug, but there is nothing we can do (and nobody
> > complained during the last 6 years).
> > 
> > Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init")
> > Reported-by: Gerard Salvatella <gerard.salvatella@siemens.com>
> > Reported-by: Lukas Stockmann <lukas.stockmann@siemens.com>
> > Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > ---
> >  drivers/net/wireless/silabs/wfx/bh.c       |  6 ++--
> >  drivers/net/wireless/silabs/wfx/bus_sdio.c |  1 +
> >  drivers/net/wireless/silabs/wfx/main.c     | 34 ++++++++++++++--------
> >  3 files changed, 26 insertions(+), 15 deletions(-)
> 
> []
> 
> > diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> > index dda36e41eed13..4e99fe7e5bb78 100644
> > --- a/drivers/net/wireless/silabs/wfx/main.c
> > +++ b/drivers/net/wireless/silabs/wfx/main.c
> > @@ -399,12 +406,12 @@ int wfx_probe(struct wfx_dev *wdev)
> >  		dev_err(wdev->dev, "unsupported firmware API version (expect 1 while firmware returns %d)\n",
> >  			wdev->hw_caps.api_version_major);
> >  		err = -EOPNOTSUPP;
> > -		goto bh_unregister;
> > +		goto irq_unsubscribe;
> >  	}
> >  
> >  	if (wdev->hw_caps.link_mode == SEC_LINK_ENFORCED) {
> >  		dev_err(wdev->dev, "chip require secure_link, but can't negotiate it\n");
> > -		goto bh_unregister;
> > +		goto irq_unsubscribe;
> >  	}
> >  
> >  	if (wdev->hw_caps.region_sel_mode) {
> 
> At this point err still holds the (positive) return value from wait_for_completion_timeout,
> so wfx_probe() would return a positive value (as failure).
> 
> But maybe it deserves a separate patch.

I was able to carry out a short regression test in the meanwhile and at least
I didn't see any regression on a system with SDIO and inband IRQs.

Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Tested-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

My colleagues will give you a feedback from a long-term test run.

Thank you!
-- 
Alexander Sverdlin
Siemens AG
www.siemens.com

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

[Jérôme Pouiller]

On Tuesday 1 September 2026 12:43:22 Central European Summer Time Sverdlin, Alexander wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
> 
> 
> Hi Jérôme!
> 
> Thanks for the patch! Just one pre-existing issue below:
> 
> On Tue, 2026-09-01 at 10:33 +0200, Jérôme Pouiller wrote:
> > The WFxxx device provides an SDIO interface. In addition to the usual
> > in-band SDIO IRQ, the device also supports out-of-band IRQ line. OOB IRQ
> > requires a specific initialization described in commit f00dc1d789e1c
> > ("staging: wfx: poll IRQ during init"):
> >
> >     When the chip starts in SDIO mode, the external IRQ (aka Out-Of-Band
> >     IRQ) cannot be used before to configure it. Therefore, the first
> >     exchanges with the chip have to be done without the OOB IRQ.
> >
> >     This patch allow to poll the data until the OOB IRQ is correctly
> >     setup. In order to keep the code simpler, this patch also poll data
> >     even if OOB IRQ is not used.
> >
> > Commit 57aa557f110d9 ("staging: wfx: introduce a way to poll IRQ")
> > announce some limitation about the data polling mechanism:
> >
> >     This function [wfx_bh_poll_irq()] must used with care: if an IRQ
> >     fires while the host reads control register, the IRQ can be lost.
> >
> > However, with last analysis, it seems it does not only impact the IRQ.
> > When this condition happen the hardware is lost and won't reply the next
> > commands. The only way to recover the error is to pull the reset pin and
> > bind the device again.
> >
> > Currently wfx_bh_poll_irq() is only used during the two first exchanges
> > with the hardware. Therefore, it has been reported to only happen after
> > a few hours of bind/rebind in a loop. This explain why it has not been
> > reported before.
> >
> > Fortunately, wfx_bh_poll_irq() is only required for OOB IRQ, which is
> > probably very marginal. The In-Band IRQ case also uses this function,
> > but only to simplify the code.
> >
> > This patch limits the use of wfx_bh_poll_irq() to the OOB IRQ. The bus
> > driver now tells wfx_probe() whether polling is necessary. When it is
> > not (in-band SDIO IRQ and SPI), the IRQ is subscribed before the first
> > exchange with the device and wfx_bh_poll_irq() is never called. When it
> > is (SDIO with OOB IRQ), the behavior is unchanged: the control register
> > is polled until the PDS file has configured the IRQ line.
> >
> > To conclude, In-Band users are now safe. Users of OOB IRQ will be still
> > impacted by the bug, but there is nothing we can do (and nobody
> > complained during the last 6 years).
> >
> > Fixes: f00dc1d789e1c ("staging: wfx: poll IRQ during init")
> > Reported-by: Gerard Salvatella <gerard.salvatella@siemens.com>
> > Reported-by: Lukas Stockmann <lukas.stockmann@siemens.com>
> > Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> > ---
> >  drivers/net/wireless/silabs/wfx/bh.c       |  6 ++--
> >  drivers/net/wireless/silabs/wfx/bus_sdio.c |  1 +
> >  drivers/net/wireless/silabs/wfx/main.c     | 34 ++++++++++++++--------
> >  3 files changed, 26 insertions(+), 15 deletions(-)
> 
> []
> 
> > diff --git a/drivers/net/wireless/silabs/wfx/main.c b/drivers/net/wireless/silabs/wfx/main.c
> > index dda36e41eed13..4e99fe7e5bb78 100644
> > --- a/drivers/net/wireless/silabs/wfx/main.c
> > +++ b/drivers/net/wireless/silabs/wfx/main.c
> > @@ -399,12 +406,12 @@ int wfx_probe(struct wfx_dev *wdev)
> >               dev_err(wdev->dev, "unsupported firmware API version (expect 1 while firmware returns %d)\n",
> >                       wdev->hw_caps.api_version_major);
> >               err = -EOPNOTSUPP;
> > -             goto bh_unregister;
> > +             goto irq_unsubscribe;
> >       }
> >
> >       if (wdev->hw_caps.link_mode == SEC_LINK_ENFORCED) {
> >               dev_err(wdev->dev, "chip require secure_link, but can't negotiate it\n");
> > -             goto bh_unregister;
> > +             goto irq_unsubscribe;
> >       }
> >
> >       if (wdev->hw_caps.region_sel_mode) {
> 
> At this point err still holds the (positive) return value from wait_for_completion_timeout,
> so wfx_probe() would return a positive value (as failure).
> 
> But maybe it deserves a separate patch.

To avoid confusion in the reviews (since this an unrelated issue), I will
place this change in a second series.

-- 
Jérôme Pouiller

[PATCH wireless-next v2 2/2] dt-bindings: net: wireless: wfx: discourage OOB IRQ with SDIO

[Jérôme Pouiller]

The WFxxx device provides an SDIO interface. In addition to the usual
in-band SDIO IRQ, the device also supports an out-of-band IRQ line.

However, using the OOB IRQ with SDIO requires to poll the control
register during the device initialization. This polling is unreliable:
if an IRQ is raised while the host reads the control register, the
device is lost and only a reset allows to recover it.

There is no way to fix this in software. So, warn the user that this
setup should be reserved to debug.

Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
---
 Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
index 6c0888ae4c4e1..60dfe257eadc2 100644
--- a/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml
@@ -50,6 +50,9 @@ properties:
       used, this property is required. When SDIO is used, the "in-band"
       interrupt provided by the SDIO bus is used unless an interrupt is defined
       in the Device Tree.
+
+      The hardware suffers from a limitation when this property is used with
+      SDIO. OOB IRQ with SDIO should only be used for debug.
     maxItems: 1
 
   reset-gpios:
-- 
2.47.3

Re: [PATCH wireless-next v2 2/2] dt-bindings: net: wireless: wfx: discourage OOB IRQ with SDIO

[Krzysztof Kozlowski]

On Tue, Sep 01, 2026 at 10:33:20AM +0200, Jérôme Pouiller wrote:
> The WFxxx device provides an SDIO interface. In addition to the usual
> in-band SDIO IRQ, the device also supports an out-of-band IRQ line.
> 
> However, using the OOB IRQ with SDIO requires to poll the control
> register during the device initialization. This polling is unreliable:
> if an IRQ is raised while the host reads the control register, the
> device is lost and only a reset allows to recover it.
> 
> There is no way to fix this in software. So, warn the user that this
> setup should be reserved to debug.
> 
> Signed-off-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
> ---
>  Documentation/devicetree/bindings/net/wireless/silabs,wfx.yaml | 3 +++
>  1 file changed, 3 insertions(+)

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof