<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/net/wireless, branch v3.11.3</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.11.3</id>
<link rel='self' href='https://git.amat.us/linux/atom/drivers/net/wireless?h=v3.11.3'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2013-10-01T16:41:02Z</updated>
<entry>
<title>cw1200: Don't perform SPI transfers in interrupt context</title>
<updated>2013-10-01T16:41:02Z</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-08-28T00:29:46Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2236ad2913d353ecb1d78231600372def5c94473'/>
<id>urn:sha1:2236ad2913d353ecb1d78231600372def5c94473</id>
<content type='text'>
commit aec8e88c947b7017e2b4bbcb68a4bfc4a1f8ad35 upstream.

When we get an interrupt from the hardware, the first thing the driver does
is tell the device to mask off the interrupt line.  Unfortunately this
involves a SPI transaction in interrupt context.  Some (most?) SPI
controllers perform the transfer asynchronously and try to sleep.
This is bad, and triggers a BUG().

So, work around this by using adding a hwbus hook for the cw1200 driver
core to call.  The cw1200_spi driver translates this into
irq_disable()/irq_enable() calls instead, which can safely be called in
interrupt context.

Apparently the platforms I used to develop the cw1200_spi driver used
synchronous spi_sync() implementations, which is why this didn't surface
until now.

Many thanks to Dave Sizeburns for the inital bug report and his services
as a tester.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.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>cw1200: Prevent a lock-related hang in the cw1200_spi driver</title>
<updated>2013-10-01T16:41:02Z</updated>
<author>
<name>Solomon Peachy</name>
<email>pizza@shaftnet.org</email>
</author>
<published>2013-08-28T00:29:47Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=524a992af32af99a4fa8521640ba5bb38fde41d1'/>
<id>urn:sha1:524a992af32af99a4fa8521640ba5bb38fde41d1</id>
<content type='text'>
commit 85ba8f529c57ac6e2fca9be0d9e17920a1afb2e8 upstream.

The cw1200_spi driver tries to mirror the cw1200_sdio driver's lock
API, which relies on sdio_claim_host/sdio_release_host to serialize
hardware operations across multiple threads.

Unfortunately the implementation was flawed, as it lacked a way to wake
up the lock requestor when there was contention, often resulting in a
hang.

This problem was uncovered while trying to fix the
spi-transfers-in-interrupt-context BUG() corrected in the previous
patch.  Many thanks to Dave Sizeburns for his assistance in fixing this.

Signed-off-by: Solomon Peachy &lt;pizza@shaftnet.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>rt2800: fix wrong TX power compensation</title>
<updated>2013-10-01T16:40:58Z</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2013-08-26T13:18:53Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8a1785c3c1ce85a36d3088e3322f9a2619716bd'/>
<id>urn:sha1:b8a1785c3c1ce85a36d3088e3322f9a2619716bd</id>
<content type='text'>
commit 6e956da2027c767859128b9bfef085cf2a8e233b upstream.

We should not do temperature compensation on devices without
EXTERNAL_TX_ALC bit set (called DynamicTxAgcControl on vendor driver).
Such devices can have totally bogus TSSI parameters on the EEPROM,
but still threaded by us as valid and result doing wrong TX power
calculations.

This fix inability to connect to AP on slightly longer distance on
some Ralink chips/devices.

Reported-and-tested-by: Fabien ADAM &lt;id2ndr@crocobox.org&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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>rt2800: change initialization sequence to fix system freeze</title>
<updated>2013-10-01T16:40:58Z</updated>
<author>
<name>Stanislaw Gruszka</name>
<email>sgruszka@redhat.com</email>
</author>
<published>2013-09-09T10:37:37Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2ad776fc3d2c243dc6fd51139dde92aac9c841ac'/>
<id>urn:sha1:2ad776fc3d2c243dc6fd51139dde92aac9c841ac</id>
<content type='text'>
commit f4e1a4d3ecbb9e42bdf8e7869ee8a4ebfa27fb20 upstream.

My commit

commit c630ccf1a127578421a928489d51e99c05037054
Author: Stanislaw Gruszka &lt;stf_xl@wp.pl&gt;
Date:   Sat Mar 16 19:19:46 2013 +0100

    rt2800: rearrange bbp/rfcsr initialization

make Maxim machine freeze when try to start wireless device.

Initialization order and sending MCU_BOOT_SIGNAL request, changed in
above commit, is important. Doing things incorrectly make PCIe bus
problems, which can froze the machine.

This patch change initialization sequence like vendor driver do:
function NICInitializeAsic() from
2011_1007_RT5390_RT5392_Linux_STA_V2.5.0.3_DPO (PCI devices) and
DPO_RT5572_LinuxSTA_2.6.1.3_20121022 (according Mediatek, latest driver
for RT8070/RT3070/RT3370/RT3572/RT5370/RT5372/RT5572 USB devices).
It fixes freezes on Maxim system.

Resolve:
https://bugzilla.redhat.com/show_bug.cgi?id=1000679

Reported-and-tested-by: Maxim Polyakov &lt;polyakov@dexmalabs.com&gt;
Bisected-by: Igor Gnatenko &lt;i.gnatenko.brain@gmail.com&gt;
Signed-off-by: Stanislaw Gruszka &lt;sgruszka@redhat.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: avoid accessing MRC registers on single-chain devices</title>
<updated>2013-09-27T00:21:45Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-08-13T10:33:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c661b37a34b6449d533c109472e19c7b005d164b'/>
<id>urn:sha1:c661b37a34b6449d533c109472e19c7b005d164b</id>
<content type='text'>
commit a1c781bb20ac1e03280e420abd47a99eb8bbdd3b upstream.

They are not implemented, and accessing them might trigger errors

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>ath9k: fix rx descriptor related race condition</title>
<updated>2013-09-27T00:21:45Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-08-10T13:59:15Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=452c0dc821996470f847ac57dd3ca51a34a4c017'/>
<id>urn:sha1:452c0dc821996470f847ac57dd3ca51a34a4c017</id>
<content type='text'>
commit e96542e55a2aacf4bdeccfe2f17b77c4895b4df2 upstream.

Similar to a race condition that exists in the tx path, the hardware
might re-read the 'next' pointer of a descriptor of the last completed
frame. This only affects non-EDMA (pre-AR93xx) devices.

To deal with this race, defer clearing and re-linking a completed rx
descriptor until the next one has been processed.

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>ath9k: always clear ps filter bit on new assoc</title>
<updated>2013-09-27T00:21:45Z</updated>
<author>
<name>Felix Fietkau</name>
<email>nbd@openwrt.org</email>
</author>
<published>2013-08-06T12:18:10Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6b8aad8df84daa0175627f36b2f299ba8e7b55e6'/>
<id>urn:sha1:6b8aad8df84daa0175627f36b2f299ba8e7b55e6</id>
<content type='text'>
commit 026d5b07c03458f9c0ccd19c3850564a5409c325 upstream.

Otherwise in some cases, EAPOL frames might be filtered during the
initial handshake, causing delays and assoc failures.

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>brcmsmac: Fix WARNING caused by lack of calls to dma_mapping_error()</title>
<updated>2013-09-27T00:21:44Z</updated>
<author>
<name>John W. Linville</name>
<email>linville@tuxdriver.com</email>
</author>
<published>2013-08-09T17:36:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1bb32952f9ec5a841d199d82a8c70328b0ee5cb6'/>
<id>urn:sha1:1bb32952f9ec5a841d199d82a8c70328b0ee5cb6</id>
<content type='text'>
commit 67d0cf50bd32b66eab709871714e55725ee30ce4 upstream.

The driver fails to check the results of DMA mapping in twp places,
which results in the following warning:

[   28.078515] ------------[ cut here ]------------
[   28.078529] WARNING: at lib/dma-debug.c:937 check_unmap+0x47e/0x930()
[   28.078533] bcma-pci-bridge 0000:0e:00.0: DMA-API: device driver failed to check map error[device address=0x00000000b5d60d6c] [size=1876 bytes] [mapped as
 single]
[   28.078536] Modules linked in: bnep bluetooth vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) ipv6 b43 brcmsmac rtl8192cu rtl8192c_common rtlwifi mac802
11 brcmutil cfg80211 snd_hda_codec_conexant rng_core snd_hda_intel kvm_amd snd_hda_codec ssb kvm mmc_core snd_pcm snd_seq snd_timer snd_seq_device snd k8temp
 cordic joydev serio_raw hwmon sr_mod sg pcmcia pcmcia_core soundcore cdrom i2c_nforce2 i2c_core forcedeth bcma snd_page_alloc autofs4 ext4 jbd2 mbcache crc1
6 scsi_dh_alua scsi_dh_hp_sw scsi_dh_rdac scsi_dh_emc scsi_dh ata_generic pata_amd
[   28.078602] CPU: 1 PID: 2570 Comm: NetworkManager Tainted: G           O 3.10.0-rc7-wl+ #42
[   28.078605] Hardware name: Hewlett-Packard HP Pavilion dv2700 Notebook PC/30D6, BIOS F.27 11/27/2008
[   28.078607]  0000000000000009 ffff8800bbb03ad8 ffffffff8144f898 ffff8800bbb03b18
[   28.078612]  ffffffff8103e1eb 0000000000000002 ffff8800b719f480 ffff8800b7b9c010
[   28.078617]  ffffffff824204c0 ffffffff81754d57 0000000000000754 ffff8800bbb03b78
[   28.078622] Call Trace:
[   28.078624]  &lt;IRQ&gt;  [&lt;ffffffff8144f898&gt;] dump_stack+0x19/0x1b
[   28.078634]  [&lt;ffffffff8103e1eb&gt;] warn_slowpath_common+0x6b/0xa0
[   28.078638]  [&lt;ffffffff8103e2c1&gt;] warn_slowpath_fmt+0x41/0x50
[   28.078650]  [&lt;ffffffff8122d7ae&gt;] check_unmap+0x47e/0x930
[   28.078655]  [&lt;ffffffff8122de4c&gt;] debug_dma_unmap_page+0x5c/0x70
[   28.078679]  [&lt;ffffffffa04a808c&gt;] dma64_getnextrxp+0x10c/0x190 [brcmsmac]
[   28.078691]  [&lt;ffffffffa04a9042&gt;] dma_rx+0x62/0x240 [brcmsmac]
[   28.078707]  [&lt;ffffffffa0479101&gt;] brcms_c_dpc+0x211/0x9d0 [brcmsmac]
[   28.078717]  [&lt;ffffffffa046d927&gt;] ? brcms_dpc+0x27/0xf0 [brcmsmac]
[   28.078731]  [&lt;ffffffffa046d947&gt;] brcms_dpc+0x47/0xf0 [brcmsmac]
[   28.078736]  [&lt;ffffffff81047dcc&gt;] tasklet_action+0x6c/0xf0
--snip--
[   28.078974]  [&lt;ffffffff813891bd&gt;] SyS_sendmsg+0xd/0x20
[   28.078979]  [&lt;ffffffff81455c24&gt;] tracesys+0xdd/0xe2
[   28.078982] ---[ end trace 6164d1a08148e9c8 ]---
[   28.078984] Mapped at:
[   28.078985]  [&lt;ffffffff8122c8fd&gt;] debug_dma_map_page+0x9d/0x150
[   28.078989]  [&lt;ffffffffa04a9322&gt;] dma_rxfill+0x102/0x3d0 [brcmsmac]
[   28.079001]  [&lt;ffffffffa047a13d&gt;] brcms_c_init+0x87d/0x1100 [brcmsmac]
[   28.079010]  [&lt;ffffffffa046d851&gt;] brcms_init+0x21/0x30 [brcmsmac]
[   28.079018]  [&lt;ffffffffa04786e0&gt;] brcms_c_up+0x150/0x430 [brcmsmac]

As the patch adds a new failure mechanism to dma_rxfill(). When I changed the
comment at the start of the routine to add that information, I also polished
the wording.

Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: Brett Rudley &lt;brudley@broadcom.com&gt;
Cc: Franky (Zhenhui) Lin &lt;frankyl@broadcom.com&gt;
Cc: Hante Meuleman &lt;meuleman@broadcom.com&gt;
Cc: brcm80211-dev-list@broadcom.com
Acked-by: Arend van Spriel &lt;arend@broadcom.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: do not create AP and P2P interfaces upon driver loading</title>
<updated>2013-09-14T14:06:46Z</updated>
<author>
<name>Bing Zhao</name>
<email>bzhao@marvell.com</email>
</author>
<published>2013-08-19T23:10:21Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ae7ab51a0ad97b41a3e173a52af033dd9e5eb118'/>
<id>urn:sha1:ae7ab51a0ad97b41a3e173a52af033dd9e5eb118</id>
<content type='text'>
commit 1211c961170cedb21c30d5bb7e2033c8720b38db upstream.

Bug 60747 - 1286:2044 [Microsoft Surface Pro]
    Marvell 88W8797 wifi show 3 interface under network
https://bugzilla.kernel.org/show_bug.cgi?id=60747

This issue was also reported previously by OLPC and some folks from
the community.

There are 3 network interfaces with different types being created
when mwifiex driver is loaded:

1. mlan0 (infra. STA)
2. uap0 (AP)
3. p2p0 (P2P_CLIENT)

The Network Manager attempts to use all 3 interfaces above without
filtering the managed interface type. As the result, 3 identical
interfaces are displayed under network manager. If user happens to
click on an entry under which its interface is uap0 or p2p0, the
association will fail.

Work around it by removing the creation of AP and P2P interfaces
at driver loading time. These interfaces can be added with 'iw' or
other applications manually when they are needed.

Signed-off-by: Bing Zhao &lt;bzhao@marvell.com&gt;
Signed-off-by: Avinash Patil &lt;patila@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: Enable PLL fix only for AR9340/AR9330</title>
<updated>2013-08-22T18:21:04Z</updated>
<author>
<name>Sujith Manoharan</name>
<email>c_manoha@qca.qualcomm.com</email>
</author>
<published>2013-08-20T04:35:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=19c361608ce3e73f352e323262f7e0a8264be3af'/>
<id>urn:sha1:19c361608ce3e73f352e323262f7e0a8264be3af</id>
<content type='text'>
The PLL hang workaround is required only for AR9330 and
AR9340. This issue was first observed on an AP121 and the WAR
is enabled for AR9340 also (DB120 etc.), since it uses a PLL
design identical to AR9330. This is not required for AR9485 and AR9550.

Various bugs have been reported regarding this:

https://bugzilla.redhat.com/show_bug.cgi?id=997217
https://bugzilla.redhat.com/show_bug.cgi?id=994648

Cc: stable@vger.kernel.org
Signed-off-by: Sujith Manoharan &lt;c_manoha@qca.qualcomm.com&gt;
Signed-off-by: John W. Linville &lt;linville@tuxdriver.com&gt;
</content>
</entry>
</feed>
