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

[Gokul Sivakumar <gokulkumar.sivakumar@infineon.com>]

On 06/03, Arend Van Spriel wrote:
> On June 3, 2025 2:29:54 PM Johannes Berg <johannes@sipsolutions.net> 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?

yes, if the driver individually checks for the CFG80211_BSS_PARAM_CHANGED_*
flag before handling the corresponding AP BSS param, then the check for the
param value as -1 is not necessary.

> > 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?

your suggested approach is fine, will update this and submit a v3 patchset.

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

Ok. I have submitted this patchset based on the suggestions in our v1 patch
review discussion, to address johannes's comment using the newly introduced
CHANGED_* flags which are helpful to the drivers.

Gokul