<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/net/wireless, branch v4.4.93</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>iwlwifi: mvm: use IWL_HCMD_NOCOPY for MCAST_FILTER_CMD</title>
<updated>2017-10-18T07:20:41+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2017-09-01T14:59:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=45bd4e40804009d0f312ce8640d1f6a1aa306aa4'/>
<id>45bd4e40804009d0f312ce8640d1f6a1aa306aa4</id>
<content type='text'>
commit 97bce57bd7f96e1218751996f549a6e61f18cc8c upstream.

The MCAST_FILTER_CMD can get quite large when we have many mcast
addresses to set (we support up to 255).  So the command should be
send as NOCOPY to prevent a warning caused by too-long commands:

WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]
Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743

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 97bce57bd7f96e1218751996f549a6e61f18cc8c upstream.

The MCAST_FILTER_CMD can get quite large when we have many mcast
addresses to set (we support up to 255).  So the command should be
send as NOCOPY to prevent a warning caused by too-long commands:

WARNING: CPU: 0 PID: 9700 at /root/iwlwifi/stack-dev/drivers/net/wireless/intel/iwlwifi/pcie/tx.c:1550 iwl_pcie_enqueue_hcmd+0x8c7/0xb40 [iwlwifi]
Command MCAST_FILTER_CMD (0x1d0) is too large (328 bytes)

This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=196743

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>brcmfmac: add length check in brcmf_cfg80211_escan_handler()</title>
<updated>2017-10-18T07:20:40+00:00</updated>
<author>
<name>Arend Van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2017-09-12T08:47:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6721969c7b8a35f85a41acaabdad190ed32cf704'/>
<id>6721969c7b8a35f85a41acaabdad190ed32cf704</id>
<content type='text'>
commit 17df6453d4be17910456e99c5a85025aa1b7a246 upstream.

Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.

Cc: Kevin Cernekee &lt;cernekee@chromium.org&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 17df6453d4be17910456e99c5a85025aa1b7a246 upstream.

Upon handling the firmware notification for scans the length was
checked properly and may result in corrupting kernel heap memory
due to buffer overruns. This fix addresses CVE-2017-0786.

Cc: Kevin Cernekee &lt;cernekee@chromium.org&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>brcmfmac: setup passive scan if requested by user-space</title>
<updated>2017-10-12T09:27:35+00:00</updated>
<author>
<name>Arend Van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2017-09-12T08:47:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=b8af4466255c0898c6ba14b729926d610a89d86a'/>
<id>b8af4466255c0898c6ba14b729926d610a89d86a</id>
<content type='text'>
commit 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.

Reported-by: Huang, Jiangyang &lt;Jiangyang.Huang@itron.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 35f62727df0ed8e5e4857e162d94fd46d861f1cf upstream.

The driver was not properly configuring firmware with regard to the
type of scan. It always performed an active scan even when user-space
was requesting for passive scan, ie. the scan request was done without
any SSIDs specified.

Reported-by: Huang, Jiangyang &lt;Jiangyang.Huang@itron.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 workaround to disable wide channels in 5GHz</title>
<updated>2017-10-12T09:27:33+00:00</updated>
<author>
<name>Luca Coelho</name>
<email>luciano.coelho@intel.com</email>
</author>
<published>2017-08-15T17:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=fc29713fa7c78fda30855444eeab2d5ea8088762'/>
<id>fc29713fa7c78fda30855444eeab2d5ea8088762</id>
<content type='text'>
commit 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels
in the 5.2GHz band.  The firmware has been modified to not allow this
in those SKUs, so the driver needs to do the same otherwise the
firmware will assert when we try to use it.

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 01a9c948a09348950515bf2abb6113ed83e696d8 upstream.

The OTP in some SKUs have erroneously allowed 40MHz and 80MHz channels
in the 5.2GHz band.  The firmware has been modified to not allow this
in those SKUs, so the driver needs to do the same otherwise the
firmware will assert when we try to use it.

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>mwifiex: correct channel stat buffer overflows</title>
<updated>2017-09-13T21:09:45+00:00</updated>
<author>
<name>Brian Norris</name>
<email>briannorris@chromium.org</email>
</author>
<published>2017-06-30T01:23:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4a9c294d7b1e7cf965e4b2e2e9955b9b548a1a0b'/>
<id>4a9c294d7b1e7cf965e4b2e2e9955b9b548a1a0b</id>
<content type='text'>
commit 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.

mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:

(a) scans can return info from more than one band (e.g., both 2.4 and 5
    GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
    channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
    (a) and (b) can easily lead to buffer overflows

Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.

Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw &lt;dev&gt; survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.

(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)

Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
Cc: Avinash Patil &lt;patila@marvell.com&gt;
Cc: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Reviewed-by: Ganapathi Bhat &lt;gbhat@marvell.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 4b5dde2d6234ff5bc68e97e6901d1f2a0a7f3749 upstream.

mwifiex records information about various channels as it receives scan
information. It does this by appending to a buffer that was sized
to the max number of supported channels on any band, but there are
numerous problems:

(a) scans can return info from more than one band (e.g., both 2.4 and 5
    GHz), so the determined "max" is not large enough
(b) some firmware appears to return multiple results for a given
    channel, so the max *really* isn't large enough
(c) there is no bounds checking when stashing these stats, so problems
    (a) and (b) can easily lead to buffer overflows

Let's patch this by setting a slightly-more-correct max (that accounts
for a combination of both 2.4G and 5G bands) and adding a bounds check
when writing to our statistics buffer.

Due to problem (b), we still might not properly report all known survey
information (e.g., with "iw &lt;dev&gt; survey dump"), since duplicate results
(or otherwise "larger than expected" results) will cause some
truncation. But that's a problem for a future bugfix.

(And because of this known deficiency, only log the excess at the WARN
level, since that isn't visible by default in this driver and would
otherwise be a bit too noisy.)

Fixes: bf35443314ac ("mwifiex: channel statistics support for mwifiex")
Cc: Avinash Patil &lt;patila@marvell.com&gt;
Cc: Xinming Hu &lt;huxm@marvell.com&gt;
Signed-off-by: Brian Norris &lt;briannorris@chromium.org&gt;
Reviewed-by: Dmitry Torokhov &lt;dmitry.torokhov@gmail.com&gt;
Reviewed-by: Ganapathi Bhat &lt;gbhat@marvell.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>rtlwifi: rtl_pci_probe: Fix fail path of _rtl_pci_find_adapter</title>
<updated>2017-09-13T21:09:45+00:00</updated>
<author>
<name>Malcolm Priestley</name>
<email>tvboxspy@gmail.com</email>
</author>
<published>2017-07-30T08:02:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ca245a6414e4dba43c144939687df81fc4fba7b2'/>
<id>ca245a6414e4dba43c144939687df81fc4fba7b2</id>
<content type='text'>
commit fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.

_rtl_pci_find_adapter fail path will jump to label fail3 for
unsupported adapter types.

However, on course for fail3 there will be call rtl_deinit_core
before rtl_init_core.

For the inclusion of checking pci_iounmap this fail can be moved to
fail2.

Fixes
[    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]

Signed-off-by: Malcolm Priestley &lt;tvboxspy@gmail.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 fc81bab5eeb103711925d7510157cf5cd2b153f4 upstream.

_rtl_pci_find_adapter fail path will jump to label fail3 for
unsupported adapter types.

However, on course for fail3 there will be call rtl_deinit_core
before rtl_init_core.

For the inclusion of checking pci_iounmap this fail can be moved to
fail2.

Fixes
[    4.492963] BUG: unable to handle kernel NULL pointer dereference at           (null)
[    4.493067] IP: rtl_deinit_core+0x31/0x90 [rtlwifi]

Signed-off-by: Malcolm Priestley &lt;tvboxspy@gmail.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>ath10k: fix memory leak in rx ring buffer allocation</title>
<updated>2017-09-13T21:09:44+00:00</updated>
<author>
<name>Rakesh Pillai</name>
<email>pillair@qti.qualcomm.com</email>
</author>
<published>2017-08-02T10:33:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2c65494080c900c8a0aa4a865b57a8001960ff26'/>
<id>2c65494080c900c8a0aa4a865b57a8001960ff26</id>
<content type='text'>
commit f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.

The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.

There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table

Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.

Signed-off-by: Rakesh Pillai &lt;pillair@qti.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Cc: Christian Lamparter &lt;chunkeey@googlemail.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 f35a7f91f66af528b3ee1921de16bea31d347ab0 upstream.

The rx ring buffers are added to a hash table if
firmware support full rx reorder. If the full rx
reorder support flag is not set before allocating
the rx ring buffers, none of the buffers are added
to the hash table.

There is a race condition between rx ring refill and
rx buffer replenish from napi poll. The interrupts are
enabled in hif start, before the rx ring is refilled during init.
We replenish buffers from napi poll due to the interrupts which
get enabled after hif start. Hence before the entire rx ring is
refilled during the init, the napi poll replenishes a few buffers
in steps of 100 buffers per attempt. During this rx ring replenish
from napi poll, the rx reorder flag has not been set due to which
the replenished buffers are not added to the hash table

Set the rx full reorder support flag before we allocate
the rx ring buffer to avoid the memory leak.

Signed-off-by: Rakesh Pillai &lt;pillair@qti.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Cc: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>wl1251: add a missing spin_lock_init()</title>
<updated>2017-09-07T06:34:09+00:00</updated>
<author>
<name>Cong Wang</name>
<email>xiyou.wangcong@gmail.com</email>
</author>
<published>2017-08-31T14:47:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c0c2e7567a34ca48c8a2d1c89d8a7a5ceb647e08'/>
<id>c0c2e7567a34ca48c8a2d1c89d8a7a5ceb647e08</id>
<content type='text'>
commit f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream.

wl1251: add a missing spin_lock_init()

This fixes the following kernel warning:

 [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
 [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: &lt;none&gt;/-1,
 .owner_cpu: 0
 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
 4.12.0-03002-gec979a4-dirty #40
 [ 5668.772796] Hardware name: Nokia RX-51 board
 [ 5668.773071] Workqueue: phy1 wl1251_irq_work
 [ 5668.773345] [&lt;c010c9e4&gt;] (unwind_backtrace) from [&lt;c010a274&gt;]
 (show_stack+0x10/0x14)
 [ 5668.773803] [&lt;c010a274&gt;] (show_stack) from [&lt;c01545a4&gt;]
 (do_raw_spin_lock+0x6c/0xa0)
 [ 5668.774230] [&lt;c01545a4&gt;] (do_raw_spin_lock) from [&lt;c06ca578&gt;]
 (_raw_spin_lock_irqsave+0x10/0x18)
 [ 5668.774658] [&lt;c06ca578&gt;] (_raw_spin_lock_irqsave) from [&lt;c048c010&gt;]
 (wl1251_op_tx+0x38/0x5c)
 [ 5668.775115] [&lt;c048c010&gt;] (wl1251_op_tx) from [&lt;c06a12e8&gt;]
 (ieee80211_tx_frags+0x188/0x1c0)
 [ 5668.775543] [&lt;c06a12e8&gt;] (ieee80211_tx_frags) from [&lt;c06a138c&gt;]
 (__ieee80211_tx+0x6c/0x130)
 [ 5668.775970] [&lt;c06a138c&gt;] (__ieee80211_tx) from [&lt;c06a3dbc&gt;]
 (ieee80211_tx+0xdc/0x104)
 [ 5668.776367] [&lt;c06a3dbc&gt;] (ieee80211_tx) from [&lt;c06a4af0&gt;]
 (__ieee80211_subif_start_xmit+0x454/0x8c8)
 [ 5668.776824] [&lt;c06a4af0&gt;] (__ieee80211_subif_start_xmit) from
 [&lt;c06a4f94&gt;] (ieee80211_subif_start_xmit+0x30/0x2fc)
 [ 5668.777343] [&lt;c06a4f94&gt;] (ieee80211_subif_start_xmit) from
 [&lt;c0578848&gt;] (dev_hard_start_xmit+0x80/0x118)
...

    by adding the missing spin_lock_init().

Reported-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Acked-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&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 f581a0dd744fe32b0a8805e279c59ec1ac676d60 upstream.

wl1251: add a missing spin_lock_init()

This fixes the following kernel warning:

 [ 5668.771453] BUG: spinlock bad magic on CPU#0, kworker/u2:3/9745
 [ 5668.771850]  lock: 0xce63ef20, .magic: 00000000, .owner: &lt;none&gt;/-1,
 .owner_cpu: 0
 [ 5668.772277] CPU: 0 PID: 9745 Comm: kworker/u2:3 Tainted: G        W
 4.12.0-03002-gec979a4-dirty #40
 [ 5668.772796] Hardware name: Nokia RX-51 board
 [ 5668.773071] Workqueue: phy1 wl1251_irq_work
 [ 5668.773345] [&lt;c010c9e4&gt;] (unwind_backtrace) from [&lt;c010a274&gt;]
 (show_stack+0x10/0x14)
 [ 5668.773803] [&lt;c010a274&gt;] (show_stack) from [&lt;c01545a4&gt;]
 (do_raw_spin_lock+0x6c/0xa0)
 [ 5668.774230] [&lt;c01545a4&gt;] (do_raw_spin_lock) from [&lt;c06ca578&gt;]
 (_raw_spin_lock_irqsave+0x10/0x18)
 [ 5668.774658] [&lt;c06ca578&gt;] (_raw_spin_lock_irqsave) from [&lt;c048c010&gt;]
 (wl1251_op_tx+0x38/0x5c)
 [ 5668.775115] [&lt;c048c010&gt;] (wl1251_op_tx) from [&lt;c06a12e8&gt;]
 (ieee80211_tx_frags+0x188/0x1c0)
 [ 5668.775543] [&lt;c06a12e8&gt;] (ieee80211_tx_frags) from [&lt;c06a138c&gt;]
 (__ieee80211_tx+0x6c/0x130)
 [ 5668.775970] [&lt;c06a138c&gt;] (__ieee80211_tx) from [&lt;c06a3dbc&gt;]
 (ieee80211_tx+0xdc/0x104)
 [ 5668.776367] [&lt;c06a3dbc&gt;] (ieee80211_tx) from [&lt;c06a4af0&gt;]
 (__ieee80211_subif_start_xmit+0x454/0x8c8)
 [ 5668.776824] [&lt;c06a4af0&gt;] (__ieee80211_subif_start_xmit) from
 [&lt;c06a4f94&gt;] (ieee80211_subif_start_xmit+0x30/0x2fc)
 [ 5668.777343] [&lt;c06a4f94&gt;] (ieee80211_subif_start_xmit) from
 [&lt;c0578848&gt;] (dev_hard_start_xmit+0x80/0x118)
...

    by adding the missing spin_lock_init().

Reported-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Cong Wang &lt;xiyou.wangcong@gmail.com&gt;
Acked-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Signed-off-by: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Signed-off-by: Pavel Machek &lt;pavel@ucw.cz&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>p54: memset(0) whole array</title>
<updated>2017-09-02T05:06:51+00:00</updated>
<author>
<name>Jiri Slaby</name>
<email>jslaby@suse.cz</email>
</author>
<published>2016-10-14T09:23:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=389328ea1379e14e8bd8678af96d7a83bc1514e5'/>
<id>389328ea1379e14e8bd8678af96d7a83bc1514e5</id>
<content type='text'>
commit 6f17581788206444cbbcdbc107498f85e9765e3d upstream.

gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]

Fix that by passing the correct size to memset.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Cc: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Acked-by: Christian Lamparter &lt;chunkeey@googlemail.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 6f17581788206444cbbcdbc107498f85e9765e3d upstream.

gcc 7 complains:
drivers/net/wireless/intersil/p54/fwio.c: In function 'p54_scan':
drivers/net/wireless/intersil/p54/fwio.c:491:4: warning: 'memset' used with length equal to number of elements without multiplication by element size [-Wmemset-elt-size]

Fix that by passing the correct size to memset.

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
Cc: Christian Lamparter &lt;chunkeey@googlemail.com&gt;
Cc: Kalle Valo &lt;kvalo@codeaurora.org&gt;
Acked-by: Christian Lamparter &lt;chunkeey@googlemail.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>wil6210: fix deadlock when using fw_no_recovery option</title>
<updated>2017-08-07T02:19:41+00:00</updated>
<author>
<name>Lior David</name>
<email>qca_liord@qca.qualcomm.com</email>
</author>
<published>2016-11-23T14:06:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=461b44fdf02f17bc98480a521dd754d016f19f67'/>
<id>461b44fdf02f17bc98480a521dd754d016f19f67</id>
<content type='text'>
commit dfb5b098e0f40b68aa07f2ec55f4dd762efefbfa upstream.

When FW crashes with no_fw_recovery option, driver
waits for manual recovery with wil-&gt;mutex held, this
can easily create deadlocks.
Fix the problem by moving the wait outside the lock.

Signed-off-by: Lior David &lt;qca_liord@qca.qualcomm.com&gt;
Signed-off-by: Maya Erez &lt;qca_merez@qca.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.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 dfb5b098e0f40b68aa07f2ec55f4dd762efefbfa upstream.

When FW crashes with no_fw_recovery option, driver
waits for manual recovery with wil-&gt;mutex held, this
can easily create deadlocks.
Fix the problem by moving the wait outside the lock.

Signed-off-by: Lior David &lt;qca_liord@qca.qualcomm.com&gt;
Signed-off-by: Maya Erez &lt;qca_merez@qca.qualcomm.com&gt;
Signed-off-by: Kalle Valo &lt;kvalo@qca.qualcomm.com&gt;
Signed-off-by: Amit Pundir &lt;amit.pundir@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
