On 28/02/2024 17:37, Kalle Valo wrote: > Marc Gonzalez writes: > >> On 28/02/2024 15:03, Kalle Valo wrote: >> >>> Marc Gonzalez writes: >>> >>>> + qcom,no-msa-ready-indicator: >>>> + type: boolean >>>> + description: >>>> + The driver waits for this indicator before proceeding, >>>> + yet some WCNSS firmwares apparently do not send it. >>>> + On those devices, it seems safe to ignore the indicator, >>>> + and continue loading the firmware. >>> >>> This sounds more like a firmware feature, not a hardware feature. What >>> about having a flag in enum ath10k_fw_features in firmware-2.bin? >> >> Are you using the word "feature" as in "it was done purposefully" ? > > No, there's no bigger meaning like that. It's more like ath10k has to do > something differently when a certain bit is enabled in the firmware. I > just had to pick a word for the enum and from my limited vocabulary I > chose "feature" :) Understood! >> Is enum ath10k_fw_features also supposed to include work-arounds? > > Yes, and we already use. > >> Sorry, I've grepped over the entire Linux source code, >> and I cannot find where ath10k_fw_features is used, >> other than in ath10k_core_get_fw_feature_str(). > > Here's one example where in ath10k we use a feature bit as a workaround: > > /* Don't trust error code from otp.bin */ > ATH10K_FW_FEATURE_IGNORE_OTP_RESULT = 7, > > .... > > if (!(skip_otp || test_bit(ATH10K_FW_FEATURE_IGNORE_OTP_RESULT, > ar->running_fw->fw_file.fw_features)) && > result != 0) { > ath10k_err(ar, "otp calibration failed: %d", result); > return -EINVAL; > } > > BTW for modifying firmware-N.bin files we have a script here: > > https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder If I understand correctly, you are saying that there is (maybe... probably) a bug in the FW, so it makes sense to tag that specific FW file with a special bit which the kernel will interpret as "this FW is broken in a specific way; and here's how to work around the issue." So this bit would serve the same purpose as my proposed "qcom,no-msa-ready-indicator" bit (that bit existed instead in my board's device tree). The problem I see is that the firmware files are signed. Thus, changing a single bit breaks the verification... UNLESS the FW format allows for a signed section ALONG-SIDE an unsigned section? >> 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. At some point, we start wandering into meta-physical considerations such as "if FW cannot ever be changed, when does FIRM become HARD?" (and other GPLv3 niceties). But this is a discussion for another list. Regards