Received-SPF: pass (google.com: domain of linux-wireless+bounces-4350-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Mon, 4 Mar 2024 19:45:57 +0000
From: Conor Dooley <conor@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.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
Message-ID: <20240304-superior-vicinity-3dc6ca88141a@spud>
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>
 <68a49964-7c05-4575-a4f3-35848c08fefc@freebox.fr>
 <20240304-component-animator-e2ee0ab7574a@spud>
 <CAA8EJpq5HQaO2E2Pd7yqUTsWyQ_pLDdyoWng8QmWTzYn5fv3PQ@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wojNABL86L/ImB3a"
Content-Disposition: inline
In-Reply-To: <CAA8EJpq5HQaO2E2Pd7yqUTsWyQ_pLDdyoWng8QmWTzYn5fv3PQ@mail.gmail.com>


--wojNABL86L/ImB3a
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote:
> 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 hardwar=
e, not
> > > >> software. This is why having this property in DT does not look rig=
ht
> > > >> 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 cert=
ain
> > > > 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/wire=
less/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 =3D ar;
> > >       ar_snoc->qmi =3D qmi;
> > >
> > > +     if (of_device_is_compatible(of_root, "qcom,msm8998")
> > > +             qmi->no_point_in_waiting_for_msa_ready_indicator =3D tr=
ue;
> > > +
> > >       if (of_property_read_bool(dev->of_node, "qcom,msa-fixed-perm"))
> > >               qmi->msa_fixed_perm =3D 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?
>=20
> No. Ath10k uses WiFi SoC as an SoC designator rather than the main SoC.

Suitability of either fix aside, can you explain this to me? Is the "WiFi
SoC" accessible from the "main SoC" at a regular MMIO address? The
"ath10k" compatible says it is SDIO-based & the other two compatibles
seem to be MMIO.

--wojNABL86L/ImB3a
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZeYk9QAKCRB4tDGHoIJi
0kaaAQDnE4MEozONllZ+Q/SJg4H13bE1VgsWK3RoMjw0F+WHYQEAvEapGyAe9GIz
HA9NkpMj89CoBgLGj94SaMDYp4oFfgo=
=fxeV
-----END PGP SIGNATURE-----

--wojNABL86L/ImB3a--