<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/net, branch v4.6.6</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>net: mvneta: set real interrupt per packet for tx_done</title>
<updated>2016-08-10T10:54:49+00:00</updated>
<author>
<name>Dmitri Epshtein</name>
<email>dima@marvell.com</email>
</author>
<published>2016-07-06T02:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f4cf2ec9191577c201aaf71cca4ccabb50cdb8e'/>
<id>2f4cf2ec9191577c201aaf71cca4ccabb50cdb8e</id>
<content type='text'>
commit 06708f81528725148473c0869d6af5f809c6824b upstream.

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.

This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.

Signed-off-by: Dmitri Epshtein &lt;dima@marvell.com&gt;
Signed-off-by: Marcin Wojtas &lt;mw@semihalf.com&gt;
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau &lt;w@1wt.eu&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 06708f81528725148473c0869d6af5f809c6824b upstream.

Commit aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay") intended to
set coalescing threshold to a value guaranteeing interrupt generation
per each sent packet, so that buffers can be released with no delay.

In fact setting threshold to '1' was wrong, because it causes interrupt
every two packets. According to the documentation a reason behind it is
following - interrupt occurs once sent buffers counter reaches a value,
which is higher than one specified in MVNETA_TXQ_SIZE_REG(q). This
behavior was confirmed during tests. Also when testing the SoC working
as a NAS device, better performance was observed with int-per-packet,
as it strongly depends on the fact that all transmitted packets are
released immediately.

This commit enables NETA controller work in interrupt per sent packet mode
by setting coalescing threshold to 0.

Signed-off-by: Dmitri Epshtein &lt;dima@marvell.com&gt;
Signed-off-by: Marcin Wojtas &lt;mw@semihalf.com&gt;
Fixes aebea2ba0f74 ("net: mvneta: fix Tx interrupt delay")
Acked-by: Willy Tarreau &lt;w@1wt.eu&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>can: fix oops caused by wrong rtnl dellink usage</title>
<updated>2016-08-10T10:54:48+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T13:45:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f3f8ae8b97c9dcae621eff74fd39cf45873d6621'/>
<id>f3f8ae8b97c9dcae621eff74fd39cf45873d6621</id>
<content type='text'>
commit 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.

For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created nor
removed with the ip tool ...

This patch adds a private dellink function for the CAN device driver interface
that does just nothing.

It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
newlink usage") but for dellink.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&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 25e1ed6e64f52a692ba3191c4fde650aab3ecc07 upstream.

For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created nor
removed with the ip tool ...

This patch adds a private dellink function for the CAN device driver interface
that does just nothing.

It's a follow up to commit 993e6f2fd ("can: fix oops caused by wrong rtnl
newlink usage") but for dellink.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>can: fix handling of unmodifiable configuration options fix</title>
<updated>2016-08-10T10:54:48+00:00</updated>
<author>
<name>Oliver Hartkopp</name>
<email>socketcan@hartkopp.net</email>
</author>
<published>2016-06-21T10:14:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=171cf1dc83ea6ba43038a86ea455c04aee908282'/>
<id>171cf1dc83ea6ba43038a86ea455c04aee908282</id>
<content type='text'>
commit bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
configuration options) a new can_validate() function was introduced.

When invoking 'ip link set can0 type can' without any configuration data
can_validate() tries to validate the content without taking into account that
there's totally no content. This patch adds a check for missing content.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&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 bce271f255dae8335dc4d2ee2c4531e09cc67f5a upstream.

With upstream commit bb208f144cf3f59 (can: fix handling of unmodifiable
configuration options) a new can_validate() function was introduced.

When invoking 'ip link set can0 type can' without any configuration data
can_validate() tries to validate the content without taking into account that
there's totally no content. This patch adds a check for missing content.

Reported-by: ajneu &lt;ajneu1@gmail.com&gt;
Signed-off-by: Oliver Hartkopp &lt;socketcan@hartkopp.net&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>can: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access</title>
<updated>2016-08-10T10:54:48+00:00</updated>
<author>
<name>Thor Thayer</name>
<email>tthayer@opensource.altera.com</email>
</author>
<published>2016-06-16T16:10:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=07562cc24b6312275a8b1e146066aafd496cf46e'/>
<id>07562cc24b6312275a8b1e146066aafd496cf46e</id>
<content type='text'>
commit 427460c83cdf55069eee49799a0caef7dde8df69 upstream.

When testing CAN write floods on Altera's CycloneV, the first 2 bytes
are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
observed bytes 4 &amp; 5 were corrupted in some cases.

The D_CAN Data registers are 32 bits and changing from 16 bit writes to
32 bit writes fixes the problem.

Testing performed on Altera CycloneV (D_CAN).  Requesting tests on other
C_CAN &amp; D_CAN platforms.

Reported-by: Richard Andrysek &lt;richard.andrysek@gomtec.de&gt;
Signed-off-by: Thor Thayer &lt;tthayer@opensource.altera.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&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 427460c83cdf55069eee49799a0caef7dde8df69 upstream.

When testing CAN write floods on Altera's CycloneV, the first 2 bytes
are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
observed bytes 4 &amp; 5 were corrupted in some cases.

The D_CAN Data registers are 32 bits and changing from 16 bit writes to
32 bit writes fixes the problem.

Testing performed on Altera CycloneV (D_CAN).  Requesting tests on other
C_CAN &amp; D_CAN platforms.

Reported-by: Richard Andrysek &lt;richard.andrysek@gomtec.de&gt;
Signed-off-by: Thor Thayer &lt;tthayer@opensource.altera.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>can: at91_can: RX queue could get stuck at high bus load</title>
<updated>2016-08-10T10:54:48+00:00</updated>
<author>
<name>Wolfgang Grandegger</name>
<email>wg@grandegger.com</email>
</author>
<published>2016-06-13T13:44:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=88e08b416173652eecb33f1d87da68096b06b8b2'/>
<id>88e08b416173652eecb33f1d87da68096b06b8b2</id>
<content type='text'>
commit 43200a4480cbbe660309621817f54cbb93907108 upstream.

At high bus load it could happen that "at91_poll()" enters with all RX
message boxes filled up. If then at the end the "quota" is exceeded as
well, "rx_next" will not be reset to the first RX mailbox and hence the
interrupts remain disabled.

Signed-off-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Tested-by: Amr Bekhit &lt;amrbekhit@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&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 43200a4480cbbe660309621817f54cbb93907108 upstream.

At high bus load it could happen that "at91_poll()" enters with all RX
message boxes filled up. If then at the end the "quota" is exceeded as
well, "rx_next" will not be reset to the first RX mailbox and hence the
interrupts remain disabled.

Signed-off-by: Wolfgang Grandegger &lt;wg@grandegger.com&gt;
Tested-by: Amr Bekhit &lt;amrbekhit@gmail.com&gt;
Signed-off-by: Marc Kleine-Budde &lt;mkl@pengutronix.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cdc_ncm: workaround for EM7455 "silent" data interface</title>
<updated>2016-07-27T15:42:14+00:00</updated>
<author>
<name>Bjørn Mork</name>
<email>bjorn@mork.no</email>
</author>
<published>2016-07-03T20:24:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33884dbad2725a3e45e010f8d2e471a73f43c592'/>
<id>33884dbad2725a3e45e010f8d2e471a73f43c592</id>
<content type='text'>
[ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ]

Several Lenovo users have reported problems with their Sierra
Wireless EM7455 modem. The driver has loaded successfully and
the MBIM management channel has appeared to work, including
establishing a connection to the mobile network. But no frames
have been received over the data interface.

The problem affects all EM7455 and MC7455, and is assumed to
affect other modems based on the same Qualcomm chipset and
baseband firmware.

Testing narrowed the problem down to what seems to be a
firmware timing bug during initialization. Adding a short sleep
while probing is sufficient to make the problem disappear.
Experiments have shown that 1-2 ms is too little to have any
effect, while 10-20 ms is enough to reliably succeed.

Reported-by: Stefan Armbruster &lt;ml001@armbruster-it.de&gt;
Reported-by: Ralph Plawetzki &lt;ralph@purejava.org&gt;
Reported-by: Andreas Fett &lt;andreas.fett@secunet.com&gt;
Reported-by: Rasmus Lerdorf &lt;rasmus@lerdorf.com&gt;
Reported-by: Samo Ratnik &lt;samo.ratnik@gmail.com&gt;
Reported-and-tested-by: Aleksander Morgado &lt;aleksander@aleksander.es&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&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>
[ Upstream commit c086e7096170390594c425114d98172bc9aceb8a ]

Several Lenovo users have reported problems with their Sierra
Wireless EM7455 modem. The driver has loaded successfully and
the MBIM management channel has appeared to work, including
establishing a connection to the mobile network. But no frames
have been received over the data interface.

The problem affects all EM7455 and MC7455, and is assumed to
affect other modems based on the same Qualcomm chipset and
baseband firmware.

Testing narrowed the problem down to what seems to be a
firmware timing bug during initialization. Adding a short sleep
while probing is sufficient to make the problem disappear.
Experiments have shown that 1-2 ms is too little to have any
effect, while 10-20 ms is enough to reliably succeed.

Reported-by: Stefan Armbruster &lt;ml001@armbruster-it.de&gt;
Reported-by: Ralph Plawetzki &lt;ralph@purejava.org&gt;
Reported-by: Andreas Fett &lt;andreas.fett@secunet.com&gt;
Reported-by: Rasmus Lerdorf &lt;rasmus@lerdorf.com&gt;
Reported-by: Samo Ratnik &lt;samo.ratnik@gmail.com&gt;
Reported-and-tested-by: Aleksander Morgado &lt;aleksander@aleksander.es&gt;
Signed-off-by: Bjørn Mork &lt;bjorn@mork.no&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>geneve: fix max_mtu setting</title>
<updated>2016-07-27T15:42:13+00:00</updated>
<author>
<name>Haishuang Yan</name>
<email>yanhaishuang@cmss.chinamobile.com</email>
</author>
<published>2016-07-02T07:02:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=309bcd10a7467abcf2b774d3ac289e128360872c'/>
<id>309bcd10a7467abcf2b774d3ac289e128360872c</id>
<content type='text'>
[ Upstream commit d5d5e8d55732c7c35c354e45e3b0af2795978a57 ]

For ipv6+udp+geneve encapsulation data, the max_mtu should subtract
sizeof(ipv6hdr), instead of sizeof(iphdr).

Signed-off-by: Haishuang Yan &lt;yanhaishuang@cmss.chinamobile.com&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>
[ Upstream commit d5d5e8d55732c7c35c354e45e3b0af2795978a57 ]

For ipv6+udp+geneve encapsulation data, the max_mtu should subtract
sizeof(ipv6hdr), instead of sizeof(iphdr).

Signed-off-by: Haishuang Yan &lt;yanhaishuang@cmss.chinamobile.com&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>macsec: set actual real device for xmit when !protect_frames</title>
<updated>2016-07-27T15:42:13+00:00</updated>
<author>
<name>Daniel Borkmann</name>
<email>daniel@iogearbox.net</email>
</author>
<published>2016-06-30T22:00:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=80420d65a62a111162808a2cb10ce242304b6c77'/>
<id>80420d65a62a111162808a2cb10ce242304b6c77</id>
<content type='text'>
[ Upstream commit 79c62220d74a4a3f961a2cb7320da09eebf5daf7 ]

Avoid recursions of dev_queue_xmit() to the wrong net device when
frames are unprotected, since at that time skb-&gt;dev still points to
our own macsec dev and unlike macsec_encrypt_finish() dev pointer
doesn't get updated to real underlying device.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&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>
[ Upstream commit 79c62220d74a4a3f961a2cb7320da09eebf5daf7 ]

Avoid recursions of dev_queue_xmit() to the wrong net device when
frames are unprotected, since at that time skb-&gt;dev still points to
our own macsec dev and unlike macsec_encrypt_finish() dev pointer
doesn't get updated to real underlying device.

Fixes: c09440f7dcb3 ("macsec: introduce IEEE 802.1AE driver")
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Sabrina Dubroca &lt;sd@queasysnail.net&gt;
Acked-by: Hannes Frederic Sowa &lt;hannes@stressinduktion.org&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>rtlwifi: Fix scheduling while atomic error from commit 49f86ec21c01</title>
<updated>2016-07-27T15:42:11+00:00</updated>
<author>
<name>Larry Finger</name>
<email>Larry.Finger@lwfinger.net</email>
</author>
<published>2016-05-21T16:50:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b184a66e847ddd5895c59cff34ec7a369d69067f'/>
<id>b184a66e847ddd5895c59cff34ec7a369d69067f</id>
<content type='text'>
commit de26859dcf363d520cc44e59f6dcaf20ebe0aadf upstream.

Commit 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") was correct
for most cases; however, driver rtl8192ce calls the affected routines while
in atomic context. The kernel bug output is as follows:

BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
[...]
  [&lt;ffffffff815c2b39&gt;] __schedule+0x899/0xad0
  [&lt;ffffffff815c2dac&gt;] schedule+0x3c/0x90
  [&lt;ffffffff815c5bb2&gt;] schedule_hrtimeout_range_clock+0xa2/0x120
  [&lt;ffffffff810e8b80&gt;] ? hrtimer_init+0x120/0x120
  [&lt;ffffffff815c5ba6&gt;] ? schedule_hrtimeout_range_clock+0x96/0x120
  [&lt;ffffffff815c5c43&gt;] schedule_hrtimeout_range+0x13/0x20
  [&lt;ffffffff815c568f&gt;] usleep_range+0x4f/0x70
  [&lt;ffffffffa0667218&gt;] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
  [&lt;ffffffffa06dd0e7&gt;] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]

To fix this bug, three of the changes from delay to sleep are reverted.
Unfortunately, one of the changes involves a delay of 50 msec. The calling
code will be modified so that this long delay can be avoided; however,
this change is being pushed now to fix the problem in kernel 4.6.0.

Fixes: 49f86ec21c01 ("rtlwifi: Change long delays to sleeps")
Reported-by: James Feeney &lt;james@nurealm.net&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: James Feeney &lt;james@nurealm.net&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 de26859dcf363d520cc44e59f6dcaf20ebe0aadf upstream.

Commit 49f86ec21c01 ("rtlwifi: Change long delays to sleeps") was correct
for most cases; however, driver rtl8192ce calls the affected routines while
in atomic context. The kernel bug output is as follows:

BUG: scheduling while atomic: wpa_supplicant/627/0x00000002
[...]
  [&lt;ffffffff815c2b39&gt;] __schedule+0x899/0xad0
  [&lt;ffffffff815c2dac&gt;] schedule+0x3c/0x90
  [&lt;ffffffff815c5bb2&gt;] schedule_hrtimeout_range_clock+0xa2/0x120
  [&lt;ffffffff810e8b80&gt;] ? hrtimer_init+0x120/0x120
  [&lt;ffffffff815c5ba6&gt;] ? schedule_hrtimeout_range_clock+0x96/0x120
  [&lt;ffffffff815c5c43&gt;] schedule_hrtimeout_range+0x13/0x20
  [&lt;ffffffff815c568f&gt;] usleep_range+0x4f/0x70
  [&lt;ffffffffa0667218&gt;] rtl_rfreg_delay+0x38/0x50 [rtlwifi]
  [&lt;ffffffffa06dd0e7&gt;] rtl92c_phy_config_rf_with_headerfile+0xc7/0xe0 [rtl8192ce]

To fix this bug, three of the changes from delay to sleep are reverted.
Unfortunately, one of the changes involves a delay of 50 msec. The calling
code will be modified so that this long delay can be avoided; however,
this change is being pushed now to fix the problem in kernel 4.6.0.

Fixes: 49f86ec21c01 ("rtlwifi: Change long delays to sleeps")
Reported-by: James Feeney &lt;james@nurealm.net&gt;
Signed-off-by: Larry Finger &lt;Larry.Finger@lwfinger.net&gt;
Cc: James Feeney &lt;james@nurealm.net&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>mac80211_hwsim: Add missing check for HWSIM_ATTR_SIGNAL</title>
<updated>2016-07-27T15:42:07+00:00</updated>
<author>
<name>Martin Willi</name>
<email>martin@strongswan.org</email>
</author>
<published>2016-05-13T10:41:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9d8bdf761e1cc2739f87ddae1747400213a2ad97'/>
<id>9d8bdf761e1cc2739f87ddae1747400213a2ad97</id>
<content type='text'>
commit 62397da50bb20a6b812c949ef465d7e69fe54bb6 upstream.

A wmediumd that does not send this attribute causes a NULL pointer
dereference, as the attribute is accessed even if it does not exist.

The attribute was required but never checked ever since userspace frame
forwarding has been introduced. The issue gets more problematic once we
allow wmediumd registration from user namespaces.

Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
Signed-off-by: Martin Willi &lt;martin@strongswan.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@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 62397da50bb20a6b812c949ef465d7e69fe54bb6 upstream.

A wmediumd that does not send this attribute causes a NULL pointer
dereference, as the attribute is accessed even if it does not exist.

The attribute was required but never checked ever since userspace frame
forwarding has been introduced. The issue gets more problematic once we
allow wmediumd registration from user namespaces.

Fixes: 7882513bacb1 ("mac80211_hwsim driver support userspace frame tx/rx")
Signed-off-by: Martin Willi &lt;martin@strongswan.org&gt;
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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