From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Conor Dooley <conor@kernel.org>
Cc: Marc Gonzalez <mgonzalez@freebox.fr>,
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>
Subject: Re: [PATCH 1/2] dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
Date: Mon, 4 Mar 2024 21:37:00 +0200 [thread overview]
Message-ID: <CAA8EJpq5HQaO2E2Pd7yqUTsWyQ_pLDdyoWng8QmWTzYn5fv3PQ@mail.gmail.com> (raw)
In-Reply-To: <20240304-component-animator-e2ee0ab7574a@spud>
On Mon, 4 Mar 2024 at 21:34, Conor Dooley <conor@kernel.org> wrote:
>
> 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?
No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.
My 2c: I think it's easier to fix the firmware features bits, it's
more future proof (and error proof).
> (I am assuming that this is not the SDIO variant, given then it'd not be
> fixed to this particular implementation)
--
With best wishes
Dmitry
next prev parent reply other threads:[~2024-03-04 19:37 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 [this message]
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
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=CAA8EJpq5HQaO2E2Pd7yqUTsWyQ_pLDdyoWng8QmWTzYn5fv3PQ@mail.gmail.com \
--to=dmitry.baryshkov@linaro.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=kvalo@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).