On 29/02/2024 19:40, Conor Dooley wrote:

quoted

On Wed, Feb 28, 2024 at 06:37:08PM +0200, Kalle Valo wrote:

quoted

Marc Gonzalez wrote:

quoted

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.