On 28/05/2024 12:11, Kalle Valo wrote: > Marc Gonzalez writes: > >> 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?) > > Yeah, these commits will go to v6.11. Because of the multiple trees > involved (ath-next -> wireless-next -> net-next -> linus) we need to > have ath.git pull request ready well before the merge window opens and > these commits missed the last pull request. > > Yes, we are slow :) My understanding of the merging process was that - new features are queued for the next cycle, so vN+1-rc1, or vN+2-rc1 if the submission came too late (after ~rc6) in cycle N - fixes are queued for the fixes batch in the same cycle This patch series is handled like a feature rather than a fix? (To me, it fixed broken behavior in the FW, but I understand if the nature of the changes require a more prudent approach. Though they are disabled for everyone by default.) Regards
