<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/drivers/net/wireless, branch v3.15-rc6</title>
<subtitle>Clone of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git</subtitle>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/'/>
<entry>
<title>rtl8192cu: Fix unbalanced irq enable in error path of rtl92cu_hw_init()</title>
<updated>2014-04-30T16:22:52+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2014-04-26T20:59:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3234f5b06fc3094176a86772cc64baf3decc98fc'/>
<id>3234f5b06fc3094176a86772cc64baf3decc98fc</id>
<content type='text'>
Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixes: a53268be0cb9 ('rtlwifi: rtl8192cu: Fix too long disable of IRQs')
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: rtl8192se: Fix regression due to commit 1bf4bbb</title>
<updated>2014-04-30T16:22:52+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2014-04-25T15:05:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=5f9186990ec4579ee5b7a99b3254c29eda479f36'/>
<id>5f9186990ec4579ee5b7a99b3254c29eda479f36</id>
<content type='text'>
Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:

Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau &lt;nbd@openwrt.org&gt;
Title: mac80211: send control port protocol frames to the VO queue

There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541

Reported-by: Alex Miller &lt;almiller_1@yahoo.co.uk&gt;
Tested-by: Alex Miller &lt;almiller_1@yahoo.co.uk&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;    [3.13+]
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Beginning with kernel 3.13, this driver fails on some systems. The problem
was bisected to:

Commit 1bf4bbb4024dcdab5e57634dd8ae1072d42a53ac
Author: Felix Fietkau &lt;nbd@openwrt.org&gt;
Title: mac80211: send control port protocol frames to the VO queue

There is noting wrong with the above commit. The regression occurs because
V0 queue on RTL8192SE cards uses priority 6, not the usual 7. The fix is to
modify the rtl8192se routine that sets the correct transmit queue.

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=74541

Reported-by: Alex Miller &lt;almiller_1@yahoo.co.uk&gt;
Tested-by: Alex Miller &lt;almiller_1@yahoo.co.uk&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt;    [3.13+]
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: remove tid-&gt;paused flag</title>
<updated>2014-04-30T15:42:35+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2014-04-28T16:32:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=62e54dbb599103ff461bb3fe6e32a3066da79754'/>
<id>62e54dbb599103ff461bb3fe6e32a3066da79754</id>
<content type='text'>
There are some corner cases where the driver could get stuck with a full
tid queue that is paused, leading to a software tx queue hang.

Since the tx queueing rework, pausing per-tid queues on aggregation
session setup is no longer necessary. The driver will assign sequence
numbers to buffered frames when a new session is established, in order
to get the correct starting sequence number.

mac80211 prevents new frames from entering the queue during setup.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are some corner cases where the driver could get stuck with a full
tid queue that is paused, leading to a software tx queue hang.

Since the tx queueing rework, pausing per-tid queues on aggregation
session setup is no longer necessary. The driver will assign sequence
numbers to buffered frames when a new session is established, in order
to get the correct starting sequence number.

mac80211 prevents new frames from entering the queue during setup.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k_hw: do not lower ANI setting below default on AR913x</title>
<updated>2014-04-30T15:39:54+00:00</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2014-04-27T14:37:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ae9c25a1826ca9602e89fe9c11700c63ce16d077'/>
<id>ae9c25a1826ca9602e89fe9c11700c63ce16d077</id>
<content type='text'>
When the amount of noise fluctuates strongly, low immunity settings
can sometimes disrupt signal detection on AR913x chips. When that
happens, no OFDM/CCK errors are reported anymore, and ANI tunes the
radio to the lowest immunity settings.
Usually rx/tx fails as well in that case.

To fix this, keep noise immunity settings at or above ANI default level,
which will keep radio parameters at or above INI values.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When the amount of noise fluctuates strongly, low immunity settings
can sometimes disrupt signal detection on AR913x chips. When that
happens, no OFDM/CCK errors are reported anymore, and ANI tunes the
radio to the lowest immunity settings.
Usually rx/tx fails as well in that case.

To fix this, keep noise immunity settings at or above ANI default level,
which will keep radio parameters at or above INI values.

Signed-off-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>brcmfmac: Fix brcmf_chip_ai_coredisable not applying reset bits to BCMA_IOCTL</title>
<updated>2014-04-25T01:46:22+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2014-04-23T10:20:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=ffa216bb5eecfce0f01b0b2a95d5c320dde90005'/>
<id>ffa216bb5eecfce0f01b0b2a95d5c320dde90005</id>
<content type='text'>
brcmfmac has been broken on my cubietruck with a BCM43362:

brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
        Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

since commit 53036261033: "brcmfmac: update core reset and disable routines".

The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.

This fixes brcmfmac hanging in firmware loading on my board.

Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
brcmfmac has been broken on my cubietruck with a BCM43362:

brcmfmac: brcmf_chip_recognition: found AXI chip: BCM43362, rev=1
brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
        Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d

since commit 53036261033: "brcmfmac: update core reset and disable routines".

The problem is that since this commit brcmf_chip_ai_resetcore no longer sets
BCMA_IOCTL itself before bringing the core out of reset, instead relying on
brcmf_chip_ai_coredisable to do so. But brcmf_chip_ai_coredisable is a nop
of the chip is already in reset. This patch modifies brcmf_chip_ai_coredisable
to always set BCMA_IOCTL even if the core is already in reset.

This fixes brcmfmac hanging in firmware loading on my board.

Cc: stable@vger.kernel.org # v3.14
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Acked-by: Arend van Spriel &lt;arend@broadcom.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix race in setting ATH_OP_INVALID</title>
<updated>2014-04-25T01:46:22+00:00</updated>
<author>
<name>Rajkumar Manoharan</name>
<email>rmanohar@qti.qualcomm.com</email>
</author>
<published>2014-04-23T09:37:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8c7ae357cc5b6bd037ad2d666e9f3789cf882925'/>
<id>8c7ae357cc5b6bd037ad2d666e9f3789cf882925</id>
<content type='text'>
The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.

Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qti.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The commit "ath9k: move sc_flags to ath_common" moved setting
ATH_OP_INVALID flag below ieee80211_register_hw. This is causing
the flag never being cleared randomly as the drv_start is called
prior to setting flag. Fix this by setting the flag prior to
register_hw.

Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qti.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: add a recv budget</title>
<updated>2014-04-22T18:09:37+00:00</updated>
<author>
<name>Tim Harvey</name>
<email>tharvey@gateworks.com</email>
</author>
<published>2014-04-21T23:14:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=c82552c5b0cb1735dbcbad78b1ffc6d3c212dc56'/>
<id>c82552c5b0cb1735dbcbad78b1ffc6d3c212dc56</id>
<content type='text'>
Implement a recv budget so that in cases of high traffic we still allow other
taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic
reception depending on system load including rcu stall's detected (ARM),
soft lockups, failure to service critical tasks such as watchdog resets,
and triggering of the tx stuck tasklet.

The same thing was proposed previously by Ben:
 http://www.spinics.net/lists/linux-wireless/msg112891.html

The only difference here is that I make sure only processed packets are counted
in the budget by checking at the end of the rx loop.

Signed-off-by: Tim Harvey &lt;tharvey@gateworks.com&gt;
Acked-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Implement a recv budget so that in cases of high traffic we still allow other
taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic
reception depending on system load including rcu stall's detected (ARM),
soft lockups, failure to service critical tasks such as watchdog resets,
and triggering of the tx stuck tasklet.

The same thing was proposed previously by Ben:
 http://www.spinics.net/lists/linux-wireless/msg112891.html

The only difference here is that I make sure only processed packets are counted
in the budget by checking at the end of the rx loop.

Signed-off-by: Tim Harvey &lt;tharvey@gateworks.com&gt;
Acked-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix possible hang on flush</title>
<updated>2014-04-22T18:09:37+00:00</updated>
<author>
<name>Tim Harvey</name>
<email>tharvey@gateworks.com</email>
</author>
<published>2014-04-21T23:14:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=3a758134e66ca74a9df792616b5288b2fa2cfd7f'/>
<id>3a758134e66ca74a9df792616b5288b2fa2cfd7f</id>
<content type='text'>
If a flush is requested, make sure to clear the descriptor once we've
processed it.

This resolves a hang that will occur if all RX descriptors are full when a
flush is requested.

Signed-off-by: Tim Harvey &lt;tharvey@gateworks.com&gt;
Acked-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a flush is requested, make sure to clear the descriptor once we've
processed it.

This resolves a hang that will occur if all RX descriptors are full when a
flush is requested.

Signed-off-by: Tim Harvey &lt;tharvey@gateworks.com&gt;
Acked-by: Felix Fietkau &lt;nbd@openwrt.org&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rtlwifi: rtl8188ee: initialize packet_beacon</title>
<updated>2014-04-22T18:09:37+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2014-04-21T16:38:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=328e203fc35f0b4f6df1c4943f74cf553bcc04f8'/>
<id>328e203fc35f0b4f6df1c4943f74cf553bcc04f8</id>
<content type='text'>
static code analysis from cppcheck reports:

[drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]:
  (error) Uninitialized variable: packet_beacon

packet_beacon is not initialized and hence packet_beacon
contains garbage from the stack, so set it to false.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt; [3.10+]
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
static code analysis from cppcheck reports:

[drivers/net/wireless/rtlwifi/rtl8188ee/trx.c:322]:
  (error) Uninitialized variable: packet_beacon

packet_beacon is not initialized and hence packet_beacon
contains garbage from the stack, so set it to false.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Cc: Stable &lt;stable@vger.kernel.org&gt; [3.10+]
Acked-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>rt2x00: fix beaconing on USB</title>
<updated>2014-04-22T18:07:48+00:00</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2014-04-17T09:08:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.exis.tech/linux.git/commit/?id=8834d3608cc516f13e2e510f4057c263f3d2ce42'/>
<id>8834d3608cc516f13e2e510f4057c263f3d2ce42</id>
<content type='text'>
When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When disable beaconing we clear register with beacon and newer set it
back, what make we stop send beacons infinitely.

Cc: stable@vger.kernel.org
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
