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

From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Conor Dooley <conor@kernel.org>, Kalle Valo <kvalo@kernel.org>
Cc: Marc Gonzalez <mgonzalez@freebox.fr>,
	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>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Thu, 29 Feb 2024 11:46:16 -0800	[thread overview]
Message-ID: <c48ead11-0e2a-4066-b324-84f802215c9a@quicinc.com> (raw)
In-Reply-To: <20240229-ageless-primal-7a0544420949@spud>

On 2/29/2024 10:40 AM, Conor Dooley wrote:
> On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:
>> Marc Gonzalez <mgonzalez@freebox.fr> writes:
> 
>>> 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.

FWIW I've compared ath10k to the out-of-tree Android driver and there
are discrepancies in this area. I've asked the development team that
supports ath10k to provide a recommendation.

/jeff