[PATCH] ath10k: workaround fw beaconing bug

Kalle Valo kvalo at qca.qualcomm.com
Tue Sep 23 02:29:46 PDT 2014


Michal Kazior <michal.kazior at tieto.com> writes:

> 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 at tieto.com>

Thanks, applied.

-- 
Kalle Valo



More information about the ath10k mailing list