Re: ath5k: fix spontaneus AR5312 freezes

[Kalle Valo <kvalo@codeaurora.org>]

> Sometimes while CPU have some load and ath5k doing the wireless
> interface reset the whole WiSoC completely freezes. Set of tests shows
> that using atomic delay function while we wait interface reset helps to
> avoid such freezes.
> 
> The easiest way to reproduce this issue: create a station interface,
> start continous scan with wpa_supplicant and load CPU by something. Or
> just create multiple station interfaces and put them all in continous
> scan.
> 
> This patch partially reverts the commit 1846ac3dbec0 ("ath5k: Use
> usleep_range where possible"), which replaces initial udelay()
> by usleep_range().
> 
> I do not know actual source of this issue, but all looks like that HW
> freeze is caused by transaction on internal SoC bus, while wireless
> block is in reset state.
> 
> Also I should note that I do not know how many chips are affected, but I
> did not see this issue with chips, other than AR5312.
> 
> CC: Jiri Slaby <jirislaby@gmail.com>
> CC: Nick Kossifidis <mickflemm@gmail.com>
> CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
> Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
> Reported-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
> Tested-by: Christophe Prevotaux <c.prevotaux@rural-networks.com>
> Tested-by: Eric Bree <ebree@nltinc.com>
> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@gmail.com>

Thanks, applied to wireless-drivers-next.git.

Kalle Valo