Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4;
Message-ID: <fc02a441-bad9-6fba-bde8-dabd01d5ee18@quicinc.com>
Date:   Mon, 25 Sep 2023 18:57:54 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.15.1
Subject: Re: [PATCH v6 05/13] wifi: ath11k: update regulatory rules when
 connect to AP on 6 GHz band for station
Content-Language: en-US
To:     Aditya Kumar Singh <quic_adisi@quicinc.com>,
        <ath11k@lists.infradead.org>
CC:     <linux-wireless@vger.kernel.org>, <kvalo@kernel.org>,
        <quic_jjohnson@quicinc.com>
References: <20230920082349.29111-1-quic_wgong@quicinc.com>
 <20230920082349.29111-6-quic_wgong@quicinc.com>
 <5e9439c5-fc02-4a18-8cc8-c76998bfcbc6@quicinc.com>
 <1f739d62-d5c0-a64b-ef9b-d5fd7b79755e@quicinc.com>
 <47e2ce79-2885-489c-b567-fdbcb120d056@quicinc.com>
 <2aae986b-1d16-3b75-d2c9-a740f6817650@quicinc.com>
 <5f95f931-e75f-459b-a7c7-b175ba12f981@quicinc.com>
From:   Wen Gong <quic_wgong@quicinc.com>
In-Reply-To: <5f95f931-e75f-459b-a7c7-b175ba12f981@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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