On 4/29/2024 7:04 AM, Marc Gonzalez wrote: > 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. > > Kalle Valo first suggested setting a bit in firmware-5.bin to trigger > work-around in the driver. However, firmware-5.bin is parsed too late. > So we are stuck with a DT property. > > Signed-off-by: Pierre-Hugues Husson <phhusson@xxxxxxxxxx> > Signed-off-by: Marc Gonzalez <mgonzalez@xxxxxxxxxx> > --- > Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > index 9b3ef4bc37325..9070a41f7fc07 100644 > --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml > @@ -122,6 +122,11 @@ properties: > Whether to skip executing an SCM call that reassigns the memory > region ownership. > > + qcom,no-msa-ready-indicator: > + type: boolean > + description: > + Don't wait for MSA_READY indicator to complete init. > + > qcom,smem-states: > $ref: /schemas/types.yaml#/definitions/phandle-array > description: State bits used by the AP to signal the WLAN Q6. with SOB cleaned up: Acked-by: Jeff Johnson <quic_jjohnson@xxxxxxxxxxx>
