<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless, branch v3.2.41</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.2.41</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.2.41'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-03-20T15:03:24Z</updated>
<entry>
<title>iwlwifi: always copy first 16 bytes of commands</title>
<updated>2013-03-20T15:03:24Z</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2013-02-25T15:01:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=81745233d8df3f506f4f571fb0e6dc43a54ba906'/>
<id>urn:sha1:81745233d8df3f506f4f571fb0e6dc43a54ba906</id>
<content type='text'>
commit 8a964f44e01ad3bbc208c3e80d931ba91b9ea786 upstream.

The FH hardware will always write back to the scratch field
in commands, even host commands not just TX commands, which
can overwrite parts of the command. This is problematic if
the command is re-used (with IWL_HCMD_DFL_NOCOPY) and can
cause calibration issues.

Address this problem by always putting at least the first
16 bytes into the buffer we also use for the command header
and therefore make the DMA engine write back into this.

For commands that are smaller than 16 bytes also always map
enough memory for the DMA engine to write back to.

Reviewed-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
[bwh: Backported to 3.2:
 - Adjust context
 - Drop the IWL_HCMD_DFL_DUP handling
 - Fix descriptor addresses and lengths for tracepoint, but otherwise
   leave it unchanged]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>mwifiex: correct sleep delay counter</title>
<updated>2013-03-20T15:03:19Z</updated>
<author>
<name>Avinash Patil</name>
<email>patila@marvell.com</email>
</author>
<published>2013-02-26T00:01:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b2650cd39a40cae1c26ebc81f3a0e319e3a587a3'/>
<id>urn:sha1:b2650cd39a40cae1c26ebc81f3a0e319e3a587a3</id>
<content type='text'>
commit 3e7a4ff7c5b6423ddb644df9c41b8b6d2fb79d30 upstream.

Maximum delay for waking up card is 50 ms. Because of typo in
counter, this delay goes to 500ms. This patch fixes the bug.

Signed-off-by: Avinash Patil &lt;patila@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Yogesh Ashok Powar &lt;yogeshp@marvell.com&gt;
Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ath9k_htc: fix signal strength handling issues</title>
<updated>2013-03-20T15:03:19Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-02-22T20:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=deca5de87684d4cc84302dc4460c980ed44ac7a0'/>
<id>urn:sha1:deca5de87684d4cc84302dc4460c980ed44ac7a0</id>
<content type='text'>
commit 838f427955dcfd16858b0108ce29029da0d56a4e upstream.

The ath9k commit 2ef167557c0a26c88162ecffb017bfcc51eb7b29
(ath9k: fix signal strength reporting issues) fixed an issue where the
reported per-frame signal strength reported to mac80211 was being
overwritten with an internal average. The same issue is also present
in ath9k_htc.
In addition to preventing the driver from overwriting the value, this
commit also ensures that the internal average (which is used for ANI)
only tracks beacons of the AP that we're connected to.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: use compare_ether_addr() instead of
 ether_addr_equal(), with opposite sense]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>ath9k: fix RSSI dummy marker value</title>
<updated>2013-03-20T15:03:19Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-02-22T20:09:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ccf970969a60c1fcc399ef492e05805243746354'/>
<id>urn:sha1:ccf970969a60c1fcc399ef492e05805243746354</id>
<content type='text'>
commit a3d63cadbad97671d740a9698acc2c95d1ca6e79 upstream.

RSSI is being stored internally as s8 in several places. The indication
of an unset RSSI value, ATH_RSSI_DUMMY_MARKER, was supposed to have been
set to 127, but ended up being set to 0x127 because of a code cleanup
mistake. This could lead to invalid signal strength values in a few
places.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>b43: Increase number of RX DMA slots</title>
<updated>2013-03-06T03:24:04Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2013-02-17T17:01:20Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c6f8eab7b3f687d2642e2c6e99da46d9dcef3927'/>
<id>urn:sha1:c6f8eab7b3f687d2642e2c6e99da46d9dcef3927</id>
<content type='text'>
commit ccae0e50c16a7f7adb029c169147400d1ce9f703 upstream.

Bastian Bittorf reported that some of the silent freezes on a Linksys WRT54G
were due to overflow of the RX DMA ring buffer, which was created with 64
slots. That finding reminded me that I was seeing similar crashed on a netbook,
which also has a relatively slow processor. After increasing the number of
slots to 128, runs on the netbook that previously failed now worked; however,
I found that 109 slots had been used in one test. For that reason, the number
of slots is being increased to 256.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Bastian Bittorf &lt;bittorf@bluebottle.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>rtlwifi: usb: allocate URB control message setup_packet and data buffer separately</title>
<updated>2013-03-06T03:24:03Z</updated>
<author>
<name>Jussi Kivilinna</name>
<email>jussi.kivilinna@mbnet.fi</email>
</author>
<published>2013-02-18T08:29:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9e2282d4b05fdc74ef5677174d3146494dff64a9'/>
<id>urn:sha1:9e2282d4b05fdc74ef5677174d3146494dff64a9</id>
<content type='text'>
commit bc6b89237acb3dee6af6e64e51a18255fef89cc2 upstream.

rtlwifi allocates both setup_packet and data buffer of control message urb,
using shared kmalloc in _usbctrl_vendorreq_async_write. Structure used for
allocating is:
	struct {
		u8 data[254];
		struct usb_ctrlrequest dr;
	};

Because 'struct usb_ctrlrequest' is __packed, setup packet is unaligned and
DMA mapping of both 'data' and 'dr' confuses ARM/sunxi, leading to memory
corruptions and freezes.

Patch changes setup packet to be allocated separately.

[v2]:
 - Use WARN_ON_ONCE instead of WARN_ON

Signed-off-by: Jussi Kivilinna &lt;jussi.kivilinna@mbnet.fi&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust context]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>rtlwifi: rtl8192cu: Add new USB ID</title>
<updated>2013-03-06T03:23:53Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2013-02-08T18:28:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4413840e5c227b869aaf53d5f9d782e72636d9e1'/>
<id>urn:sha1:4413840e5c227b869aaf53d5f9d782e72636d9e1</id>
<content type='text'>
commit 8708aac79e4572ba673d7a21e94ddca9f3abb7fc upstream.

A new model of the RTL8188CUS has appeared.

Reported-and-tested-by: Thomas Rosenkrantz &lt;tom.rosary@googlemail.com&gt;
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: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>rtlwifi: rtl8192cu: Fix NULL dereference BUG when using new_id</title>
<updated>2013-03-06T03:23:53Z</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2013-02-06T18:54:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=581e58916c90eb2ba65f6c0a5a1c33ba2238a7bf'/>
<id>urn:sha1:581e58916c90eb2ba65f6c0a5a1c33ba2238a7bf</id>
<content type='text'>
commit 957f4aca5fa0db69635271bc4621cc0b65b2d590 upstream.

When the new_id entry in /sysfs is used for a foreign USB device, rtlwifi
BUGS with a NULL pointer dereference because the per-driver configuration
data is not available. The probe function has been restructured as
suggested by Ben Hutchings &lt;bhutchings@solarflare.com&gt;.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
[bwh: Backported to 3.2: adjust context, indentation]
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>p54usb: corrected USB ID for T-Com Sinus 154 data II</title>
<updated>2013-03-06T03:23:53Z</updated>
<author>
<name>Tomasz Guszkowski</name>
<email>tsg@o2.pl</email>
</author>
<published>2013-02-05T21:10:31Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d66d1873526fa1fb405fef0206035cd3e683a7c2'/>
<id>urn:sha1:d66d1873526fa1fb405fef0206035cd3e683a7c2</id>
<content type='text'>
commit 008e33f733ca51acb2dd9d88ea878693b04d1d2a upstream.

Corrected USB ID for T-Com Sinus 154 data II. ISL3887-based. The
device was tested in managed mode with no security, WEP 128
bit and WPA-PSK (TKIP) with firmware 2.13.1.0.lm87.arm (md5sum:
7d676323ac60d6e1a3b6d61e8c528248). It works.

Signed-off-by: Tomasz Guszkowski &lt;tsg@o2.pl&gt;
Acked-By: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
<entry>
<title>rt2800usb: Add support for 2001:3c1e (D-Link DWA-125 rev B1) USB Wi-Fi adapter</title>
<updated>2013-02-20T03:15:27Z</updated>
<author>
<name>Maia Kozheva</name>
<email>sikon@ubuntu.com</email>
</author>
<published>2012-12-09T09:07:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=31317e96c36a1d45bf6618a8f02839c924d2bcaf'/>
<id>urn:sha1:31317e96c36a1d45bf6618a8f02839c924d2bcaf</id>
<content type='text'>
commit fd7b9270120ca7e53fbf0469febe0c68acf6a0a2 upstream.

D-Link DWA-125/B1 is a relatively new USB Wi-Fi adapter, using a
Ralink chipset supported by the rt2800usb driver. Currently, to work
around the problem (it's missing in all present kernel versions,
up to and including 3.7.x), I had to add this to /etc/rc.local:

echo 2001 3c1e &gt;&gt; /sys/bus/usb/drivers/rt2800usb/new_id

After that, the device works without problems. Been using it for over
a week with no bugs in sight.

The attached patch is trivial and simply adds the new USB ID to the
list of devices handled by rt2800usb.

Signed-off-by: Maia Kozheva &lt;sikon@ubuntu.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
</content>
</entry>
</feed>
