1. 10 8月, 2013 1 次提交
  2. 30 7月, 2013 1 次提交
    • S
      rt2x00: fix stop queue · e2288b66
      Stanislaw Gruszka 提交于
      Since we clear QUEUE_STARTED in rt2x00queue_stop_queue(), following
      call to rt2x00queue_pause_queue() reduce to noop, i.e we do not
      stop queue in mac80211.
      
      To fix that introduce rt2x00queue_pause_queue_nocheck() function,
      which will stop queue in mac80211 directly.
      
      Note that rt2x00_start_queue() explicitly set QUEUE_PAUSED bit.
      
      Note also that reordering operations i.e. first call to
      rt2x00queue_pause_queue() and then clear QUEUE_STARTED bit, will race
      with rt2x00queue_unpause_queue(), so calling ieee80211_stop_queue()
      directly is the only available solution to fix the problem without
      major rework.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e2288b66
  3. 13 6月, 2013 6 次提交
  4. 11 6月, 2013 1 次提交
    • G
      rt2x00: rt2x00queue: initialize data_queue fields earlier · 10af87c3
      Gabor Juhos 提交于
      Support for rt2800 device is broken since my
      'rt2x00: rt2x00dev: use rt2x00dev->tx->limit'
      patch. The changelog of that commit says that the
      TX data queue is initialized already when the
      rt2x00lib_probe_hw() function is called.
      
      However as Jakub noticed it, this statement is not
      correct. The queue->limit field is initialized in
      the rt2x00queue_alloc_entries routine and that is
      not yet called when rt2x00lib_probe_hw() runs.
      Because the value of tx->limit contains zero, the
      driver tries to allocate a kernel fifo with zero
      size and kfifo_alloc rejects that with -EINVAL.
      
        PCI: Enabling device 0000:01:00.0 (0000 -> 0002)
        ieee80211 phy1: rt2x00_set_rt: Info - RT chipset 3071, rev 021c detected
        ieee80211 phy1: rt2x00_set_rf: Info - RF chipset 0008 detected
        ieee80211 phy1: rt2x00lib_probe_dev: Error - Failed to initialize hw
        rt2800pci: probe of 0000:01:00.0 failed with error -22
      
      Move the data_queue field initialization from
      the rt2x00queue_alloc_entries routine into the
      rt2x00queue_init function. The initialization
      code is not strictly related to the allocation,
      and the change ensures that the queue_data fields
      can be used in the probe routines.
      
      The patch also introduces a helper function in
      order to be able to get the correct data_queue_desc
      structure for a given queue. This helper is only
      needed temporarily and it will be removed later.
      Reported-by: NJakub Kicinski <moorray@wp.pl>
      Signed-off-by: NGabor Juhos <juhosg@openwrt.org>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      10af87c3
  5. 23 4月, 2013 2 次提交
    • 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
    • S
      rt2x00: provide separate information about TXWI & RXWI sizes · f0bda571
      Stanislaw Gruszka 提交于
      On new 2800 hardware sizes of TXWI & RXIW can be different than TXD
      & RXD sizes, so we need to difference between them. Let's define
      winfo_size as size of in buffer descriptor (TXWI & RXWI), and desc_size
      of as size of additional descriptor - in separate DMA coherent buffer
      for PCI hardware (TXD & RXD) and yet another in buffer descriptor for
      USB hardware (TXINFO & RXINFO).
      
      Change is rt2x00 wild, but should affect only 2800 driver.
      
      Patch also fix beaconing for 5592usb AP mode.
      Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      f0bda571
  6. 19 3月, 2013 1 次提交
  7. 15 2月, 2013 2 次提交
  8. 23 1月, 2013 1 次提交
    • H
      rt2x00: Improve TX status handling for BlockAckReq frames · 84e9e8eb
      Helmut Schaa 提交于
      Since rt2800 hardware isn't capable of reporting the TX status of
      BlockAckReq frames implement the TX status handling of BARs in
      rt2x00lib. We keep track of all BARs that are send out and try to
      match incoming BAs to the appropriate BARs. This allows us to report a
      more or less accurate TX status for BAR frames which in turn improves
      BA session stability.
      
      This is loosley based on Christian Lamparter's patch for carl9170
      "carl9170: fix HT peer BA session corruption".
      
      We have to walk the list of pending BARs for every rx'red BA even
      though most BAs don't belong to any of these BARs as they are just
      acknowledging an AMPDU. To keep that overhead low use RCU which allows
      us to walk the list of pending BARs without the need to acquire a lock.
      This however requires us to _copy_ relevant information from the BAR
      (RA, TA, control field, start sequence number) into our BAR list entry.
      Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
      Tested-by: NAndreas Hartmann <andihartmann@01019freenet.de>
      Acked-by: NGertjan van Wingerde <gwingerde@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      84e9e8eb
  9. 31 7月, 2012 1 次提交
  10. 12 7月, 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. 24 4月, 2012 1 次提交
  13. 12 4月, 2012 2 次提交
  14. 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
  15. 15 9月, 2011 1 次提交
  16. 08 7月, 2011 3 次提交
  17. 02 6月, 2011 1 次提交
  18. 20 4月, 2011 5 次提交
  19. 05 4月, 2011 2 次提交
  20. 31 3月, 2011 1 次提交
  21. 05 3月, 2011 5 次提交