Marc Gonzalez <mgonzalez@xxxxxxxxxx> writes: > 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. The point with firmware-N.bin file is that NO tweaking or hunting down firmware files is necessary. All the files would be in linux-firmware.git and ath10k would automatically choose the correct firmware-N file. From ath10k side all is needed is Dmitry's patchset[1] and your (Marc) patch adding the feature bit check to ath10k. And if later the firmware is fixed, we will update the firmware-N.bin file at the same time in linux-firmware.git and the user doesn't notice anything. [1] https://patchwork.kernel.org/project/linux-wireless/cover/20240130-wcn3990-firmware-path-v1-0-826b93202964@xxxxxxxxxx/ -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
