Received-SPF: pass (google.com: domain of linux-wireless+bounces-5775-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <ad88712a-e4dd-4a2b-ba9d-a42ebb39ad4d@quicinc.com>
Date: Tue, 2 Apr 2024 16:32:41 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v2 3/3] arm64: dts: qcom: msm8998: set
 qcom,no-msa-ready-indicator for wifi
Content-Language: en-US
To: Alexey Minnekhanov <alexeymin@postmarketos.org>,
        Dmitry Baryshkov
	<dmitry.baryshkov@linaro.org>,
        Marc Gonzalez <mgonzalez@freebox.fr>, Kalle
 Valo <kvalo@kernel.org>
CC: Konrad Dybcio <konrad.dybcio@linaro.org>,
        Krzysztof Kozlowski
	<krzysztof.kozlowski@linaro.org>,
        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>,
        Bjorn Andersson <andersson@kernel.org>,
        Jami
 Kettunen <jamipkettunen@gmail.com>,
        Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
References: <fd26ce4a-a9f3-4ada-8d46-ed36fb2456ca@freebox.fr>
 <5cdad89c-282a-4df5-a286-b8404bc4dd81@freebox.fr>
 <252618e8-9e80-4774-a96c-caa7f838ef01@linaro.org>
 <502322f1-4f66-4922-bc4e-46bacac23410@linaro.org>
 <0ca1221b-b707-450f-877d-ca07a601624d@freebox.fr>
 <CAA8EJppeREj-0g9oGCzzKx5ywhg1mgmJR1q8yvXKN7N45do1Xg@mail.gmail.com>
 <8ef4f56c-83a3-4b26-877e-f1c7a0307e98@postmarketos.org>
From: Jeff Johnson <quic_jjohnson@quicinc.com>
In-Reply-To: <8ef4f56c-83a3-4b26-877e-f1c7a0307e98@postmarketos.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit

On 4/2/2024 11:25 AM, Alexey Minnekhanov wrote:
> 
> 
> On 02.04.2024 18:55, Dmitry Baryshkov wrote:
>> I'd say, we should take a step back and actually verify how this was
>> handled in the vendor kernel.
> 
> 
> AFAIK there is no such thing in vendor kernel driver for this, as
> this startup procedure is likely handled entirely in userspace in
> cnss_daemon.
> 

So now I'm looking at the cnss-daemon, and there it appears that MSA READY is
always expected to be received.

There is target-specific logic to set the flags sent to firmware:
	if (gdata->instance_id == ADRASTEA_ID) {
		req.msa_ready_enable_valid = 1;
		req.msa_ready_enable = 1;
	} else { /* All targets other than Adrastea */
		req.fw_mem_ready_enable_valid = 1;
		req.fw_mem_ready_enable = 1;
	}

Logic to set an internal flag if the message is received:
	case QMI_WLFW_MSA_READY_IND_V01:
		gdata->state |= CNSS_MSA_READY;

And Adrastea-specific logic to set that flag if it is set in a separate status
indicator:
static int wlfw_adrastea_init(struct wlfw_client_data *gdata)
[...]
	if (fw_status & QMI_WLFW_MSA_READY_V01) {
		wsvc_printf_dbg("MSA is ready");
		gdata->state |= CNSS_MSA_READY;
	}

So that flag is only set by receiving the QMI_WLFW_MSA_READY_IND_V01 message
or, only for Adrastea, if the response to wlfw_send_ind_register_req()
indicates MSA_READY

Later there is a wait for MSA_READY that has no conditions:
	while (!CNSS_IS_MSA_READY(gdata->state))

Truthfully this is code I've never had to deal with before, and I've struggled
to find developers who have the necessary background. The least disruptive
paths seem to either be the DT item or adding a new item for this in struct
ath10k_hw_params.

Kalle, do you have any different guidance?