Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 6月, 2010 9 次提交
  3. 08 6月, 2010 5 次提交
  5. 05 6月, 2010 2 次提交
  7. 03 6月, 2010 11 次提交
  9. 02 6月, 2010 1 次提交
  11. 25 5月, 2010 1 次提交
    • B
      ath5k: consistently use rx_bufsize for RX DMA · b5eae9ff
      由 Bruno Randolf 提交于 
      We should use the same buffer size we set up for DMA also in the hardware
descriptor. Previously we used common->rx_bufsize for setting up the DMA
mapping, but used skb_tailroom(skb) for the size we tell to the hardware in the
descriptor itself. The problem is that skb_tailroom(skb) can give us a larger
value than the size we set up for DMA before. This allows the hardware to write
into memory locations not set up for DMA. In practice this should rarely happen
because all packets should be smaller than the maximum 802.11 packet size.

On the tested platform rx_bufsize is 2528, and we allocated an skb of 2559
bytes length (including padding for cache alignment) but sbk_tailroom() was
2592. Just consistently use rx_bufsize for all RX DMA memory sizes.

Also use the return value of the descriptor setup function.

Cc: stable@kernel.org
Signed-off-by: NBruno Randolf <br1@einfach.org>
Reviewed-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      b5eae9ff
  13. 14 5月, 2010 1 次提交
    • J
      drivers/net: Remove unnecessary returns from void function()s · a4b77097
      由 Joe Perches 提交于 
      This patch removes from drivers/net/ all the unnecessary
return; statements that precede the last closing brace of
void functions.

It does not remove the returns that are immediately
preceded by a label as gcc doesn't like that.

It also does not remove null void functions with return.

Done via:
$ grep -rP --include=*.[ch] -l "return;\n}" net/ | \
  xargs perl -i -e 'local $/ ; while (<>) { s/\n[ \t\n]+return;\n}/\n}/g; print; }'

with some cleanups by hand.

Compile tested x86 allmodconfig only.
Signed-off-by: NJoe Perches <joe@perches.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a4b77097
  15. 12 5月, 2010 1 次提交
    • L
      ath5k: drop warning on jumbo frames · 9637e516
      由 Luis R. Rodriguez 提交于 
      Jumbo frames are not supported, and if they are seen it is likely
a bogus frame so just silently discard them instead of warning on
them all time. Also, instead of dropping them immediately though
move the check *after* we check for all sort of frame errors. This
should enable us to discard these frames if the hardware picks
other bogus items first. Lets see if we still get those jumbo
counters increasing still with this.

Jumbo frames would happen if we tell hardware we can support
a small 802.11 chunks of DMA'd frame, hardware would split RX'd
frames into parts and we'd have to reconstruct them in software.
This is done with USB due to the bulk size but with ath5k we
already provide a good limit to hardware and this should not be
happening.

This is reported quite often and if it fills the logs then this
needs to be addressed and to avoid spurious reports.

Cc: stable@kernel.org
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9637e516
  17. 11 5月, 2010 1 次提交
  19. 01 5月, 2010 1 次提交
  21. 29 4月, 2010 1 次提交
  23. 20 4月, 2010 1 次提交
  25. 17 4月, 2010 1 次提交
    • B
      ath5k/ath9k: Fix 64 bits TSF reads · 1c0fc65e
      由 Benoit Papillault 提交于 
      According to tests, both TSF lower and upper registers kept counting, so
the higher part could have been updated after the lower part has been
read, as shown in the following log where the upper part is read first
and the lower part next.

tsf = {00000003-fffffffd}
tsf = {00000003-00000001}
tsf = {00000004-0000000b}

This patch corrects this by checking that the upper part has not been
changed while the lower part was read. It has been tested in an IBSS
network where artifical IBSS merges have been done in order to trigger
hundreds of rollover for the TSF lower part.

It follows the logic mentionned by Derek, with only 2 register reads
needed at each additional steps instead of 3 (the minimum number of
register reads is still 3).
Signed-off-by: NBenoit Papillault <benoit.papillault@free.fr>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1c0fc65e
  27. 15 4月, 2010 2 次提交
    • B
      ath5k: treat RXORN as non-fatal · 87d77c4e
      由 Bruno Randolf 提交于 
      We get RXORN interrupts when all receive buffers are full. This is not
necessarily a fatal situation. It can also happen when the bus is busy or the
CPU is not fast enough to process all frames.

Older chipsets apparently need a reset to come out of this situration, but on
newer chips we can treat RXORN like RX, as going thru a full reset does more
harm than good, there.

The exact chip revisions which need a reset are unknown - this guess
AR5K_SREV_AR5212 ("venice") is copied from the HAL.

Inspired by openwrt 413-rxorn.patch:
"treat rxorn like rx, reset after rxorn seems to do more harm than good"
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      87d77c4e
    • B
      ath5k: Use high bitrates for ACK/CTS · 0edc9a67
      由 Bruno Randolf 提交于 
      There was a confusion in the usage of the bits AR5K_STA_ID1_ACKCTS_6MB and
AR5K_STA_ID1_BASE_RATE_11B. If they are set (1), we will get lower bitrates for
ACK and CTS. Therefore ath5k_hw_set_ack_bitrate_high(ah, false) actually
resulted in high bitrates, which i think is what we want anyways. Cleared the
confusion and added some documentation.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0edc9a67
  29. 09 4月, 2010 2 次提交