Received-SPF: pass (google.com: domain of linux-wireless+bounces-8201-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
From: Kalle Valo <kvalo@kernel.org>
To: Marc Gonzalez <mgonzalez@freebox.fr>
Cc: Bjorn Andersson <andersson@kernel.org>,  Jeff Johnson
 <quic_jjohnson@quicinc.com>,  ath10k <ath10k@lists.infradead.org>,
  wireless <linux-wireless@vger.kernel.org>,  DT
 <devicetree@vger.kernel.org>,  MSM <linux-arm-msm@vger.kernel.org>,  Rob
 Herring <robh+dt@kernel.org>,  Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@linaro.org>,  Conor Dooley <conor+dt@kernel.org>,
  Pierre-Hugues Husson <phhusson@freebox.fr>,  Arnaud Vrac
 <avrac@freebox.fr>,  Konrad Dybcio <konrad.dybcio@linaro.org>,  Jami
 Kettunen <jamipkettunen@gmail.com>,  Jeffrey Hugo
 <quic_jhugo@quicinc.com>,  Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
  Alexey Minnekhanov <alexeymin@postmarketos.org>
Subject: Re: [PATCH v3 1/3] dt-bindings: net: wireless: ath10k: add
 qcom,no-msa-ready-indicator prop
References: <54ac2295-36b4-49fc-9583-a10db8d9d5d6@freebox.fr>
	<171560975908.1690511.498631481702370762.kvalo@kernel.org>
	<3464a980-36a7-4ed2-b2dc-be8fd9091b06@freebox.fr>
	<87zfsa6ybl.fsf@kernel.org>
	<74ab64e2-9bb4-4e98-9f2f-f6402ba42c08@freebox.fr>
Date: Tue, 28 May 2024 16:34:46 +0300
In-Reply-To: <74ab64e2-9bb4-4e98-9f2f-f6402ba42c08@freebox.fr> (Marc
	Gonzalez's message of "Tue, 28 May 2024 14:36:02 +0200")
Message-ID: <87msoa6ow9.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Marc Gonzalez <mgonzalez@freebox.fr> 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@freebox.fr>
>>>>> Reviewed-by: Bjorn Andersson <quic_bjorande@quicinc.com>
>>>>> Acked-by: Jeff Johnson <quic_jjohnson@quicinc.com>
>>>>> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>>>>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
>>>>
>>>> 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