1. 12 11月, 2013 1 次提交
  2. 19 10月, 2013 1 次提交
    • S
      rt2x00: check if device is still available on rt2x00mac_flush() · 5671ab05
      Stanislaw Gruszka 提交于
      Fix random kernel panic with below messages when remove dongle.
      
      [ 2212.355447] BUG: unable to handle kernel NULL pointer dereference at 0000000000000250
      [ 2212.355527] IP: [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.355599] PGD 0
      [ 2212.355626] Oops: 0000 [#1] SMP
      [ 2212.355664] Modules linked in: rt2800usb rt2x00usb rt2800lib crc_ccitt rt2x00lib mac80211 cfg80211 tun arc4 fuse rfcomm bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec btusb uvcvideo bluetooth snd_hwdep x86_pkg_temp_thermal snd_seq coretemp aesni_intel aes_x86_64 snd_seq_device glue_helper snd_pcm ablk_helper videobuf2_vmalloc sdhci_pci videobuf2_memops videobuf2_core sdhci videodev mmc_core serio_raw snd_page_alloc microcode i2c_i801 snd_timer hid_multitouch thinkpad_acpi lpc_ich mfd_core snd tpm_tis wmi tpm tpm_bios soundcore acpi_cpufreq i915 i2c_algo_bit drm_kms_helper drm i2c_core video [last unloaded: cfg80211]
      [ 2212.356224] CPU: 0 PID: 34 Comm: khubd Not tainted 3.12.0-rc3-wl+ #3
      [ 2212.356268] Hardware name: LENOVO 3444CUU/3444CUU, BIOS G6ET93WW (2.53 ) 02/04/2013
      [ 2212.356319] task: ffff880212f687c0 ti: ffff880212f66000 task.ti: ffff880212f66000
      [ 2212.356392] RIP: 0010:[<ffffffffa02667f2>]  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.356481] RSP: 0018:ffff880212f67750  EFLAGS: 00010202
      [ 2212.356519] RAX: 000000000000000c RBX: 000000000000000c RCX: 0000000000000293
      [ 2212.356568] RDX: ffff8801f4dc219a RSI: 0000000000000000 RDI: 0000000000000240
      [ 2212.356617] RBP: ffff880212f67778 R08: ffffffffa02667e0 R09: 0000000000000002
      [ 2212.356665] R10: 0001f95254ab4b40 R11: ffff880212f675be R12: ffff8801f4dc2150
      [ 2212.356712] R13: 0000000000000000 R14: ffffffffa02667e0 R15: 000000000000000d
      [ 2212.356761] FS:  0000000000000000(0000) GS:ffff88021e200000(0000) knlGS:0000000000000000
      [ 2212.356813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [ 2212.356852] CR2: 0000000000000250 CR3: 0000000001a0c000 CR4: 00000000001407f0
      [ 2212.356899] Stack:
      [ 2212.356917]  000000000000000c ffff8801f4dc2150 0000000000000000 ffffffffa02667e0
      [ 2212.356980]  000000000000000d ffff880212f677b8 ffffffffa03a31ad ffff8801f4dc219a
      [ 2212.357038]  ffff8801f4dc2150 0000000000000000 ffff8800b93217a0 ffff8801f49bc800
      [ 2212.357099] Call Trace:
      [ 2212.357122]  [<ffffffffa02667e0>] ? rt2x00usb_interrupt_txdone+0x90/0x90 [rt2x00usb]
      [ 2212.357174]  [<ffffffffa03a31ad>] rt2x00queue_for_each_entry+0xed/0x170 [rt2x00lib]
      [ 2212.357244]  [<ffffffffa026701c>] rt2x00usb_kick_queue+0x5c/0x60 [rt2x00usb]
      [ 2212.357314]  [<ffffffffa03a3682>] rt2x00queue_flush_queue+0x62/0xa0 [rt2x00lib]
      [ 2212.357386]  [<ffffffffa03a2930>] rt2x00mac_flush+0x30/0x70 [rt2x00lib]
      [ 2212.357470]  [<ffffffffa04edded>] ieee80211_flush_queues+0xbd/0x140 [mac80211]
      [ 2212.357555]  [<ffffffffa0502e52>] ieee80211_set_disassoc+0x2d2/0x3d0 [mac80211]
      [ 2212.357645]  [<ffffffffa0506da3>] ieee80211_mgd_deauth+0x1d3/0x240 [mac80211]
      [ 2212.357718]  [<ffffffff8108b17c>] ? try_to_wake_up+0xec/0x290
      [ 2212.357788]  [<ffffffffa04dbd18>] ieee80211_deauth+0x18/0x20 [mac80211]
      [ 2212.357872]  [<ffffffffa0418ddc>] cfg80211_mlme_deauth+0x9c/0x140 [cfg80211]
      [ 2212.357913]  [<ffffffffa041907c>] cfg80211_mlme_down+0x5c/0x60 [cfg80211]
      [ 2212.357962]  [<ffffffffa041cd18>] cfg80211_disconnect+0x188/0x1a0 [cfg80211]
      [ 2212.358014]  [<ffffffffa04013bc>] ? __cfg80211_stop_sched_scan+0x1c/0x130 [cfg80211]
      [ 2212.358067]  [<ffffffffa03f8954>] cfg80211_leave+0xc4/0xe0 [cfg80211]
      [ 2212.358124]  [<ffffffffa03f8d1b>] cfg80211_netdev_notifier_call+0x3ab/0x5e0 [cfg80211]
      [ 2212.358177]  [<ffffffff815140f8>] ? inetdev_event+0x38/0x510
      [ 2212.358217]  [<ffffffff81085a94>] ? __wake_up+0x44/0x50
      [ 2212.358254]  [<ffffffff8155995c>] notifier_call_chain+0x4c/0x70
      [ 2212.358293]  [<ffffffff81081156>] raw_notifier_call_chain+0x16/0x20
      [ 2212.358361]  [<ffffffff814b6dd5>] call_netdevice_notifiers_info+0x35/0x60
      [ 2212.358429]  [<ffffffff814b6ec9>] __dev_close_many+0x49/0xd0
      [ 2212.358487]  [<ffffffff814b7028>] dev_close_many+0x88/0x100
      [ 2212.358546]  [<ffffffff814b8150>] rollback_registered_many+0xb0/0x220
      [ 2212.358612]  [<ffffffff814b8319>] unregister_netdevice_many+0x19/0x60
      [ 2212.358694]  [<ffffffffa04d8eb2>] ieee80211_remove_interfaces+0x112/0x190 [mac80211]
      [ 2212.358791]  [<ffffffffa04c585f>] ieee80211_unregister_hw+0x4f/0x100 [mac80211]
      [ 2212.361994]  [<ffffffffa03a1221>] rt2x00lib_remove_dev+0x161/0x1a0 [rt2x00lib]
      [ 2212.365240]  [<ffffffffa0266e2e>] rt2x00usb_disconnect+0x2e/0x70 [rt2x00usb]
      [ 2212.368470]  [<ffffffff81419ce4>] usb_unbind_interface+0x64/0x1c0
      [ 2212.371734]  [<ffffffff813b446f>] __device_release_driver+0x7f/0xf0
      [ 2212.374999]  [<ffffffff813b4503>] device_release_driver+0x23/0x30
      [ 2212.378131]  [<ffffffff813b3c98>] bus_remove_device+0x108/0x180
      [ 2212.381358]  [<ffffffff813b0565>] device_del+0x135/0x1d0
      [ 2212.384454]  [<ffffffff81417760>] usb_disable_device+0xb0/0x270
      [ 2212.387451]  [<ffffffff8140d9cd>] usb_disconnect+0xad/0x1d0
      [ 2212.390294]  [<ffffffff8140f6cd>] hub_thread+0x63d/0x1660
      [ 2212.393034]  [<ffffffff8107c860>] ? wake_up_atomic_t+0x30/0x30
      [ 2212.395728]  [<ffffffff8140f090>] ? hub_port_debounce+0x130/0x130
      [ 2212.398412]  [<ffffffff8107baa0>] kthread+0xc0/0xd0
      [ 2212.401058]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
      [ 2212.403639]  [<ffffffff8155de3c>] ret_from_fork+0x7c/0xb0
      [ 2212.406193]  [<ffffffff8107b9e0>] ? insert_kthread_work+0x40/0x40
      [ 2212.408732] Code: 24 58 08 00 00 bf 80 00 00 00 e8 3a c3 e0 e0 5b 41 5c 5d c3 0f 1f 44 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 41 56 41 55 41 54 53 <48> 8b 47 10 48 89 fb 4c 8b 6f 28 4c 8b 20 49 8b 04 24 4c 8b 30
      [ 2212.414671] RIP  [<ffffffffa02667f2>] rt2x00usb_kick_tx_entry+0x12/0x160 [rt2x00usb]
      [ 2212.417646]  RSP <ffff880212f67750>
      [ 2212.420547] CR2: 0000000000000250
      [ 2212.441024] ---[ end trace 5442918f33832bce ]---
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      5671ab05
  3. 15 10月, 2013 1 次提交
  4. 23 4月, 2013 1 次提交
    • J
      rt2x00: Use more current logging styles, shrink object size · ec9c4989
      Joe Perches 提交于
      Reduce object space ~2% using more current logging styles.
      
      Neaten and simplify logging macros.
      Use wiphy_<level> where appropriate.
      Coalesce formats.
      
      Convert ERROR/WARNING/INFO macros to rt2x00_<level>
      Convert EEPROM to rt2x00_eeprom_dbg
      Convert PROBE_ERROR to rt2x00_probe_err
      Convert DEBUG to rt2x00_dbg
      Convert EEPROM to rt2x00_eeprom_dbg
      
      $ size drivers/net/wireless/rt2x00/built-in.o*
         text	   data	    bss	    dec	    hex	filename
       245639	  71696	  69584	 386919	  5e767	drivers/net/wireless/rt2x00/built-in.o.new
       240609	  70096	  68944	 379649	  5cb01	drivers/net/wireless/rt2x00/built-in.o.new.nodyndbg
       240609	  70096	  68944	 379649	  5cb01	drivers/net/wireless/rt2x00/built-in.o.new.no_rt2x00_debug
       249198	  70096	  70352	 389646	  5f20e	drivers/net/wireless/rt2x00/built-in.o.old
       249198	  70096	  70352	 389646	  5f20e	drivers/net/wireless/rt2x00/built-in.o.old.nodyndbg
       244222	  70096	  69712	 384030	  5dc1e	drivers/net/wireless/rt2x00/built-in.o.old.no_rt2x00_debug
      Signed-off-by: NJoe Perches <joe@perches.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ec9c4989
  5. 19 3月, 2013 1 次提交
  6. 31 1月, 2013 1 次提交
  7. 10 11月, 2012 1 次提交
    • J
      mac80211: clarify interface iteration and make it configurable · 8b2c9824
      Johannes Berg 提交于
      During hardware restart, all interfaces are iterated even
      though they haven't been re-added to the driver, document
      this behaviour. The same also happens during resume, which
      is even more confusing since all of the interfaces were
      previously removed from the driver. Make this optional so
      drivers relying on the current behaviour can still use it,
      but to let drivers that don't want this behaviour disable
      it.
      
      Also convert all API users, keeping the old semantics
      except in hwsim, where the new normal ones are desired.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8b2c9824
  8. 26 9月, 2012 2 次提交
  9. 31 7月, 2012 1 次提交
  10. 07 6月, 2012 1 次提交
  11. 05 6月, 2012 1 次提交
    • S
      rt2x00: use atomic variable for seqno · e5851dac
      Stanislaw Gruszka 提交于
      Remove spinlock as atomic_t can be used instead. Note we use only 16
      lower bits, upper bits are changed but we impilcilty cast to u16.
      
      This fix possible deadlock on IBSS mode reproted by lockdep:
      
      =================================
      [ INFO: inconsistent lock state ]
      3.4.0-wl+ #4 Not tainted
      ---------------------------------
      inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
      kworker/u:2/30374 [HC0[0]:SC0[0]:HE1:SE1] takes:
       (&(&intf->seqlock)->rlock){+.?...}, at: [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
      {IN-SOFTIRQ-W} state was registered at:
        [<c04978ab>] __lock_acquire+0x47b/0x1050
        [<c0498504>] lock_acquire+0x84/0xf0
        [<c0835733>] _raw_spin_lock+0x33/0x40
        [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
        [<f9979f2a>] rt2x00queue_write_tx_frame+0x1a/0x300 [rt2x00lib]
        [<f997834f>] rt2x00mac_tx+0x7f/0x380 [rt2x00lib]
        [<f98fe363>] __ieee80211_tx+0x1b3/0x300 [mac80211]
        [<f98ffdf5>] ieee80211_tx+0x105/0x130 [mac80211]
        [<f99000dd>] ieee80211_xmit+0xad/0x100 [mac80211]
        [<f9900519>] ieee80211_subif_start_xmit+0x2d9/0x930 [mac80211]
        [<c0782e87>] dev_hard_start_xmit+0x307/0x660
        [<c079bb71>] sch_direct_xmit+0xa1/0x1e0
        [<c0784bb3>] dev_queue_xmit+0x183/0x730
        [<c078c27a>] neigh_resolve_output+0xfa/0x1e0
        [<c07b436a>] ip_finish_output+0x24a/0x460
        [<c07b4897>] ip_output+0xb7/0x100
        [<c07b2d60>] ip_local_out+0x20/0x60
        [<c07e01ff>] igmpv3_sendpack+0x4f/0x60
        [<c07e108f>] igmp_ifc_timer_expire+0x29f/0x330
        [<c04520fc>] run_timer_softirq+0x15c/0x2f0
        [<c0449e3e>] __do_softirq+0xae/0x1e0
      irq event stamp: 18380437
      hardirqs last  enabled at (18380437): [<c0526027>] __slab_alloc.clone.3+0x67/0x5f0
      hardirqs last disabled at (18380436): [<c0525ff3>] __slab_alloc.clone.3+0x33/0x5f0
      softirqs last  enabled at (18377616): [<c0449eb3>] __do_softirq+0x123/0x1e0
      softirqs last disabled at (18377611): [<c041278d>] do_softirq+0x9d/0xe0
      
      other info that might help us debug this:
       Possible unsafe locking scenario:
      
             CPU0
             ----
        lock(&(&intf->seqlock)->rlock);
        <Interrupt>
          lock(&(&intf->seqlock)->rlock);
      
       *** DEADLOCK ***
      
      4 locks held by kworker/u:2/30374:
       #0:  (wiphy_name(local->hw.wiphy)){++++.+}, at: [<c045cf99>] process_one_work+0x109/0x3f0
       #1:  ((&sdata->work)){+.+.+.}, at: [<c045cf99>] process_one_work+0x109/0x3f0
       #2:  (&ifibss->mtx){+.+.+.}, at: [<f98f005b>] ieee80211_ibss_work+0x1b/0x470 [mac80211]
       #3:  (&intf->beacon_skb_mutex){+.+...}, at: [<f997a644>] rt2x00queue_update_beacon+0x24/0x50 [rt2x00lib]
      
      stack backtrace:
      Pid: 30374, comm: kworker/u:2 Not tainted 3.4.0-wl+ #4
      Call Trace:
       [<c04962a6>] print_usage_bug+0x1f6/0x220
       [<c0496a12>] mark_lock+0x2c2/0x300
       [<c0495ff0>] ? check_usage_forwards+0xc0/0xc0
       [<c04978ec>] __lock_acquire+0x4bc/0x1050
       [<c0527890>] ? __kmalloc_track_caller+0x1c0/0x1d0
       [<c0777fb6>] ? copy_skb_header+0x26/0x90
       [<c0498504>] lock_acquire+0x84/0xf0
       [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<c0835733>] _raw_spin_lock+0x33/0x40
       [<f9979a20>] ? rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<f9979a20>] rt2x00queue_create_tx_descriptor+0x380/0x490 [rt2x00lib]
       [<f997a5cf>] rt2x00queue_update_beacon_locked+0x5f/0xb0 [rt2x00lib]
       [<f997a64d>] rt2x00queue_update_beacon+0x2d/0x50 [rt2x00lib]
       [<f9977e3a>] rt2x00mac_bss_info_changed+0x1ca/0x200 [rt2x00lib]
       [<f9977c70>] ? rt2x00mac_remove_interface+0x70/0x70 [rt2x00lib]
       [<f98e4dd0>] ieee80211_bss_info_change_notify+0xe0/0x1d0 [mac80211]
       [<f98ef7b8>] __ieee80211_sta_join_ibss+0x3b8/0x610 [mac80211]
       [<c0496ab4>] ? mark_held_locks+0x64/0xc0
       [<c0440012>] ? virt_efi_query_capsule_caps+0x12/0x50
       [<f98efb09>] ieee80211_sta_join_ibss+0xf9/0x140 [mac80211]
       [<f98f0456>] ieee80211_ibss_work+0x416/0x470 [mac80211]
       [<c0496d8b>] ? trace_hardirqs_on+0xb/0x10
       [<c077683b>] ? skb_dequeue+0x4b/0x70
       [<f98f207f>] ieee80211_iface_work+0x13f/0x230 [mac80211]
       [<c045cf99>] ? process_one_work+0x109/0x3f0
       [<c045d015>] process_one_work+0x185/0x3f0
       [<c045cf99>] ? process_one_work+0x109/0x3f0
       [<f98f1f40>] ? ieee80211_teardown_sdata+0xa0/0xa0 [mac80211]
       [<c045ed86>] worker_thread+0x116/0x270
       [<c045ec70>] ? manage_workers+0x1e0/0x1e0
       [<c0462f64>] kthread+0x84/0x90
       [<c0462ee0>] ? __init_kthread_worker+0x60/0x60
       [<c083d382>] kernel_thread_helper+0x6/0x10
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e5851dac
  12. 12 4月, 2012 1 次提交
  13. 13 3月, 2012 1 次提交
    • S
      rt2x00: fix random stalls · 3780d038
      Stanislaw Gruszka 提交于
      Is possible that we stop queue and then do not wake up it again,
      especially when packets are transmitted fast. That can be easily
      reproduced with modified tx queue entry_num to some small value e.g. 16.
      
      If mac80211 already hold local->queue_stop_reason_lock, then we can wait
      on that lock in both rt2x00queue_pause_queue() and
      rt2x00queue_unpause_queue(). After drooping ->queue_stop_reason_lock
      is possible that __ieee80211_wake_queue() will be performed before
      __ieee80211_stop_queue(), hence we stop queue and newer wake up it
      again.
      
      Another race condition is possible when between rt2x00queue_threshold()
      check and rt2x00queue_pause_queue() we will process all pending tx
      buffers on different cpu. This might happen if for example interrupt
      will be triggered on cpu performing rt2x00mac_tx().
      
      To prevent race conditions serialize pause/unpause by queue->tx_lock.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3780d038
  14. 15 12月, 2011 1 次提交
  15. 04 10月, 2011 1 次提交
    • E
      mac80211: pass vif param to conf_tx() callback · 8a3a3c85
      Eliad Peller 提交于
      tx params should be configured per interface.
      add ieee80211_vif param to the conf_tx callback,
      and change all the drivers that use this callback.
      
      The following spatch was used:
      @rule1@
      struct ieee80211_ops ops;
      identifier conf_tx_op;
      @@
      	ops.conf_tx = conf_tx_op;
      
      @rule2@
      identifier rule1.conf_tx_op;
      identifier hw, queue, params;
      @@
      	conf_tx_op (
      -		struct ieee80211_hw *hw,
      +		struct ieee80211_hw *hw, struct ieee80211_vif *vif,
      		u16 queue,
      		const struct ieee80211_tx_queue_params *params) {...}
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8a3a3c85
  16. 15 9月, 2011 3 次提交
  17. 03 8月, 2011 1 次提交
  18. 08 7月, 2011 1 次提交
  19. 20 4月, 2011 4 次提交
  20. 05 3月, 2011 5 次提交
  21. 26 2月, 2011 1 次提交
    • J
      mac80211: make tx() operation return void · 7bb45683
      Johannes Berg 提交于
      The return value of the tx operation is commonly
      misused by drivers, leading to errors. All drivers
      will drop frames if they fail to TX the frame, and
      they must also properly manage the queues (if they
      didn't, mac80211 would already warn).
      
      Removing the ability for drivers to return a BUSY
      value also allows significant cleanups of the TX
      TX handling code in mac80211.
      
      Note that this also fixes a bug in ath9k_htc, the
      old "return -1" there was wrong.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Tested-by: Sedat Dilek <sedat.dilek@googlemail.com> [ath5k]
      Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> [rt2x00]
      Acked-by: Larry Finger <Larry.Finger@lwfinger.net> [b43, rtl8187, rtlwifi]
      Acked-by: Luciano Coelho <coelho@ti.com> [wl12xx]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7bb45683
  22. 22 2月, 2011 1 次提交
  23. 01 2月, 2011 2 次提交
    • H
      rt2x00: Limit beacon updates in bss_info_changed to USB devices · 1dae8d34
      Helmut Schaa 提交于
      Currently there are two places that trigger a beacon update on PCI
      devices. The bss_info_changed callback and the periodic update
      triggered by the TBTT or PRETBTT interrupt.
      
      Since the next TBTT or PRETBTT interrupt will periodically fetch an
      updated beacon remove the update_beacon call in the bss_info_changed
      callback for PCI devices.
      
      In the worst case it will take one beacon interval longer to fetch
      the new beacon then before. For devices that have a PRETBTT interrupt
      there should be no change at all.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      1dae8d34
    • H
      rt2x00: Refactor beacon code to make use of start- and stop_queue · 69cf36a4
      Helmut Schaa 提交于
      This patch allows to dynamically remove beaconing interfaces without
      shutting beaconing down on all interfaces.
      
      The only place to start and stop beaconing are now the start- and
      stop_queue callbacks. Hence, we can remove some register writes during
      interface bring up (config_intf) and only write the correct sync mode
      to the register there.
      
      When multiple beaconing interfaces are present we should enable
      beaconing as soon as mac80211 enables beaconing on at least one of
      them. The beacon queue gets stopped when the last beaconing
      interface was stopped by mac80211. Therefore, introduce another
      interface counter to keep track ot the number of enabled beaconing
      interfaces and start or stop the beacon queue accordingly.
      
      To allow single interfaces to stop beaconing, add a new driver
      callback clear_beacon to clear a single interface's beacon without
      affecting the other interfaces. Don't overload the clear_entry callback
      for clearing beacons as that would introduce additional overhead
      (check for each TX queue) into the clear_entry callback which is used
      on the drivers TX/RX hotpaths.
      
      Furthermore, the write beacon callback doesn't need to enable beaconing
      anymore but since beaconing should be disabled while a new beacon is
      written or cleared we still disable beacon generation and enable it
      afterwards again in the driver specific callbacks. However, beacon
      related interrupts should not be disabled/enabled here, that's solely
      done from the start- and stop queue callbacks. It would be nice to stop
      the beacon queue just before the beacon update and enable it afterwards
      in rt2x00queue itself instead of the current implementation that relies
      on the driver doing the right thing. However, since start- and
      stop_queue are mutex protected we cannot use them for atomic beacon
      updates.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      69cf36a4
  24. 05 1月, 2011 6 次提交