1. 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
  2. 28 9月, 2011 1 次提交
  3. 17 9月, 2011 2 次提交
  4. 15 9月, 2011 12 次提交
  5. 14 9月, 2011 1 次提交
  6. 23 8月, 2011 1 次提交
    • S
      rt2x00: do not drop usb dev reference counter on suspend · 543cc38c
      Stanislaw Gruszka 提交于
      When hibernating ->resume may not be called by usb core, but disconnect
      and probe instead, so we do not increase the counter after decreasing
      it in ->supend. As a result we free memory early, and get crash when
      unplugging usb dongle.
      
      BUG: unable to handle kernel paging request at 6b6b6b9f
      IP: [<c06909b0>] driver_sysfs_remove+0x10/0x30
      *pdpt = 0000000034f21001 *pde = 0000000000000000
      Pid: 20, comm: khubd Not tainted 3.1.0-rc1-wl+ #20 LENOVO 6369CTO/6369CTO
      EIP: 0060:[<c06909b0>] EFLAGS: 00010202 CPU: 1
      EIP is at driver_sysfs_remove+0x10/0x30
      EAX: 6b6b6b6b EBX: f52bba34 ECX: 00000000 EDX: 6b6b6b6b
      ESI: 6b6b6b6b EDI: c0a0ea20 EBP: f61c9e68 ESP: f61c9e64
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process khubd (pid: 20, ti=f61c8000 task=f6138270 task.ti=f61c8000)
      Call Trace:
       [<c06909ef>] __device_release_driver+0x1f/0xa0
       [<c0690b20>] device_release_driver+0x20/0x40
       [<c068fd64>] bus_remove_device+0x84/0xe0
       [<c068e12a>] ? device_remove_attrs+0x2a/0x80
       [<c068e267>] device_del+0xe7/0x170
       [<c06d93d4>] usb_disconnect+0xd4/0x180
       [<c06d9d61>] hub_thread+0x691/0x1600
       [<c0473260>] ? wake_up_bit+0x30/0x30
       [<c0442a39>] ? complete+0x49/0x60
       [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
       [<c06d96d0>] ? hub_disconnect+0xd0/0xd0
       [<c0472eb4>] kthread+0x74/0x80
       [<c0472e40>] ? kthread_worker_fn+0x150/0x150
       [<c0809b3e>] kernel_thread_helper+0x6/0x10
      
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      543cc38c
  7. 12 8月, 2011 3 次提交
    • S
      rt2x00: fix crash in rt2800usb_get_txwi · 674db134
      Stanislaw Gruszka 提交于
      Patch should fix this oops:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000a0
      IP: [<f81b30c9>] rt2800usb_get_txwi+0x19/0x70 [rt2800usb]
      *pdpt = 0000000000000000 *pde = f000ff53f000ff53
      Oops: 0000 [#1] SMP
      Pid: 198, comm: kworker/u:3 Tainted: G        W   3.0.0-wl+ #9 LENOVO 6369CTO/6369CTO
      EIP: 0060:[<f81b30c9>] EFLAGS: 00010283 CPU: 1
      EIP is at rt2800usb_get_txwi+0x19/0x70 [rt2800usb]
      EAX: 00000000 EBX: f465e140 ECX: f4494960 EDX: ef24c5f8
      ESI: 810f21f5 EDI: f1da9960 EBP: f4581e80 ESP: f4581e70
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Process kworker/u:3 (pid: 198, ti=f4580000 task=f4494960 task.ti=f4580000)
      Call Trace:
       [<f804790f>] rt2800_txdone_entry+0x2f/0xf0 [rt2800lib]
       [<c045110d>] ? warn_slowpath_common+0x7d/0xa0
       [<f81b3a38>] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
       [<f81b3a38>] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
       [<f81b3a13>] rt2800usb_work_txdone+0x263/0x360 [rt2800usb]
       [<c046a8d6>] process_one_work+0x186/0x440
       [<c046a85a>] ? process_one_work+0x10a/0x440
       [<f81b37b0>] ? rt2800usb_probe_hw+0x120/0x120 [rt2800usb]
       [<c046c283>] worker_thread+0x133/0x310
       [<c04885db>] ? trace_hardirqs_on+0xb/0x10
       [<c046c150>] ? manage_workers+0x1e0/0x1e0
       [<c047054c>] kthread+0x7c/0x90
       [<c04704d0>] ? __init_kthread_worker+0x60/0x60
       [<c0826b42>] kernel_thread_helper+0x6/0x1
      
      Oops might happen because we check rt2x00queue_empty(queue) twice,
      but this condition can change and we can process entry in
      rt2800_txdone_entry(), which was already processed by
      rt2800usb_txdone_entry_check() -> rt2x00lib_txdone_noinfo() and
      has nullify entry->skb .
      Reported-by: NJustin Piszcz <jpiszcz@lucidpixels.com>
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      674db134
    • S
      rt2x00: fix order of entry flags modification · df71c9cf
      Stanislaw Gruszka 提交于
      In rt2800usb_work_txdone we check flags in order:
      
      - ENTRY_OWNER_DEVICE_DATA
      - ENTRY_DATA_STATUS_PENDING
      - ENTRY_DATA_IO_FAILED
      
      Modify flags in separate order in rt2x00usb_interrupt_txdone, to avoid
      processing entries in _txdone with wrong flags or skip processing
      ready entries.
      Reported-by: NJustin Piszcz <jpiszcz@lucidpixels.com>
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      df71c9cf
    • S
      rt2x00: fix crash in rt2800usb_write_tx_desc · 4b1bfb7d
      Stanislaw Gruszka 提交于
      Patch should fix this oops:
      
      BUG: unable to handle kernel NULL pointer dereference at 000000a0
      IP: [<f8e06078>] rt2800usb_write_tx_desc+0x18/0xc0 [rt2800usb]
      *pdpt = 000000002408c001 *pde = 0000000024079067 *pte = 0000000000000000
      Oops: 0000 [#1] SMP
      EIP: 0060:[<f8e06078>] EFLAGS: 00010282 CPU: 0
      EIP is at rt2800usb_write_tx_desc+0x18/0xc0 [rt2800usb]
      EAX: 00000035 EBX: ef2bef10 ECX: 00000000 EDX: d40958a0
      ESI: ef1865f8 EDI: ef1865f8 EBP: d4095878 ESP: d409585c
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      Call Trace:
       [<f8da5e85>] rt2x00queue_write_tx_frame+0x155/0x300 [rt2x00lib]
       [<f8da424c>] rt2x00mac_tx+0x7c/0x370 [rt2x00lib]
       [<c04882b2>] ? mark_held_locks+0x62/0x90
       [<c081f645>] ? _raw_spin_unlock_irqrestore+0x35/0x60
       [<c04884ba>] ? trace_hardirqs_on_caller+0x5a/0x170
       [<c04885db>] ? trace_hardirqs_on+0xb/0x10
       [<f8d618ac>] __ieee80211_tx+0x5c/0x1e0 [mac80211]
       [<f8d631fc>] ieee80211_tx+0xbc/0xe0 [mac80211]
       [<f8d63163>] ? ieee80211_tx+0x23/0xe0 [mac80211]
       [<f8d632e1>] ieee80211_xmit+0xc1/0x200 [mac80211]
       [<f8d63220>] ? ieee80211_tx+0xe0/0xe0 [mac80211]
       [<c0487d45>] ? lock_release_holdtime+0x35/0x1b0
       [<f8d63986>] ? ieee80211_subif_start_xmit+0x446/0x5f0 [mac80211]
       [<f8d637dd>] ieee80211_subif_start_xmit+0x29d/0x5f0 [mac80211]
       [<f8d63924>] ? ieee80211_subif_start_xmit+0x3e4/0x5f0 [mac80211]
       [<c0760188>] ? sock_setsockopt+0x6a8/0x6f0
       [<c0760000>] ? sock_setsockopt+0x520/0x6f0
       [<c076daef>] dev_hard_start_xmit+0x2ef/0x650
      
      Oops might happen because we perform parallel putting new entries in a
      queue (rt2x00queue_write_tx_frame()) and removing entries after
      finishing transmitting (rt2800usb_work_txdone()). There are cases when
      _txdone may process an entry that was not fully send and nullify
      entry->skb .
      
      To fix check in _txdone if entry has flags that indicate pending
      transmission and wait until flags get cleared.
      Reported-by: NJustin Piszcz <jpiszcz@lucidpixels.com>
      Cc: stable@kernel.org
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4b1bfb7d
  8. 10 8月, 2011 3 次提交
  9. 03 8月, 2011 2 次提交
  10. 02 8月, 2011 1 次提交
  11. 12 7月, 2011 1 次提交
  12. 08 7月, 2011 6 次提交
  13. 28 6月, 2011 1 次提交
  14. 23 6月, 2011 2 次提交
    • S
      rt2x00: reset usb devices at probe · bf4c02d5
      Stanislaw Gruszka 提交于
      When module is reloaded, device may fail to work, with messages:
      
      [  342.211926] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x0059, type=2.
      [  342.314254] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004a, type=2.
      [  342.416458] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 3183 max 2432.
      [  342.518605] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00c9, type=2.
      [  342.620836] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00ae, type=1.
      [  342.723201] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
      [  342.825399] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
      [  342.927624] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 0 max 2432.
      [  343.029804] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2491 max 2432.
      [  343.132008] phy40 -> rt2x00lib_rxdone: Warning - Wrong frame size 2576 max 2432.
      [  343.234326] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x004c, type=1.
      [  343.438723] phy40 -> rt2x00lib_rxdone_read_signal: Warning - Frame received with unrecognized signal, mode=0x0000, signal=0x00e6, type=1.
      
      Whereas replugging device make it functional. To solve that problem
      force reset device during probe.
      
      With patch messages are gone. Unfortunately device may sometimes
      still does not operate correctly after module reload (fail to receive
      data after associate), but such cases are rarer than without the patch.
      Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bf4c02d5
    • S
      rt2x00: fix possible memory corruption in case of invalid rxdesc.size · 7f503fc4
      Stanislaw Gruszka 提交于
      Sometimes rxdesc descriptor provided by hardware contains invalid
      (random) data. For example rxdesc.size can be bigger than actual
      size of the buffer. When this happen rt2x00crypto_rx_insert_iv()
      corrupt memory doing memmove outside of buffer boundaries.
      Signed-off-by: NStanislaw Gruszka <stf_xl@wp.pl>
      Acked-by: NIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7f503fc4
  15. 07 6月, 2011 2 次提交
  16. 06 6月, 2011 1 次提交