[PATCH v6 05/13] wifi: ath11k: update regulatory rules when connect to AP on 6 GHz band for station

[Wen Gong]

On 9/25/2023 6:52 PM, Aditya Kumar Singh wrote:
> On 9/25/23 16:13, Wen Gong wrote:
>> On 9/22/2023 9:18 PM, Aditya Kumar Singh wrote:
>>> On 9/22/23 15:32, Wen Gong wrote:
>>>> On 9/22/2023 5:39 PM, Aditya Kumar Singh wrote:
>>>>> On 9/20/23 13:53, Wen Gong wrote:
>>>>>
>>>>>> +    if (ath11k_mac_supports_6ghz_cc_ext(ar) &&
>>>>>> +        ctx->def.chan->band == NL80211_BAND_6GHZ &&
>>>>>> +        arvif->vdev_type == WMI_VDEV_TYPE_STA) {
>>>>>> +        reg_info = &ab->reg_info_store[ar->pdev_idx];
>>>>>> +        power_type = vif->bss_conf.power_type;
>>>>>> +        ath11k_dbg(ab, ATH11K_DBG_MAC, "mac chanctx power type 
>>>>>> %d\n",
>>>>>> +               power_type);
>>>>>> +        if (power_type == IEEE80211_REG_UNSET_AP)
>>>>>> +            power_type = IEEE80211_REG_LPI_AP;
>>>>> Why having _UNSET_ power type in vif->bss_conf.power_type is fine? 
>>>>> Typically, during association, we would be setting this from the 
>>>>> beacon/association response frame's HE 6 GHz Operation Info Field. 
>>>>> So is it fine if the field is carrying some info which we don't 
>>>>> know (or may be don't support it yet)? Why are we masking it with 
>>>>> _LPI_ mode?
>>>>>
>>>>> Also, I see that currently mac80211 only sets LPI or SP. So let's 
>>>>> say STA is trying to connect to VLP AP, mac80211 will set it as 
>>>>> _UNSET_. And then here, we will be treating it as LPI AP. Is that 
>>>>> fine?
>>>>
>>>> Currently only SP/LPI are defined in "Table E-12—Regulatory Info 
>>>> subfield encoding in the United States" of IEEE Std 802.11ax™‐2021.
>>>>
>>>> So maybe I need to set power_type to VLP when it is UNSET here.
>>> Yeah, or may be deny association if we don't support that mode? I 
>>> would let others comment on this.
>> Do you know how to check which mode support by ath11k?
> IMHO we should not maintain two different supported modes, one in 
> driver and another in mac80211. I mean w.r.t mac80211 we should try to 
> match it as far as possible. In this case, we can return error from 
> mac80211 itself when a non-supported mode (as in VLP) is trying to 
> associate? Since as you have quoted, VLP is not yet defined in spec 
> IEEE Std 802.11ax‐2021 so why to mask the mode and continue in 
> mac80211 itself?
>
> If we do like this, then mac80211 will not simply set _UNSET_ for 6 
> GHz client interface and in driver if we see its still _UNSET_ then we 
> can be sure that something has gone wrong and we can take steps 
> accordingly.
Yes, I will change to return fail for _UNSET_.