<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net/wireless, branch v4.7.2</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>brcmfmac: restore stopping netdev queue when bus clogs up</title>
<updated>2016-08-20T16:10:53+00:00</updated>
<author>
<name>Arend Van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2016-07-15T10:16:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=86825b84e701f71e77bd898fdf83df93e74dee5e'/>
<id>86825b84e701f71e77bd898fdf83df93e74dee5e</id>
<content type='text'>
commit 82bc9ab6a8f577d2174a736c33f3d4ecf7d9ef47 upstream.

When the host-interface bus has hard time handling transmit packets
it informs higher layer about this and it would stop the netdev
queue when needed. However, since commit 9cd18359d31e ("brcmfmac:
Make FWS queueing configurable.") this was broken. With this patch
the behaviour is restored.

Fixes: 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.")
Tested-by: Per Förlin &lt;per.forlin@gmail.com&gt;
Reviewed-by: Hante Meuleman &lt;hante.meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieter-paul.giesberts@broadcom.com&gt;
Reviewed-by: Franky Lin &lt;franky.lin@broadcom.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 82bc9ab6a8f577d2174a736c33f3d4ecf7d9ef47 upstream.

When the host-interface bus has hard time handling transmit packets
it informs higher layer about this and it would stop the netdev
queue when needed. However, since commit 9cd18359d31e ("brcmfmac:
Make FWS queueing configurable.") this was broken. With this patch
the behaviour is restored.

Fixes: 9cd18359d31e ("brcmfmac: Make FWS queueing configurable.")
Tested-by: Per Förlin &lt;per.forlin@gmail.com&gt;
Reviewed-by: Hante Meuleman &lt;hante.meuleman@broadcom.com&gt;
Reviewed-by: Pieter-Paul Giesberts &lt;pieter-paul.giesberts@broadcom.com&gt;
Reviewed-by: Franky Lin &lt;franky.lin@broadcom.com&gt;
Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: add new 8265</title>
<updated>2016-08-20T16:10:53+00:00</updated>
<author>
<name>Oren Givon</name>
<email>oren.givon@intel.com</email>
</author>
<published>2016-05-23T06:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=46f3ab603b921e9d80306566907cb50f25730f21'/>
<id>46f3ab603b921e9d80306566907cb50f25730f21</id>
<content type='text'>
commit f24bbae565d279cd90c904fe55b539a45631705e upstream.

Add 6 new 8265 series PCI IDs:
  - (0x24FD, 0x1130)
  - (0x24FD, 0x0130)
  - (0x24FD, 0x0910)
  - (0x24FD, 0x0930)
  - (0x24FD, 0x0950)
  - (0x24FD, 0x0850)

Signed-off-by: Oren Givon &lt;oren.givon@intel.com&gt;
Signed-off-by: David Spinadel &lt;david.spinadel@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f24bbae565d279cd90c904fe55b539a45631705e upstream.

Add 6 new 8265 series PCI IDs:
  - (0x24FD, 0x1130)
  - (0x24FD, 0x0130)
  - (0x24FD, 0x0910)
  - (0x24FD, 0x0930)
  - (0x24FD, 0x0950)
  - (0x24FD, 0x0850)

Signed-off-by: Oren Givon &lt;oren.givon@intel.com&gt;
Signed-off-by: David Spinadel &lt;david.spinadel@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: add new 8260 PCI IDs</title>
<updated>2016-08-20T16:10:53+00:00</updated>
<author>
<name>Oren Givon</name>
<email>oren.givon@intel.com</email>
</author>
<published>2016-05-23T06:58:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a5d4f5196d00d5bfae124ab1f2f46e11a1eeb781'/>
<id>a5d4f5196d00d5bfae124ab1f2f46e11a1eeb781</id>
<content type='text'>
commit 4b79deece5d45396422d469afa11f9d69ccb3d8b upstream.

Add 3 new 8260 series PCI IDs:
  - (0x24F3, 0x10B0)
  - (0x24F3, 0xD0B0)
  - (0x24F3, 0xB0B0)

Signed-off-by: Oren Givon &lt;oren.givon@intel.com&gt;
Signed-off-by: David Spinadel &lt;david.spinadel@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4b79deece5d45396422d469afa11f9d69ccb3d8b upstream.

Add 3 new 8260 series PCI IDs:
  - (0x24F3, 0x10B0)
  - (0x24F3, 0xD0B0)
  - (0x24F3, 0xB0B0)

Signed-off-by: Oren Givon &lt;oren.givon@intel.com&gt;
Signed-off-by: David Spinadel &lt;david.spinadel@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: fix a race in firmware loading flow</title>
<updated>2016-08-20T16:10:53+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2016-06-13T05:28:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3de99eb07b92ebc433303692b70ab17848012119'/>
<id>3de99eb07b92ebc433303692b70ab17848012119</id>
<content type='text'>
commit f16c3ebfa64fdf0e2dc88e6baa72da95ab70ffd7 upstream.

Upon firmware load interrupt (FH_TX), the ISR re-enables the
firmware load interrupt only to avoid races with other
flows as described in the commit below. When the firmware
is completely loaded, the thread that is loading the
firmware will enable all the interrupts to make sure that
the driver gets the ALIVE interrupt.
The problem with that is that the thread that is loading
the firmware is actually racing against the ISR and we can
get to the following situation:

CPU0					CPU1
iwl_pcie_load_given_ucode
	...
	iwl_pcie_load_firmware_chunk
		wait_for_interrupt
					&lt;interrupt&gt;
					ISR handles CSR_INT_BIT_FH_TX
					ISR wakes up the thread on CPU0
	/* enable all the interrupts
	 * to get the ALIVE interrupt
	 */
	iwl_enable_interrupts
					ISR re-enables CSR_INT_BIT_FH_TX only
	/* start the firmware */
	iwl_write32(trans, CSR_RESET, 0);

BUG! ALIVE interrupt will never arrive since it has been
masked by CPU1.

In order to fix that, change the ISR to first check if
STATUS_INT_ENABLED is set. If so, re-enable all the
interrupts. If STATUS_INT_ENABLED is clear, then we can
check what specific interrupt happened and re-enable only
that specific interrupt (RFKILL or FH_TX).

All the credit for the analysis goes to Kirtika who did the
actual debugging work.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit f16c3ebfa64fdf0e2dc88e6baa72da95ab70ffd7 upstream.

Upon firmware load interrupt (FH_TX), the ISR re-enables the
firmware load interrupt only to avoid races with other
flows as described in the commit below. When the firmware
is completely loaded, the thread that is loading the
firmware will enable all the interrupts to make sure that
the driver gets the ALIVE interrupt.
The problem with that is that the thread that is loading
the firmware is actually racing against the ISR and we can
get to the following situation:

CPU0					CPU1
iwl_pcie_load_given_ucode
	...
	iwl_pcie_load_firmware_chunk
		wait_for_interrupt
					&lt;interrupt&gt;
					ISR handles CSR_INT_BIT_FH_TX
					ISR wakes up the thread on CPU0
	/* enable all the interrupts
	 * to get the ALIVE interrupt
	 */
	iwl_enable_interrupts
					ISR re-enables CSR_INT_BIT_FH_TX only
	/* start the firmware */
	iwl_write32(trans, CSR_RESET, 0);

BUG! ALIVE interrupt will never arrive since it has been
masked by CPU1.

In order to fix that, change the ISR to first check if
STATUS_INT_ENABLED is set. If so, re-enable all the
interrupts. If STATUS_INT_ENABLED is clear, then we can
check what specific interrupt happened and re-enable only
that specific interrupt (RFKILL or FH_TX).

All the credit for the analysis goes to Kirtika who did the
actual debugging work.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>iwlwifi: pcie: enable interrupts before releasing the NIC's CPU</title>
<updated>2016-08-20T16:10:53+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2016-06-08T20:07:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c04cc6df704ecadb26a1574fb0b7ad6846983080'/>
<id>c04cc6df704ecadb26a1574fb0b7ad6846983080</id>
<content type='text'>
commit 2aabdbdc17b7c53490337bfc58de3409c84d85d2 upstream.

The NIC's CPU gets started after the firmware has been
written to its memory. The first thing it does is to
send an interrupt to let the driver know that it is
running. In order to get that interrupt, the driver needs
to make sure it is not masked. Of course, the interrupt
needs to be enabled in the driver before the CPU starts to
run.
I mistakenly inversed those two steps leading to races
which prevented the driver from getting the alive interrupt
from the firmware.
Fix that.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2aabdbdc17b7c53490337bfc58de3409c84d85d2 upstream.

The NIC's CPU gets started after the firmware has been
written to its memory. The first thing it does is to
send an interrupt to let the driver know that it is
running. In order to get that interrupt, the driver needs
to make sure it is not masked. Of course, the interrupt
needs to be enabled in the driver before the CPU starts to
run.
I mistakenly inversed those two steps leading to races
which prevented the driver from getting the alive interrupt
from the firmware.
Fix that.

Fixes: a6bd005fe92 ("iwlwifi: pcie: fix RF-Kill vs. firmware load race")
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Signed-off-by: Luca Coelho &lt;luciano.coelho@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'wireless-drivers-for-davem-2016-06-21' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers</title>
<updated>2016-06-23T19:22:31+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2016-06-23T19:22:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00e8cb00bc72f5279fde9d014b47f36dc4805dd8'/>
<id>00e8cb00bc72f5279fde9d014b47f36dc4805dd8</id>
<content type='text'>
Kalle Valo says:

====================
wireless-drivers fixes for 4.7

iwlwifi

* fix the scan timeout for long scans
* fix an RCU splat caused when updating the TKIP key
* fix a potential NULL-derefence introduced recently
* fix a IGTK key bug that has existed since the MVM driver was introduced
* fix some fw capabilities checks that got accidentally inverted

rtl8xxxu

* fix typo on variable name

ath10k

* fix deadlock when peer cannot be created
* fix crash related to printing features
* fix deadlock while processing rx_in_ord_ind

ath9k

* fix GPIO mask regression for AR9462 and AR9565
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Kalle Valo says:

====================
wireless-drivers fixes for 4.7

iwlwifi

* fix the scan timeout for long scans
* fix an RCU splat caused when updating the TKIP key
* fix a potential NULL-derefence introduced recently
* fix a IGTK key bug that has existed since the MVM driver was introduced
* fix some fw capabilities checks that got accidentally inverted

rtl8xxxu

* fix typo on variable name

ath10k

* fix deadlock when peer cannot be created
* fix crash related to printing features
* fix deadlock while processing rx_in_ord_ind

ath9k

* fix GPIO mask regression for AR9462 and AR9565
====================

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge ath-current from ath.git</title>
<updated>2016-06-16T14:55:19+00:00</updated>
<author>
<name>Kalle Valo</name>
<email>kvalo@codeaurora.org</email>
</author>
<published>2016-06-16T14:55:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=034fdd4a17ff089c2428ece18efa65c5396810d2'/>
<id>034fdd4a17ff089c2428ece18efa65c5396810d2</id>
<content type='text'>
ath.git fixes for 4.7. Major changes:

ath9k

* fix GPIO mask regression with AR9462 and AR9565

ath10k

* fix deadlock while processing rx_in_ord_ind
* fix crash related to printing firmware features in debug mode
* fix deadlock when peer cannot be created
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
ath.git fixes for 4.7. Major changes:

ath9k

* fix GPIO mask regression with AR9462 and AR9565

ath10k

* fix deadlock while processing rx_in_ord_ind
* fix crash related to printing firmware features in debug mode
* fix deadlock when peer cannot be created
</pre>
</div>
</content>
</entry>
<entry>
<title>rtl8xxxu: fix typo on variable name, compare against correct variable</title>
<updated>2016-06-16T14:49:18+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.king@canonical.com</email>
</author>
<published>2016-06-09T18:38:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c70410cb91de70707a507ee7beef7021a5a89f0d'/>
<id>c70410cb91de70707a507ee7beef7021a5a89f0d</id>
<content type='text'>
path_b_ok is being assigned but immediately after path_a_ok is being
compared to the value 0x03.  This appears to be a typo on the
variable name, compare path_b_ok instead.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Jes Sorensen &lt;Jes.Sorensen@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
path_b_ok is being assigned but immediately after path_a_ok is being
compared to the value 0x03.  This appears to be a typo on the
variable name, compare path_b_ok instead.

Signed-off-by: Colin Ian King &lt;colin.king@canonical.com&gt;
Signed-off-by: Jes Sorensen &lt;Jes.Sorensen@redhat.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath9k: fix GPIO mask for AR9462 and AR9565</title>
<updated>2016-06-14T13:21:31+00:00</updated>
<author>
<name>Miaoqing Pan</name>
<email>miaoqing@codeaurora.org</email>
</author>
<published>2016-06-07T12:47:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e024111f6946f45cf1559a8c6fd48d2d0f696d07'/>
<id>e024111f6946f45cf1559a8c6fd48d2d0f696d07</id>
<content type='text'>
The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
Also fix the mask for AR9565.

WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778 ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
CPU: 1 PID: 199 Comm: kworker/u16:9 Not tainted 4.7.0-rc1-next-20160530+ #5
Hardware name: Acer TravelMate P243/BA40_HC, BIOS V1.01 04/20/2012
Workqueue: events_power_efficient rfkill_poll
 0000000000000000 ffff88002cf73d28 ffffffff813b8ddc 0000000000000000
 0000000000000000 ffff88002cf73d68 ffffffff8107a331 00000ada00000086
 ffff880148d9c018 000000000000000b ffff880147e68720 0000000000000200
Call Trace:
 [&lt;ffffffff813b8ddc&gt;] dump_stack+0x63/0x87
 [&lt;ffffffff8107a331&gt;] __warn+0xd1/0xf0
 [&lt;ffffffff8107a41d&gt;] warn_slowpath_null+0x1d/0x20
 [&lt;ffffffffc0775b19&gt;] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
 [&lt;ffffffffc047f3e4&gt;] ath9k_rfkill_poll_state+0x34/0x60 [ath9k]
 [&lt;ffffffffc06dbb53&gt;] ieee80211_rfkill_poll+0x33/0x40 [mac80211]
 [&lt;ffffffffc03ad65a&gt;] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211]
 [&lt;ffffffff817c5514&gt;] rfkill_poll+0x24/0x50
 [&lt;ffffffff81093183&gt;] process_one_work+0x153/0x3f0
 [&lt;ffffffff8109393b&gt;] worker_thread+0x12b/0x4b0
 [&lt;ffffffff81093810&gt;] ? rescuer_thread+0x340/0x340
 [&lt;ffffffff81099129&gt;] kthread+0xc9/0xe0
 [&lt;ffffffff817d8f1f&gt;] ret_from_fork+0x1f/0x40
 [&lt;ffffffff81099060&gt;] ? kthread_park+0x60/0x60

Fixes: a01ab81b09c5 ("ath9k: define correct GPIO numbers and bits mask")
Reported-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Tested-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Signed-off-by: Miaoqing Pan &lt;miaoqing@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
Also fix the mask for AR9565.

WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778 ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
CPU: 1 PID: 199 Comm: kworker/u16:9 Not tainted 4.7.0-rc1-next-20160530+ #5
Hardware name: Acer TravelMate P243/BA40_HC, BIOS V1.01 04/20/2012
Workqueue: events_power_efficient rfkill_poll
 0000000000000000 ffff88002cf73d28 ffffffff813b8ddc 0000000000000000
 0000000000000000 ffff88002cf73d68 ffffffff8107a331 00000ada00000086
 ffff880148d9c018 000000000000000b ffff880147e68720 0000000000000200
Call Trace:
 [&lt;ffffffff813b8ddc&gt;] dump_stack+0x63/0x87
 [&lt;ffffffff8107a331&gt;] __warn+0xd1/0xf0
 [&lt;ffffffff8107a41d&gt;] warn_slowpath_null+0x1d/0x20
 [&lt;ffffffffc0775b19&gt;] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
 [&lt;ffffffffc047f3e4&gt;] ath9k_rfkill_poll_state+0x34/0x60 [ath9k]
 [&lt;ffffffffc06dbb53&gt;] ieee80211_rfkill_poll+0x33/0x40 [mac80211]
 [&lt;ffffffffc03ad65a&gt;] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211]
 [&lt;ffffffff817c5514&gt;] rfkill_poll+0x24/0x50
 [&lt;ffffffff81093183&gt;] process_one_work+0x153/0x3f0
 [&lt;ffffffff8109393b&gt;] worker_thread+0x12b/0x4b0
 [&lt;ffffffff81093810&gt;] ? rescuer_thread+0x340/0x340
 [&lt;ffffffff81099129&gt;] kthread+0xc9/0xe0
 [&lt;ffffffff817d8f1f&gt;] ret_from_fork+0x1f/0x40
 [&lt;ffffffff81099060&gt;] ? kthread_park+0x60/0x60

Fixes: a01ab81b09c5 ("ath9k: define correct GPIO numbers and bits mask")
Reported-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Tested-by: Sudip Mukherjee &lt;sudip.mukherjee@codethink.co.uk&gt;
Signed-off-by: Miaoqing Pan &lt;miaoqing@codeaurora.org&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ath10k: fix deadlock while processing rx_in_ord_ind</title>
<updated>2016-06-14T12:06:17+00:00</updated>
<author>
<name>Rajkumar Manoharan</name>
<email>rmanohar@qti.qualcomm.com</email>
</author>
<published>2016-06-09T06:03:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e50525bef593c3dd0564df676c567d77f7c20322'/>
<id>e50525bef593c3dd0564df676c567d77f7c20322</id>
<content type='text'>
commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.

Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 &amp; qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes

=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G            E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
 (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d7ef19&gt;]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]

but task is already holding lock:
 (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d82cab&gt;]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock);
  lock(&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by swapper/3/0:
 #0:  (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d82cab&gt;]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian &lt;mike@fireburn.co.uk&gt;
Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qti.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
introduced deadlock while processing rx in order indication message
for qca6174 based devices. While merging replenish and txrx tasklets,
replenish task should be called out of htt rx ring locking since it
is also try to acquire the same lock.

Unfortunately this issue is not exposed by other solutions (qca988x,
qca99x0 &amp; qca4019), as rx_in_ord_ind message is specific to qca6174
based devices. This patch fixes

=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-wt-ath+ #1353 Tainted: G            E
---------------------------------------------
swapper/3/0 is trying to acquire lock:
 (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d7ef19&gt;]
ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]

but task is already holding lock:
 (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d82cab&gt;]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock);
  lock(&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock);

 *** DEADLOCK ***

 May be due to missing lock nesting notation

1 lock held by swapper/3/0:
 #0:  (&amp;(&amp;htt-&gt;rx_ring.lock)-&gt;rlock){+.-...}, at: [&lt;f8d82cab&gt;]
ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
Fixes: 5c86d97bcc1d ("ath10k: combine txrx and replenish task")
Reported-by: Mike Lothian &lt;mike@fireburn.co.uk&gt;
Signed-off-by: Rajkumar Manoharan &lt;rmanohar@qti.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
