Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop

From: Marc Gonzalez <mgonzalez@freebox.fr>
To: Kalle Valo <kvalo@kernel.org>
Cc: Jeff Johnson <quic_jjohnson@quicinc.com>,
	ath10k <ath10k@lists.infradead.org>,
	wireless <linux-wireless@vger.kernel.org>,
	DT <devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Pierre-Hugues Husson <phhusson@freebox.fr>,
	Jami Kettunen <jamipkettunen@gmail.com>,
	Jeffrey Hugo <quic_jhugo@quicinc.com>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Wed, 28 Feb 2024 17:12:11 +0100	[thread overview]
Message-ID: <3392f356-7b19-483d-b9f8-3bd84068fa52@freebox.fr> (raw)
In-Reply-To: <871q8wk7o3.fsf@kernel.org>

On 28/02/2024 15:03, Kalle Valo wrote:

> Marc Gonzalez writes:
> 
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares apparently do not send it.
>> On those devices, it seems safe to ignore the indicator,
>> and continue loading the firmware.
>>
>> Signed-off-by: Pierre-Hugues Husson <phhusson@freebox.fr>
>> Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
>> ---
>>  Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> index 7758a55dd3286..145fa1a3c1c6a 100644
>> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
>> @@ -121,6 +121,14 @@ properties:
>>        Whether to skip executing an SCM call that reassigns the memory
>>        region ownership.
>>  
>> +  qcom,no-msa-ready-indicator:
>> +    type: boolean
>> +    description:
>> +      The driver waits for this indicator before proceeding,
>> +      yet some WCNSS firmwares apparently do not send it.
>> +      On those devices, it seems safe to ignore the indicator,
>> +      and continue loading the firmware.
> 
> This sounds more like a firmware feature, not a hardware feature. What
> about having a flag in enum ath10k_fw_features in firmware-2.bin?

Are you using the word "feature" as in "it was done purposefully" ?
This looks very much like a FW bug to my untrained eye.

Is enum ath10k_fw_features also supposed to include work-arounds?

Sorry, I've grepped over the entire Linux source code,
and I cannot find where ath10k_fw_features is used,
other than in ath10k_core_get_fw_feature_str().

As mentioned in my other reply, there are several msm8998-based
devices affected by this issue. Is it not appropriate to consider
a kernel-based work-around?

Regards