1. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      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: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  2. 20 2月, 2010 1 次提交
    • K
      nl80211: add power save commands · ffb9eb3d
      Kalle Valo 提交于
      The most needed command from nl80211, which Wireless Extensions had,
      is support for power save mode. Add a simple command to make it possible
      to enable and disable power save via nl80211.
      
      I was also planning about extending the interface, for example adding the
      timeout value, but after thinking more about this I decided not to do it.
      Basically there were three reasons:
      
      Firstly, the parameters for power save are very much hardware dependent.
      Trying to find a unified interface which would work with all hardware, and
      still make sense to users, will be very difficult.
      
      Secondly, IEEE 802.11 power save implementation in Linux is still in state
      of flux. We have a long way to still to go and there is no way to predict
      what kind of implementation we will have after few years. And because we
      need to support nl80211 interface a long time, practically forever, adding
      now parameters to nl80211 might create maintenance problems later on.
      
      Third issue are the users. Power save parameters are mostly used for
      debugging, so debugfs is better, more flexible, interface for this.
      For example, wpa_supplicant currently doesn't configure anything related
      to power save mode. It's better to strive that kernel can automatically
      optimise the power save parameters, like with help of pm qos network
      and other traffic parameters.
      
      Later on, when we have better understanding of power save, we can extend
      this command with more features, if there's a need for that.
      Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ffb9eb3d
  3. 19 2月, 2010 1 次提交
  4. 16 2月, 2010 2 次提交
  5. 09 2月, 2010 1 次提交
  6. 03 2月, 2010 2 次提交
  7. 02 2月, 2010 2 次提交
  8. 28 1月, 2010 1 次提交
  9. 27 1月, 2010 1 次提交
  10. 23 1月, 2010 2 次提交
    • A
      mac80211: Account HT Control field in Data frame hdrlen according to 802.11n-2009 · d0dd2de0
      Andriy Tkachuk 提交于
      ieee80211_hdrlen() should account account new HT Control field in 802.11
      data frame header introduced by IEEE 802.11n standard.
      
      According to 802.11n-2009 HT Control field is present in data frames
      when both of following are met:
      
         1. It is QoS data frame.
         2. Order bit is set in Frame Control field.
      
      The change might be totally compatible with legacy non-11n aware frames,
      because 802.11-2007 standard states that "all QoS STAs set this subfield
      to 0".
      Signed-off-by: NAndriy V. Tkachuk <andrit@ukr.net>
      Acked-by : Benoit Papillault <benoit.papillault@free.fr>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d0dd2de0
    • J
      cfg80211: export multiple MAC addresses in sysfs · ef15aac6
      Johannes Berg 提交于
      If a device has multiple MAC addresses, userspace will
      need to know about that. Similarly, if it allows the
      MAC addresses to vary by a bitmask.
      
      If a driver exports multiple addresses, it is assumed
      that it will be able to deal with that many different
      addresses, which need not necessarily match the ones
      programmed into the device; if a mask is set then the
      device should deal addresses within that mask based
      on an arbitrary "base address".
      
      To test it all and show how it is used, add support
      to hwsim even though it can't actually deal with
      addresses different from the default.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ef15aac6
  11. 20 1月, 2010 2 次提交
  12. 18 1月, 2010 1 次提交
  13. 16 1月, 2010 1 次提交
    • L
      cfg80211: make regulatory_hint_11d() band specific · 84920e3e
      Luis R. Rodriguez 提交于
      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: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      84920e3e
  14. 15 1月, 2010 3 次提交
  15. 13 1月, 2010 7 次提交
  16. 12 1月, 2010 1 次提交
  17. 06 1月, 2010 2 次提交
  18. 05 1月, 2010 1 次提交
  19. 29 12月, 2009 5 次提交
    • J
      mac80211/cfg80211: add station events · 98b62183
      Johannes Berg 提交于
      When, for instance, a new IBSS peer is found, userspace
      wants to be notified. Add events for all new stations
      that mac80211 learns about.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      98b62183
    • J
      cfg80211: add remain-on-channel command · 9588bbd5
      Jouni Malinen 提交于
      Add new commands for requesting the driver to remain awake
      on a specified channel for the specified amount of time
      (and another command to cancel such an operation). This
      can be used to implement userspace-controlled off-channel
      operations, like Public Action frame exchange on another
      channel than the operation channel.
      
      The off-channel operation should behave similarly to scan,
      i.e. the local station (if associated) moves into power
      save mode to request the AP to buffer frames for it and
      then moves to the other channel to allow the off-channel
      operation to be completed. The duration parameter can be
      used to request enough time to receive a response from
      the target station.
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9588bbd5
    • J
      wireless: remove CONFIG_WIRELESS_OLD_REGULATORY · baeb66fe
      John W. Linville 提交于
      This is no longer needed with the availability of
      CONFIG_CFG80211_INTERNAL_REGDB.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      baeb66fe
    • J
      cfg80211: fix error path in cfg80211_wext_siwscan · 65486c8b
      Johannes Berg 提交于
      If there's an invalid channel or SSID, the code leaks
      the scan request. Always free the scan request, unless
      it was successfully given to the driver.
      Reported-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Acked-by: NDan Carpenter <error27@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      65486c8b
    • J
      cfg80211: fix race between deauth and assoc response · 3bdb2d48
      Johannes Berg 提交于
      Joseph Nahmias reported, in http://bugs.debian.org/562016,
      that he was getting the following warning (with some log
      around the issue):
      
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: direct probe responded
        ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: authenticated
        ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: RX AssocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
        ath0: associated
        ------------[ cut here ]------------
        WARNING: at net/wireless/mlme.c:97 cfg80211_send_rx_assoc+0x14d/0x152 [cfg80211]()
        Hardware name: 7658CTO
        ...
        Pid: 761, comm: phy0 Not tainted 2.6.32-trunk-686 #1
        Call Trace:
         [<c1030a5d>] ? warn_slowpath_common+0x5e/0x8a
         [<c1030a93>] ? warn_slowpath_null+0xa/0xc
         [<f86cafc7>] ? cfg80211_send_rx_assoc+0x14d/0x152
        ...
        ath0: link becomes ready
        ath0: deauthenticating from 00:11:95:77:e0:b0 by local choice (reason=3)
        ath0: no IPv6 routers present
        ath0: link is not ready
        ath0: direct probe to AP 00:11:95:77:e0:b0 (try 1)
        ath0: direct probe responded
        ath0: authenticate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: authenticated
        ath0: associate with AP 00:11:95:77:e0:b0 (try 1)
        ath0: RX ReassocResp from 00:11:95:77:e0:b0 (capab=0x421 status=0 aid=2)
        ath0: associated
      
      It is not clear to me how the first "direct probe" here
      happens, but this seems to be a race condition, if the
      user requests to deauth after requesting assoc, but before
      the assoc response is received. In that case, it may
      happen that mac80211 tries to report the assoc success to
      cfg80211, but gets blocked on the wdev lock that is held
      because the user is requesting the deauth.
      
      The result is that we run into a warning. This is mostly
      harmless, but maybe cause an unexpected event to be sent
      to userspace; we'd send an assoc success event although
      userspace was no longer expecting that.
      
      To fix this, remove the warning and check whether the
      race happened and in that case abort processing.
      Reported-by: NJoseph Nahmias <joe@nahmias.net>
      Cc: stable@kernel.org
      Cc: 562016-quiet@bugs.debian.org
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3bdb2d48
  20. 26 12月, 2009 1 次提交
  21. 23 12月, 2009 2 次提交
    • J
      cfg80211: avoid sending spurious deauth to userspace · 5fba4af3
      Johannes Berg 提交于
      Before
        commit ca9034592823e8179511e48a78731f95bfdd766c
        Author: Holger Schurig <hs4233@mail.mn-solutions.de>
        Date:   Tue Oct 13 13:45:28 2009 +0200
      
            cfg80211: remove warning in deauth case
      
      we assumed that drivers never give us spurious deauth
      frames because they filter them out based on the auth
      state they keep track of. This turned out to be racy,
      because userspace might deauth while the AP is also
      sending a deauth frame, so the warning was removed.
      
      However, in that case we should not tell userspace
      about the AP's frame if it requested deauth "first",
      where "first" means it came to cfg80211 first.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5fba4af3
    • Z
      wireless: add ieee80211_amsdu_to_8023s · eaf85ca7
      Zhu Yi 提交于
      Move the A-MSDU handling code from mac80211 to cfg80211 so that more
      drivers can use it. The new created function ieee80211_amsdu_to_8023s
      converts an A-MSDU frame to a list of 802.3 frames.
      
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NZhu Yi <yi.zhu@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      eaf85ca7