b3f194e54b
There were a few places where the sc->rxlink pointer was set to NULL "just in
case". This helps nothing - quite to the contrary it is problematic since it
can create self-linked rx descriptors in the middle of the list of receive
buffers.
Here is an example how this could happen (thanks Bob!):
cpu 0: cpu 1:
ath5k_rx_stop
ath5k_tasklet_rx
sc->rxlink = NULL; /* just in case */
// following doesn't link used
// buffer to prev.
ath5k_rxbuf_setup()
In the case of ath5k_rx_stop() and ath5k_stop_locked() buffers/descriptors are
not changed so rxlink should not be changed as well.
In ath5k_intr() we seem to try to work around a hardware bug, as the comment
(which is copied 1:1 from the HAL) suggests. I don't see how this could help.
Also the HAL does not set rxlink in this case (So where does this code come
from? It has been there since the first import of ath5k). Changed to just
increment a statistics counter.
After this patch rxlink is only set to NULL before we initialize rx descriptors
and updated when the descriptors are linked together.
Signed-off-by: Bruno Randolf <br1@einfach.org>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
|
||
|---|---|---|
| .. | ||
| ani.c | ||
| ani.h | ||
| ath5k.h | ||
| attach.c | ||
| base.c | ||
| base.h | ||
| caps.c | ||
| debug.c | ||
| debug.h | ||
| desc.c | ||
| desc.h | ||
| dma.c | ||
| eeprom.c | ||
| eeprom.h | ||
| gpio.c | ||
| initvals.c | ||
| Kconfig | ||
| led.c | ||
| Makefile | ||
| pcu.c | ||
| phy.c | ||
| qcu.c | ||
| reg.h | ||
| reset.c | ||
| rfbuffer.h | ||
| rfgain.h | ||
| rfkill.c | ||
| sysfs.c | ||