[PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Rafael Beims]

From: Rafael Beims <rafael.beims@toradex.com>

In order for the firmware to sleep, the driver has to confirm a
previously received sleep request. The normal sequence of evets goes
like this:
EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm
-> SLEEP -> EVENT_AWAKE -> AWAKE.
Before sending the sleep-confirm command, the driver must make sure
there are no commands either running or waiting to be completed.

mwifiex_ret_802_11_associate() unconditionally sets
ps_state = PS_STATE_AWAKE when it processes the association command
response, outside of the normal powersave management flow. If
EVENT_SLEEP arrives while the association command is in flight,
ps_state is PRE_SLEEP when the association command response is parsed,
and the forced AWAKE overwrites it. The deferred sleep-confirm is
never sent.

A subsequent scan_start command is correctly acknowledged, but the
firmware doesn't generate scan_result events. The scan request never
finishes, and additional requests from userspace fail with -EBUSY.

After testing on both IW412 and W8997, I could only trigger the bug on
the IW412 and observed the firmwares behave differently. On the IW412
the firmware still sends EVENT_SLEEP while the authentication /
association process is ongoing. A W8997 under the same
conditions seems to suppress power-save for the duration of the
association, so PRE_SLEEP never coincided with the association response
even after extended periods of testing using the loops
described below (>12hours).

On the IW412, the delay between commands that triggers an EVENT_SLEEP
was empirically determined to be ~20ms. This delay can naturally occur
when the driver is outputting debugging information
(debug_mask = 0x00000037), in which situation the busy scans issue is
repeatable while running "test 1)" as described below. If the delay
between commands is less than ~20ms, the firmware stays awake and
the issue was not reproducible running the same test.

The host_mlme=false path also behaves differently. In this case, the
entire authentication / association transaction is executed by one
command (HostCmd_CMD_802_11_ASSOCIATE), and the firmware doesn't emit
EVENT_SLEEP while the command is running.

Remove the assignment so the ps_state is only manipulated in the paths
that are related to powersave event handling and on the main workqueue
for correct sleep confirmation.

The following loop tests were performed (with debugging output enabled):
1) force roaming between two AP's, one 5GHz and one 2.4GHz, same
SSID. Use wpa_cli to trigger the roaming behavior, sleep 2s
between iterations.
2) force a disconnection to AP 1 and a connection to AP 2, test
scan. Use wpa_cli to trigger the connection changes, sleep 2s
between iterations.

Each test ran in each device for at least 3 hours.

Fixes: 5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Rafael Beims <rafael.beims@toradex.com>
---
 drivers/net/wireless/marvell/mwifiex/join.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/join.c b/drivers/net/wireless/marvell/mwifiex/join.c
index 5a1a0287c1d5..b48f7febaf03 100644
--- a/drivers/net/wireless/marvell/mwifiex/join.c
+++ b/drivers/net/wireless/marvell/mwifiex/join.c
@@ -736,7 +736,6 @@ int mwifiex_ret_802_11_associate(struct mwifiex_private *priv,
 	/* Send a Media Connected event, according to the Spec */
 	priv->media_connected = true;
 
-	priv->adapter->ps_state = PS_STATE_AWAKE;
 	priv->adapter->pps_uapsd_mode = false;
 	priv->adapter->tx_lock_flag = false;
 
-- 
2.53.0

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Francesco Dolcini]

On Fri, Jun 12, 2026 at 09:25:46AM -0300, Rafael Beims wrote:
> From: Rafael Beims <rafael.beims@toradex.com>
> 
> In order for the firmware to sleep, the driver has to confirm a
> previously received sleep request. The normal sequence of evets goes
> like this:
> EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm
> -> SLEEP -> EVENT_AWAKE -> AWAKE.
> Before sending the sleep-confirm command, the driver must make sure
> there are no commands either running or waiting to be completed.
> 
> mwifiex_ret_802_11_associate() unconditionally sets
> ps_state = PS_STATE_AWAKE when it processes the association command
> response, outside of the normal powersave management flow. If
> EVENT_SLEEP arrives while the association command is in flight,
> ps_state is PRE_SLEEP when the association command response is parsed,
> and the forced AWAKE overwrites it. The deferred sleep-confirm is
> never sent.

Brian / Jeff: I am not that familiar with this part of the code, it
sounds correct to me (and I discussed it with Rafael before he did send
the patch), maybe you can also have a look.

Jeff: same issue in the nxpwifi driver.

Francesco

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Jeff Chen]

On Fri, Jun 12, 2026 at 09:25:46 AM -0300, Rafael Beims wrote:
> From: Rafael Beims <rafael.beims@toradex.com>
> 
> In order for the firmware to sleep, the driver has to confirm a
> previously received sleep request. The normal sequence of evets goes
> like this:
> EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm
> -> SLEEP -> EVENT_AWAKE -> AWAKE.
> Before sending the sleep-confirm command, the driver must make sure
> there are no commands either running or waiting to be completed.
> 
> mwifiex_ret_802_11_associate() unconditionally sets
> ps_state = PS_STATE_AWAKE when it processes the association command
> response, outside of the normal powersave management flow. If
> EVENT_SLEEP arrives while the association command is in flight,
> ps_state is PRE_SLEEP when the association command response is parsed,
> and the forced AWAKE overwrites it. The deferred sleep-confirm is
> never sent.
> 

Hi Rafael,
Thanks for the clear analysis.
Agreed with the fix — association response handling shouldn’t override ps_state.
For reference, the NXP downstream driver also doesn’t update ps_state in the
association response path, so this is consistent.

Reviewed-by: Jeff Chen <jeff.chen_1@nxp.com>

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Jeff Chen]

On Fri, Jun 12, 2026 at 09:25:46 AM -0300, Rafael Beims wrote:
> From: Rafael Beims <rafael.beims@toradex.com>
> 
> 
> After testing on both IW412 and W8997, I could only trigger the bug on

I don't think there's an IW412 in NXP's lineup — did you mean IW416?

> the IW412 and observed the firmwares behave differently. On the IW412
> the firmware still sends EVENT_SLEEP while the authentication /
> association process is ongoing. A W8997 under the same
> conditions seems to suppress power-save for the duration of the
> association, so PRE_SLEEP never coincided with the association response
> even after extended periods of testing using the loops
> described below (>12hours).
> 

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Francesco Dolcini]

On Mon, Jun 15, 2026 at 03:45:44PM +0800, Jeff Chen wrote:
> On Fri, Jun 12, 2026 at 09:25:46 AM -0300, Rafael Beims wrote:
> > From: Rafael Beims <rafael.beims@toradex.com>
> > 
> > 
> > After testing on both IW412 and W8997, I could only trigger the bug on
> 
> I don't think there's an IW412 in NXP's lineup — did you mean IW416?

Yes, I can confirm it is IW416.

The commit message should be fixed.

Francesco

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Jeff Chen]

On Fri, Jun 12, 2026 at 03:06:28 PM +0200, Francesco Dolcini wrote:
> On Fri, Jun 12, 2026 at 09:25:46AM -0300, Rafael Beims wrote:
> > From: Rafael Beims <rafael.beims@toradex.com>
> > 
> > In order for the firmware to sleep, the driver has to confirm a
> > previously received sleep request. The normal sequence of evets goes
> > like this:
> > EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm
> > -> SLEEP -> EVENT_AWAKE -> AWAKE.
> > Before sending the sleep-confirm command, the driver must make sure
> > there are no commands either running or waiting to be completed.
> > 
> > mwifiex_ret_802_11_associate() unconditionally sets
> > ps_state = PS_STATE_AWAKE when it processes the association command
> > response, outside of the normal powersave management flow. If
> > EVENT_SLEEP arrives while the association command is in flight,
> > ps_state is PRE_SLEEP when the association command response is parsed,
> > and the forced AWAKE overwrites it. The deferred sleep-confirm is
> > never sent.
> 
> Brian / Jeff: I am not that familiar with this part of the code, it
> sounds correct to me (and I discussed it with Rafael before he did send
> the patch), maybe you can also have a look.
> 
> Jeff: same issue in the nxpwifi driver.
> 
> Francesco
> 

Hi Francesco,

Thanks for the heads up.

I looked into this for nxpwifi. The nxpwifi driver currently only
supports IW61x. Based on our analysis of the IW61x firmware source code,
the firmware stops the auto deep sleep idle timer upon receiving any host
command and restarts it only after the command response is sent,
preventing EVENT_SLEEP from being issued while the association command is
in flight. This means the race condition described in the patch should
not be triggered with IW61x.

Jeff

Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations

[Francesco Dolcini]

On Mon, Jun 15, 2026 at 05:33:48PM +0800, Jeff Chen wrote:
> On Fri, Jun 12, 2026 at 03:06:28 PM +0200, Francesco Dolcini wrote:
> > On Fri, Jun 12, 2026 at 09:25:46AM -0300, Rafael Beims wrote:
> > > From: Rafael Beims <rafael.beims@toradex.com>
> > > 
> > > In order for the firmware to sleep, the driver has to confirm a
> > > previously received sleep request. The normal sequence of evets goes
> > > like this:
> > > EVENT_SLEEP -> adapter->ps_state = PS_STATE_PRE_SLEEP -> sleep-confirm
> > > -> SLEEP -> EVENT_AWAKE -> AWAKE.
> > > Before sending the sleep-confirm command, the driver must make sure
> > > there are no commands either running or waiting to be completed.
> > > 
> > > mwifiex_ret_802_11_associate() unconditionally sets
> > > ps_state = PS_STATE_AWAKE when it processes the association command
> > > response, outside of the normal powersave management flow. If
> > > EVENT_SLEEP arrives while the association command is in flight,
> > > ps_state is PRE_SLEEP when the association command response is parsed,
> > > and the forced AWAKE overwrites it. The deferred sleep-confirm is
> > > never sent.
...
> > 
> > Jeff: same issue in the nxpwifi driver.
> > 
> I looked into this for nxpwifi. The nxpwifi driver currently only
> supports IW61x.

Up to you, but maybe is worth applying the same change there. I assume
you are going to add support for more Wi-Fi chips over time, and you do
not want to have to debug this issue again.

Francesco