Re: [PATCH wireless-next v2 0/5] wifi: cfg80211: Add support to indicate changed AP BSS parameters to drivers

On June 3, 2025 2:29:54 PM Johannes Berg <[email protected]> wrote:

> On Tue, 2025-06-03 at 17:42 +0530, Gokul Sivakumar wrote:
>>>
>>>> In AP mode, the "ap_isolate" value from the cfg80211 layer represents,
>>>> 0 = allow low-level bridging of frames between associated stations
>>>> 1 = restrict low-level bridging of frames to isolate associated stations
>>>> -1 = do not change existing setting
>>>
>>> Is that -1 still true? Seems like now it should just be that
>>> CFG80211_BSS_PARAM_CHANGED_AP_ISOLATE isn't set and then you don't touch
>>> it?
>
>> Kindly note that the driver is rejecting the SET_BSS operation if an
>> unsupported AP BSS param is passed by userspace, while the opposite is not
>> true. ie. the operation would not be rejected by the driver, when a
>> supported AP BSS param is not passed by the userspace.
>
> Sure. That's a different question though.
>
>> So yes, the significance of "-1" still holds true, because if suppose the
>> userspace skipped this param in the SET_BSS request, the driver when
>> receiving the request will have the ap_isolate param with the default
>> value "-1". The driver is checking if the param value is >=0 before
>> proceeding with handling it. And will ignore the param, only if it is -1.
>
> Why though? It seems odd. Basically in this case cfg80211 is saying "I'm
> not changing this parameter" but then anyway you check it's value, why?
>
> While we're changing all the drivers, it would seem better to me to just
> change them in a way that they don't look at the value if the
> corresponding change flag isn't set?

I do have a couple of patches prepped for this, but did want to run few 
tests before sending it out. Now that this is submitted I am not sure what 
to do with that. I can send it as RFC so the idea is clear.

Regards,
Arend