[PATCH v3 2/2] wifi: ath11k: reduce the timeout value back for hw scan from 10 seconds to 1 second

[Wen Gong]

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