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