<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless, branch v3.4.53</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.4.53</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.4.53'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-06-20T18:58:44Z</updated>
<entry>
<title>ath9k: Use minstrel rate control by default</title>
<updated>2013-06-20T18:58:44Z</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2013-06-06T04:36:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=91c930674642f4b849d64398db261ad13c3ab354'/>
<id>urn:sha1:91c930674642f4b849d64398db261ad13c3ab354</id>
<content type='text'>
commit 5efac94999ff218e0101f67a059e44abb4b0b523 upstream.

The ath9k rate control algorithm has various architectural
issues that make it a poor fit in scenarios like congested
environments etc.

An example: https://bugzilla.redhat.com/show_bug.cgi?id=927191

Change the default to minstrel which is more robust in such cases.
The ath9k RC code is left in the driver for now, maybe it can
be removed altogether later on.

Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Cc: Jouni Malinen &lt;jouni@qca.qualcomm.com&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&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>ath9k: Disable PowerSave by default</title>
<updated>2013-06-20T18:58:44Z</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2013-06-01T01:38:09Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=75b780e57baec8085beba0bf0e8ed9df68a24fb7'/>
<id>urn:sha1:75b780e57baec8085beba0bf0e8ed9df68a24fb7</id>
<content type='text'>
commit 531671cb17af07281e6f28c1425f754346e65c41 upstream.

Almost all the DMA issues which have plagued ath9k (in station mode)
for years are related to PS. Disabling PS usually "fixes" the user's
connection stablility. Reports of DMA problems are still trickling in
and are sitting in the kernel bugzilla. Until the PS code in ath9k is
given a thorough review, disbale it by default. The slight increase
in chip power consumption is a small price to pay for improved link
stability.

Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.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>b43: stop format string leaking into error msgs</title>
<updated>2013-06-20T18:58:43Z</updated>
<author>
<name>Kees Cook</name>
<email>keescook@chromium.org</email>
</author>
<published>2013-05-10T21:48:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d2305b5a32d15d0156115c24adcd8ecfa30209c7'/>
<id>urn:sha1:d2305b5a32d15d0156115c24adcd8ecfa30209c7</id>
<content type='text'>
commit e0e29b683d6784ef59bbc914eac85a04b650e63c upstream.

The module parameter "fwpostfix" is userspace controllable, unfiltered,
and is used to define the firmware filename. b43_do_request_fw() populates
ctx-&gt;errors[] on error, containing the firmware filename. b43err()
parses its arguments as a format string. For systems with b43 hardware,
this could lead to a uid-0 to ring-0 escalation.

CVE-2013-2852

Signed-off-by: Kees Cook &lt;keescook@chromium.org&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>B43: Handle DMA RX descriptor underrun</title>
<updated>2013-05-19T17:54:41Z</updated>
<author>
<name>Thommy Jakobsson</name>
<email>thommyj@gmail.com</email>
</author>
<published>2013-04-23T19:45:11Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5219d3dd6f96a7640929307a2344d9905cdf6b2c'/>
<id>urn:sha1:5219d3dd6f96a7640929307a2344d9905cdf6b2c</id>
<content type='text'>
commit 73b82bf0bfbf58e6ff328d3726934370585f6e78 upstream.

Add handling of rx descriptor underflow. This fixes a fault that could
happen on slow machines, where data is received faster than the CPU can
handle. In such a case the device will use up all rx descriptors and
refuse to send any more data before confirming that it is ok. This
patch enables necessary interrupt to discover such a situation and will
handle them by dropping everything in the ring buffer.

Reviewed-by: Michael Buesch &lt;m@bues.ch&gt;
Signed-off-by: Thommy Jakobsson &lt;thommyj@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>mwifiex: fix setting of multicast filter</title>
<updated>2013-05-19T17:54:41Z</updated>
<author>
<name>Daniel Drake</name>
<email>dsd@laptop.org</email>
</author>
<published>2013-05-08T19:37:19Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2969620bf1452ec310fdcbf0d5a567627d0f5c74'/>
<id>urn:sha1:2969620bf1452ec310fdcbf0d5a567627d0f5c74</id>
<content type='text'>
commit ccd384b10420ac81ba3fb9b0a7d18272c7173552 upstream.

A small bug in this code was causing the ALLMULTI filter to be set
when in fact we were just wanting to program a selective multicast list
to the hardware.

Fix that bug and remove a redundant if condition in the code that
follows.

This fixes wakeup behaviour when multicast WOL is enabled. Previously,
all multicast packets would wake up the system. Now, only those that the
host intended to receive trigger wakeups.

Signed-off-by: Daniel Drake &lt;dsd@laptop.org&gt;
Acked-by: Bing Zhao &lt;bzhao@marvell.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>mwifiex: clear is_suspended flag when interrupt is received early</title>
<updated>2013-05-19T17:54:41Z</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2013-05-07T02:46:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4f68f0ba1c85d66c3f8665c59a007971ad11adc1'/>
<id>urn:sha1:4f68f0ba1c85d66c3f8665c59a007971ad11adc1</id>
<content type='text'>
commit 48795424acff7215d5eac0b52793a2c1eb3a6283 upstream.

When the XO-4 with 8787 wireless is woken up due to wake-on-WLAN
mwifiex is often flooded with "not allowed while suspended" messages
and the interface is unusable.

[  202.171609] int: sdio_ireg = 0x1
[  202.180700] info: mwifiex_process_hs_config: auto cancelling host
               sleep since there is interrupt from the firmware
[  202.201880] event: wakeup device...
[  202.211452] event: hs_deactivated
[  202.514638] info: --- Rx: Data packet ---
[  202.514753] data: 4294957544 BSS(0-0): Data &lt;= kernel
[  202.514825] PREP_CMD: device in suspended state
[  202.514839] data: dequeuing the packet ec7248c0 ec4869c0
[  202.514886] mwifiex_write_data_sync: not allowed while suspended
[  202.514886] host_to_card, write iomem (1) failed: -1
[  202.514917] mwifiex_write_data_sync: not allowed while suspended
[  202.514936] host_to_card, write iomem (2) failed: -1
[  202.514949] mwifiex_write_data_sync: not allowed while suspended
[  202.514965] host_to_card, write iomem (3) failed: -1
[  202.514976] mwifiex_write_data_async failed: 0xFFFFFFFF

This can be readily reproduced when putting the XO-4 in a loop where
it goes to sleep due to inactivity, but then wakes up due to an
incoming ping. The error is hit within an hour or two.

This issue happens when an interrupt comes in early while host sleep
is still activated. Driver handles this case by auto cancelling host
sleep. However is_suspended flag is still set which prevents any cmd
or data from being sent to firmware. Fix it by clearing is_suspended
flag in this path.

Reported-by: Daniel Drake &lt;dsd@laptop.org&gt;
Tested-by: Daniel Drake &lt;dsd@laptop.org&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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ath9k: fix key allocation error handling for powersave keys</title>
<updated>2013-05-19T17:54:40Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-04-27T09:47:01Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=48633a6011b0bcbf2bf5a4071a5a55a4a3b45a94'/>
<id>urn:sha1:48633a6011b0bcbf2bf5a4071a5a55a4a3b45a94</id>
<content type='text'>
commit 4ef69d0394cba8caa9f75d3f2e53429bfb8b3045 upstream.

If no keycache slots are available, ath_key_config can return -ENOSPC.
If the key index is not checked for errors, it can lead to logspam that
looks like this: "ath: wiphy0: keyreset: keycache entry 228 out of range"
This can cause follow-up errors if the invalid keycache index gets
used for tx.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&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>mwifiex: Call pci_release_region after calling pci_disable_device</title>
<updated>2013-05-08T02:51:52Z</updated>
<author>
<name>Yogesh Ashok Powar</name>
<email>yogeshp@marvell.com</email>
</author>
<published>2013-04-23T23:49:48Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b174e3c05c191442e0675e8d9c329f2c42ee363a'/>
<id>urn:sha1:b174e3c05c191442e0675e8d9c329f2c42ee363a</id>
<content type='text'>
commit 5b0d9b218b74042ff72bf4bfda6eeb2e4bf98397 upstream.

"drivers should call pci_release_region() AFTER
calling pci_disable_device()"

Please refer section 3.2 Request MMIO/IOP resources
in Documentation/PCI/pci.txt

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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>mwifiex: Use pci_release_region() instead of a pci_release_regions()</title>
<updated>2013-05-08T02:51:52Z</updated>
<author>
<name>Yogesh Ashok Powar</name>
<email>yogeshp@marvell.com</email>
</author>
<published>2013-04-23T23:49:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9758cfd231405b21f2244c9f4cc1fff89fcee3e0'/>
<id>urn:sha1:9758cfd231405b21f2244c9f4cc1fff89fcee3e0</id>
<content type='text'>
commit c380aafb77b7435d010698fe3ca6d3e1cd745fde upstream.

PCI regions are associated with the device using
pci_request_region() call. Hence use pci_release_region()
instead of pci_release_regions().

Signed-off-by: Yogesh Ashok Powar &lt;yogeshp@marvell.com&gt;
Signed-off-by: Amitkumar Karwar &lt;akarwar@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@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: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ssb: implement spurious tone avoidance</title>
<updated>2013-04-26T04:19:55Z</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2013-04-02T13:57:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=d6b8c333ca71eba35911fc4460ca37568ccfa9c0'/>
<id>urn:sha1:d6b8c333ca71eba35911fc4460ca37568ccfa9c0</id>
<content type='text'>
commit 46fc4c909339f5a84d1679045297d9d2fb596987 upstream.

And make use of it in b43. This fixes a regression introduced with
49d55cef5b1925a5c1efb6aaddaa40fc7c693335
b43: N-PHY: implement spurious tone avoidance
This commit made BCM4322 use only MCS 0 on channel 13, which of course
resulted in performance drop (down to 0.7Mb/s).

Reported-by: Stefan Brüns &lt;stefan.bruens@rwth-aachen.de&gt;
Signed-off-by: Rafał Miłecki &lt;zajec5@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>
</feed>
