Received-SPF: pass (google.com: domain of linux-wireless+bounces-4382-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
From: Kalle Valo <kvalo@kernel.org>
To: Conor Dooley <conor@kernel.org>
Cc: Marc Gonzalez <mgonzalez@freebox.fr>,  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>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add
 qcom,no-msa-ready-indicator prop
References: <14daa98e-7fd3-4ebb-87bb-5d2c1fba679f@freebox.fr>
	<b8de96c7-cbb6-4a09-a4d4-2c11b3ab3e01@freebox.fr>
	<871q8wk7o3.fsf@kernel.org>
	<3392f356-7b19-483d-b9f8-3bd84068fa52@freebox.fr>
	<87wmqoilzf.fsf@kernel.org>
	<20240229-ageless-primal-7a0544420949@spud>
Date: Tue, 05 Mar 2024 16:45:53 +0200
In-Reply-To: <20240229-ageless-primal-7a0544420949@spud> (Conor Dooley's
	message of "Thu, 29 Feb 2024 18:40:57 +0000")
Message-ID: <87le6w7n4u.fsf@kernel.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

Conor Dooley <conor@kernel.org> writes:

> 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?

This is why we implemented in ath10k firmware-N.bin with all sorts of
meta data about the firmware. There are a lots of different ath10k
firmware branches and they have differences which ath10k needs to take
into account. firmware-N.bin tells all that info to ath10k runtime, per
firmware release.

> 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.

For me it feels wrong to use DT for handling WLAN firmware differences.
For example, what if the ath10k firmware in linux-firmware is fixed? Are
we expecting that DT in existing boards is updated? But how is the DT
update going to be synced with linux-firmware releases? Sure, in this
case it most likely won't matter but as a generic solution this looks
very fragile to me.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches