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

[Grumbach, Emmanuel]

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 ;-)
> 
> 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.