Re: [PATCH wireless-next v1] wifi: mwifiex: fix permanently busy scans after multiple roam iterations
From: Jeff Chen
Date: Mon Jun 15 2026 - 05:33:48 EST
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@xxxxxxxxxxx>
> >
> > 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