1. 09 7月, 2012 1 次提交
    • J
      nl80211: prepare for non-netdev wireless devs · 89a54e48
      Johannes Berg 提交于
      In order to support a P2P device abstraction and
      Bluetooth high-speed AMPs, we need to have a way
      to identify virtual interfaces that don't have a
      netdev associated.
      
      Do this by adding a NL80211_ATTR_WDEV attribute
      to identify a wdev which may or may not also be
      a netdev.
      
      To simplify things, use a 64-bit value with the
      high 32 bits being the wiphy index for this new
      wdev identifier in the nl80211 API.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      89a54e48
  2. 08 7月, 2012 1 次提交
  3. 04 7月, 2012 1 次提交
  4. 02 7月, 2012 1 次提交
  5. 29 6月, 2012 6 次提交
  6. 27 6月, 2012 1 次提交
  7. 20 6月, 2012 1 次提交
  8. 17 5月, 2012 1 次提交
  9. 17 4月, 2012 1 次提交
    • J
      cfg80211: enforce lack of interface combinations · 8e8b41f9
      Johannes Berg 提交于
      My grand plan to allow drivers to gradually move over
      to advertising virtual interface combinations and only
      enforce with drivers that do want it enforced doesn't
      seem to be working out, only Christian ever added the
      advertising (to carl9170), nobody else did.
      
      Begin enforcing combinations in cfg80211 so that users
      can rely on the information reported about a device.
      
      Cc: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
      Cc: Jouni Malinen <jouni@qca.qualcomm.com>
      Cc: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
      Cc: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Kalle Valo <kvalo@qca.qualcomm.com>
      Cc: Jiri Slaby <jirislaby@gmail.com>
      Cc: Nick Kossifidis <mickflemm@gmail.com>
      Cc: Bob Copeland <me@bobcopeland.com>
      Cc: Bing Zhao <bzhao@marvell.com>
      Cc: Lennert Buytenhek <buytenh@wantstofly.org>
      Cc: Ivo van Doorn <IvDoorn@gmail.com>
      Cc: Gertjan van Wingerde <gwingerde@gmail.com>
      Cc: Helmut Schaa <helmut.schaa@googlemail.com>
      Cc: Luciano Coelho <coelho@ti.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e8b41f9
  10. 12 4月, 2012 1 次提交
  11. 10 11月, 2011 1 次提交
  12. 15 9月, 2011 1 次提交
  13. 23 8月, 2011 1 次提交
    • S
      mac80211: fix suspend/resume races with unregister hw · ecb44335
      Stanislaw Gruszka 提交于
      Do not call ->suspend, ->resume methods after we unregister wiphy. Also
      delete sta_clanup timer after we finish wiphy unregister to avoid this:
      
      WARNING: at lib/debugobjects.c:262 debug_print_object+0x85/0xa0()
      Hardware name: 6369CTO
      ODEBUG: free active (active state 0) object type: timer_list hint: sta_info_cleanup+0x0/0x180 [mac80211]
      Modules linked in: aes_i586 aes_generic fuse bridge stp llc autofs4 sunrpc cpufreq_ondemand acpi_cpufreq mperf ext2 dm_mod uinput thinkpad_acpi hwmon sg arc4 rt2800usb rt2800lib crc_ccitt rt2x00usb rt2x00lib mac80211 cfg80211 i2c_i801 iTCO_wdt iTCO_vendor_support e1000e ext4 mbcache jbd2 sd_mod crc_t10dif sr_mod cdrom yenta_socket ahci libahci pata_acpi ata_generic ata_piix i915 drm_kms_helper drm i2c_algo_bit video [last unloaded: microcode]
      Pid: 5663, comm: pm-hibernate Not tainted 3.1.0-rc1-wl+ #19
      Call Trace:
       [<c0454cfd>] warn_slowpath_common+0x6d/0xa0
       [<c05e05e5>] ? debug_print_object+0x85/0xa0
       [<c05e05e5>] ? debug_print_object+0x85/0xa0
       [<c0454dae>] warn_slowpath_fmt+0x2e/0x30
       [<c05e05e5>] debug_print_object+0x85/0xa0
       [<f8a808e0>] ? sta_info_alloc+0x1a0/0x1a0 [mac80211]
       [<c05e0bd2>] debug_check_no_obj_freed+0xe2/0x180
       [<c051175b>] kfree+0x8b/0x150
       [<f8a126ae>] cfg80211_dev_free+0x7e/0x90 [cfg80211]
       [<f8a13afd>] wiphy_dev_release+0xd/0x10 [cfg80211]
       [<c068d959>] device_release+0x19/0x80
       [<c05d06ba>] kobject_release+0x7a/0x1c0
       [<c07646a8>] ? rtnl_unlock+0x8/0x10
       [<f8a13adb>] ? wiphy_resume+0x6b/0x80 [cfg80211]
       [<c05d0640>] ? kobject_del+0x30/0x30
       [<c05d1a6d>] kref_put+0x2d/0x60
       [<c05d056d>] kobject_put+0x1d/0x50
       [<c08015f4>] ? mutex_lock+0x14/0x40
       [<c068d60f>] put_device+0xf/0x20
       [<c069716a>] dpm_resume+0xca/0x160
       [<c04912bd>] hibernation_snapshot+0xcd/0x260
       [<c04903df>] ? freeze_processes+0x3f/0x90
       [<c049151b>] hibernate+0xcb/0x1e0
       [<c048fdc0>] ? pm_async_store+0x40/0x40
       [<c048fe60>] state_store+0xa0/0xb0
       [<c048fdc0>] ? pm_async_store+0x40/0x40
       [<c05d0200>] kobj_attr_store+0x20/0x30
       [<c0575ea4>] sysfs_write_file+0x94/0xf0
       [<c051e26a>] vfs_write+0x9a/0x160
       [<c0575e10>] ? sysfs_open_file+0x200/0x200
       [<c051e3fd>] sys_write+0x3d/0x70
       [<c080959f>] sysenter_do_call+0x12/0x28
      
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ecb44335
  14. 21 7月, 2011 1 次提交
  15. 16 7月, 2011 1 次提交
  16. 06 7月, 2011 1 次提交
    • L
      cfg80211: fix deadlock with rfkill/sched_scan by adding new mutex · c10841ca
      Luciano Coelho 提交于
      There was a deadlock when rfkill-blocking a wireless interface,
      because we were locking the rdev mutex on NETDEV_GOING_DOWN to stop
      sched_scans that were eventually running.  The rfkill block code was
      already holding a mutex under rdev:
      
      kernel: =======================================================
      kernel: [ INFO: possible circular locking dependency detected ]
      kernel: 3.0.0-rc1-00049-g1fa7b6a2 #57
      kernel: -------------------------------------------------------
      kernel: kworker/0:1/4525 is trying to acquire lock:
      kernel: (&rdev->mtx){+.+.+.}, at: [<ffffffff8164c831>] cfg80211_netdev_notifier_call+0x131/0x5b0
      kernel:
      kernel: but task is already holding lock:
      kernel: (&rdev->devlist_mtx){+.+.+.}, at: [<ffffffff8164dcef>] cfg80211_rfkill_set_block+0x4f/0xa0
      kernel:
      kernel: which lock already depends on the new lock.
      
      To fix this, add a new mutex specifically for sched_scan, to protect
      the sched_scan_req element in the rdev struct, instead of using the
      global rdev mutex.
      Reported-by: NDuane Griffin <duaneg@dghda.com>
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      c10841ca
  17. 17 5月, 2011 1 次提交
    • J
      cfg80211: advertise possible interface combinations · 7527a782
      Johannes Berg 提交于
      Add the ability to advertise interface combinations in nl80211.
      This allows the driver to indicate what the combinations are
      that it supports. "Combinations" of just a single interface are
      implicit, as previously. Note that cfg80211 will enforce that
      the restrictions are met, but not for all drivers yet (once all
      drivers are updated, we can remove the flag and enforce for all).
      
      When no combinations are actually supported, an empty list will
      be exported so that userspace can know if the kernel exported
      this info or not (although it isn't clear to me what tools using
      the info should do if the kernel didn't export it).
      
      Since some interface types are purely virtual/software and don't
      fit the restrictions, those are exposed in a new list of pure SW
      types, not subject to restrictions. This mainly exists to handle
      AP-VLAN and monitor interfaces in mac80211.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7527a782
  18. 13 5月, 2011 2 次提交
  19. 12 5月, 2011 1 次提交
    • L
      cfg80211/nl80211: add support for scheduled scans · 807f8a8c
      Luciano Coelho 提交于
      Implement new functionality for scheduled scan offload.  With this feature we
      can scan automatically at certain intervals.
      
      The idea is that the hardware can perform scan automatically and filter on
      desired results without waking up the host unnecessarily.
      
      Add NL80211_CMD_START_SCHED_SCAN and NL80211_CMD_STOP_SCHED_SCAN
      commands to the nl80211 interface.  When results are available they are
      reported by NL80211_CMD_SCHED_SCAN_RESULTS events.  The userspace is
      informed when the scheduled scan has stopped with a
      NL80211_CMD_SCHED_SCAN_STOPPED event, which can be triggered either by
      the driver or by a call to NL80211_CMD_STOP_SCHED_SCAN.
      Signed-off-by: NLuciano Coelho <coelho@ti.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      807f8a8c
  20. 06 5月, 2011 1 次提交
  21. 26 4月, 2011 1 次提交
  22. 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
  23. 21 12月, 2010 1 次提交
  24. 07 12月, 2010 1 次提交
    • J
      cfg80211/mac80211: add mesh join/leave commands · 29cbe68c
      Johannes Berg 提交于
      Instead of tying mesh activity to interface up,
      add join and leave commands for mesh. Since we
      must be backward compatible, let cfg80211 handle
      joining a mesh if a mesh ID was pre-configured
      when the device goes up.
      
      Note that this therefore must modify mac80211 as
      well since mac80211 needs to lose the logic to
      start the mesh on interface up.
      
      We now allow querying mesh parameters before the
      mesh is connected, which simply returns defaults.
      Setting them (internally renamed to "update") is
      only allowed while connected. Specify them with
      the new mesh join command instead where needed.
      
      In mac80211, beaconing must now also follow the
      mesh enabled/not enabled state, which is done
      by testing the mesh ID.
      Signed-off-by: NJavier Cardona <javier@cozybit.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      29cbe68c
  25. 25 11月, 2010 1 次提交
  26. 12 10月, 2010 1 次提交
  27. 06 10月, 2010 1 次提交
  28. 17 9月, 2010 2 次提交
  29. 01 9月, 2010 1 次提交
    • J
      wireless: register wiphy rfkill w/o holding cfg80211_mutex · c3d34d5d
      John W. Linville 提交于
      Otherwise lockdep complains...
      
      https://bugzilla.kernel.org/show_bug.cgi?id=17311
      
      [ INFO: possible circular locking dependency detected ]
      2.6.36-rc2-git4 #12
      -------------------------------------------------------
      kworker/0:3/3630 is trying to acquire lock:
       (rtnl_mutex){+.+.+.}, at: [<ffffffff813396c7>] rtnl_lock+0x12/0x14
      
      but task is already holding lock:
       (rfkill_global_mutex){+.+.+.}, at: [<ffffffffa014b129>]
      rfkill_switch_all+0x24/0x49 [rfkill]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (rfkill_global_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa014b4ab>] rfkill_register+0x2b/0x29c [rfkill]
             [<ffffffffa0185ba0>] wiphy_register+0x1ae/0x270 [cfg80211]
             [<ffffffffa0206f01>] ieee80211_register_hw+0x1b4/0x3cf [mac80211]
             [<ffffffffa0292e98>] iwl_ucode_callback+0x9e9/0xae3 [iwlagn]
             [<ffffffff812d3e9d>] request_firmware_work_func+0x54/0x6f
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      
      -> #1 (cfg80211_mutex){+.+.+.}:
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffffa018605e>] cfg80211_get_dev_from_ifindex+0x1b/0x7c [cfg80211]
             [<ffffffffa0189f36>] cfg80211_wext_giwscan+0x58/0x990 [cfg80211]
             [<ffffffff8139a3ce>] ioctl_standard_iw_point+0x1a8/0x272
             [<ffffffff8139a529>] ioctl_standard_call+0x91/0xa7
             [<ffffffff8139a687>] T.723+0xbd/0x12c
             [<ffffffff8139a727>] wext_handle_ioctl+0x31/0x6d
             [<ffffffff8133014e>] dev_ioctl+0x63d/0x67a
             [<ffffffff8131afd9>] sock_ioctl+0x48/0x21d
             [<ffffffff81102abd>] do_vfs_ioctl+0x4ba/0x509
             [<ffffffff81102b5d>] sys_ioctl+0x51/0x74
             [<ffffffff81009e02>] system_call_fastpath+0x16/0x1b
      
      -> #0 (rtnl_mutex){+.+.+.}:
             [<ffffffff810796b0>] __lock_acquire+0xa93/0xd9a
             [<ffffffff81079ad7>] lock_acquire+0x120/0x15b
             [<ffffffff813ae869>] __mutex_lock_common+0x54/0x52e
             [<ffffffff813aede9>] mutex_lock_nested+0x34/0x39
             [<ffffffff813396c7>] rtnl_lock+0x12/0x14
             [<ffffffffa0185cb5>] cfg80211_rfkill_set_block+0x1a/0x7b [cfg80211]
             [<ffffffffa014aed0>] rfkill_set_block+0x80/0xd5 [rfkill]
             [<ffffffffa014b07e>] __rfkill_switch_all+0x3f/0x6f [rfkill]
             [<ffffffffa014b13d>] rfkill_switch_all+0x38/0x49 [rfkill]
             [<ffffffffa014b821>] rfkill_op_handler+0x105/0x136 [rfkill]
             [<ffffffff81060708>] process_one_work+0x248/0x403
             [<ffffffff81062620>] worker_thread+0x139/0x214
             [<ffffffff81065d15>] kthread+0x8c/0x94
             [<ffffffff8100ac24>] kernel_thread_helper+0x4/0x10
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      Acked-by: NJohannes Berg <johannes@sipsolutions.net>
      c3d34d5d
  30. 25 8月, 2010 1 次提交
  31. 17 8月, 2010 1 次提交
  32. 28 7月, 2010 1 次提交
    • J
      wireless: Convert wiphy_debug macro to function · 073730d7
      Joe Perches 提交于
      Save a few bytes of text
      
      (allyesconfig)
      $ size drivers/net/wireless/built-in.o*
         text	   data	    bss	    dec	    hex	filename
      3924568	 100548	 871056	4896172	 4ab5ac	drivers/net/wireless/built-in.o.new
      3926520	 100548	 871464	4898532	 4abee4	drivers/net/wireless/built-in.o.old
      
      $ size net/wireless/core.o*
         text	   data	    bss	    dec	    hex	filename
        12843	    216	   3768	  16827	   41bb	net/wireless/core.o.new
        12328	    216	   3656	  16200	   3f48	net/wireless/core.o
      Signed-off-by: NJoe Perches <joe@perches.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      073730d7
  33. 22 7月, 2010 1 次提交