1. 13 3月, 2015 6 次提交
    • S
      ath9k: Add PCIE powersave macros · e519f78f
      Sujith Manoharan 提交于
      These will be used to handle chip-specific
      power save configuration.
      Signed-off-by: NSujith Manoharan <c_manoha@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      e519f78f
    • V
      wil6210: support AP isolation · 02beaf1a
      Vladimir Kondratiev 提交于
      For the AP, configuration may say not to bridge traffic between
      wireless clients. This is conveyed from user space (ex: hostapd has
      ap_isolate parameter) with NL80211_CMD_SET_BSS, to the driver's
      cfg80211 ops method change_bss
      
      Add support for this setting.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      02beaf1a
    • V
      wil6210: re-submit Rx frames to the wireless media if appropriate · c42da999
      Vladimir Kondratiev 提交于
      This is for AP only. If Rx data frame targeted to one of associated clients,
      transmit it back to the wireless media and don't deliver to the host.
      For the multicast frames, deliver to both host and wireless media.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      c42da999
    • V
      wil6210: NAPI completion refactor · 7308a20e
      Vladimir Kondratiev 提交于
      It is expected that driver completes NAPI when less than
      full budget is consumed.
      
      Fulfill this requirement.
      Signed-off-by: NVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7308a20e
    • S
      ath5k: fix reset race · ab5e290a
      Sergey Ryazanov 提交于
      To prepare for reset ath5k should finish all asynchronous tasks. At
      first, it disables the interrupt generation, then it waits for the
      interrupt handler and tasklets completion, and then proceeds to the HW
      configuration update. But it does not consider that the interrupt
      handler or tasklet re-enables the interrupt generation. And we fall in a
      situation when ath5k assumes that interrupts are disabled, but it is
      not.
      
      This can lead to different consequences, such as reception of the frame,
      when we do not expect it. Under certain circumstances, this can lead to
      the following warning:
      
        WARNING: at ath5k/base.c:589 ath5k_tasklet_rx+0x318/0x6ec [ath5k]()
        invalid hw_rix: 1a
        [..]
        Call Trace:
        [<802656a8>] show_stack+0x48/0x70
        [<802dd92c>] warn_slowpath_common+0x88/0xbc
        [<802dd98c>] warn_slowpath_fmt+0x2c/0x38
        [<81b51be8>] ath5k_tasklet_rx+0x318/0x6ec [ath5k]
        [<8028ac64>] tasklet_action+0x8c/0xf0
        [<80075804>] __do_softirq+0x180/0x32c
        [<80196ce8>] irq_exit+0x54/0x70
        [<80041848>] ret_from_irq+0x0/0x4
        [<80182fdc>] ioread32+0x4/0xc
        [<81b4c42c>] ath5k_hw_set_sleep_clock+0x2ec/0x474 [ath5k]
        [<81b4cf28>] ath5k_hw_reset+0x50/0xeb8 [ath5k]
        [<81b50900>] ath5k_reset+0xd4/0x310 [ath5k]
        [<81b557e8>] ath5k_config+0x4c/0x104 [ath5k]
        [<80d01770>] ieee80211_hw_config+0x2f4/0x35c [mac80211]
        [<80d09aa8>] ieee80211_scan_work+0x2e4/0x414 [mac80211]
        [<8022c3f4>] process_one_work+0x28c/0x400
        [<802df8f8>] worker_thread+0x258/0x3c0
        [<801b5710>] kthread+0xe0/0xec
        [<800418a8>] ret_from_kernel_thread+0x14/0x1c
      
      Fix this issue by adding a new status flag, which forbids to re-enable
      the interrupt generation until the HW configuration is completed.
      
      Note: previous patch, which reorders the Rx disable code helps to avoid
      the above warning, but not fixes the root cause of unexpected frame
      receiving.
      
      CC: Jiri Slaby <jirislaby@gmail.com>
      CC: Nick Kossifidis <mickflemm@gmail.com>
      CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
      Reported-by: NChristophe Prevotaux <cprevotaux@nltinc.com>
      Tested-by: NChristophe Prevotaux <cprevotaux@nltinc.com>
      Tested-by: NEric Bree <ebree@nltinc.com>
      Signed-off-by: NSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ab5e290a
    • S
      ath5k: channel change fix · 4a2f248f
      Sergey Ryazanov 提交于
      ath5k updates the channel pointer and after that it stops the Rx logic
      and apply channel to HW. In case of channel switch, such sequence
      creates a small window when a frame, which is received on the old
      channel is considered as a frame received on the new one.
      
      The most notable consequence of this situation occurs during the switch
      from 2 GHz band (CCK+OFDM) to the 5GHz band (OFDM-only). Frame received
      with CCK rate, e.g. beacon received at the 1mbps, causes the following
      warning:
      
        WARNING: at ath5k/base.c:589 ath5k_tasklet_rx+0x318/0x6ec [ath5k]()
        invalid hw_rix: 1a
        [..]
        Call Trace:
        [<802656a8>] show_stack+0x48/0x70
        [<802dd92c>] warn_slowpath_common+0x88/0xbc
        [<802dd98c>] warn_slowpath_fmt+0x2c/0x38
        [<81b51be8>] ath5k_tasklet_rx+0x318/0x6ec [ath5k]
        [<8028ac64>] tasklet_action+0x8c/0xf0
        [<80075804>] __do_softirq+0x180/0x32c
        [<80196ce8>] irq_exit+0x54/0x70
        [<80041848>] ret_from_irq+0x0/0x4
        [<80182fdc>] ioread32+0x4/0xc
        [<81b4c42c>] ath5k_hw_set_sleep_clock+0x2ec/0x474 [ath5k]
        [<81b4cf28>] ath5k_hw_reset+0x50/0xeb8 [ath5k]
        [<81b50900>] ath5k_reset+0xd4/0x310 [ath5k]
        [<81b557e8>] ath5k_config+0x4c/0x104 [ath5k]
        [<80d01770>] ieee80211_hw_config+0x2f4/0x35c [mac80211]
        [<80d09aa8>] ieee80211_scan_work+0x2e4/0x414 [mac80211]
        [<8022c3f4>] process_one_work+0x28c/0x400
        [<802df8f8>] worker_thread+0x258/0x3c0
        [<801b5710>] kthread+0xe0/0xec
        [<800418a8>] ret_from_kernel_thread+0x14/0x1c
      
      The easiest way to reproduce this warning is to run scan with dualband
      NIC in noisy environments, when the channel 11 runs multiple APs. In my
      tests if the APs num >= 12, the warning appears in the first few
      seconds of scanning.
      
      In order to fix this, the Rx disable code moved to a higher level and
      placed before the channel pointer update. This is also makes the code a
      bit more symmetrical, since we disable and enable the Rx in the same
      function.
      
      In fact, at the pointer update time new frames should not appear,
      because interrupt generation at this point should already be disabled.
      The next patch should address this issue.
      
      CC: Jiri Slaby <jirislaby@gmail.com>
      CC: Nick Kossifidis <mickflemm@gmail.com>
      CC: Luis R. Rodriguez <mcgrof@do-not-panic.com>
      Reported-by: NChristophe Prevotaux <cprevotaux@nltinc.com>
      Tested-by: NChristophe Prevotaux <cprevotaux@nltinc.com>
      Tested-by: NEric Bree <ebree@nltinc.com>
      Signed-off-by: NSergey Ryazanov <ryazanov.s.a@gmail.com>
      Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      4a2f248f
  2. 04 3月, 2015 6 次提交
  3. 03 3月, 2015 18 次提交
  4. 27 2月, 2015 8 次提交
  5. 26 2月, 2015 2 次提交