ath9k: fix processing RXORN interrupts
The "goto chip_reset" is a bit misleading, because it does not actually issue a chip reset. Instead it is bypassing processing of other interrupts and assumes that the tasklet will issue a chip reset. In the case of RXORN this does not happen, so bypassing processing of other interrupts will simply allow them to fire again. Even if RXORN was triggering a reset, it is not critical enough to need the bypass here. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
This commit is contained in:
parent
257b5bc680
commit
3b58014472
@ -545,11 +545,10 @@ irqreturn_t ath_isr(int irq, void *dev)
|
||||
sched = true;
|
||||
|
||||
/*
|
||||
* If a FATAL or RXORN interrupt is received, we have to reset the
|
||||
* chip immediately.
|
||||
* If a FATAL interrupt is received, we have to reset the chip
|
||||
* immediately.
|
||||
*/
|
||||
if ((status & ATH9K_INT_FATAL) || ((status & ATH9K_INT_RXORN) &&
|
||||
!(ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)))
|
||||
if (status & ATH9K_INT_FATAL)
|
||||
goto chip_reset;
|
||||
|
||||
if ((ah->config.hw_hang_checks & HW_BB_WATCHDOG) &&
|
||||
|
Loading…
Reference in New Issue
Block a user