Re: [RFC 1/4] wifi: nl80211: allow drivers to support subset of NL80211_CMD_SET_BSS

On June 4, 2025 4:06:51 PM Jeff Johnson <[email protected]> wrote:

> On 6/4/2025 1:55 AM, Arend van Spriel wrote:
>> @@ -2899,6 +2899,9 @@ enum nl80211_commands {
>> * APs Support". Drivers may set additional flags that they support
>> * in the kernel or device.
>> *
>> + * @NL80211_ATTR_BSS_PARAM: nested attribute used with %NL80211_CMD_GET_WIPHY
>> + * which indicates which BSS parameters can be modified.
>> + *
>
> Ideally this should describe what is contained in the nested attribute

Thanks, Jeff

Sure. Can add that info.

>
>
>> @@ -2996,6 +2996,40 @@ static int nl80211_send_wiphy(struct 
>> cfg80211_registered_device *rdev,
>> rdev->wiphy.ext_features))
>> goto nla_put_failure;
>>
>> + if (rdev->wiphy.bss_param_support) {
>> + struct nlattr *nested;
>> + u32 parsup = rdev->wiphy.bss_param_support;
>> +
>> + nested = nla_nest_start(msg, NL80211_ATTR_BSS_PARAM);
>> + if (!nested)
>> + goto nla_put_failure;
>> +
>> + if ((parsup & WIPHY_BSS_PARAM_CTS_PROT) &&
>> +    nla_put_flag(msg, NL80211_ATTR_BSS_CTS_PROT))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_SHORT_PREAMBLE) &&
>> +    nla_put_flag(msg, NL80211_ATTR_BSS_SHORT_PREAMBLE))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_SHORT_SLOT_TIME) &&
>> +    nla_put_flag(msg, NL80211_ATTR_BSS_SHORT_SLOT_TIME))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_BASIC_RATES) &&
>> +    nla_put_flag(msg, NL80211_ATTR_BSS_BASIC_RATES))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_AP_ISOLATE) &&
>> +    nla_put_flag(msg, NL80211_ATTR_AP_ISOLATE))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_HT_OPMODE) &&
>> +    nla_put_flag(msg, NL80211_ATTR_BSS_HT_OPMODE))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_P2P_CTWINDOW) &&
>> +    nla_put_flag(msg, NL80211_ATTR_P2P_CTWINDOW))
>> + goto nla_put_failure;
>> + if ((parsup & WIPHY_BSS_PARAM_P2P_OPPPS) &&
>> +    nla_put_flag(msg, NL80211_ATTR_P2P_OPPPS))
>> + goto nla_put_failure;
>> + nla_nest_end(msg, nested);
>
> I'm personally not a fan of (ab)using attribute ids in this manner. This means
> the receiver would need two different nla_parse policies, one that expects
> these to be NLA_FLAG when parsing the new attribute, along with the existing
> policy (such as the kernel's own nl80211_policy[NUM_NL80211_ATTR]) that is
> currently used when parsing the actual attributes.
>
> Does nl80211 have existing examples of using attribute ids like this?

Having two policies with the same attribute on receiving side would also 
rub my feathers. For the attributes used above we probably have other 
places where we use them from kernel to user-space. Clearly an oversight by 
me. Let me check.

Regards,
Arend
>