1. 27 3月, 2012 1 次提交
  2. 14 3月, 2012 1 次提交
  3. 13 3月, 2012 1 次提交
  4. 07 3月, 2012 2 次提交
  5. 06 3月, 2012 2 次提交
  6. 01 3月, 2012 1 次提交
  7. 23 2月, 2012 1 次提交
  8. 07 2月, 2012 4 次提交
  9. 31 1月, 2012 1 次提交
  10. 28 1月, 2012 2 次提交
  11. 25 1月, 2012 1 次提交
    • H
      wireless: Save original maximum regulatory transmission power for the... · eccc068e
      Hong Wu 提交于
      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 (7.3.2.16
      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: NHong Wu <hong.wu@dspg.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      eccc068e
  12. 12 1月, 2012 1 次提交
  13. 05 1月, 2012 5 次提交
  14. 20 12月, 2011 1 次提交
  15. 16 12月, 2011 4 次提交
  16. 15 12月, 2011 1 次提交
  17. 14 12月, 2011 2 次提交
    • R
      cfg80211: notify core hints that helps to restore regd settings · 4a38994f
      Rajkumar Manoharan 提交于
      Regulatory updates set by CORE are ignored for custom regulatory cards.
      Let us notify the changes to the driver, as some drivers uses core hint
      to restore its orig_* reg domain setting.
      
      Cc: Paul Stewart <pstew@google.com>
      Signed-off-by: NRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Acked-by: NLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4a38994f
    • V
      cfg80211: Fix race in bss timeout · adbde344
      Vasanthakumar Thiagarajan 提交于
      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
      __cfg80211_roamed+0xc2/0x1b1()
      [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: NKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: NVasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      adbde344
  18. 08 12月, 2011 1 次提交
  19. 07 12月, 2011 1 次提交
  20. 01 12月, 2011 2 次提交
  21. 29 11月, 2011 4 次提交
  22. 22 11月, 2011 1 次提交
    • J
      cfg80211: work around a sparse issue · 11a2a357
      Johannes Berg 提交于
      sparse reports:
      net/wireless/util.c:499:30: error: cannot size expression
      net/wireless/util.c:503:30: error: cannot size expression
      
      This is evidently due to the EXPORT_SYMBOL() of the
      bridge_tunnel_header and rfc1042 header variables.
      Move them to the end of the file to work around the
      sparse issue. The error itself from sparse can be
      ignored safely, but since sparse stops parsing at
      errors, other issues after this would go undetected.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      11a2a357