ath10k: workaround fw beaconing bug
authorMichal Kazior <michal.kazior@tieto.com>
Thu, 18 Sep 2014 08:18:02 +0000 (11:18 +0300)
committerKalle Valo <kvalo@qca.qualcomm.com>
Tue, 23 Sep 2014 09:28:52 +0000 (12:28 +0300)
commit64badcb6d6459cc6f7b46f7d45e44c95ab874337
treeb7b4cb38e44abc22ceadcc5fd4495f0f6fd5a025
parentb25f32cb02155d68c690255ba846796a1c248fd3
ath10k: workaround fw beaconing bug

Some firmware revisions don't wait for beacon tx
completion before sending another SWBA event. This
could lead to hardware using old (freed) beacon
data in some cases, e.g. tx credit starvation
combined with missed TBTT. This is very very rare.

On non-IOMMU-enabled hosts this could be a
possible security issue because hw could beacon
some random data on the air.  On IOMMU-enabled
hosts DMAR faults would occur in most cases and
target device would crash.

Since there are no beacon tx completions (implicit
nor explicit) propagated to host the only
workaround for this is to allocate a DMA-coherent
buffer for a lifetime of a vif and use it for all
beacon tx commands. Worst case for this approach
is some beacons may become corrupted, e.g. garbled
IEs or out-of-date TIM bitmap.

Keep the original beacon-related code as-is in
case future firmware revisions solve this problem
so that the old path can be easily re-enabled with
a fw_feature flag.

Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
drivers/net/wireless/ath/ath10k/core.h
drivers/net/wireless/ath/ath10k/mac.c
drivers/net/wireless/ath/ath10k/mac.h
drivers/net/wireless/ath/ath10k/wmi.c