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

[Marc Gonzalez]

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 at freebox.fr>
>> Signed-off-by: Marc Gonzalez <mgonzalez at 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