Marc Gonzalez <mgonzalez@xxxxxxxxxx> writes: > 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.) So the path for ath10k/ath11k/ath12k fixes to current -rc release is: ath-current -> wireless -> net -> linus For new features going to the next release: ath-next -> wireless-next -> net-next -> (in merge window) linus To reduce conflicts between trees most of the patches I apply go to -next, I usually take only important regression fixes to -current. In this case I didn't even consider taking the patches to -current as there were changes in DT and I just assumed this is for -next. If you considered otherwise I didn't realise it, sorry about that. In future, if you think a patch should go to -current please mention it somewhere, preferably something like tagging it with "[PATCH wireless]" or "[PATCH ath-current]" etc. to document which tree it is for. Or just as a simple reply. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
