On Mon, 4 Mar 2024 at 21:46, Conor Dooley <conor@xxxxxxxxxx> wrote: > > 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. Yes, this is correct. MSM8996 uses PCI to access WiFi chip, MSM8998 uses MMIO. -- With best wishes Dmitry
