1. 21 12月, 2010 2 次提交
  2. 16 12月, 2010 1 次提交
  3. 08 12月, 2010 1 次提交
  4. 01 12月, 2010 1 次提交
  5. 30 11月, 2010 1 次提交
    • G
      ath9k: use per-device struct for pm_qos_* operations · 98c316e3
      Gabor Juhos 提交于
      The ath9k driver uses a shared pm_qos_request_list structure for all
      devices. This causes the following warning if more than one device is
      present in the system:
      
      WARNING: at kernel/pm_qos_params.c:234 ath9k_init_device+0x5e8/0x6b0()
      pm_qos_add_request() called for already added request
      Modules linked in:
      Call Trace:
      [<802b1cdc>] dump_stack+0x8/0x34
      [<8007dd90>] warn_slowpath_common+0x78/0xa4
      [<8007de44>] warn_slowpath_fmt+0x2c/0x38
      [<801b0828>] ath9k_init_device+0x5e8/0x6b0
      [<801bc508>] ath_pci_probe+0x2dc/0x39c
      [<80176254>] pci_device_probe+0x64/0xa4
      [<8019471c>] driver_probe_device+0xbc/0x188
      [<80194854>] __driver_attach+0x6c/0xa4
      [<80193e20>] bus_for_each_dev+0x60/0xb0
      [<80193580>] bus_add_driver+0xcc/0x268
      [<80194c08>] driver_register+0xe0/0x198
      [<801764e0>] __pci_register_driver+0x50/0xe0
      [<80365f48>] ath9k_init+0x3c/0x6c
      [<8006050c>] do_one_initcall+0xfc/0x1d8
      [<80355340>] kernel_init+0xd4/0x174
      [<800639a4>] kernel_thread_helper+0x10/0x18
      
      ---[ end trace 5345fc6f870564a6 ]---
      
      This patch fixes that warning by using a separate pm_qos_request_list
      sructure for each device.
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      98c316e3
  6. 18 11月, 2010 12 次提交
  7. 17 11月, 2010 2 次提交
  8. 16 11月, 2010 3 次提交
  9. 10 11月, 2010 1 次提交
  10. 09 11月, 2010 1 次提交
  11. 28 10月, 2010 1 次提交
  12. 16 10月, 2010 2 次提交
  13. 12 10月, 2010 1 次提交
  14. 07 10月, 2010 1 次提交
  15. 21 9月, 2010 3 次提交
  16. 17 9月, 2010 1 次提交
    • L
      ath9k: fix enabling ANI / tx monitor after bg scan · 48a6a468
      Luis R. Rodriguez 提交于
      ath9k's entire logic with SC_OP_SCANNING is incorrect due to the
      way mac80211 currently implements the scan complete callback and
      we handle it in ath9k. This patch removes the flag completely in
      preference for the SC_OP_OFFCHANNEL which is really what we wanted.
      
      The scanning flag was used to ensure we reset ANI to the old values
      when we go back to the home channel, but if we are offchannel we
      use some defaults. The flag was also used to re-enable the TX monitor.
      
      Without this patch we simply never re-enabled ANI and the TX monitor
      after going offchannel. This means that after one background
      scan we are prone to noise issues and if we had a TX hang we would
      not recover. To get this to work properly we must enable ANI after
      we have configured the beacon timers, otherwise hardware acts really
      oddly.
      
      This patch has stable fixes which apply down to [2.6.36+], there
      *may* be a to fix this on older kernels but requires a bit of
      work since this patch relies on the new mac80211 flag
      IEEE80211_CONF_OFFCHANNEL which was introduced as of 2.6.36.
      
      Cc: stable@kernel.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Amod Bodas <amod.bodas@atheros.com>
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      48a6a468
  17. 15 9月, 2010 1 次提交
    • F
      ath9k: fix BSSID mask calculation · 31a01645
      Felix Fietkau 提交于
      At the time the .add_interface driver op is called, the interface has not
      been marked as running yet, so ieee80211_iterate_active_interfaces will
      not pass it to the iterator function.
      Because of this, the calculated BSSID mask is wrong, which breaks multi-BSS
      operation.
      
      Additionally, the current way of comparing all addresses against each other
      is pointless, as the hardware only uses the hardware MAC address and the BSSID
      mask for matching the destination address, so all the address array
      reallocation is completely unnecessary.
      
      This patch simplifies the logic by setting the initial mask bytes to 0xff
      and removing all bits in the iterator call that don't match the hardware MAC
      address. It also calls the iterator for the vif that was passed to
      add_interface()
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Tested-by: NBen Greear <greearb@candelatech.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      31a01645
  18. 08 9月, 2010 1 次提交
  19. 25 8月, 2010 1 次提交
  20. 17 8月, 2010 1 次提交
  21. 05 8月, 2010 2 次提交
    • F
      ath9k_hw: clean up per-channel calibration data · 20bd2a09
      Felix Fietkau 提交于
      The noise floor history buffer is currently not kept per channel, which
      can lead to problems when changing channels from a clean channel to a
      noisy one. Also when switching from HT20 to HT40, the noise floor
      history buffer is full of measurements, but none of them contain data
      for the extension channel, which it needs quite a bit of time to recover
      from.
      
      This patch puts all the per-channel calibration data into a single data
      structure, and gives the the driver control over whether that is used
      per-channel or even not used for some channels.
      
      For ath9k_htc, I decided to keep this per-channel in order to avoid
      creating regressions.
      
      For ath9k, the data is kept only for the operating channel, which saves
      some space. ath9k_hw takes care of wiping old data when the operating
      channel or its channel flags change.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      20bd2a09
    • F
      ath9k: prevent calibration during off-channel activity · 5ee08656
      Felix Fietkau 提交于
      Previously the software scan callback was used to indicate to the hardware,
      when it was safe to calibrate. This didn't really work properly, because it
      depends on a specific order of software scan callbacks vs. channel changes.
      Also, software scans are not the only thing that triggers off-channel
      activity, so it's better to use the newly added indication from mac80211 for
      this and not use the software scan callback for anything calibration related.
      
      This fixes at least some of the invalid noise floor readings that I've seen
      in AP mode on AR9160
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5ee08656