diff options
| author | Marc Gonzalez <[email protected]> | 2024-04-29 16:04:51 +0200 |
|---|---|---|
| committer | Kalle Valo <[email protected]> | 2024-05-13 17:15:47 +0300 |
| commit | 71b6e321e30271beb08772871c4f76777f49e402 (patch) | |
| tree | 6c975d24a88a18933d60c0b926e8134f1eb51526 /tools/perf/scripts/python/event_analyzing_sample.py | |
| parent | 3b9344740843d965e9e37fba30620b3b1c0afa4f (diff) | |
dt-bindings: net: wireless: ath10k: add qcom,no-msa-ready-indicator prop
The ath10k driver waits for an "MSA_READY" indicator
to complete initialization. If the indicator is not
received, then the device remains unusable.
cf. ath10k_qmi_driver_event_work()
Several msm8998-based devices are affected by this issue.
Oddly, it seems safe to NOT wait for the indicator, and
proceed immediately when QMI_EVENT_SERVER_ARRIVE.
Jeff Johnson wrote:
The feedback I received was "it might be ok to change all ath10k qmi
to skip waiting for msa_ready", and it was pointed out that ath11k
(and ath12k) do not wait for it.
However with so many deployed devices, "might be ok" isn't a strong
argument for changing the default behavior.
Kalle Valo first suggested setting a bit in firmware-5.bin to trigger
work-around in the driver. However, firmware-5.bin is parsed too late.
So we are stuck with a DT property.
Signed-off-by: Marc Gonzalez <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Acked-by: Jeff Johnson <[email protected]>
Acked-by: Rob Herring (Arm) <[email protected]>
Signed-off-by: Kalle Valo <[email protected]>
Link: https://msgid.link/[email protected]
Diffstat (limited to 'tools/perf/scripts/python/event_analyzing_sample.py')
0 files changed, 0 insertions, 0 deletions