On 13/05/2024 16:16, Kalle Valo wrote: > 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: Marc Gonzalez <mgonzalez@xxxxxxxxxx> >> Reviewed-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx> >> Acked-by: Jeff Johnson <quic_jjohnson@xxxxxxxxxxx> >> Acked-by: Rob Herring (Arm) <robh@xxxxxxxxxx> >> Signed-off-by: Kalle Valo <quic_kvalo@xxxxxxxxxxx> > > 2 patches applied to ath-next branch of ath.git, thanks. > > 71b6e321e302 dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop > 6d67d18014a8 wifi: ath10k: do not always wait for MSA_READY indicator Hello Kalle, What version of Linux will these be included in? (I don't see them in v6.10-rc1. Are they considered a new feature, rather than a fix, and thus 6.11?) Hello Bjorn, Will you pick up patch 3 ? Regards
