1. 12 5月, 2011 9 次提交
  2. 11 5月, 2011 1 次提交
  3. 06 5月, 2011 2 次提交
    • J
      nl80211/cfg80211: WoWLAN support · ff1b6e69
      Johannes Berg 提交于
      This is based on (but now quite far from) the
      original work from Luis and Eliad. Add support
      for configuring WoWLAN triggers, and getting
      the configuration out again. Changes from the
      original patchset are too numerous to list,
      but one important change needs highlighting:
      the suspend() callback is passed NULL for the
      trigger configuration if userspace has not
      configured WoWLAN at all.
      Signed-off-by: NLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ff1b6e69
    • J
      nl80211: Fix set_key regression with some drivers · 0e579d6a
      Jouni Malinen 提交于
      Commit dbd2fd65 added a mechanism for
      user space to indicate whether a default key is being configured for
      only unicast or only multicast frames instead of all frames. This
      commit added a driver capability flag for indicating whether separate
      default keys are supported and validation of the set_key command based
      on that capability.
      
      However, this single capability flag is not enough to cover possible
      difference based on mode (AP/IBSS/STA) and the way this change was
      introduced resulted in a regression with drivers that do not indicate
      the new capability (i.e.., more or less any non-mac80211 driver using
      cfg80211) when using a recent wpa_supplicant snapshot.
      
      Fix the regression by removing the new check which is not strictly
      speaking needed. The new separate default key functionality is needed
      only for RSN IBSS which has a separate capability indication.
      
      Cc: stable@kernel.org
      Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0e579d6a
  4. 27 4月, 2011 1 次提交
  5. 26 4月, 2011 1 次提交
  6. 13 4月, 2011 7 次提交
  7. 08 4月, 2011 3 次提交
  8. 31 3月, 2011 1 次提交
  9. 29 3月, 2011 2 次提交
  10. 12 3月, 2011 1 次提交
  11. 10 3月, 2011 1 次提交
  12. 02 3月, 2011 1 次提交
  13. 22 2月, 2011 1 次提交
    • D
      fix cfg80211_wext_siwfreq lock ordering... · 4f919a3b
      Daniel J Blueman 提交于
      I previously managed to reproduce a hang while scanning wireless
      channels (reproducible with airodump-ng hopping channels); subsequent
      lockdep instrumentation revealed a lock ordering issue.
      
      Without knowing the design intent, it looks like the locks should be
      taken in reverse order; please comment.
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.38-rc5-341cd #4
      -------------------------------------------------------
      airodump-ng/15445 is trying to acquire lock:
       (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff816b1266>]
      cfg80211_wext_siwfreq+0xc6/0x100
      
      but task is already holding lock:
       (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>] cfg80211_wext_siwfreq+0xbc/0x100
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #1 (&wdev->mtx){+.+.+.}:
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff81696080>] cfg80211_netdev_notifier_call+0x430/0x5f0
             [<ffffffff8109351b>] notifier_call_chain+0x8b/0x100
             [<ffffffff810935b1>] raw_notifier_call_chain+0x11/0x20
             [<ffffffff81576d92>] call_netdevice_notifiers+0x32/0x60
             [<ffffffff815771a4>] __dev_notify_flags+0x34/0x80
             [<ffffffff81577230>] dev_change_flags+0x40/0x70
             [<ffffffff8158587c>] do_setlink+0x1fc/0x8d0
             [<ffffffff81586042>] rtnl_setlink+0xf2/0x140
             [<ffffffff81586923>] rtnetlink_rcv_msg+0x163/0x270
             [<ffffffff8159d741>] netlink_rcv_skb+0xa1/0xd0
             [<ffffffff815867b0>] rtnetlink_rcv+0x20/0x30
             [<ffffffff8159d39a>] netlink_unicast+0x2ba/0x300
             [<ffffffff8159dd57>] netlink_sendmsg+0x267/0x3e0
             [<ffffffff8155e364>] sock_sendmsg+0xe4/0x110
             [<ffffffff8155f3a3>] sys_sendmsg+0x253/0x3b0
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      -> #0 (&rdev->devlist_mtx){+.+.+.}:
             [<ffffffff810a7222>] __lock_acquire+0x1622/0x1d10
             [<ffffffff810a79d6>] lock_acquire+0xc6/0x280
             [<ffffffff816d6bce>] mutex_lock_nested+0x6e/0x4b0
             [<ffffffff816b1266>] cfg80211_wext_siwfreq+0xc6/0x100
             [<ffffffff816b2fad>] ioctl_standard_call+0x5d/0xd0
             [<ffffffff816b3223>] T.808+0x163/0x170
             [<ffffffff816b326a>] wext_handle_ioctl+0x3a/0x90
             [<ffffffff815798d2>] dev_ioctl+0x6f2/0x830
             [<ffffffff8155cf3d>] sock_ioctl+0xfd/0x290
             [<ffffffff8117dffd>] do_vfs_ioctl+0x9d/0x590
             [<ffffffff8117e53a>] sys_ioctl+0x4a/0x80
             [<ffffffff81003192>] system_call_fastpath+0x16/0x1b
      
      other info that might help us debug this:
      
      2 locks held by airodump-ng/15445:
       #0:  (rtnl_mutex){+.+.+.}, at: [<ffffffff81586782>] rtnl_lock+0x12/0x20
       #1:  (&wdev->mtx){+.+.+.}, at: [<ffffffff816b125c>]
      cfg80211_wext_siwfreq+0xbc/0x100
      
      stack backtrace:
      Pid: 15445, comm: airodump-ng Not tainted 2.6.38-rc5-341cd #4
      Call Trace:
       [<ffffffff810a3f0a>] ? print_circular_bug+0xfa/0x100
       [<ffffffff810a7222>] ? __lock_acquire+0x1622/0x1d10
       [<ffffffff810a1f99>] ? trace_hardirqs_off_caller+0x29/0xc0
       [<ffffffff810a79d6>] ? lock_acquire+0xc6/0x280
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816d6bce>] ? mutex_lock_nested+0x6e/0x4b0
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff810a31d7>] ? mark_held_locks+0x67/0x90
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b1266>] ? cfg80211_wext_siwfreq+0xc6/0x100
       [<ffffffff816b2fad>] ? ioctl_standard_call+0x5d/0xd0
       [<ffffffff8157818b>] ? __dev_get_by_name+0x9b/0xc0
       [<ffffffff816b2f50>] ? ioctl_standard_call+0x0/0xd0
       [<ffffffff816b3223>] ? T.808+0x163/0x170
       [<ffffffff8112ddf2>] ? might_fault+0x72/0xd0
       [<ffffffff816b326a>] ? wext_handle_ioctl+0x3a/0x90
       [<ffffffff8112de3b>] ? might_fault+0xbb/0xd0
       [<ffffffff815798d2>] ? dev_ioctl+0x6f2/0x830
       [<ffffffff810a1bae>] ? put_lock_stats+0xe/0x40
       [<ffffffff810a1c8c>] ? lock_release_holdtime+0xac/0x150
       [<ffffffff8155cf3d>] ? sock_ioctl+0xfd/0x290
       [<ffffffff8117dffd>] ? do_vfs_ioctl+0x9d/0x590
       [<ffffffff8116c8ff>] ? fget_light+0x1df/0x3c0
       [<ffffffff8117e53a>] ? sys_ioctl+0x4a/0x80
       [<ffffffff81003192>] ? system_call_fastpath+0x16/0x1b
      Signed-off-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4f919a3b
  14. 04 2月, 2011 1 次提交
    • J
      cfg80211: Fix power save state after interface type change · bf6a0579
      Juuso Oikarinen 提交于
      Currently cfg80211 only configures the PSM state to the driver upon creation
      of a new virtual interface, but not after interface type change. The mac80211
      on the other hand reinitializes its sdata structure every time the interface
      type is changed, losing the PSM configuration.
      
      Hence, if the interface type is changed to, say, ad-hoc and then back to
      managed, "iw wlan0 get power_save" will claim that PSM is enabled, when in
      fact on mac80211 level it is not.
      
      Fix this in cfg80211 by configuring the PSM state to the driver each time
      the interface is brought up instead of just when the interface is created.
      Signed-off-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bf6a0579
  15. 29 1月, 2011 2 次提交
  16. 22 1月, 2011 1 次提交
    • B
      cfg80211: Extend channel to frequency mapping for 802.11j · 59eb21a6
      Bruno Randolf 提交于
      Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
      IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
      channel numbers in the 2GHz and 5GHz band we can't map from channel to
      frequency without knowing the band. This is no problem as in most contexts we
      know the band. In places where we don't know the band (and WEXT compatibility)
      we assume the 2GHz band for channels below 14.
      
      This patch does not implement all channel to frequency mappings defined in
      802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
      channels as well as 802.11y channels have been omitted.
      
      The following drivers have been updated to reflect the API changes:
      iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
      The drivers have been compile-tested only.
      Signed-off-by: NBruno Randolf <br1@einfach.org>
      Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
      Acked-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59eb21a6
  17. 21 1月, 2011 1 次提交
    • D
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes 提交于
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a108a14
  18. 05 1月, 2011 1 次提交
  19. 21 12月, 2010 3 次提交