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@xxxxxxxxxx> >> Signed-off-by: Marc Gonzalez <mgonzalez@xxxxxxxxxx> >> --- >> 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
