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

From: Marc Gonzalez <mgonzalez@freebox.fr>
To: Jeff Johnson <quic_jjohnson@quicinc.com>,
	Kalle Valo <kvalo@kernel.org>,
	ath10k <ath10k@lists.infradead.org>,
	Jami Kettunen <jamipkettunen@gmail.com>,
	Jeffrey Hugo <quic_jhugo@quicinc.com>
Cc: wireless <linux-wireless@vger.kernel.org>,
	DT <devicetree@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>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Wed, 28 Feb 2024 17:00:56 +0100	[thread overview]
Message-ID: <73d85158-6286-45c3-986e-22850fa20c38@freebox.fr> (raw)
In-Reply-To: <d8c90f33-d0ab-4d73-9580-2547446671a0@quicinc.com>

[ Adding Jami Kettunen who documented the same issue 3 years ago ]
[ Adding Jeffrey Hugo for his past work on msm8998 ]

On 28/02/2024 15:59, Jeff Johnson wrote:

> On 2/28/2024 5:24 AM, Marc Gonzalez wrote:
> 
>> The driver waits for this indicator before proceeding,
>> yet some WCNSS firmwares apparently do not send it.
>> On those devices, it seems safe to ignore the indicator,
>> and continue loading the firmware.
> 
> Can you list the product/hardware/firmware where this is observed?
> Would prefer to fix the firmware if the issue is there

This issue is observed on an apq8098 (msm8998) SoC using
QC_IMAGE_VERSION_STRING = WLAN.HL.1.0-01202-QCAHLSWMTPLZ-1.221523.2
according to /sys/kernel/debug/qcom_soc_info/cnss/name

We are not the first to run into the issue:

https://wiki.postmarketos.org/wiki/Qualcomm_Snapdragon_835_(MSM8998)#WLAN

"Currently if you get FW details printed in dmesg from ath10k
with nothing else seemingly happening, you'll most likely have
to fake an MSA ready indication"

https://github.com/JamiKettunen/linux-mainline-oneplus5/commit/088eaa9153803e2b028e092f88539036442da4a3

The issue is also observed on an F(x)tec Pro1 phone (msm8998-based)
with unknown firmware.

The issue was apparently also observed on the OnePlus 5,
also msm8998/sdm835-based, also unknown firmware.

If the firmwares are signed, and the signature is verified by some remote proc,
then working around the issue in the kernel seems a more pragmatic solution?

Regards