1. 15 Nov, 2010 3 commits
    • Luis R. Rodriguez's avatar
      cfg80211: fix disabling channels based on hints · ca4ffe8f
      Luis R. Rodriguez authored
      
      
      After a module loads you will have loaded the world roaming regulatory
      domain or a custom regulatory domain. Further regulatory hints are
      welcomed and should be respected unless the regulatory hint is coming
      from a country IE as the IEEE spec allows for a country IE to be a subset
      of what is allowed by the local regulatory agencies.
      
      So disable all channels that do not fit a regulatory domain sent
      from a unless the hint is from a country IE and the country IE had
      no information about the band we are currently processing.
      
      This fixes a few regulatory issues, for example for drivers that depend
      on CRDA and had no 5 GHz freqencies allowed were not properly disabling
      5 GHz at all, furthermore it also allows users to restrict devices
      further as was intended.
      
      If you recieve a country IE upon association we will also disable the
      channels that are not allowed if the country IE had at least one
      channel on the respective band we are procesing.
      
      This was the original intention behind this design but it was
      completely overlooked...
      
      Cc: David Quan <david.quan@atheros.com>
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ca4ffe8f
    • Luis R. Rodriguez's avatar
      cfg80211: fix allowing country IEs for WIPHY_FLAG_STRICT_REGULATORY · 749b527b
      Luis R. Rodriguez authored
      
      
      We should be enabling country IE hints for WIPHY_FLAG_STRICT_REGULATORY
      even if we haven't yet recieved regulatory domain hint for the driver
      if it needed one. Without this Country IEs are not passed on to drivers
      that have set WIPHY_FLAG_STRICT_REGULATORY, today this is just all
      Atheros chipset drivers: ath5k, ath9k, ar9170, carl9170.
      
      This was part of the original design, however it was completely
      overlooked...
      
      Cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      749b527b
    • Luis R. Rodriguez's avatar
      cfg80211: pass the reg hint initiator to helpers · 7ca43d03
      Luis R. Rodriguez authored
      
      
      This is required later.
      
      Cc: Easwar Krishnan <easwar.krishnan@atheros.com>
      Cc: stable@kernel.org
      signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7ca43d03
  2. 25 Oct, 2010 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: fix regression on processing country IEs · a171fba4
      Luis R. Rodriguez authored
      The patch 4f366c5d
      
      :
      
      	wireless: only use alpha2 regulatory information from country IE
      
      removed some complex intersection we were always doing between the AP's
      country IE info and what we got from CRDA. When CRDA sent us back a
      regulatory domain we would do some sanity checks on that regulatory
      domain response we just got. Part of these sanity checks included
      checking that we already had performed an intersection for the
      request of NL80211_REGDOM_SET_BY_COUNTRY_IE type.
      
      This mean that cfg80211 was only processing country IEs for cases
      where we already had an intersection, but since we removed enforcing
      this this is no longer required, we should just apply the country
      IE country hint with the data received from CRDA.
      
      This patch has fixes intended for kernels >= 2.6.36.
      
      Cc: stable@kernel.org
      Reported-by: default avatarEaswar Krishnan <easwar.krishnan@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a171fba4
  3. 16 Sep, 2010 1 commit
  4. 16 Aug, 2010 1 commit
  5. 28 Jul, 2010 1 commit
  6. 26 Jul, 2010 1 commit
  7. 20 Jul, 2010 2 commits
  8. 24 Jun, 2010 1 commit
  9. 18 Jun, 2010 1 commit
  10. 31 Mar, 2010 1 commit
  11. 30 Mar, 2010 2 commits
    • John W. Linville's avatar
      wireless: convert reg_regdb_search_lock to mutex · 368d06f5
      John W. Linville authored
      
      
      Stanse discovered that kmalloc is being called with GFP_KERNEL while
      holding this spinlock.  The spinlock can be a mutex instead, which also
      enables the removal of the unlock/lock around the lock/unlock of
      cfg80211_mutex and the call to set_regdom.
      Reported-by: default avatarJiri Slaby <jirislaby@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      368d06f5
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  12. 01 Feb, 2010 2 commits
  13. 15 Jan, 2010 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: make regulatory_hint_11d() band specific · 84920e3e
      Luis R. Rodriguez authored
      
      
      In practice APs do not send country IE channel triplets for channels
      the AP is not operating on and if they were to do so they would have
      to use the regulatory extension which we currently do not process.
      No AP has been seen in practice that does this though so just drop
      those country IEs.
      
      Additionally it has been noted the first series of country IE
      channels triplets are specific to the band the AP sends. Propagate
      the band on which the country IE was found on reject the country
      IE then if the triplets are ever oustide of the band.
      
      Although we now won't process country IE information with multiple
      band information we leave the intersection work as is as it is
      technically possible for someone to want to eventually process these
      type of country IEs with regulatory extensions.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      84920e3e
  14. 14 Jan, 2010 2 commits
  15. 12 Jan, 2010 3 commits
  16. 05 Jan, 2010 2 commits
  17. 04 Jan, 2010 1 commit
  18. 28 Dec, 2009 1 commit
  19. 21 Dec, 2009 1 commit
  20. 10 Dec, 2009 1 commit
  21. 04 Dec, 2009 1 commit
    • Kalle Valo's avatar
      cfg80211: indent regulatory messages with spaces · 269ac5fd
      Kalle Valo authored
      
      
      The regulatory messages in syslog look weird:
      
      kernel: cfg80211: Regulatory domain: US
      kernel: ^I(start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
      kernel: ^I(2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
      kernel: ^I(5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
      kernel: ^I(5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
      kernel: ^I(5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
      kernel: ^I(5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
      kernel: ^I(5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
      
      Indent them with four spaces instead of the tab character to get prettier
      output.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Acked: Luis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      269ac5fd
  22. 19 Nov, 2009 1 commit
  23. 14 Aug, 2009 2 commits
  24. 04 Aug, 2009 4 commits
    • Luis R. Rodriguez's avatar
      cfg80211: enable country IE support to all cfg80211 drivers · 8b19e6ca
      Luis R. Rodriguez authored
      
      
      Since the bss is always set now once we are connected, if the
      bss has its own information element we refer to it and pass that
      instead of relying on mac80211's parsing.
      
      Now all cfg80211 drivers get country IE support, automatically and
      we reduce the call overhead that we had on mac80211 which called this
      upon every beacon and instead now call this only upon a successfull
      connection by a STA on cfg80211.
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      8b19e6ca
    • Luis R. Rodriguez's avatar
      cfg80211: decouple regulatory variables from cfg80211_mutex · abc7381b
      Luis R. Rodriguez authored
      
      
      We change regulatory code to be protected by its own regulatory
      mutex and alleviate cfg80211_mutex to only be used to protect
      cfg80211_rdev_list, the registered device list.
      
      By doing this we will be able to work on regulatory core components
      without having to have hog up the cfg80211_mutex. An example here is
      we no longer need to use the cfg80211_mutex during driver specific
      wiphy_apply_custom_regulatory(). We also no longer need it for the
      the country IE regulatory hint; by doing so we end up curing this
      new lockdep warning:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.31-rc4-wl #12
      -------------------------------------------------------
      phy1/1709 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<ffffffffa00af852>] regulatory_hint_11d+0x32/0x3f0 [cfg80211]
      
      but task is already holding lock:
       (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #3 (&ifmgd->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa0141bb8>] ieee80211_mgd_auth+0x108/0x1f0 [mac80211]
             [<ffffffffa0148563>] ieee80211_auth+0x13/0x20 [mac80211]
             [<ffffffffa00bc3a1>] __cfg80211_mlme_auth+0x1b1/0x2a0 [cfg80211]
             [<ffffffffa00bc516>] cfg80211_mlme_auth+0x86/0xc0 [cfg80211]
             [<ffffffffa00b368d>] nl80211_authenticate+0x21d/0x230 [cfg80211]
             [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
             [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
             [<ffffffff814169d9>] genl_rcv+0x29/0x40
             [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
             [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
             [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
             [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #2 (&wdev->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa00ab304>] cfg80211_netdev_notifier_call+0x1a4/0x390 [cfg80211]
             [<ffffffff814f3dff>] notifier_call_chain+0x3f/0x80
             [<ffffffff81075a91>] raw_notifier_call_chain+0x11/0x20
             [<ffffffff813f665a>] dev_open+0x10a/0x120
             [<ffffffff813f59bd>] dev_change_flags+0x9d/0x1e0
             [<ffffffff8144eb6e>] devinet_ioctl+0x6fe/0x760
             [<ffffffff81450204>] inet_ioctl+0x94/0xc0
             [<ffffffff813e25fa>] sock_ioctl+0x6a/0x290
             [<ffffffff8111e911>] vfs_ioctl+0x31/0xa0
             [<ffffffff8111ea9a>] do_vfs_ioctl+0x8a/0x5c0
             [<ffffffff8111f069>] sys_ioctl+0x99/0xa0
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      -> #1 (&rdev->mtx){+.+.+.}:
             [<ffffffff810857b6>] __lock_acquire+0xd76/0x12b0
             [<ffffffff81085dd3>] lock_acquire+0xe3/0x120
             [<ffffffff814eeae4>] mutex_lock_nested+0x44/0x350
             [<ffffffffa00ac4d0>] cfg80211_get_dev_from_ifindex+0x60/0x90 [cfg80211]
             [<ffffffffa00b21ff>] get_rdev_dev_by_info_ifindex+0x6f/0xa0 [cfg80211]
             [<ffffffffa00b51eb>] nl80211_set_interface+0x3b/0x260 [cfg80211]
             [<ffffffff81416ba6>] genl_rcv_msg+0x1b6/0x1f0
             [<ffffffff81415c39>] netlink_rcv_skb+0x89/0xb0
             [<ffffffff814169d9>] genl_rcv+0x29/0x40
             [<ffffffff8141591d>] netlink_unicast+0x29d/0x2b0
             [<ffffffff81416514>] netlink_sendmsg+0x214/0x300
             [<ffffffff813e4407>] sock_sendmsg+0x107/0x130
             [<ffffffff813e45b9>] sys_sendmsg+0x189/0x320
             [<ffffffff81011f82>] system_call_fastpath+0x16/0x1b
             [<ffffffffffffffff>] 0xffffffffffffffff
      
      other info that might help us debug this:
      
      3 locks held by phy1/1709:
       #0:  ((wiphy_name(local->hw.wiphy))){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
       #1:  (&ifmgd->work){+.+.+.}, at: [<ffffffff8106b45d>] worker_thread+0x19d/0x340
       #2:  (&ifmgd->mtx){+.+.+.}, at: [<ffffffffa0144228>] ieee80211_sta_work+0x108/0x10f0 [mac80211]
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      abc7381b
    • Luis R. Rodriguez's avatar
      cfg80211: do not iterate over rdev list on country IE hint · 4b44c8bc
      Luis R. Rodriguez authored
      
      
      Simplify the country IE hint code by just bailing out if
      a previous country IE has been issued. We currently just trust
      the first AP we connect to on any card. The idea was to perform
      conflict resolution within this routine but since we can no longer
      iterate over the registered device list here we leave conflict
      resolution to be dealt with at a later time on the workqueue.
      
      This code has no functional changes other than saving us an
      interation over the registered device list when a second card
      is connected, or you unplug and connect the same one, and a
      country IE is received. This would have been done upon every
      beacon received.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      4b44c8bc
    • Luis R. Rodriguez's avatar
      9828b017
  25. 03 Aug, 2009 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: fix regression on beacon world roaming feature · 37184244
      Luis R. Rodriguez authored
      A regression was added through patch a4ed90d6
      
      :
      
      "cfg80211: respect API on orig_flags on channel for beacon hint"
      
      We did indeed respect _orig flags but the intention was not clearly
      stated in the commit log. This patch fixes firmware issues picked
      up by iwlwifi when we lift passive scan of beaconing restrictions
      on channels its EEPROM has been configured to always enable.
      
      By doing so though we also disallowed beacon hints on devices
      registering their wiphy with custom world regulatory domains
      enabled, this happens to be currently ath5k, ath9k and ar9170.
      The passive scan and beacon restrictions on those devices would
      never be lifted even if we did find a beacon and the hardware did
      support such enhancements when world roaming.
      
      Since Johannes indicates iwlwifi firmware cannot be changed to
      allow beacon hinting we set up a flag now to specifically allow
      drivers to disable beacon hints for devices which cannot use them.
      
      We enable the flag on iwlwifi to disable beacon hints and by default
      enable it for all other drivers. It should be noted beacon hints lift
      passive scan flags and beacon restrictions when we receive a beacon from
      an AP on any 5 GHz non-DFS channels, and channels 12-14 on the 2.4 GHz
      band. We don't bother with channels 1-11 as those channels are allowed
      world wide.
      
      This should fix world roaming for ath5k, ath9k and ar9170, thereby
      improving scan time when we receive the first beacon from any AP,
      and also enabling beaconing operation (AP/IBSS/Mesh) on cards which
      would otherwise not be allowed to do so. Drivers not using custom
      regulatory stuff (wiphy_apply_custom_regulatory()) were not affected
      by this as the orig_flags for the channels would have been cleared
      upon wiphy registration.
      
      I tested this with a world roaming ath5k card.
      
      Cc: Jouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      37184244
  26. 24 Jul, 2009 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: treat ieee80211_regdom hints as user hints · ae9e4b0d
      Luis R. Rodriguez authored
      
      
      We were treating ieee80211_regdom module parameter hints
      as core hints, this means we were not letting the user help
      compliance further when using the module parameter. It also
      meant that users with a device with a custom regulatory
      domain set (wiphy->custom_regulatory) using this module
      parameter were being stuck to the original default core
      static regualtory domain. We fix this by using the static
      cfg80211_regdomain alpha2 as the core hint and treating the
      module parameter separately.
      
      All iwlwifi and ath5k/ath9k/ar9170 devices which world roam
      set the wiphy->custom_regulatory. This change allows users
      using this module parameter to have it trated as a a proper
      user hint and not have it ignored.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Acked-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      ae9e4b0d
  27. 10 Jul, 2009 1 commit