From: "Jérôme Pouiller" <jerome.pouiller@silabs.com>
To: sashiko-reviews@lists.linux.dev
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH wireless-next 1/2] wifi: wfx: fix possible device hang during init
Date: Mon, 31 Aug 2026 21:35:45 +0200 [thread overview]
Message-ID: <6025474.DvuYhMxLoT@nb0018864> (raw)
In-Reply-To: <20260831192342.2360E1F000E9@smtp.kernel.org>
On Monday 31 August 2026 21:23:41 Central European Summer Time sashiko-bot@kernel.org wrote:
[...]
>
> commit b2aaae6022fa921df221babdf79ea3e5f12e766f
> Author: Jérôme Pouiller <jerome.pouiller@silabs.com>
>
> 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.
>
> > 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
>
> [ ... ]
>
> > @@ -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
next prev parent reply other threads:[~2026-08-31 19:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 16:40 [PATCH wireless-next 0/2] wifi: wfx: fix possible device hang during init Jérôme Pouiller
2026-08-31 16:40 ` [PATCH wireless-next 1/2] " Jérôme Pouiller
2026-08-31 19:23 ` sashiko-bot
2026-08-31 19:35 ` Jérôme Pouiller [this message]
2026-08-31 16:40 ` [PATCH wireless-next 2/2] dt-bindings: net: wireless: wfx: discourage OOB IRQ with SDIO Jérôme Pouiller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6025474.DvuYhMxLoT@nb0018864 \
--to=jerome.pouiller@silabs.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.