We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
I've found interesting thing
$ ath10k-fwencoder --dump-cmdline firmware-5.bin ath10k-fwencoder --create \ --features=wowlan,no-nwifi-decap-4addr-padding,allows-mesh-bcast,mgmt-tx-by-ref,non-bmi,single-chan-info-per-channel \ --set-wmi-op-version=tlv \ --set-htt-op-version=tlv \
Seems like we don't have to even package firmware-5.bin, it's not a real firmware, but more like "firmware flags" file which can encode some board-specific fw features or quirks (see https://groups.google.com/a/chromium.org/g/chromium-os-reviews/c/7YVeGZrVhtY ). And we can just run ath10k-fwencoder --create ... with those set of flags to get the file. I've been looking how to upstream our msm8998/660 hack 3d1b275 and I think this should be encoded in firmware-5.bin as firmware quirk. It needs enum value added to struct ath10k_fw_features and also to array ath10k_core_fw_feature_str and same value in ath10k-fwencoder https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder#L45 and new firmware-5.bin generated with this quirk.
firmware-5.bin
ath10k-fwencoder --create ...
ath10k-fwencoder
call flag like ATH10K_FW_FEATURE_NO_MSA_READY_IND and do smth like
ATH10K_FW_FEATURE_NO_MSA_READY_IND
$ ath10k-fwencoder --create --features=wowlan,no-nwifi-decap-4addr-padding,allows-mesh-bcast,mgmt-tx-by-ref,non-bmi,single-chan-info-per-channel,no-msa-ready-ind \ --set-wmi-op-version=tlv --set-htt-op-version=tlv --set-fw-api=5
test for pesence of this flag in the ath10k_qmi_driver_event_work() func like
ath10k_qmi_driver_event_work()
struct ath10k *ar = qmi->ar; if (test_bit(ATH10K_FW_FEATURE_NO_MSA_READY_IND, ar->running_fw->fw_file.fw_features)) ...
The text was updated successfully, but these errors were encountered:
Ah, someone is already doing that http://lists.infradead.org/pipermail/ath10k/2024-March/015316.html
Sorry, something went wrong.
Looks like this was already tried and it didn't work => https://lore.kernel.org/ath10k/[email protected]/
reason being
QMI stuff happens much EARLIER than firmware-5.bin handling. (ar->running_fw is still NULL)
Maybe we can try/pick [PATCH v3 0/3] Work around missing MSA_READY indicator for msm8998 devices
[PATCH v3 0/3] Work around missing MSA_READY indicator for msm8998 devices
It is almost adccepted already, and final solution is to use separate DT property qcom,no-msa-ready-indicator in wlan wcn3990 node.
qcom,no-msa-ready-indicator
No branches or pull requests
I've found interesting thing
Seems like we don't have to even package
firmware-5.bin
, it's not a real firmware, but more like "firmware flags" file which can encode some board-specific fw features or quirks (see https://groups.google.com/a/chromium.org/g/chromium-os-reviews/c/7YVeGZrVhtY ). And we can just runath10k-fwencoder --create ...
with those set of flags to get the file.I've been looking how to upstream our msm8998/660 hack 3d1b275
and I think this should be encoded in
firmware-5.bin
as firmware quirk. It needs enum value added to struct ath10k_fw_features and also to array ath10k_core_fw_feature_str and same value inath10k-fwencoder
https://github.com/qca/qca-swiss-army-knife/blob/master/tools/scripts/ath10k/ath10k-fwencoder#L45 and new firmware-5.bin generated with this quirk.call flag like
ATH10K_FW_FEATURE_NO_MSA_READY_IND
and do smth liketest for pesence of this flag in the
ath10k_qmi_driver_event_work()
func likeThe text was updated successfully, but these errors were encountered: