Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <73908049-4a69-e65c-665b-97d068f1fef7@quicinc.com>
Date:   Fri, 13 Jan 2023 14:54:50 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.1
Subject: Re: [PATCH v3 2/2] wifi: ath11k: reduce the timeout value back for hw
 scan from 10 seconds to 1 second
Content-Language: en-US
From:   Wen Gong <quic_wgong@quicinc.com>
To:     Kalle Valo <kvalo@kernel.org>
CC:     <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
References: <20221011072408.23731-1-quic_wgong@quicinc.com>
 <20221011072408.23731-3-quic_wgong@quicinc.com> <8735atg335.fsf@kernel.org>
 <cd96eea8-dce0-bcb9-e8ce-05fa0e0f22fb@quicinc.com>
 <e7e34c3d-8b73-f7d5-9ce8-5ed346ca9d28@quicinc.com>
 <7bcd1a12-fb60-98cd-1a29-f55efa8d1499@quicinc.com>
In-Reply-To: <7bcd1a12-fb60-98cd-1a29-f55efa8d1499@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi Kalle,

Should I change commit log with below explanation and send v4?

On 12/16/2022 11:08 AM, Wen Gong wrote:
> Hi Kalle,
>
> Should I change commit log with below explanation and send v4?
>
> On 11/23/2022 11:41 AM, Wen Gong wrote:
>> On 11/18/2022 6:29 PM, Wen Gong wrote:
>>> On 11/8/2022 6:20 PM, Kalle Valo wrote:
>>>> Wen Gong <quic_wgong@quicinc.com> writes:
>>>>
>>> ...
>>>> [...]
>>>>
>>>>> @@ -3682,7 +3677,12 @@ static int ath11k_mac_op_hw_scan(struct 
>>>>> ieee80211_hw *hw,
>>>>>         ret = ath11k_start_scan(ar, &arg);
>>>>>       if (ret) {
>>>>> -        ath11k_warn(ar->ab, "failed to start hw scan: %d\n", ret);
>>>>> +        if (ret == -EBUSY)
>>>>> +            ath11k_dbg(ar->ab, ATH11K_DBG_MAC,
>>>>> +                   "scan engine is busy 11d state %d\n", 
>>>>> ar->state_11d);
>>>>> +        else
>>>>> +            ath11k_warn(ar->ab, "failed to start hw scan: %d\n", 
>>>>> ret);
>>>>> +
>>>>>           spin_lock_bh(&ar->data_lock);
>>>>>           ar->scan.state = ATH11K_SCAN_IDLE;
>>>>>           spin_unlock_bh(&ar->data_lock);
>>>> This feels like a hack to me, for example will these failed scans now
>>>> cause delays is connection establishment? IMHO it's crucial from 
>>>> user's
>>>> point of view that we don't delay that in any way.
>>> It will not delay connection.
>>> After wlan load, the 1st hw scan will arrived to ath11k, and then 11d
>>> scan will be sent to firmware after the 1st hw scan. It means the hw
>>> scan for connection is run before 11d scan, and then connection could
>>> be started immediately after the 1st hw scan finished. It means no
>>> delay for connection.
>>>> I would rather fix the root cause, do we know what's causing this?
>>> In firmware, hw scan and 11d scan are all running in the same queue,
>>> they can not be run parallel.
>>>
>>> When 6 GHz enabled, the 1st hw scan cost about 7s and finished, and
>>> then 11d scan cost the next 7s. After the 14s, the each hw scan arrived
>>> to ath11k will be run immediately. If the 2nd hw scan arrived before
>>> the 11d scan finished, for example, it arrived 7.1 seconds after the
>>> 1st hw scan, at this moment, the 11d scan is still running in firmware,
>>> then the 2nd hw scan will not receive scan started event untill the 11d
>>> scan finished, and meanwhile, the 2nd hw scan is holding the 
>>> ar->conf_mutex
>>> in ath11k_mac_op_hw_scan(), it is not good to hold a lock for some
>>> seconds because ar->conf_mutex is widely used. So reduce the 10s to 1s
>>> to avoid holding ar->conf_mutex for long time.
>>
>> Hi Kalle,
>>
>> Should I change commit log with above explanation and send v4?
>>