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.
--
Regards
