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

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

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

/jeff