Re: [PATCH wireless-next] wifi: mac80211: Fix ADDBA request rejection after MLD link removal

[Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>]

On 5/11/2026 2:16 PM, Johannes Berg wrote:
> On Mon, 2026-05-11 at 11:56 +0530, Manish Dharanenthiran wrote:
>> No, there is no implementations that combine these two, but there are
>> cases where the update AddBA request can be received from the station
>> with link reconfiguration.
>>
>> For instance, if a station associated in 2 GHz, later with link
>> reconfiguration station can either move to 5 GHz or it can add 5 GHz (as
>> MLD). Station then can send a AddBA request to update the window size or
>> other related parameters.
> 
> Ah, well, OK - technically an implementation can do that all the time
> (and technically we can refuse it all the time), but I guess then that
> some implementations do it with link reconfiguration, and also don't
> like the refusal :)
> 
Yes :)

>>
>> We believe that a no-op update is not required (or at-least we couldn't
>> think of a case in which that is actually needed) as there can might be
>> an actual change in the subsequent AddBA request.
> 
> I just think that once we require an UPDATE call from the driver, that
> raises the question of whether we should even call it for a no-op. This
> seems a bit strange? And if we don't then we wouldn't require it for no-
> ops either, which is probably generally good for drivers that don't
> (immediately) implement the UPDATE.
> 
> johannes

Got it! Then, we should store the parameters differently as you 
mentioned in [1], which can be used to identify the no-op.

[1] 
https://lore.kernel.org/all/ab5b9eb76e4a94745c7cf1bfa886f067618a54b6.camel@sipsolutions.net/#t

Even-then, if there is a actual change, it goes to invoke the UPDATE. 
For the driver(s) which didn't implement the UPDATE yet, should we use 
additional flags to notify the UPDATE support or returning a failure 
from driver should be suffice?