On Mon, Mar 04, 2024 at 09:37:00PM +0200, Dmitry Baryshkov wrote: > On Mon, 4 Mar 2024 at 21:34, Conor Dooley <conor@xxxxxxxxxx> 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. 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.
Attachment:
signature.asc
Description: PGP signature
