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

From: Conor Dooley <conor@kernel.org>
To: Marc Gonzalez <mgonzalez@freebox.fr>
Cc: Kalle Valo <kvalo@kernel.org>,
	Jeff Johnson <quic_jjohnson@quicinc.com>,
	ath10k <ath10k@lists.infradead.org>,
	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>,
	Jami Kettunen <jamipkettunen@gmail.com>,
	Jeffrey Hugo <quic_jhugo@quicinc.com>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Mon, 4 Mar 2024 19:34:24 +0000	[thread overview]
Message-ID: <20240304-component-animator-e2ee0ab7574a@spud> (raw)
In-Reply-To: <68a49964-7c05-4575-a4f3-35848c08fefc@freebox.fr>

[-- Attachment #1: Type: text/plain, Size: 2482 bytes --]

On Mon, Mar 04, 2024 at 05:21:37PM +0100, Marc Gonzalez wrote:
> On 29/02/2024 19:40, Conor Dooley wrote:
> 
> > On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
> >
> >> Marc Gonzalez wrote:
> >> 
> >>> As mentioned in my other reply, there are several msm8998-based
> >>> devices affected by this issue. Is it not appropriate to consider
> >>> a kernel-based work-around?
> >>
> >> Sorry, not following you here. But I'll try to answer anyway:
> >>
> >> I have understood that Device Tree is supposed to describe hardware, not
> >> software. This is why having this property in DT does not look right
> >> place for this. For example, if the ath10k firmware is fixed then DT
> >> would have to be changed even though nothing changed in hardware. But of
> >> course DT maintainers have the final say.
> > 
> > I dunno, if the firmware affects the functionality of the hardware in a
> > way that cannot be detected from the operating system at runtime how
> > else is it supposed to deal with that?
> > The devicetree is supposed to describe hardware, yes, but at a certain
> > point the line between firmware and hardware is invisible :)
> > Not describing software is mostly about not using it to determine
> > software policy in the operating system.
> 
> Recording here what was discussed a few days ago on IRC:
> 
> If all msm8998 boards are affected, then it /might/ make sense
> to work around the issue for ALL msm8998 boards:
> 
> diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
> index 0776e79b25f3a..9da06da518fb6 100644
> --- a/drivers/net/wireless/ath/ath10k/qmi.c
> +++ b/drivers/net/wireless/ath/ath10k/qmi.c
> @@ -1076,6 +1076,9 @@ int ath10k_qmi_init(struct ath10k *ar, u32 msa_size)
>  	qmi->ar = ar;
>  	ar_snoc->qmi = qmi;
>  
> +	if (of_device_is_compatible(of_root, "qcom,msm8998")
> +		qmi->no_point_in_waiting_for_msa_ready_indicator = true;
> +
>  	if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
>  		qmi->msa_fixed_perm = true;
>  
> 
> Thus, anyone porting an msm8998 board to mainline would automatically
> get the work-around, without having to hunt down the feature bit,
> and tweak the FW files.

How come the root node comes into this, don't you have a soc-specific
compatible for the integration on this SoC?
(I am assuming that this is not the SDIO variant, given then it'd not be
fixed to this particular implementation)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]