Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop

From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Marc Gonzalez <mgonzalez@freebox.fr>
Cc: Kalle Valo <kvalo@kernel.org>,
	ath10k <ath10k@lists.infradead.org>,
	wireless <linux-wireless@vger.kernel.org>,
	DT <devicetree@vger.kernel.org>,
	Pierre-Hugues Husson <phhusson@freebox.fr>,
	Arnaud Vrac <avrac@freebox.fr>,
	Jami Kettunen <jamipkettunen@gmail.com>,
	Jeffrey Hugo <quic_jhugo@quicinc.com>,
	Bjorn Andersson <andersson@kernel.org>,
	"Konrad Dybcio" <konrad.dybcio@linaro.org>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Tue, 26 Mar 2024 13:21:20 -0700	[thread overview]
Message-ID: <4b7bf7cc-ede6-4c2a-983c-da4c8c09c5d1@quicinc.com> (raw)
In-Reply-To: <CAA8EJppn6M9dpzyu9d283AUtaeN-i-L=-aM5P9BEELXPLFS8YQ@mail.gmail.com>

On 3/26/2024 10:51 AM, Dmitry Baryshkov wrote:
> On Tue, 26 Mar 2024 at 19:45, Marc Gonzalez <mgonzalez@freebox.fr> wrote:
>>
>> [ It has been pointed out to me that the previous message was unclear. ]
>> [ Below is my 2nd attempt at a clearer message. ]
>>
>> Problem: firmware-5.bin has not been parsed yet when we have to handle
>> the ATH10K_QMI_EVENT_SERVER_ARRIVE case, so we can't rely on feature bits
>> to work around the lack of MSA_READY indicator.
> 
> Then, I'd say, we have to resort to the DT property, unless Kalle or
> Jeff have other proposals.

Another option is to follow the downstream driver model and only expect this
based upon static configuration within the driver.

Downstream driver has:
	if (priv->device_id == ADRASTEA_DEVICE_ID) {
		ret = wlfw_msa_mem_info_send_sync_msg(priv);
		ret = wlfw_msa_ready_send_sync_msg(priv);
	}

https://git.codelinaro.org/clo/la/platform/vendor/qcom-opensource/wlan/platform/-/blob/wlan-platform.lnx.1.0.r4-rel/icnss2/main.c?ref_type=heads#L968

The downstream MSA logic (including some other code that populates MSA-related
fields in the QMI messages) is only invoked for ADRASTEA_DEVICE_ID.

We could introduce a new hw_params parameter to have the same semantics.

But I'm OK with the DT option as well.

Kalle?

/jeff