<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lwn.git/drivers/net/wireless/rt2x00, branch v3.0.27</title>
<subtitle>Linux kernel documentation tree maintained by Jonathan Corbet</subtitle>
<id>http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.0.27</id>
<link rel='self' href='http://mirrors.hust.edu.cn/git/lwn.git/atom?h=v3.0.27'/>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/'/>
<updated>2012-04-02T16:27:08+00:00</updated>
<entry>
<title>rt2x00: Add support for D-Link DWA-127 to rt2800usb.</title>
<updated>2012-04-02T16:27:08+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2012-02-11T20:58:09+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=dc1c756aeaf15e67a293b4aaedbd062f5026e18e'/>
<id>urn:sha1:dc1c756aeaf15e67a293b4aaedbd062f5026e18e</id>
<content type='text'>
commit d42a179b941a9e4cc6cf41d0f3cbadd75fc48a89 upstream.

This is an RT3070 based device.

Reported-by: Mikhail Kryshen &lt;mikhail@kryshen.net&gt;
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rt2x00: fix random stalls</title>
<updated>2012-03-19T15:57:44+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-03-09T11:39:54+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=60d3a450571b3d92f5f9f78f2898a7f425031b51'/>
<id>urn:sha1:60d3a450571b3d92f5f9f78f2898a7f425031b51</id>
<content type='text'>
commit 3780d038fdf4b5ef26ead10b0604ab1f46dd9510 upstream.

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-&gt;queue_stop_reason_lock, then we can wait
on that lock in both rt2x00queue_pause_queue() and
rt2x00queue_unpause_queue(). After drooping -&gt;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-&gt;tx_lock.

Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>rt2800pci: fix spurious interrupts generation</title>
<updated>2012-01-26T01:25:02+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2012-01-13T11:59:32+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=ac631973a9ad6bba3d666f687288ebeb819c0df0'/>
<id>urn:sha1:ac631973a9ad6bba3d666f687288ebeb819c0df0</id>
<content type='text'>
commit dfd00c4c8f3dfa1fd7cec45f83d98b2a49743dcd upstream.

Same devices can generate interrupt without properly setting bit in
INT_SOURCE_CSR register (spurious interrupt), what will cause IRQ line
will be disabled by interrupts controller driver.

We discovered that clearing INT_MASK_CSR stops such behaviour. We
previously first read that register, and then clear all know interrupt
sources bits and do not touch reserved bits. After this patch, we write
to all register content (I believe writing to reserved bits on that
register will not cause any problems, I tested that on my rt2800pci
device).

This fix very bad performance problem, practically making device
unusable (since worked without interrupts), reported in:
https://bugzilla.redhat.com/show_bug.cgi?id=658451

We previously tried to workaround that issue in commit
4ba7d9997869d25bd223dea7536fc1ce9fab3b3b "rt2800pci: handle spurious
interrupts", but it was reverted in commit
82e5fc2a34fa9ffea38f00c4066b7e600a0ca5e6
as thing, that will prevent to detect real spurious interrupts.

Reported-and-tested-by: Amir Hedayaty &lt;hedayaty@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2800usb: Move ID out of unknown</title>
<updated>2012-01-12T19:34:58+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2011-12-27T18:22:51+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=081fa89b1a6e7ed3a05459b88ad974a6f3795a90'/>
<id>urn:sha1:081fa89b1a6e7ed3a05459b88ad974a6f3795a90</id>
<content type='text'>
commit 3f81f8f1524ccca24df1029b0cf825ecef5e5cdc upstream.

Testing on the openSUSE wireless forum has shown that a Linksys
WUSB54GC v3 with USB ID 1737:0077 works with rt2800usb when the ID is
written to /sys/.../new_id. This ID can therefore be moved out of UNKNOWN.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Acked-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2x00: Fix efuse EEPROM reading on PPC32.</title>
<updated>2011-12-09T16:52:30+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2011-11-16T22:16:15+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=2e72634a130dcac5d9e88e9187d7eab6c0ea8713'/>
<id>urn:sha1:2e72634a130dcac5d9e88e9187d7eab6c0ea8713</id>
<content type='text'>
commit 68fa64ef606bcee688fce46d07aa68f175070156 upstream.

Fix __le32 to __le16 conversion of the first word of an 8-word block
of EEPROM read via the efuse method.

Reported-and-tested-by: Ingvar Hagelund &lt;ingvar@redpill-linpro.com&gt;
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2x00: Fix sleep-while-atomic bug in powersaving code.</title>
<updated>2011-11-26T17:09:54+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2011-11-12T18:10:44+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=11885cd854b27c1dcf35ab44d4899e8d20e08290'/>
<id>urn:sha1:11885cd854b27c1dcf35ab44d4899e8d20e08290</id>
<content type='text'>
commit ed66ba472a742cd8df37d7072804b2111cdb1014 upstream.

The generic powersaving code that determines after reception of a frame
whether the device should go back to sleep or whether is could stay
awake was calling rt2x00lib_config directly from RX tasklet context.
On a number of the devices this call can actually sleep, due to having
to confirm that the sleeping commands have been executed successfully.

Fix this by moving the call to rt2x00lib_config to a workqueue call.

This fixes bug https://bugzilla.redhat.com/show_bug.cgi?id=731672

Tested-by: Tomas Trnka &lt;tomastrnka@gmx.com&gt;
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2x00: Serialize TX operations on a queue.</title>
<updated>2011-10-16T21:14:53+00:00</updated>
<author>
<name>Gertjan van Wingerde</name>
<email>gwingerde@gmail.com</email>
</author>
<published>2011-07-06T20:56:24+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=8a60d75bbc5feca1291edd728d6696be9e8dd465'/>
<id>urn:sha1:8a60d75bbc5feca1291edd728d6696be9e8dd465</id>
<content type='text'>
commit 77a861c405da75d81e9e6e32c50eb7f9777777e8 upstream.

The rt2x00 driver gets frequent occurrences of the following error message
when operating under load:
phy0 -&gt; rt2x00queue_write_tx_frame: Error - Arrived at non-free entry in the
non-full queue 2.

This is caused by simultaneous attempts from mac80211 to send a frame via
rt2x00, which are not properly serialized inside rt2x00queue_write_tx_frame,
causing the second frame to fail sending with the above mentioned error
message.

Fix this by introducing a per-queue spinlock to serialize the TX operations
on that queue.

Reported-by: Andreas Hartmann &lt;andihartmann@01019freenet.de&gt;
Signed-off-by: Gertjan van Wingerde &lt;gwingerde@gmail.com&gt;
Acked-by: Helmut Schaa &lt;helmut.schaa@googlemail.com&gt;
Signed-off-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Cc: Tim Gardner &lt;tim.gardner@canonical.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rtl2800usb: Fix incorrect storage of MAC address on big-endian platforms</title>
<updated>2011-10-03T18:40:40+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2011-09-14T21:50:23+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=35ff9b5a4d0c8881d85dc5874964460f858f7e2d'/>
<id>urn:sha1:35ff9b5a4d0c8881d85dc5874964460f858f7e2d</id>
<content type='text'>
commit daabead1c32f331edcfb255fd973411c667977e8 upstream.

The eeprom data is stored in little-endian order in the rt2x00 library.
As it was converted to cpu order in the read routines, the data need to
be converted to LE on a big-endian platform.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2800pci: Fix compiler error on PowerPC</title>
<updated>2011-10-03T18:40:38+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2011-09-14T21:50:22+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=2826eac8b4cf7b948eb41cdc77d67dbf84aced82'/>
<id>urn:sha1:2826eac8b4cf7b948eb41cdc77d67dbf84aced82</id>
<content type='text'>
commit d331eb51e4d4190b2178c30fcafea54a94a577e8 upstream.

Using gcc 4.4.5 on a Powerbook G4 with a PPC cpu, a complicated
if statement results in incorrect flow, whereas the equivalent switch
statement works correctly.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>rt2x00: fix crash in rt2800usb_get_txwi</title>
<updated>2011-10-03T18:39:58+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2011-08-25T15:14:26+00:00</published>
<link rel='alternate' type='text/html' href='http://mirrors.hust.edu.cn/git/lwn.git/commit/?id=d6b0fa557a435a3073da6298a88cd3f273fd8f5f'/>
<id>urn:sha1:d6b0fa557a435a3073da6298a88cd3f273fd8f5f</id>
<content type='text'>
commit 674db1344443204b6ce3293f2df8fd1b7665deea upstream.

Patch should fix this oops:

BUG: unable to handle kernel NULL pointer dereference at 000000a0
IP: [&lt;f81b30c9&gt;] 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:[&lt;f81b30c9&gt;] 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:
 [&lt;f804790f&gt;] rt2800_txdone_entry+0x2f/0xf0 [rt2800lib]
 [&lt;c045110d&gt;] ? warn_slowpath_common+0x7d/0xa0
 [&lt;f81b3a38&gt;] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
 [&lt;f81b3a38&gt;] ? rt2800usb_work_txdone+0x288/0x360 [rt2800usb]
 [&lt;f81b3a13&gt;] rt2800usb_work_txdone+0x263/0x360 [rt2800usb]
 [&lt;c046a8d6&gt;] process_one_work+0x186/0x440
 [&lt;c046a85a&gt;] ? process_one_work+0x10a/0x440
 [&lt;f81b37b0&gt;] ? rt2800usb_probe_hw+0x120/0x120 [rt2800usb]
 [&lt;c046c283&gt;] worker_thread+0x133/0x310
 [&lt;c04885db&gt;] ? trace_hardirqs_on+0xb/0x10
 [&lt;c046c150&gt;] ? manage_workers+0x1e0/0x1e0
 [&lt;c047054c&gt;] kthread+0x7c/0x90
 [&lt;c04704d0&gt;] ? __init_kthread_worker+0x60/0x60
 [&lt;c0826b42&gt;] 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() -&gt; rt2x00lib_txdone_noinfo() and
has nullify entry-&gt;skb .

Reported-by: Justin Piszcz &lt;jpiszcz@lucidpixels.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Acked-by: Ivo van Doorn &lt;IvDoorn@gmail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
</feed>
