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
Date: Tue, 05 Mar 2024 16:45:53 +0200 [thread overview]
Message-ID: <87le6w7n4u.fsf@kernel.org> (raw)
In-Reply-To: <20240229-ageless-primal-7a0544420949@spud> (Conor Dooley's message of "Thu, 29 Feb 2024 18:40:57 +0000")
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
next prev parent reply other threads:[~2024-03-05 14:46 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 13:22 [PATCH 0/2] Work around missing MSA_READY indicator from ath10k FW Marc Gonzalez
2024-02-28 13:24 ` [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop Marc Gonzalez
2024-02-28 14:03 ` Kalle Valo
2024-02-28 16:12 ` Marc Gonzalez
2024-02-28 16:37 ` Kalle Valo
2024-02-28 17:19 ` Marc Gonzalez
2024-03-01 8:10 ` Kalle Valo
2024-03-04 15:51 ` Marc Gonzalez
2024-03-05 14:31 ` Kalle Valo
2024-03-05 17:32 ` Marc Gonzalez
2024-03-05 19:20 ` Kalle Valo
2024-03-13 15:09 ` Marc Gonzalez
2024-03-13 15:48 ` Konrad Dybcio
2024-03-13 15:53 ` Dmitry Baryshkov
2024-03-14 12:31 ` Marc Gonzalez
2024-03-14 12:52 ` Dmitry Baryshkov
2024-03-18 16:56 ` Marc Gonzalez
2024-03-19 13:47 ` Marc Gonzalez
2024-03-19 14:39 ` Marc Gonzalez
2024-03-19 17:05 ` Marc Gonzalez
2024-03-26 15:04 ` Marc Gonzalez
2024-03-26 17:45 ` Marc Gonzalez
2024-03-26 17:51 ` Dmitry Baryshkov
2024-03-26 20:21 ` Jeff Johnson
2024-03-28 17:09 ` Marc Gonzalez
2024-02-29 18:40 ` Conor Dooley
2024-02-29 19:46 ` Jeff Johnson
2024-03-07 15:29 ` Marc Gonzalez
2024-03-07 16:46 ` Jeff Johnson
2024-03-14 14:33 ` Jeff Johnson
2024-03-14 17:52 ` Marc Gonzalez
2024-03-14 19:28 ` Jeff Johnson
2024-03-04 16:21 ` Marc Gonzalez
2024-03-04 19:34 ` Conor Dooley
2024-03-04 19:37 ` Dmitry Baryshkov
2024-03-04 19:45 ` Conor Dooley
2024-03-04 19:59 ` Dmitry Baryshkov
2024-03-04 20:17 ` Conor Dooley
2024-03-04 20:21 ` Dmitry Baryshkov
2024-03-05 8:04 ` Krzysztof Kozlowski
2024-03-05 13:41 ` Marc Gonzalez
2024-03-05 15:02 ` Kalle Valo
2024-03-05 14:45 ` Kalle Valo [this message]
2024-02-28 14:59 ` Jeff Johnson
2024-02-28 16:00 ` Marc Gonzalez
2024-02-29 15:49 ` Marc Gonzalez
2024-02-28 13:25 ` [PATCH 2/2] wifi: ath10k: work around missing MSA_READY indicator Marc Gonzalez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87le6w7n4u.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=conor+dt@kernel.org \
--cc=conor@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jamipkettunen@gmail.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mgonzalez@freebox.fr \
--cc=phhusson@freebox.fr \
--cc=quic_jhugo@quicinc.com \
--cc=quic_jjohnson@quicinc.com \
--cc=robh+dt@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.