Re: [PATCH 1/1] wifi: mac80211: ignore PM bit in non-bufferable MMPDUs for PS start

[Lee Jones]

On Tue, 20 Oct 2026, Grumbach, Emmanuel wrote:

> On Tue, 2026-10-20 at 09:42 +0200, Johannes Berg wrote:
> > On Tue, 2026-10-20 at 07:58 +0100, Lee Jones wrote:
> > > 
> > > You were also right to suspect the client-side TIM path in
> > > ieee80211_rx_mgmt_beacon(), when (dynamic_ps_timeout == 0) (for
> > > instance,
> > > when power-save is disabled on the client interface) and
> > > IEEE80211_CONF_PS
> > > is not set, mac80211 currently ignores its AID bit in the TIM and
> > > never
> > > sends a wake nullfunc frame to flush the AP's buffered frames.
> > > 
> > > If you're happy for me to do so, I'll send the following 2-patch v3
> > > series:
> > > 
> > >  1. Symmetric PM-bit handling in ieee80211_rx_h_sta_process() (only
> > >     consulting the PM bit on data and bufferable management frames,
> > > while
> > >     waking sleeping stations on Auth / (Re)AssocReq as-per
> > > 9fef65443388).
> > > 
> > >  2. Sending a wake nullfunc in ieee80211_rx_mgmt_beacon() when the
> > > TIM
> > >     indicates buffered unicast traffic while IEEE80211_CONF_PS is
> > > not set.
> > > 
> > > Does this help or hinder?  Your call.  If you decline, I'll go
> > > ahead and
> > > close out our internal (Android) report as `Won't Fix` and move on
> > > to
> > > something else.
> > 
> > I think what you do with your report is probably not my problem ;-)

Yeah, TMI, sorry! =:-)

> > IMHO adding the client side defence definitely makes sense, though in
> > many/most cases it'll be up to the firmware anyway.
> > 
> > I don't think I have a problem with the AP-side spec alignment, even
> > if
> > it's a touchy area, but depends how complex the code gets perhaps? I
> > don't think any client would rely on us not handling the PM bit in
> > those
> > frames, and they're supposed to set it to 0 (reserved) anyway, so I'm
> > not very worried about it. The patch was fine and I guess moving that
> > around to apply to both sides wouldn't really change it much? Want to
> > try?
> > 
> 
> FWIW: the firmware on Intel devices will send an NDP with PM=0 when we
> get a TIM bit set even if we are already awake. This is meant to re-
> sync the AP in case we are out of sync. So 2. makes sense to me.

Okay, let me follow-up.  Bear with.

-- 
Lee Jones