The ath10k driver waits for an "MSA_READY" indicator
to complete initialization. If the indicator is not
received, then the device remains unusable.
cf. ath10k_qmi_driver_event_work()
Several msm8998-based devices are affected by this issue.
Oddly, it seems safe to NOT wait for the indicator, and
proceed immediately when QMI_EVENT_SERVER_ARRIVE.
Jeff Johnson wrote:
The feedback I received was "it might be ok to change all ath10k qmi
to skip waiting for msa_ready", and it was pointed out that ath11k
(and ath12k) do not wait for it.
However with so many deployed devices, "might be ok" isn't a strong
argument for changing the default behavior.
Signed-off-by: Pierre-Hugues Husson <phhusson@xxxxxxxxxx>
Signed-off-by: Marc Gonzalez <mgonzalez@xxxxxxxxxx>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
index 9b3ef4bc37325..1680604cd1b7e 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
@@ -122,6 +122,13 @@ 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 an MSA_READY indicator to complete init.
+ If the indicator is not received, interface remains unusable.
+ Pretending we received the indicator works around the issue.
+
qcom,smem-states:
$ref: /schemas/types.yaml#/definitions/phandle-array
description: State bits used by the AP to signal the WLAN Q6.
--
2.34.1
