1. 29 Feb, 2012 1 commit
  2. 22 Feb, 2012 1 commit
  3. 06 Feb, 2012 3 commits
  4. 30 Jan, 2012 1 commit
  5. 27 Jan, 2012 2 commits
  6. 24 Jan, 2012 1 commit
    • Hong Wu's avatar
      wireless: Save original maximum regulatory transmission power for the... · eccc068e
      Hong Wu authored
      wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit power
      The local maximum transmit power is the maximum power a wireless device
      allowed to transmit. If Power Constraint is presented, the local maximum
      power equals to the maximum allowed power defined in regulatory domain
      minus power constraint.
      The maximum transmit power is maximum power a wireless device capable of
      transmitting, and should be used in Power Capability element (
      IEEE802.11 2007).
      The transmit power from a wireless device should not greater than the
      local maximum transmit power.
      The maximum transmit power was not calculated correctly in the current
      Linux wireless/mac80211 when Power Constraint is presented.
      Signed-off-by: default avatarHong Wu <hong.wu@dspg.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  7. 23 Jan, 2012 1 commit
  8. 19 Dec, 2011 1 commit
  9. 16 Dec, 2011 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: allow following country IE power for custom regdom cards · 061acaae
      Luis R. Rodriguez authored
      By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the
      wiphy to adjust itself to the country IE power information if the
      card had no regulatory data but we had no way to tell cfg80211 that if
      the card also had its own custom regulatory domain (these are typically
      custom world regulatory domains) that we want to follow the country IE's
      noted values for power for each channel. We add support for this and
      document it.
      This is not a critical fix but a performance optimization for cards
      with custom regulatory domains that associate to an AP with sends
      out country IEs with a higher EIRP than the one on the custom
      regulatory domain. In practice the only driver affected right now
      are the Atheros drivers as they are the only drivers using both
      used on cards that have an Atheros world regulatory domain. Cards
      that have been programmed to follow a country specifically will not
      follow the country IE power. So although not a stable fix distributions
      should consider cherry picking this.
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Reported-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 15 Dec, 2011 1 commit
  11. 13 Dec, 2011 1 commit
    • Vasanthakumar Thiagarajan's avatar
      cfg80211: Fix race in bss timeout · adbde344
      Vasanthakumar Thiagarajan authored
      It is quite possible to run into a race in bss timeout where
      the drivers see the bss entry just before notifying cfg80211
      of a roaming event but it got timed out by the time rdev->event_work
      got scehduled from cfg80211_wq. This would result in the following
      WARN-ON() along with the failure to notify the user space of
      the roaming. The other situation which is happening with ath6kl
      that runs into issue is when the driver reports roam to same AP
      event where the AP bss entry already got expired. To fix this,
      move cfg80211_get_bss() from __cfg80211_roamed() to cfg80211_roamed().
      [158645.538384] WARNING: at net/wireless/sme.c:586
      [158645.538810] Call Trace:
      [158645.538838]  [<c1033527>] warn_slowpath_common+0x65/0x7a
      [158645.538917]  [<c14cfacf>] ? __cfg80211_roamed+0xc2/0x1b1
      [158645.538946]  [<c103354b>] warn_slowpath_null+0xf/0x13
      [158645.539055]  [<c14cfacf>] __cfg80211_roamed+0xc2/0x1b1
      [158645.539086]  [<c14beb5b>] cfg80211_process_rdev_events+0x153/0x1cc
      [158645.539166]  [<c14bd57b>] cfg80211_event_work+0x26/0x36
      [158645.539195]  [<c10482ae>] process_one_work+0x219/0x38b
      [158645.539273]  [<c14bd555>] ? wiphy_new+0x419/0x419
      [158645.539301]  [<c10486cb>] worker_thread+0xf6/0x1bf
      [158645.539379]  [<c10485d5>] ? rescuer_thread+0x1b5/0x1b5
      [158645.539407]  [<c104b3e2>] kthread+0x62/0x67
      [158645.539484]  [<c104b380>] ? __init_kthread_worker+0x42/0x42
      [158645.539514]  [<c151309a>] kernel_thread_helper+0x6/0xd
      Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarVasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  12. 06 Dec, 2011 1 commit
  13. 30 Nov, 2011 1 commit
  14. 28 Nov, 2011 3 commits
  15. 21 Nov, 2011 3 commits
  16. 11 Nov, 2011 3 commits
  17. 09 Nov, 2011 8 commits
  18. 08 Nov, 2011 1 commit
  19. 14 Oct, 2011 1 commit
  20. 30 Sep, 2011 2 commits
  21. 27 Sep, 2011 2 commits
  22. 19 Sep, 2011 1 commit