Re: athk10: Poll service ready completion by default to avoid warning `failed to receive service ready completion, polling..`?

[Baochen Qiang <baochen.qiang@oss.qualcomm.com>]

On 7/28/2025 3:39 PM, Paul Menzel wrote:
>>>>> Additionally I have two questions regarding the code:
>>>>>
>>>>> 1.  Is `WMI_SERVICE_READY_TIMEOUT_HZ` the right value to pass to
>>>>> `wait_for_completion_timeout(struct completion *done, unsigned long timeout)`?
>>>>>
>>>>> The macro is defined as:
>>>>>
>>>>>       drivers/net/wireless/ath/ath10k/wmi.h:#define WMI_SERVICE_READY_TIMEOUT_HZ (5 *
>>>>> HZ)
>>>>>
>>>>> `timeout` is supposed to be in jiffies, and `CONFIG_HZ_250=y` on my system. I wonder how
>>>>> that amounts to five seconds on my system.
>>>>
>>>> HZ is defined as jiffies per second, so 5 * HZ equals 5 seconds.
> 
> Sorry, I missed to comment here in my previous reply. HZ can be defined differently – like

Sorry for misleading - I was trying to say the HZ has a direct relationship with jiffies,
it equals jiffies-per-second in its value.

> 1000 HZ –, so the timeout would very, and then not match the actual timeout required by
> the hardware? `Documentation/scheduler/completion.rst` contains:

Not quite sure about what the 'timeout' actually mean here
- If you are referring it as the argument passed to wait_for_completion_timeout(): yes, of
course if could vary based on HZ value.
- But if you are talking about the actual max time wait_for_completion_timeout() will
block: the answer is NO.

> 
>> Timeouts are preferably calculated with msecs_to_jiffies() or usecs_to_jiffies(),
>> to make the code largely HZ-invariant. 

I am not quite understanding the 'HZ-invariant' here:
- Does it mean the actual max time blocked will vary if timeout argument is defined based
on HZ?
- Or it is saying the value of timeout argument itself could vary? But note the result of
msecs_to_jiffies() even varies on HZ as well.