Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 04 3月, 2010 1 次提交
    • S
      mac80211: Fix HT rate control configuration · 4fa00437
      由 Sujith 提交于 
      Handling HT configuration changes involved setting the channel
with the new HT parameters and then issuing a rate_update()
notification to the driver.

This behavior changed after the off-channel changes. Now, the channel
is not updated with the new HT params in enable_ht() - instead, it
is now done when the scan work terminates. This results in the driver
depending on stale information, defaulting to non-HT mode always.

Fix this by passing the new channel type to the driver.

Cc: stable@kernel.org
Signed-off-by: NSujith <Sujith.Manoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4fa00437
  3. 20 2月, 2010 1 次提交
    • F
      ath9k: fix rate control fallback rate selection · 5c0ba62f
      由 Felix Fietkau 提交于 
      When selecting the tx fallback rate, rc.c used a separate variable
'nrix' for storing the next rate index, however it did not use that as
reference for further rate index lowering. Because of that, it ended up
reusing the same rate for multiple multi-rate retry stages, thus
decreasing delivery probability under changing link conditions.

This patch removes the separate (unnecessary) variable and fixes
fallback the way it was intended to work.
This should result in increased throughput and better link stability.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5c0ba62f
  5. 26 1月, 2010 1 次提交
    • F
      ath9k: improve max rate retry handling · 65896510
      由 Felix Fietkau 提交于 
      ath9k currently forces hw->max_rate_tries to 4 to work around rate
control inefficiencies. This has some negative side effects, such as
rate_control_send_low also using a maximum of 4 tries, which could
negatively affect reliability of unicast management frames.
This patch pushes the retry limit to the rate control instead, and
allows it to use more tries on the last stage to prevent unnecessary
packet loss.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      65896510
  7. 04 12月, 2009 1 次提交
  9. 29 11月, 2009 3 次提交
    • L
      ath9k: Fix maximum tx fifo settings for single stream devices · f4709fdf
      由 Luis R. Rodriguez 提交于 
      Atheros single stream AR9285 and AR9271 have half the PCU TX FIFO
buffer size of that of dual stream devices. Dual stream devices
have a max PCU TX FIFO size of 8 KB while single stream devices
have 4 KB. Single stream devices have an issue though and require
hardware only to use half of the amount of its capable PCU TX FIFO
size, 2 KB and this requires a change in software.

Technically a change would not have been required (except for frame
burst considerations of 128 bytes) if these devices would have been
able to use the full 4 KB of the PCU TX FIFO size but our systems
engineers recommend 2 KB to be used only. We enforce this through
software by reducing the max frame triggger level to 2 KB.

Fixing the max frame trigger level should then have a few benefits:

  * The PER will now be adjusted as designed for underruns when the
    max trigger level is reached. This should help alleviate the
    bus as the rate control algorithm chooses a slower rate which
    should ensure frames are transmitted properly under high system
    bus load.

  * The poll we use on our TX queues should now trigger and work
    as designed for single stream devices. The hardware passes
    data from each TX queue on the PCU TX FIFO queue respecting each
    queue's priority. The new trigger level ensures this seeding of
    the PCU TX FIFO queue occurs as designed which could mean avoiding
    false resets and actually reseting hw correctly when a TX queue
    is indeed stuck.

  * Some undocumented / unsupported behaviour could have been triggered
    when the max trigger level level was being set to 4 KB on single
    stream devices. Its not clear what this issue was to me yet.

Cc: Kyungwan Nam <kyungwan.nam@atheros.com>
Cc: Bennyam Malavazi <bennyam.malavazi@atheros.com>
Cc: Stephen Chen <stephen.chen@atheros.com>
Cc: Shan Palanisamy <shan.palanisamy@atheros.com>
Cc: Paul Shaw <paul.shaw@atheros.com>
Signed-off-by: NVasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f4709fdf
    • F
      ath9k: clean up rc rate table · 1fe8234a
      由 Felix Fietkau 提交于 
      Remove some fields from struct ath_rate_table that are now unused.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1fe8234a
    • F
      ath9k: properly use the mac80211 rate control api · 545750d3
      由 Felix Fietkau 提交于 
      This patch changes ath9k to pass proper MCS indexes and flags
between the RC and the rest of the driver code.
sc->cur_rate_table remains, as it's used by the RC code internally,
but the rest of the driver code no longer uses it, so a potential
new RC for ath9k would not have to update it.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      545750d3
  11. 19 11月, 2009 2 次提交
  13. 31 10月, 2009 1 次提交
  15. 08 10月, 2009 3 次提交
  17. 05 8月, 2009 2 次提交
  19. 25 7月, 2009 16 次提交
  21. 07 5月, 2009 2 次提交
  23. 25 4月, 2009 1 次提交
    • J
      wireless: remove some (bogus?) 'may be used uninitialized' warnings · d3feaf5a
      由 John W. Linville 提交于 
      net/mac80211/tx.c: In function ‘ieee80211_tx_h_select_key’:
net/mac80211/tx.c:448: warning: ‘key’ may be used uninitialized in this function

drivers/net/wireless/ath/ath9k/rc.c: In function ‘ath_rc_rate_getidx’:
drivers/net/wireless/ath/ath9k/rc.c:815: warning: ‘nextindex’ may be used uninitialized in this function

drivers/net/wireless/hostap/hostap_plx.c: In function ‘prism2_plx_probe’:
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_index’ may be used uninitialized in this function
drivers/net/wireless/hostap/hostap_plx.c:438: warning: ‘cor_offset’ may be used uninitialized in this function
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d3feaf5a
  25. 23 4月, 2009 3 次提交
  27. 28 3月, 2009 3 次提交