> 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@xxxxxxxxx>
> CC: Nick Kossifidis <mickflemm@xxxxxxxxx>
> CC: Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxx>
> Fixes: 1846ac3dbec0 ("ath5k: Use usleep_range where possible")
> Reported-by: Christophe Prevotaux <c.prevotaux@xxxxxxxxxxxxxxxxxx>
> Tested-by: Christophe Prevotaux <c.prevotaux@xxxxxxxxxxxxxxxxxx>
> Tested-by: Eric Bree <ebree@xxxxxxxxxx>
> Signed-off-by: Sergey Ryazanov <ryazanov.s.a@xxxxxxxxx>
Thanks, applied to wireless-drivers-next.git.
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
