* Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
From: Johannes Berg @ 2016-08-08 6:45 UTC (permalink / raw)
To: Ben Hutchings
Cc: rasun Maiti, Ujjal Roy, Dibyajyoti Ghosh, linux-wireless, stable
In-Reply-To: <1470588577.4325.4.camel@decadent.org.uk>
On Sun, 2016-08-07 at 17:49 +0100, Ben Hutchings wrote:
> I'm looking at commit 3d5fdff46c4b as part of the stable process.
>
> The path it touches is only used for drivers that don't describe
> their private wext handlers, right? So how can we know that the
> private ioctl is using the iw_point structure and not one of the
> other types in union iwreq_data? Doesn't this result in a regression
> when another type is being used?
>
Crap, that's good point. I'll revert the patch.
Fortunately this code path is never actually used. The only "mainline"
driver that appears to use it is staging/wilc1000.
I wonder if we should just remove it entirely. Yes, it'd break that
staging driver to some extent, but it's clearly an unsafe code path.
Prasun, did you need this for the mwifiex wext ioctl support that was
shot down anyway?
johannes
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-08-08 6:41 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Ted Tso, Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo, Jason Cooper
In-Reply-To: <657897b90b8344eeab10d7a0f604988d@aptaiexm02f.ap.qualcomm.com>
Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> The entropy was evaluated by crypto expert, the analysis report show the
> ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits
> value, we conservatively assume the min-entropy is 10 bits out of 32 bits,
> so that's why set entropy quality to 320/1024 = 10/32. Also we have
> explained in the commit message why can't use the HW RNG framework.
Where is the description of the RNG, where is the test implementation?
>
> Otherwise, your patch will cause high CPU load, as continuously read ADC
> data if entropy bits under write_wakeup_threshold.
The issue is that although you may have analyzed it, others are unable to
measure the quality of the RNG and assess the design as well as the
implementation of the RNG. This RNG is the only implementation of a hardware
RNG that per default and without being able to change it at runtime injects
data into the input_pool where the noise source cannot be audited. Note, even
other respected RNG noise sources like the Intel RDRAND will not feed into /
dev/random per default in a way that dominates all other noise sources.
I would like to be able to deactivate that noise source to the extent that it
does not cause /dev/random to unblock. The reason is that your noise source
starts to dominate all other noise sources.
If you think that this patch is a challenge because your driver starts to
spin, please help and offer another solution.
>
> --
> Miaoqing
>
> -----Original Message-----
> From: Stephan Mueller [mailto:smueller@chronox.de]
> Sent: Sunday, August 07, 2016 5:36 PM
> To: Ted Tso <tytso@mit.edu>
> Cc: herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org;
> linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>;
> linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo
> <kvalo@codeaurora.org>; Jason Cooper <jason@lakedaemon.net> Subject: [PATCH
> v2] RANDOM: ATH9K RNG delivers zero bits of entropy
>
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
>
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds data
> into the input_pool but it is assumed to have no entropy.
>
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
the
> entropy estimation considering that a user can change that value at boot
> and runtime.
>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
> drivers/net/wireless/ath/ath9k/rng.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..1ed8338 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -22,7 +22,6 @@
> #include "ar9003_phy.h"
>
> #define ATH9K_RNG_BUF_SIZE 320
> -#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024
> */
>
> static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32
> buf_size) { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
> fail_stats = 0;
>
> /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> - ATH9K_RNG_ENTROPY(bytes_read));
> + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
> }
>
> kfree(rng_buf);
> --
> 2.7.4
Ciao
Stephan
^ permalink raw reply
* RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Pan, Miaoqing @ 2016-08-08 2:03 UTC (permalink / raw)
To: Stephan Mueller, Ted Tso, Sepehrdad, Pouyan
Cc: herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo, Jason Cooper
In-Reply-To: <1654172.XfclnXhRmn@positron.chronox.de>
The entropy was evaluated by crypto expert, the analysis report show the ADC with at least 10bits and up to 22 bits of min-entropy for a 32 bits value, we conservatively assume the min-entropy is 10 bits out of 32 bits, so that's why set entropy quality to 320/1024 = 10/32. Also we have explained in the commit message why can't use the HW RNG framework.
Otherwise, your patch will cause high CPU load, as continuously read ADC data if entropy bits under write_wakeup_threshold.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Sunday, August 07, 2016 5:36 PM
To: Ted Tso <tytso@mit.edu>
Cc: herbert@gondor.apana.org.au; linux-kernel@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel@lists.ath9k.org; Kalle Valo <kvalo@codeaurora.org>; Jason Cooper <jason@lakedaemon.net>
Subject: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
The ATH9K driver implements an RNG which is completely bypassing the standard Linux HW generator logic.
The RNG may or may not deliver entropy. Considering the conservative approach in treating entropy with respect to non-auditable sources, this patch changes the delivered entropy value to zero. The RNG still feeds data into the input_pool but it is assumed to have no entropy.
When the ATH9K RNG changes to use the HW RNG framework, it may re-enable the entropy estimation considering that a user can change that value at boot and runtime.
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/net/wireless/ath/ath9k/rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..1ed8338 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,6 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size) { @@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
fail_stats = 0;
/* sleep until entropy bits under write_wakeup_threshold */
- add_hwgenerator_randomness((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
^ permalink raw reply related
* Re: wext: Fix 32 bit iwpriv compatibility issue with 64 bit Kernel
From: Ben Hutchings @ 2016-08-07 16:49 UTC (permalink / raw)
To: Johannes Berg
Cc: rasun Maiti, Ujjal Roy, Dibyajyoti Ghosh, linux-wireless, stable
[-- Attachment #1: Type: text/plain, Size: 499 bytes --]
I'm looking at commit 3d5fdff46c4b as part of the stable process.
The path it touches is only used for drivers that don't describe their
private wext handlers, right? So how can we know that the private
ioctl is using the iw_point structure and not one of the other types in
union iwreq_data? Doesn't this result in a regression when another
type is being used?
Ben.
--
Ben Hutchings
Beware of bugs in the above code;
I have only proved it correct, not tried it. - Donald Knuth
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Arend van Spriel @ 2016-08-07 11:41 UTC (permalink / raw)
To: Jörg Krause, Franky Lin
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <1470492734.2120.0.camel@embedded.rocks>
On 06-08-16 16:12, Jörg Krause wrote:
> Hi all,
A bit weird email format making it a bit hard to determine where your
last reply starts...
> On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
>
> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause@embedded.ro
> cks>
> wrote:
>
>
>
>
>
> Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
> arend.vanspriel@broadcom.com>:
>
>
> Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> <joerg.krause@embedded.rocks>:
>
>
>
> Hi,
>
> I'm using a custom ARM board with an BCM43362 wifi chip from
>
> Broadcom.
>
>
> The wifi chip is attached via SDIO to the controller with a
> clock of
> 48MHz. Linux kernel version is 4.7.
>
> When measuring the network bandwidth with iperf3 I get a
> bandwith of
> only around 5 Mbps. I found a similar thread at the Broadcom
>
> community
>
>
> [1] where the test was done with a M4 CPU + BCM43362 and an
> average
> result of 3.3 Mbps.
>
> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
>
> throughput
>
>
> greater than 20 Mbps.
>
> Why is the throughput I measured much lower? Note that I
> measured
> several times with almost no neighbor devices or networks.
>
> This is a test sample measured with iperf3:
>
> $ iperf3 -c 192.168.2.1 -i 1 -t 10
> Connecting to host 192.168.2.1, port 5201
> [ 4] local 192.168.2.155 port 36442 connected to
> 192.168.2.1
>
> port
>
>
> 5201
> [ ID]
> Interval Transfer Bandwidth Retr Cwnd
> [ 4] 0.00-1.00 sec 615 KBytes 5.04
> Mbits/sec 0 56.6
> KBytes
> [ 4] 1.00-2.00 sec 622 KBytes 5.10
> Mbits/sec 0 84.8
> KBytes
> [ 4] 2.00-3.00 sec 625 KBytes 5.12
> Mbits/sec 0 113
> KBytes
> [ 4] 3.00-4.00 sec 571 KBytes 4.68
> Mbits/sec 0 140
> KBytes
> [ 4] 4.00-5.00 sec 594 KBytes 4.87
> Mbits/sec 0 167
> KBytes
> [ 4] 5.00-6.00 sec 628 KBytes 5.14
> Mbits/sec 0 195
> KBytes
> [ 4] 6.00-7.00 sec 619 KBytes 5.07
> Mbits/sec 0 202
> KBytes
> [ 4] 7.00-8.00 sec 608 KBytes 4.98
> Mbits/sec 0 202
> KBytes
> [ 4] 8.00-9.00 sec 602 KBytes 4.93
> Mbits/sec 0 202
> KBytes
> [ 4] 9.00-10.00 sec 537 KBytes 4.40
> Mbits/sec 0 202
> KBytes
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bandwidth Retr
> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
> Mbits/sec 0 sender
> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
> Mbits/sec receiver
>
>
> Not overly familiar with iperf3. Do these lines mean you are
> doing
> bidirectional test, ie. upstream and downstream at the same time.
> Another
> thing affecting tput could be power-save.
>
>
> No, iperf3 does not support bidrectional test. Power-save is turned
> off.
>
> What does iw link say?
>
but I guess it starts here!
> I compared the results with a Cubietruck I have:
>
> # iperf3 -s
> -----------------------------------------------------------
> Server listening on 5201
> -----------------------------------------------------------
> Accepted connection from 192.168.178.46, port 42906
> [ 5] local 192.168.178.38 port 5201 connected to 192.168.178.46 port
> 42908
> [ ID] Interval Transfer Bandwidth
> [ 5] 0.00-1.00 sec 2.29 MBytes 19.2 Mbits/sec
> [ 5] 1.00-2.00 sec 2.21 MBytes 18.5 Mbits/sec
> [ 5] 2.00-3.00 sec 2.17 MBytes 18.2 Mbits/sec
> [ 5] 3.00-4.00 sec 2.09 MBytes 17.6 Mbits/sec
> [ 5] 4.00-5.00 sec 2.20 MBytes 18.5 Mbits/sec
> [ 5] 5.00-6.00 sec 2.64 MBytes 22.1 Mbits/sec
> [ 5] 6.00-7.00 sec 2.67 MBytes 22.4 Mbits/sec
> [ 5] 7.00-8.00 sec 2.62 MBytes 22.0 Mbits/sec
> [ 5] 8.00-9.00 sec 2.35 MBytes 19.8 Mbits/sec
> [ 5] 9.00-10.00 sec 2.30 MBytes 19.3 Mbits/sec
> [ 5] 10.00-10.03 sec 83.4 KBytes 23.5 Mbits/sec
> - - - - - - - - - - - - - - - - - - - - - - - - -
> [ ID] Interval Transfer Bandwidth Retr
> [ 5] 0.00-10.03 sec 23.9 MBytes 20.0
> Mbits/sec 0 sender
> [ 5] 0.00-10.03 sec 23.6 MBytes 19.8
> Mbits/sec receiver
>
> # iw dev wlan0 link
> Connected to xx:xx:xx:xx:xx (on wlan0)
> SSID: xxx
> freq: 2437
> tx bitrate: 65.0 MBit/s
>
> bss flags: short-preamble short-slot-time
> dtim period: 1
> beacon int: 100
Too bad RSSI is not in the output above. That may be due to a regression
in our driver which has been fixed by commit 94abd778a7bb ("brcmfmac:
add fallback for devices that do not report per-chain values"). However,
the tx bitrate seems within the same range as the other platform.
> The Cubietruck works also with the brcmfmac driver.
>
> May it depend on the NVRAM file?
Not sure. Can you tell me a bit more about the custom ARM board. Does it
use the same wifi module as Cubietruck, ie. the AMPAK AP6210? If you can
make a wireshark sniff we can check the actual bitrate and medium
density in terms of packets. Another thing to look at is the SDIO host
controller. In brcmf_sdiod_sgtable_alloc() some key values are used from
the host controller. It only logs the number of entries of the
scatter-gather table, but could you add the other values in this
function that are used to determine the number of entries.
Regards,
Arend
^ permalink raw reply
* [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-08-07 9:36 UTC (permalink / raw)
To: Ted Tso
Cc: herbert, linux-kernel, linux-crypto, ath9k-devel, linux-wireless,
ath9k-devel, Kalle Valo, Jason Cooper
In-Reply-To: <34197429.2CvoIfft9B@positron.chronox.de>
The ATH9K driver implements an RNG which is completely bypassing the
standard Linux HW generator logic.
The RNG may or may not deliver entropy. Considering the conservative
approach in treating entropy with respect to non-auditable sources, this
patch changes the delivered entropy value to zero. The RNG still feeds
data into the input_pool but it is assumed to have no entropy.
When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
the entropy estimation considering that a user can change that value at
boot and runtime.
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
drivers/net/wireless/ath/ath9k/rng.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..1ed8338 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,6 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
@@ -92,8 +91,7 @@ static int ath9k_rng_kthread(void *data)
fail_stats = 0;
/* sleep until entropy bits under write_wakeup_threshold */
- add_hwgenerator_randomness((void *)rng_buf, bytes_read,
- ATH9K_RNG_ENTROPY(bytes_read));
+ add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
}
kfree(rng_buf);
--
2.7.4
^ permalink raw reply related
* iwlwifi errors (regression?) on 4.7.0
From: Andy Lutomirski @ 2016-08-07 8:54 UTC (permalink / raw)
To: Linux Wireless List, Intel Linux Wireless, Luca Coelho,
Emmanuel Grumbach, Johannes Berg
My Intel 7265 used to work flawlessly, but for the past week or two it
has seemed to be very unreliable. It's also throwing errors. I see
problems on firmware versions 16 and 21, although I haven't gotten the
warning and backtrace on firmware 16 yet.
I have:
iwlwifi 0000:3a:00.0: enabling device (0000 -> 0002)
iwlwifi 0000:3a:00.0: Unsupported splx structure
iwlwifi 0000:3a:00.0: loaded firmware version 21.302800.0 op_mode iwlmvm
iwlwifi 0000:3a:00.0: Detected Intel(R) Dual Band Wireless AC 7265, REV=0x210
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
I just got this error on 4.7.0:
[324188.495734] wlp58s0: associated
[324281.259579] iwlwifi 0000:3a:00.0: Queue 16 stuck for 10000 ms.
[324281.259600] iwlwifi 0000:3a:00.0: Current SW read_ptr 255 write_ptr 13
[324281.259648] iwl data: 00000000: 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 ................
[324281.259676] iwlwifi 0000:3a:00.0: FH TRBs(0) = 0x00000000
[324281.259703] iwlwifi 0000:3a:00.0: FH TRBs(1) = 0xc011000c
[324281.259728] iwlwifi 0000:3a:00.0: FH TRBs(2) = 0x00000000
[324281.259753] iwlwifi 0000:3a:00.0: FH TRBs(3) = 0x80300024
[324281.259779] iwlwifi 0000:3a:00.0: FH TRBs(4) = 0x00000000
[324281.259804] iwlwifi 0000:3a:00.0: FH TRBs(5) = 0x00000000
[324281.259830] iwlwifi 0000:3a:00.0: FH TRBs(6) = 0x00000000
[324281.259855] iwlwifi 0000:3a:00.0: FH TRBs(7) = 0x007090e6
[324281.259925] iwlwifi 0000:3a:00.0: Q 0 is active and mapped to fifo
3 ra_tid 0x0000 [37,37]
[324281.259999] iwlwifi 0000:3a:00.0: Q 1 is active and mapped to fifo
2 ra_tid 0x0000 [0,0]
[324281.260065] iwlwifi 0000:3a:00.0: Q 2 is active and mapped to fifo
1 ra_tid 0x0000 [7,7]
[324281.260131] iwlwifi 0000:3a:00.0: Q 3 is active and mapped to fifo
0 ra_tid 0x0000 [0,0]
[324281.260197] iwlwifi 0000:3a:00.0: Q 4 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260264] iwlwifi 0000:3a:00.0: Q 5 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260330] iwlwifi 0000:3a:00.0: Q 6 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260396] iwlwifi 0000:3a:00.0: Q 7 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260462] iwlwifi 0000:3a:00.0: Q 8 is active and mapped to fifo
3 ra_tid 0x0000 [0,0]
[324281.260528] iwlwifi 0000:3a:00.0: Q 9 is active and mapped to fifo
7 ra_tid 0x0000 [231,231]
[324281.260595] iwlwifi 0000:3a:00.0: Q 10 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260662] iwlwifi 0000:3a:00.0: Q 11 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260731] iwlwifi 0000:3a:00.0: Q 12 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260806] iwlwifi 0000:3a:00.0: Q 13 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260873] iwlwifi 0000:3a:00.0: Q 14 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.260939] iwlwifi 0000:3a:00.0: Q 15 is active and mapped to
fifo 5 ra_tid 0x0000 [0,0]
[324281.261006] iwlwifi 0000:3a:00.0: Q 16 is active and mapped to
fifo 1 ra_tid 0x1fff [255,13]
[324281.261085] iwlwifi 0000:3a:00.0: Q 17 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261214] iwlwifi 0000:3a:00.0: Q 18 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261356] iwlwifi 0000:3a:00.0: Q 19 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261499] iwlwifi 0000:3a:00.0: Q 20 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261636] iwlwifi 0000:3a:00.0: Q 21 is inactive and mapped to
fifo 0 ra_tid 0x8000 [0,0]
[324281.261775] iwlwifi 0000:3a:00.0: Q 22 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.261903] iwlwifi 0000:3a:00.0: Q 23 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262032] iwlwifi 0000:3a:00.0: Q 24 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262173] iwlwifi 0000:3a:00.0: Q 25 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262285] iwlwifi 0000:3a:00.0: Q 26 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262426] iwlwifi 0000:3a:00.0: Q 27 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262555] iwlwifi 0000:3a:00.0: Q 28 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262684] iwlwifi 0000:3a:00.0: Q 29 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262812] iwlwifi 0000:3a:00.0: Q 30 is inactive and mapped to
fifo 0 ra_tid 0x0000 [0,0]
[324281.262909] iwlwifi 0000:3a:00.0: Microcode SW error detected.
Restarting 0x2000000.
[324281.262918] iwlwifi 0000:3a:00.0: CSR values:
[324281.262925] iwlwifi 0000:3a:00.0: (2nd byte of CSR_INT_COALESCING
is CSR_INT_PERIODIC_REG)
[324281.262945] iwlwifi 0000:3a:00.0: CSR_HW_IF_CONFIG_REG: 0X00489200
[324281.262960] iwlwifi 0000:3a:00.0: CSR_INT_COALESCING: 0X00000040
[324281.262976] iwlwifi 0000:3a:00.0: CSR_INT: 0X00000000
[324281.262992] iwlwifi 0000:3a:00.0: CSR_INT_MASK: 0X00000000
[324281.263007] iwlwifi 0000:3a:00.0: CSR_FH_INT_STATUS: 0X00000000
[324281.263022] iwlwifi 0000:3a:00.0: CSR_GPIO_IN: 0X00000000
[324281.263037] iwlwifi 0000:3a:00.0: CSR_RESET: 0X00000000
[324281.263053] iwlwifi 0000:3a:00.0: CSR_GP_CNTRL: 0X080403c5
[324281.263069] iwlwifi 0000:3a:00.0: CSR_HW_REV: 0X00000210
[324281.263084] iwlwifi 0000:3a:00.0: CSR_EEPROM_REG: 0Xd55555d5
[324281.263099] iwlwifi 0000:3a:00.0: CSR_EEPROM_GP: 0X00000000
[324281.263115] iwlwifi 0000:3a:00.0: CSR_OTP_GP_REG: 0Xd55555d5
[324281.263131] iwlwifi 0000:3a:00.0: CSR_GIO_REG: 0X001f0042
[324281.263146] iwlwifi 0000:3a:00.0: CSR_GP_UCODE_REG: 0X00000000
[324281.263162] iwlwifi 0000:3a:00.0: CSR_GP_DRIVER_REG: 0X00000000
[324281.263177] iwlwifi 0000:3a:00.0: CSR_UCODE_DRV_GP1: 0X00000000
[324281.263192] iwlwifi 0000:3a:00.0: CSR_UCODE_DRV_GP2: 0X00000000
[324281.263208] iwlwifi 0000:3a:00.0: CSR_LED_REG: 0X00000060
[324281.263223] iwlwifi 0000:3a:00.0: CSR_DRAM_INT_TBL_REG: 0X88272f5f
[324281.263238] iwlwifi 0000:3a:00.0: CSR_GIO_CHICKEN_BITS: 0X27800200
[324281.263253] iwlwifi 0000:3a:00.0: CSR_ANA_PLL_CFG: 0Xd55555d5
[324281.263272] iwlwifi 0000:3a:00.0: CSR_MONITOR_STATUS_REG: 0Xc3b7ff57
[324281.263293] iwlwifi 0000:3a:00.0: CSR_HW_REV_WA_REG: 0X0001001a
[324281.263311] iwlwifi 0000:3a:00.0: CSR_DBG_HPET_MEM_REG: 0Xffff0010
[324281.263317] iwlwifi 0000:3a:00.0: FH register values:
[324281.263347] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_STTS_WPTR_REG: 0X274eac00
[324281.263374] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_RBDCB_BASE_REG: 0X0274eaf0
[324281.263401] iwlwifi 0000:3a:00.0:
FH_RSCSR_CHNL0_WPTR: 0X00000000
[324281.263427] iwlwifi 0000:3a:00.0:
FH_MEM_RCSR_CHNL0_CONFIG_REG: 0X00801114
[324281.263454] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_SHARED_CTRL_REG: 0X000000fc
[324281.263482] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_RX_STATUS_REG: 0X03030000
[324281.263509] iwlwifi 0000:3a:00.0:
FH_MEM_RSSR_RX_ENABLE_ERR_IRQ2DRV: 0X00000000
[324281.263535] iwlwifi 0000:3a:00.0:
FH_TSSR_TX_STATUS_REG: 0X07ff0001
[324281.263598] iwlwifi 0000:3a:00.0:
FH_TSSR_TX_ERROR_REG: 0X00000000
[324281.263732] iwlwifi 0000:3a:00.0: Start IWL Error Log Dump:
[324281.263739] iwlwifi 0000:3a:00.0: Status: 0x00000000, count: 6
[324281.263745] iwlwifi 0000:3a:00.0: Loaded firmware version: 21.302800.0
[324281.263751] iwlwifi 0000:3a:00.0: 0x00000084 | NMI_INTERRUPT_UNKNOWN
[324281.263756] iwlwifi 0000:3a:00.0: 0x000002F3 | trm_hw_status0
[324281.263762] iwlwifi 0000:3a:00.0: 0x00000000 | trm_hw_status1
[324281.263767] iwlwifi 0000:3a:00.0: 0x000401D4 | branchlink2
[324281.263772] iwlwifi 0000:3a:00.0: 0x00049A60 | interruptlink1
[324281.263777] iwlwifi 0000:3a:00.0: 0x000069F6 | interruptlink2
[324281.263782] iwlwifi 0000:3a:00.0: 0x00000000 | data1
[324281.263787] iwlwifi 0000:3a:00.0: 0x00000080 | data2
[324281.263793] iwlwifi 0000:3a:00.0: 0x03030000 | data3
[324281.263798] iwlwifi 0000:3a:00.0: 0xE280296F | beacon time
[324281.263804] iwlwifi 0000:3a:00.0: 0x0188C690 | tsf low
[324281.263809] iwlwifi 0000:3a:00.0: 0x00000233 | tsf hi
[324281.263814] iwlwifi 0000:3a:00.0: 0x00000000 | time gp1
[324281.263819] iwlwifi 0000:3a:00.0: 0x2E22C83F | time gp2
[324281.263825] iwlwifi 0000:3a:00.0: 0x00000000 | uCode revision type
[324281.263832] iwlwifi 0000:3a:00.0: 0x00000015 | uCode version major
[324281.263838] iwlwifi 0000:3a:00.0: 0x00049ED0 | uCode version minor
[324281.263844] iwlwifi 0000:3a:00.0: 0x00000210 | hw version
[324281.263850] iwlwifi 0000:3a:00.0: 0x00489200 | board version
[324281.263857] iwlwifi 0000:3a:00.0: 0x10FF001C | hcmd
[324281.263862] iwlwifi 0000:3a:00.0: 0x26E22002 | isr0
[324281.263868] iwlwifi 0000:3a:00.0: 0x01804000 | isr1
[324281.263873] iwlwifi 0000:3a:00.0: 0x00000002 | isr2
[324281.263879] iwlwifi 0000:3a:00.0: 0x40400080 | isr3
[324281.263883] iwlwifi 0000:3a:00.0: 0x00000000 | isr4
[324281.263888] iwlwifi 0000:3a:00.0: 0x10800112 | last cmd Id
[324281.263894] iwlwifi 0000:3a:00.0: 0x00000000 | wait_event
[324281.263899] iwlwifi 0000:3a:00.0: 0x00000288 | l2p_control
[324281.263904] iwlwifi 0000:3a:00.0: 0x00001C22 | l2p_duration
[324281.263909] iwlwifi 0000:3a:00.0: 0x000000BF | l2p_mhvalid
[324281.263914] iwlwifi 0000:3a:00.0: 0x00000020 | l2p_addr_match
[324281.263919] iwlwifi 0000:3a:00.0: 0x00000007 | lmpm_pmg_sel
[324281.263925] iwlwifi 0000:3a:00.0: 0x09031909 | timestamp
[324281.263931] iwlwifi 0000:3a:00.0: 0x00340010 | flow_handler
[324281.263940] ieee80211 phy0: Hardware restart was requested
[324281.668963] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.669167] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.734332] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
[324281.734597] iwlwifi 0000:3a:00.0: L1 Enabled - LTR Disabled
Earlier on the same boot I got:
[266562.042662] ------------[ cut here ]------------
[266562.042693] WARNING: CPU: 2 PID: 994 at
drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1377
iwl_mvm_rx_tx_cmd+0x665/0x870 [iwlmvm]
[266562.042697] Modules linked in: rfcomm fuse ccm xt_CHECKSUM
ipt_MASQUERADE nf_nat_masquerade_ipv4 tun nf_conntrack_netbios_ns
nf_conntrack_broadcast ip6t_REJECT nf_reject_ipv6 xt_conntrack
ip6t_rpfilter ebtable_broute bridge stp llc ebtable_nat
ip6table_mangle ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 ip6table_raw ip6table_security iptable_mangle iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
iptable_raw iptable_security ebtable_filter ebtables ip6table_filter
ip6_tables cmac bnep arc4 iwlmvm vfat fat mac80211 snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel
snd_hda_codec iwlwifi intel_rapl snd_hwdep x86_pkg_temp_thermal
hid_multitouch coretemp snd_hda_core kvm_intel kvm snd_seq btusb btrtl
cfg80211 btbcm snd_seq_device btintel
[266562.042780] snd_pcm bluetooth uvcvideo i2c_designware_platform
iTCO_wdt iTCO_vendor_support i2c_designware_core snd_timer
videobuf2_vmalloc dell_wmi videobuf2_memops snd videobuf2_v4l2
videobuf2_core videodev mei_me dell_laptop dell_smbios mei dcdbas
irqbypass efi_pstore joydev rtsx_pci_ms memstick efivars media pcspkr
soundcore i2c_i801 shpchp rfkill idma64 processor_thermal_device
intel_soc_dts_iosf intel_lpss_pci wmi nfsd acpi_als kfifo_buf tpm_tis
industrialio auth_rpcgss pinctrl_sunrisepoint int3400_thermal
intel_lpss_acpi pinctrl_intel tpm intel_lpss nfs_acl intel_hid
acpi_thermal_rel lockd int3403_thermal int340x_thermal_zone
sparse_keymap acpi_pad grace sunrpc binfmt_misc dm_crypt i915
i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt
fb_sys_fops rtsx_pci_sdmmc mmc_core drm crct10dif_pclmul
[266562.042923] crc32_pclmul crc32c_intel ghash_clmulni_intel
serio_raw rtsx_pci i2c_hid video i2c_dev
[266562.042944] CPU: 2 PID: 994 Comm: irq/283-iwlwifi Tainted: G
W 4.7.0-xps13+ #113
[266562.042950] Hardware name: Dell Inc. XPS 13 9350/07TYC2, BIOS
1.4.4 06/14/2016
[266562.042956] 0000000000000286 000000009bd58e95 ffff880273217bb0
ffffffff81462534
[266562.042967] 0000000000000000 0000000000000000 ffff880273217bf0
ffffffff81097a4b
[266562.042976] 0000056175c08720 0000000000000000 0000000000000d14
0000000000000d14
[266562.042986] Call Trace:
[266562.043000] [<ffffffff81462534>] dump_stack+0x65/0x91
[266562.043008] [<ffffffff81097a4b>] __warn+0xcb/0xf0
[266562.043016] [<ffffffff81097b7d>] warn_slowpath_null+0x1d/0x20
[266562.043043] [<ffffffffa085e2e5>] iwl_mvm_rx_tx_cmd+0x665/0x870 [iwlmvm]
[266562.043065] [<ffffffffa0854605>] iwl_mvm_rx_common+0x165/0x260 [iwlmvm]
[266562.043082] [<ffffffffa085475b>] iwl_mvm_rx+0x5b/0x70 [iwlmvm]
[266562.043102] [<ffffffffa0734979>] iwl_pcie_rx_handle+0x319/0x950 [iwlwifi]
[266562.043127] [<ffffffffa07363cb>] iwl_pcie_irq_handler+0x4db/0xb10 [iwlwifi]
[266562.043137] [<ffffffff810f51c0>] ? irq_forced_thread_fn+0x70/0x70
[266562.043144] [<ffffffff810f51e0>] irq_thread_fn+0x20/0x50
[266562.043152] [<ffffffff810f54ad>] irq_thread+0x12d/0x1c0
[266562.043162] [<ffffffff81887773>] ? __schedule+0x2f3/0x7b0
[266562.043169] [<ffffffff810f52d0>] ? wake_threads_waitq+0x30/0x30
[266562.043177] [<ffffffff810f5380>] ? irq_thread_dtor+0xb0/0xb0
[266562.043186] [<ffffffff810b7808>] kthread+0xd8/0xf0
[266562.043197] [<ffffffff8188c7bf>] ret_from_fork+0x1f/0x40
[266562.043207] [<ffffffff810b7730>] ? kthread_worker_fn+0x160/0x160
[266562.043215] ---[ end trace fc942b7f981b5787 ]---
[266563.131187] ------------[ cut here ]------------
^ permalink raw reply
* Re: pull-request: mac80211 2016-08-05
From: David Miller @ 2016-08-07 7:24 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <1470400329-23256-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Fri, 5 Aug 2016 14:32:08 +0200
> Here's a first set of fixes for the current cycle. See the tag message
> for more information.
>
> I'll probably have a follow-up fix for the real problem in mac80211
> that caused the crash later, but for now we have this patch and it
> makes sense and fixes the crash, even if the behaviour isn't quite
> right (afaict.)
>
> Let me know if there's any problem.
Pulled, thanks.
^ permalink raw reply
* Re: pull request: iwlwifi 2016-04-12
From: Emmanuel Grumbach @ 2016-08-07 4:38 UTC (permalink / raw)
To: Grumbach, Emmanuel; +Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org
In-Reply-To: <1460448559.2630.8.camel@intel.com>
On Sun, Aug 7, 2016 at 7:35 AM, Grumbach, Emmanuel
<emmanuel.grumbach@intel.com> wrote:
>
> Hi Kalle,
>
> Here is a pull request for 4.6. I have here a patch that was merged to
> -next already, but clearly, it should have been routed through the
> current cycle's trees. Sorry about that.
> The patch is:
Wow.. I knew evolution was sometimes stupid, but this is new to me..
Obviously you should ignore that.
Sorry...
>
> commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
> Author: Ayala Beker <ayala.beker@intel.com>
> Date: Wed Feb 3 15:36:52 2016 +0200
>
> iwlwifi: mvm: avoid to WARN about gscan capabilities
>
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV and avoid to WARN
> if the firmware does not have the new capabilities.
>
> It appears in -next as:
>
> commit a0b09f13036cedfd67c9cb4b9d05138e7022723d
> Author: Ayala Beker <ayala.beker@intel.com>
> Date: Wed Feb 3 15:36:52 2016 +0200
>
> iwlwifi: mvm: update GSCAN capabilities
>
> Gscan capabilities were updated with new capabilities supported
> by the device. Update GSCAN capabilities TLV.
>
> The commit message wasn't good enough for the current cycle, so I
> rewrote it. Besides that one, all is fairly normal.
> Let me know if you have issues!
>
> Thanks.
>
>
> The following changes since commit 7fdf9663261cc77a516396fec82cee8a8ea07e76:
>
> iwlwifi: mvm: fix memory leak in paging (2016-03-20 23:01:54 +0200)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2016-04-12
>
> for you to fetch changes up to 2d25fb8b3a138706b63bd26ad72a95c58029954a:
>
> iwlwifi: mvm: fix accessing Null pointer during fw dump collection (2016-04-12 10:03:17 +0300)
>
> ----------------------------------------------------------------
> * add new device IDs for 8265
> * fix a NULL pointer dereference when paging firmware asserts
> * remove a WARNING on gscan capabilities
> * fix MODULE_FIRMWARE for 8260
>
> ----------------------------------------------------------------
> Ayala Beker (1):
> iwlwifi: mvm: avoid to WARN about gscan capabilities
>
> Matti Gottlieb (1):
> iwlwifi: mvm: fix accessing Null pointer during fw dump collection
>
> Oren Givon (1):
> iwlwifi: add device IDs for the 8265 device
>
> Sara Sharon (1):
> iwlwifi: 8000: fix MODULE_FIRMWARE input
>
> drivers/net/wireless/intel/iwlwifi/iwl-8000.c | 2 +-
> drivers/net/wireless/intel/iwlwifi/iwl-drv.c | 26 ++++++++++----------------
> drivers/net/wireless/intel/iwlwifi/mvm/fw-dbg.c | 6 ++++--
> drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 2 ++
> drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 10 ++++++++++
> 5 files changed, 27 insertions(+), 19 deletions(-)
^ permalink raw reply
* pull request: iwlwifi 2016-04-12
From: Grumbach, Emmanuel @ 2016-08-07 4:35 UTC (permalink / raw)
To: kvalo@codeaurora.org; +Cc: linux-wireless@vger.kernel.org
SGkgS2FsbGUsDQoNCkhlcmUgaXMgYSBwdWxsIHJlcXVlc3QgZm9yIDQuNi4gSSBoYXZlIGhlcmUg
YSBwYXRjaCB0aGF0IHdhcyBtZXJnZWQgdG8gDQotbmV4dCBhbHJlYWR5LCBidXQgY2xlYXJseSwg
aXQgc2hvdWxkIGhhdmUgYmVlbiByb3V0ZWQgdGhyb3VnaCB0aGUNCmN1cnJlbnQgY3ljbGUncyB0
cmVlcy4gU29ycnkgYWJvdXQgdGhhdC4NClRoZSBwYXRjaCBpczoNCg0KY29tbWl0IGNkNDk3Mjdl
MWEyYmNjYzRmZjAwOGRkZTI0YzJmODQzMGRkOWUzNjgNCkF1dGhvcjogQXlhbGEgQmVrZXIgPGF5
YWxhLmJla2VyQGludGVsLmNvbT4NCkRhdGU6ICAgV2VkIEZlYiAzIDE1OjM2OjUyIDIwMTYgKzAy
MDANCg0KICAgIGl3bHdpZmk6IG12bTogYXZvaWQgdG8gV0FSTiBhYm91dCBnc2NhbiBjYXBhYmls
aXRpZXMNCiAgICANCiAgICBHc2NhbiBjYXBhYmlsaXRpZXMgd2VyZSB1cGRhdGVkIHdpdGggbmV3
IGNhcGFiaWxpdGllcyBzdXBwb3J0ZWQNCiAgICBieSB0aGUgZGV2aWNlLiBVcGRhdGUgR1NDQU4g
Y2FwYWJpbGl0aWVzIFRMViBhbmQgYXZvaWQgdG8gV0FSTg0KICAgIGlmIHRoZSBmaXJtd2FyZSBk
b2VzIG5vdCBoYXZlIHRoZSBuZXcgY2FwYWJpbGl0aWVzLg0KDQpJdCBhcHBlYXJzIGluIC1uZXh0
IGFzOg0KDQpjb21taXQgYTBiMDlmMTMwMzZjZWRmZDY3YzljYjRiOWQwNTEzOGU3MDIyNzIzZA0K
QXV0aG9yOiBBeWFsYSBCZWtlciA8YXlhbGEuYmVrZXJAaW50ZWwuY29tPg0KRGF0ZTogICBXZWQg
RmViIDMgMTU6MzY6NTIgMjAxNiArMDIwMA0KDQogICAgaXdsd2lmaTogbXZtOiB1cGRhdGUgR1ND
QU4gY2FwYWJpbGl0aWVzDQogICAgDQogICAgR3NjYW4gY2FwYWJpbGl0aWVzIHdlcmUgdXBkYXRl
ZCB3aXRoIG5ldyBjYXBhYmlsaXRpZXMgc3VwcG9ydGVkDQogICAgYnkgdGhlIGRldmljZS4gVXBk
YXRlIEdTQ0FOIGNhcGFiaWxpdGllcyBUTFYuDQoNClRoZSBjb21taXQgbWVzc2FnZSB3YXNuJ3Qg
Z29vZCBlbm91Z2ggZm9yIHRoZSBjdXJyZW50IGN5Y2xlLCBzbyBJDQpyZXdyb3RlIGl0LiBCZXNp
ZGVzIHRoYXQgb25lLCBhbGwgaXMgZmFpcmx5IG5vcm1hbC4NCkxldCBtZSBrbm93IGlmIHlvdSBo
YXZlIGlzc3VlcyENCg0KVGhhbmtzLg0KDQoNClRoZSBmb2xsb3dpbmcgY2hhbmdlcyBzaW5jZSBj
b21taXQgN2ZkZjk2NjMyNjFjYzc3YTUxNjM5NmZlYzgyY2VlOGE4ZWEwN2U3NjoNCg0KICBpd2x3
aWZpOiBtdm06IGZpeCBtZW1vcnkgbGVhayBpbiBwYWdpbmcgKDIwMTYtMDMtMjAgMjM6MDE6NTQg
KzAyMDApDQoNCmFyZSBhdmFpbGFibGUgaW4gdGhlIGdpdCByZXBvc2l0b3J5IGF0Og0KDQogIGh0
dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvcHViL3NjbS9saW51eC9rZXJuZWwvZ2l0L2l3bHdpZmkvaXds
d2lmaS1maXhlcy5naXQgdGFncy9pd2x3aWZpLWZvci1rYWxsZS0yMDE2LTA0LTEyDQoNCmZvciB5
b3UgdG8gZmV0Y2ggY2hhbmdlcyB1cCB0byAyZDI1ZmI4YjNhMTM4NzA2YjYzYmQyNmFkNzJhOTVj
NTgwMjk5NTRhOg0KDQogIGl3bHdpZmk6IG12bTogZml4IGFjY2Vzc2luZyBOdWxsIHBvaW50ZXIg
ZHVyaW5nIGZ3IGR1bXAgY29sbGVjdGlvbiAoMjAxNi0wNC0xMiAxMDowMzoxNyArMDMwMCkNCg0K
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KKiBhZGQgbmV3IGRldmljZSBJRHMgZm9yIDgyNjUNCiogZml4IGEgTlVMTCBwb2lu
dGVyIGRlcmVmZXJlbmNlIHdoZW4gcGFnaW5nIGZpcm13YXJlIGFzc2VydHMNCiogcmVtb3ZlIGEg
V0FSTklORyBvbiBnc2NhbiBjYXBhYmlsaXRpZXMNCiogZml4IE1PRFVMRV9GSVJNV0FSRSBmb3Ig
ODI2MA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tDQpBeWFsYSBCZWtlciAoMSk6DQogICAgICBpd2x3aWZpOiBtdm06IGF2
b2lkIHRvIFdBUk4gYWJvdXQgZ3NjYW4gY2FwYWJpbGl0aWVzDQoNCk1hdHRpIEdvdHRsaWViICgx
KToNCiAgICAgIGl3bHdpZmk6IG12bTogZml4IGFjY2Vzc2luZyBOdWxsIHBvaW50ZXIgZHVyaW5n
IGZ3IGR1bXAgY29sbGVjdGlvbg0KDQpPcmVuIEdpdm9uICgxKToNCiAgICAgIGl3bHdpZmk6IGFk
ZCBkZXZpY2UgSURzIGZvciB0aGUgODI2NSBkZXZpY2UNCg0KU2FyYSBTaGFyb24gKDEpOg0KICAg
ICAgaXdsd2lmaTogODAwMDogZml4IE1PRFVMRV9GSVJNV0FSRSBpbnB1dA0KDQogZHJpdmVycy9u
ZXQvd2lyZWxlc3MvaW50ZWwvaXdsd2lmaS9pd2wtODAwMC5jICAgfCAgMiArLQ0KIGRyaXZlcnMv
bmV0L3dpcmVsZXNzL2ludGVsL2l3bHdpZmkvaXdsLWRydi5jICAgIHwgMjYgKysrKysrKysrKy0t
LS0tLS0tLS0tLS0tLS0NCiBkcml2ZXJzL25ldC93aXJlbGVzcy9pbnRlbC9pd2x3aWZpL212bS9m
dy1kYmcuYyB8ICA2ICsrKystLQ0KIGRyaXZlcnMvbmV0L3dpcmVsZXNzL2ludGVsL2l3bHdpZmkv
bXZtL2Z3LmMgICAgIHwgIDIgKysNCiBkcml2ZXJzL25ldC93aXJlbGVzcy9pbnRlbC9pd2x3aWZp
L3BjaWUvZHJ2LmMgICB8IDEwICsrKysrKysrKysNCiA1IGZpbGVzIGNoYW5nZWQsIDI3IGluc2Vy
dGlvbnMoKyksIDE5IGRlbGV0aW9ucygtKQ==
^ permalink raw reply
* RE: [PATCH] cfg80211: Add support for user configurable beacon data rate
From: Undekari, Sunil Dutt @ 2016-08-06 4:38 UTC (permalink / raw)
To: Johannes Berg, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath
In-Reply-To: <1470387784.2977.30.camel@sipsolutions.net>
PiBEb2Vzbid0IHRoaXMgaGF2ZSB0byBjaGVjayB0aGF0IGl0IGFjdHVhbGx5IGdvdCBpbmZvcm1h
dGlvbiBmb3IgdGhlIHJpZ2h0IGJhbmQ/DQpIaSBKb2hhbm5lcyAsDQpubDgwMjExX3BhcnNlX3R4
X2JpdHJhdGVfbWFzayAoIGEgbmV3IHdyYXBwZXIgdG8gdGhlIGV4aXN0aW5nIGZ1bmN0aW9uYWxp
dHkgaW4gbmw4MDIxMV9zZXRfdHhfYml0cmF0ZV9tYXNrICkgZG9lcyB0aGlzICwgaXNuJ3QgPyAN
Cg0KUmVnYXJkcywNClN1bmlsDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv
bTogSm9oYW5uZXMgQmVyZyBbbWFpbHRvOmpvaGFubmVzQHNpcHNvbHV0aW9ucy5uZXRdIA0KU2Vu
dDogRnJpZGF5LCBBdWd1c3QgNSwgMjAxNiAyOjMzIFBNDQpUbzogS3VzaHdhaGEsIFB1cnVzaG90
dGFtIDxwa3VzaHdhaEBxdGkucXVhbGNvbW0uY29tPg0KQ2M6IGxpbnV4LXdpcmVsZXNzQHZnZXIu
a2VybmVsLm9yZzsgTWFsaW5lbiwgSm91bmkgPGpvdW5pQHFjYS5xdWFsY29tbS5jb20+OyBVbmRl
a2FyaSwgU3VuaWwgRHV0dCA8dXNkdXR0QHF0aS5xdWFsY29tbS5jb20+OyBLb25kYWJhdHRpbmks
IEdhbmVzaCA8Z2FuZXNoa0BxdGkucXVhbGNvbW0uY29tPjsgS2FsaWtvdCBWZWV0aWwsIE1haGVz
aCBLdW1hciA8bWthbGlrb3RAcWNhLnF1YWxjb21tLmNvbT47IEh1bGx1ciBTdWJyYW1hbnlhbSwg
QW1hcm5hdGggPGFtYXJuYXRoQHFjYS5xdWFsY29tbS5jb20+DQpTdWJqZWN0OiBSZTogW1BBVENI
XSBjZmc4MDIxMTogQWRkIHN1cHBvcnQgZm9yIHVzZXIgY29uZmlndXJhYmxlIGJlYWNvbiBkYXRh
IHJhdGUNCg0KT24gRnJpLCAyMDE2LTA4LTA1IGF0IDEwOjA1ICswNTMwLCBQdXJ1c2hvdHRhbSBL
dXNod2FoYSB3cm90ZToNCj7CoA0KPiArc3RhdGljIGludCBubDgwMjExX3BhcnNlX3R4X2JpdHJh
dGVfbWFzayhzdHJ1Y3QgZ2VubF9pbmZvICppbmZvLA0KPiArCQkJCQnCoHN0cnVjdCBjZmc4MDIx
MV9iaXRyYXRlX21hc2sgKm1hc2spOw0KDQpJIHRoaW5rIHlvdSBzaG91bGQgbW92ZSB0aGUgZnVu
Y3Rpb24gaW5zdGVhZC4NCg0KPiBAQCAtMzQ1Nyw2ICszNDU5LDExIEBAIHN0YXRpYyBpbnQgbmw4
MDIxMV9zdGFydF9hcChzdHJ1Y3Qgc2tfYnVmZiANCj4gKnNrYiwgc3RydWN0IGdlbmxfaW5mbyAq
aW5mbykNCj4gwqAJZXJyID0gY2ZnODAyMTFfdmFsaWRhdGVfYmVhY29uX2ludChyZGV2LA0KPiBw
YXJhbXMuYmVhY29uX2ludGVydmFsKTsNCj4gwqAJaWYgKGVycikNCj4gwqAJCXJldHVybiBlcnI7
DQo+ICsJaWYgKGluZm8tPmF0dHJzW05MODAyMTFfQVRUUl9UWF9SQVRFU10pIHsNCj4gKwkJZXJy
ID0gbmw4MDIxMV9wYXJzZV90eF9iaXRyYXRlX21hc2soaW5mbywNCj4gJnBhcmFtcy5iZWFjb25f
cmF0ZSk7DQo+ICsJCWlmIChlcnIpDQo+ICsJCQlyZXR1cm4gZXJyOw0KPiArCX0NCg0KRG9lc24n
dCB0aGlzIGhhdmUgdG8gY2hlY2sgdGhhdCBpdCBhY3R1YWxseSBnb3QgaW5mb3JtYXRpb24gZm9y
IHRoZSByaWdodCBiYW5kPw0KDQpqb2hhbm5lcw0K
^ permalink raw reply
* [PATCH] ath10k: fix group privacy action frame decryption for qca4019
From: Rajkumar Manoharan @ 2016-08-06 4:19 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, rmanohar, Rajkumar Manoharan
Recent commit 'mac80211: Encrypt "Group addressed privacy" action frames'
encrypts group privacy action frames. But qca99x0 family chipset delivers
broadcast/multicast management frames as encrypted and it should be
decrypted by mac80211. Setting RX_FLAG_DECRYPTED stats for those frames
is breaking mesh connection establishment.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/core.c | 4 ++++
drivers/net/wireless/ath/ath10k/core.h | 5 +++++
drivers/net/wireless/ath/ath10k/wmi.c | 30 +++++++++++++++++++++++++-----
3 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index 0ca58cf0ffea..c4d1a5ba216e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -182,6 +182,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9984_HW_1_0_DEV_VERSION,
@@ -205,6 +206,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9888_HW_2_0_DEV_VERSION,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
{
.id = QCA9377_HW_1_0_DEV_VERSION,
@@ -285,6 +288,7 @@ static const struct ath10k_hw_params ath10k_hw_params_list[] = {
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
},
+ .sw_decrypt_mcast_mgmt = true,
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index f36c2b274ee5..7254bd3e7c82 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -765,6 +765,11 @@ struct ath10k {
size_t board_size;
size_t board_ext_size;
} fw;
+
+ /* qca99x0 family chips deliver broadcast/multicast management
+ * frames encrypted and expect software do decryption.
+ */
+ bool sw_decrypt_mcast_mgmt;
} hw_params;
/* contains the firmware images used with ATH10K_FIRMWARE_MODE_NORMAL */
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 169cd2e783eb..bced8ac7ed94 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2240,6 +2240,30 @@ static int ath10k_wmi_10_4_op_pull_mgmt_rx_ev(struct ath10k *ar,
return 0;
}
+static bool ath10k_wmi_rx_is_decrypted(struct ath10k *ar,
+ struct ieee80211_hdr *hdr)
+{
+ if (!ieee80211_has_protected(hdr->frame_control))
+ return false;
+
+ /* FW delivers WEP Shared Auth frame with Protected Bit set and
+ * encrypted payload. However in case of PMF it delivers decrypted
+ * frames with Protected Bit set.
+ */
+ if (ieee80211_is_auth(hdr->frame_control))
+ return false;
+
+ /* qca99x0 based FW delivers broadcast or multicast management frames
+ * (ex: group privacy action frames in mesh) as encrypted payload.
+ */
+ if ((is_broadcast_ether_addr(ieee80211_get_DA(hdr)) ||
+ is_multicast_ether_addr(ieee80211_get_DA(hdr))) &&
+ ar->hw_params.sw_decrypt_mcast_mgmt)
+ return false;
+
+ return true;
+}
+
int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
{
struct wmi_mgmt_rx_ev_arg arg = {};
@@ -2326,11 +2350,7 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
ath10k_wmi_handle_wep_reauth(ar, skb, status);
- /* FW delivers WEP Shared Auth frame with Protected Bit set and
- * encrypted payload. However in case of PMF it delivers decrypted
- * frames with Protected Bit set. */
- if (ieee80211_has_protected(hdr->frame_control) &&
- !ieee80211_is_auth(hdr->frame_control)) {
+ if (ath10k_wmi_rx_is_decrypted(ar, hdr)) {
status->flag |= RX_FLAG_DECRYPTED;
if (!ieee80211_is_action(hdr->frame_control) &&
--
2.9.2
^ permalink raw reply related
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-08-06 14:12 UTC (permalink / raw)
To: Franky Lin
Cc: Arend Van Spriel, Brett Rudley, brcm80211-dev-list,
Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel
In-Reply-To: <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com>
Hi all,
On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause@embedded.ro
cks>
wrote:
Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
arend.vanspriel@broadcom.com>:
Op 5 aug. 2016 22:46 schreef "Jörg Krause"
<joerg.krause@embedded.rocks>:
Hi,
I'm using a custom ARM board with an BCM43362 wifi chip from
Broadcom.
The wifi chip is attached via SDIO to the controller with a
clock of
48MHz. Linux kernel version is 4.7.
When measuring the network bandwidth with iperf3 I get a
bandwith of
only around 5 Mbps. I found a similar thread at the Broadcom
community
[1] where the test was done with a M4 CPU + BCM43362 and an
average
result of 3.3 Mbps.
Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
throughput
greater than 20 Mbps.
Why is the throughput I measured much lower? Note that I
measured
several times with almost no neighbor devices or networks.
This is a test sample measured with iperf3:
$ iperf3 -c 192.168.2.1 -i 1 -t 10
Connecting to host 192.168.2.1, port 5201
[ 4] local 192.168.2.155 port 36442 connected to
192.168.2.1
port
5201
[ ID]
Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 615 KBytes 5.04
Mbits/sec 0 56.6
KBytes
[ 4] 1.00-2.00 sec 622 KBytes 5.10
Mbits/sec 0 84.8
KBytes
[ 4] 2.00-3.00 sec 625 KBytes 5.12
Mbits/sec 0 113
KBytes
[ 4] 3.00-4.00 sec 571 KBytes 4.68
Mbits/sec 0 140
KBytes
[ 4] 4.00-5.00 sec 594 KBytes 4.87
Mbits/sec 0 167
KBytes
[ 4] 5.00-6.00 sec 628 KBytes 5.14
Mbits/sec 0 195
KBytes
[ 4] 6.00-7.00 sec 619 KBytes 5.07
Mbits/sec 0 202
KBytes
[ 4] 7.00-8.00 sec 608 KBytes 4.98
Mbits/sec 0 202
KBytes
[ 4] 8.00-9.00 sec 602 KBytes 4.93
Mbits/sec 0 202
KBytes
[ 4] 9.00-10.00 sec 537 KBytes 4.40
Mbits/sec 0 202
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 5.88 MBytes 4.93
Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 5.68 MBytes 4.76
Mbits/sec receiver
Not overly familiar with iperf3. Do these lines mean you are
doing
bidirectional test, ie. upstream and downstream at the same time.
Another
thing affecting tput could be power-save.
No, iperf3 does not support bidrectional test. Power-save is turned
off.
What does iw link say?
I compared the results with a Cubietruck I have:
# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 192.168.178.46, port 42906
[ 5] local 192.168.178.38 port 5201 connected to 192.168.178.46 port
42908
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 2.29 MBytes 19.2 Mbits/sec
[ 5] 1.00-2.00 sec 2.21 MBytes 18.5 Mbits/sec
[ 5] 2.00-3.00 sec 2.17 MBytes 18.2 Mbits/sec
[ 5] 3.00-4.00 sec 2.09 MBytes 17.6 Mbits/sec
[ 5] 4.00-5.00 sec 2.20 MBytes 18.5 Mbits/sec
[ 5] 5.00-6.00 sec 2.64 MBytes 22.1 Mbits/sec
[ 5] 6.00-7.00 sec 2.67 MBytes 22.4 Mbits/sec
[ 5] 7.00-8.00 sec 2.62 MBytes 22.0 Mbits/sec
[ 5] 8.00-9.00 sec 2.35 MBytes 19.8 Mbits/sec
[ 5] 9.00-10.00 sec 2.30 MBytes 19.3 Mbits/sec
[ 5] 10.00-10.03 sec 83.4 KBytes 23.5 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 5] 0.00-10.03 sec 23.9 MBytes 20.0
Mbits/sec 0 sender
[ 5] 0.00-10.03 sec 23.6 MBytes 19.8
Mbits/sec receiver
# iw dev wlan0 link
Connected to xx:xx:xx:xx:xx (on wlan0)
SSID: xxx
freq: 2437
tx bitrate: 65.0 MBit/s
bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100
The Cubietruck works also with the brcmfmac driver.
May it depend on the NVRAM file?
Best regards
Jörg Krause
^ permalink raw reply
* brcmfmac43430-sdio.bin in linux-firmware
From: Fabio Estevam @ 2016-08-06 15:15 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless, brcm80211-dev-list, Hante Meuleman
Hi,
I managed to get Wifi working on a imx7 warp board, which has a BCM43430 device.
I used the firmware from the RaspberryPi repository:
https://github.com/RPi-Distro/firmware-nonfree/tree/master/brcm80211/brcm
Are there any plans to make brcmfmac43430-sdio.bin available in the
official linux-firmware repository?
Thanks,
Fabio Estevam
^ permalink raw reply
* Re: [patch] ath9k: indent an if statement
From: Julian Calaby @ 2016-08-06 14:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: QCA ath9k Development, Benjamin Berg, Kalle Valo, linux-wireless,
ath9k-devel, kernel-janitors
In-Reply-To: <20160803184339.GB775@mwanda>
Hi All,
On Thu, Aug 4, 2016 at 4:43 AM, Dan Carpenter <dan.carpenter@oracle.com> wrote:
> It looks like this code is correct, but it just needs to be indented a
> bit.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Looks right to me.
Reviewed-by: Julian Calaby <julian.calaby@gmail.com>
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH] cfg80211: Add support for user configurable beacon data rate
From: Johannes Berg @ 2016-08-06 19:57 UTC (permalink / raw)
To: Undekari, Sunil Dutt, Kushwaha, Purushottam
Cc: linux-wireless@vger.kernel.org, Malinen, Jouni,
Kondabattini, Ganesh, Kalikot Veetil, Mahesh Kumar,
Hullur Subramanyam, Amarnath
In-Reply-To: <92b06d4df5984e6ea91081126e096a96@aphydexm01f.ap.qualcomm.com>
On Sat, 2016-08-06 at 04:38 +0000, Undekari, Sunil Dutt wrote:
> >
> > Doesn't this have to check that it actually got information for the
> > right band?
> Hi Johannes ,
> nl80211_parse_tx_bitrate_mask ( a new wrapper to the existing
> functionality in nl80211_set_tx_bitrate_mask ) does this , isn't ?
>
It checks that everything matches up with capabilities, but it doesn't
check that if you specified NL80211_ATTR_TX_RATES you didn't do
something stupid like specifying it for 2.4GHz while your AP is
starting up on 5GHz.
It also doesn't check that you specified exactly one rate, but it's not
clear how else this would work?
johannes
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-08-06 8:07 UTC (permalink / raw)
To: Franky Lin
Cc: Arend Van Spriel, Brett Rudley, brcm80211-dev-list,
Hante Meuleman, Franky Lin, linux-wireless, Arend van Spriel
In-Reply-To: <CA+8PC_f7VQMwBfQmZZ_vUtYtNJKVYzmFmxziAwoG8-iRUeW9Jw@mail.gmail.com>
Hi Franky,
On Fr, 2016-08-05 at 17:56 -0700, Franky Lin wrote:
> On Fri, Aug 5, 2016 at 2:29 PM, Jörg Krause <joerg.krause@embedded.ro
> cks>
> wrote:
>
> >
> >
> >
> > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
> > arend.vanspriel@broadcom.com>:
> > >
> > > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> > > <joerg.krause@embedded.rocks>:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > I'm using a custom ARM board with an BCM43362 wifi chip from
> > > Broadcom.
> > > >
> > > > The wifi chip is attached via SDIO to the controller with a
> > > > clock of
> > > > 48MHz. Linux kernel version is 4.7.
> > > >
> > > > When measuring the network bandwidth with iperf3 I get a
> > > > bandwith of
> > > > only around 5 Mbps. I found a similar thread at the Broadcom
> > > community
> > > >
> > > > [1] where the test was done with a M4 CPU + BCM43362 and an
> > > > average
> > > > result of 3.3 Mbps.
> > > >
> > > > Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
> > > throughput
> > > >
> > > > greater than 20 Mbps.
> > > >
> > > > Why is the throughput I measured much lower? Note that I
> > > > measured
> > > > several times with almost no neighbor devices or networks.
> > > >
> > > > This is a test sample measured with iperf3:
> > > >
> > > > $ iperf3 -c 192.168.2.1 -i 1 -t 10
> > > > Connecting to host 192.168.2.1, port 5201
> > > > [ 4] local 192.168.2.155 port 36442 connected to
> > > > 192.168.2.1
> > > port
> > > >
> > > > 5201
> > > > [ ID]
> > > > Interval Transfer Bandwidth Retr Cwnd
> > > > [ 4] 0.00-1.00 sec 615 KBytes 5.04
> > > > Mbits/sec 0 56.6
> > > > KBytes
> > > > [ 4] 1.00-2.00 sec 622 KBytes 5.10
> > > > Mbits/sec 0 84.8
> > > > KBytes
> > > > [ 4] 2.00-3.00 sec 625 KBytes 5.12
> > > > Mbits/sec 0 113
> > > > KBytes
> > > > [ 4] 3.00-4.00 sec 571 KBytes 4.68
> > > > Mbits/sec 0 140
> > > > KBytes
> > > > [ 4] 4.00-5.00 sec 594 KBytes 4.87
> > > > Mbits/sec 0 167
> > > > KBytes
> > > > [ 4] 5.00-6.00 sec 628 KBytes 5.14
> > > > Mbits/sec 0 195
> > > > KBytes
> > > > [ 4] 6.00-7.00 sec 619 KBytes 5.07
> > > > Mbits/sec 0 202
> > > > KBytes
> > > > [ 4] 7.00-8.00 sec 608 KBytes 4.98
> > > > Mbits/sec 0 202
> > > > KBytes
> > > > [ 4] 8.00-9.00 sec 602 KBytes 4.93
> > > > Mbits/sec 0 202
> > > > KBytes
> > > > [ 4] 9.00-10.00 sec 537 KBytes 4.40
> > > > Mbits/sec 0 202
> > > > KBytes
> > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > [ ID] Interval Transfer Bandwidth Retr
> > > > [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
> > > > Mbits/sec 0 sender
> > > > [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
> > > > Mbits/sec receiver
> > >
> > > Not overly familiar with iperf3. Do these lines mean you are
> > > doing
> > > bidirectional test, ie. upstream and downstream at the same time.
> > > Another
> > > thing affecting tput could be power-save.
> >
> > No, iperf3 does not support bidrectional test. Power-save is turned
> > off.
> >
> > What does iw link say?
It says:
# iw dev wlan0 link
Connected to xx:xx:xx:xx:xx (on wlan0)
SSID: xxx
freq: 2437
signal: -60 dBm
tx bitrate: 58.5 MBit/s
bss flags: short-preamble short-slot-time
dtim period: 1
beacon int: 100
Best regards
Jörg Krause
^ permalink raw reply
* Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-06 20:16 UTC (permalink / raw)
To: Stephan Mueller
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo
In-Reply-To: <6481670.KeU7RXkv1k@myon.chronox.de>
Hi Stephan,
On Sat, Aug 06, 2016 at 10:03:58PM +0200, Stephan Mueller wrote:
> Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper:
> > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote:
...
> > > diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> > > b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..d63dc48 100644
> > > --- a/drivers/net/wireless/ath/ath9k/rng.c
> > > +++ b/drivers/net/wireless/ath/ath9k/rng.c
> > > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data)
> > >
> > > fail_stats = 0;
> > >
> > > /* sleep until entropy bits under write_wakeup_threshold */
> > >
> > > - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> > > - ATH9K_RNG_ENTROPY(bytes_read));
> >
> > This is the only use of this macro. I'd remove the #define on line 25
> > as well.
>
> My idea for leaving it was that folks who would bring the RNG into the
> hwrandom framework could reuse the ideas from the original authors.
>
> What about commenting it out with #if 0 ?
#if 0 is frowned upon. If that calculation is documented somewhere,
then it can be redone from the spec. If it isn't, then I'd be curious
to know where it came from.
Perhaps one of the ath9k devs can point to a document containing the
formula? We could put the reference in a comment.
thx,
Jason.
^ permalink raw reply
* Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Stephan Mueller @ 2016-08-06 20:03 UTC (permalink / raw)
To: Jason Cooper
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo
In-Reply-To: <20160806194551.GA4511@io.lakedaemon.net>
Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper:
Hi Jason,
> Hi Stephan,
>
> On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote:
> > Hi Ted, Herbert,
> >
> > I sent a question to the ATH9K RNG some time ago to the developers.
> > See
> > https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html
> >
> > I have not yet received a word and I think this issue should be resolved.
> >
> > Thanks
> > Stephan
> >
> > ---8<---
>
> If the above text is placed below the three dashes, "---", below ...
>
> > The ATH9K driver implements an RNG which is completely bypassing the
> > standard Linux HW generator logic.
> >
> > The RNG may or may not deliver entropy. Considering the conservative
> > approach in treating entropy with respect to non-auditable sources, this
> > patch changes the delivered entropy value to zero. The RNG still feeds
> > data into the input_pool but it is assumed to have no entropy.
> >
> > When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> > the entropy estimation considering that a user can change that value at
> > boot and runtime.
> >
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> > ---
>
> here, then the mail can be applied directly without editing.
Thank you for the hint. I will resend the patch that can be applied.
>
> > drivers/net/wireless/ath/ath9k/rng.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/rng.c
> > b/drivers/net/wireless/ath/ath9k/rng.c index d38e50f..d63dc48 100644
> > --- a/drivers/net/wireless/ath/ath9k/rng.c
> > +++ b/drivers/net/wireless/ath/ath9k/rng.c
> > @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data)
> >
> > fail_stats = 0;
> >
> > /* sleep until entropy bits under write_wakeup_threshold */
> >
> > - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> > - ATH9K_RNG_ENTROPY(bytes_read));
>
> This is the only use of this macro. I'd remove the #define on line 25
> as well.
My idea for leaving it was that folks who would bring the RNG into the
hwrandom framework could reuse the ideas from the original authors.
What about commenting it out with #if 0 ?
>
> > + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
> >
> > }
> >
> > kfree(rng_buf);
>
> Other than that,
>
> Reviewed-by: Jason Cooper <jason@lakedaemon.net>
Thank you.
>
> thx,
>
> Jason.
--
Ciao
Stephan
^ permalink raw reply
* Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-06 19:45 UTC (permalink / raw)
To: Stephan Mueller
Cc: Ted Tso, herbert, linux-kernel, linux-crypto, ath9k-devel,
linux-wireless, ath9k-devel, Kalle Valo
In-Reply-To: <34197429.2CvoIfft9B@positron.chronox.de>
Hi Stephan,
On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote:
> Hi Ted, Herbert,
>
> I sent a question to the ATH9K RNG some time ago to the developers.
> See https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg19115.html
>
> I have not yet received a word and I think this issue should be resolved.
>
> Thanks
> Stephan
>
> ---8<---
If the above text is placed below the three dashes, "---", below ...
> The ATH9K driver implements an RNG which is completely bypassing the
> standard Linux HW generator logic.
>
> The RNG may or may not deliver entropy. Considering the conservative
> approach in treating entropy with respect to non-auditable sources, this
> patch changes the delivered entropy value to zero. The RNG still feeds
> data into the input_pool but it is assumed to have no entropy.
>
> When the ATH9K RNG changes to use the HW RNG framework, it may re-enable
> the entropy estimation considering that a user can change that value at
> boot and runtime.
>
> Signed-off-by: Stephan Mueller <smueller@chronox.de>
> ---
here, then the mail can be applied directly without editing.
> drivers/net/wireless/ath/ath9k/rng.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
> index d38e50f..d63dc48 100644
> --- a/drivers/net/wireless/ath/ath9k/rng.c
> +++ b/drivers/net/wireless/ath/ath9k/rng.c
> @@ -92,8 +92,7 @@ static int ath9k_rng_kthread(void *data)
> fail_stats = 0;
>
> /* sleep until entropy bits under write_wakeup_threshold */
> - add_hwgenerator_randomness((void *)rng_buf, bytes_read,
> - ATH9K_RNG_ENTROPY(bytes_read));
This is the only use of this macro. I'd remove the #define on line 25
as well.
> + add_hwgenerator_randomness((void *)rng_buf, bytes_read, 0);
> }
>
> kfree(rng_buf);
Other than that,
Reviewed-by: Jason Cooper <jason@lakedaemon.net>
thx,
Jason.
^ permalink raw reply
* Re: TCP data throughput for BCM43362
From: Jörg Krause @ 2016-08-05 21:29 UTC (permalink / raw)
To: Arend Van Spriel
Cc: Brett Rudley, brcm80211-dev-list, Hante Meuleman, Franky Lin,
linux-wireless, Arend van Spriel
In-Reply-To: <CAF7Mx6o+WuQqtzuApMWQ8YAkLSX7xQ_H06xmO--RxFdwHwzLdQ@mail.gmail.com>
Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <arend.vanspriel@broadcom.com>:
>Op 5 aug. 2016 22:46 schreef "Jörg Krause"
><joerg.krause@embedded.rocks>:
>>
>> Hi,
>>
>> I'm using a custom ARM board with an BCM43362 wifi chip from
>Broadcom.
>> The wifi chip is attached via SDIO to the controller with a clock of
>> 48MHz. Linux kernel version is 4.7.
>>
>> When measuring the network bandwidth with iperf3 I get a bandwith of
>> only around 5 Mbps. I found a similar thread at the Broadcom
>community
>> [1] where the test was done with a M4 CPU + BCM43362 and an average
>> result of 3.3 Mbps.
>>
>> Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data
>throughput
>> greater than 20 Mbps.
>>
>> Why is the throughput I measured much lower? Note that I measured
>> several times with almost no neighbor devices or networks.
>>
>> This is a test sample measured with iperf3:
>>
>> $ iperf3 -c 192.168.2.1 -i 1 -t 10
>> Connecting to host 192.168.2.1, port 5201
>> [ 4] local 192.168.2.155 port 36442 connected to 192.168.2.1
>port
>> 5201
>> [ ID] Interval Transfer Bandwidth Retr Cwnd
>> [ 4] 0.00-1.00 sec 615 KBytes 5.04 Mbits/sec 0 56.6
>> KBytes
>> [ 4] 1.00-2.00 sec 622 KBytes 5.10 Mbits/sec 0 84.8
>> KBytes
>> [ 4] 2.00-3.00 sec 625 KBytes 5.12 Mbits/sec 0 113
>> KBytes
>> [ 4] 3.00-4.00 sec 571 KBytes 4.68 Mbits/sec 0 140
>> KBytes
>> [ 4] 4.00-5.00 sec 594 KBytes 4.87 Mbits/sec 0 167
>> KBytes
>> [ 4] 5.00-6.00 sec 628 KBytes 5.14 Mbits/sec 0 195
>> KBytes
>> [ 4] 6.00-7.00 sec 619 KBytes 5.07 Mbits/sec 0 202
>> KBytes
>> [ 4] 7.00-8.00 sec 608 KBytes 4.98 Mbits/sec 0 202
>> KBytes
>> [ 4] 8.00-9.00 sec 602 KBytes 4.93 Mbits/sec 0 202
>> KBytes
>> [ 4] 9.00-10.00 sec 537 KBytes 4.40 Mbits/sec 0 202
>> KBytes
>> - - - - - - - - - - - - - - - - - - - - - - - - -
>> [ ID] Interval Transfer Bandwidth Retr
>> [ 4] 0.00-10.00 sec 5.88 MBytes 4.93
>> Mbits/sec 0 sender
>> [ 4] 0.00-10.00 sec 5.68 MBytes 4.76
>> Mbits/sec receiver
>
>Not overly familiar with iperf3. Do these lines mean you are doing
>bidirectional test, ie. upstream and downstream at the same time.
>Another
>thing affecting tput could be power-save.
No, iperf3 does not support bidrectional test. Power-save is turned off.
^ permalink raw reply
* TCP data throughput for BCM43362
From: Jörg Krause @ 2016-08-05 20:46 UTC (permalink / raw)
To: linux-wireless
Cc: brcm80211-dev-list, Brett Rudley, Arend van Spriel, Franky Lin,
Hante Meuleman
Hi,
I'm using a custom ARM board with an BCM43362 wifi chip from Broadcom.
The wifi chip is attached via SDIO to the controller with a clock of
48MHz. Linux kernel version is 4.7.
When measuring the network bandwidth with iperf3 I get a bandwith of
only around 5 Mbps. I found a similar thread at the Broadcom community
[1] where the test was done with a M4 CPU + BCM43362 and an average
result of 3.3 Mbps.
Interestingly, a BCM43362 Wi-Fi Dev Kit [2] notes a TCP data throughput
greater than 20 Mbps.
Why is the throughput I measured much lower? Note that I measured
several times with almost no neighbor devices or networks.
This is a test sample measured with iperf3:
$ iperf3 -c 192.168.2.1 -i 1 -t 10
Connecting to host 192.168.2.1, port 5201
[ 4] local 192.168.2.155 port 36442 connected to 192.168.2.1 port
5201
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 615 KBytes 5.04 Mbits/sec 0 56.6
KBytes
[ 4] 1.00-2.00 sec 622 KBytes 5.10 Mbits/sec 0 84.8
KBytes
[ 4] 2.00-3.00 sec 625 KBytes 5.12 Mbits/sec 0 113
KBytes
[ 4] 3.00-4.00 sec 571 KBytes 4.68 Mbits/sec 0 140
KBytes
[ 4] 4.00-5.00 sec 594 KBytes 4.87 Mbits/sec 0 167
KBytes
[ 4] 5.00-6.00 sec 628 KBytes 5.14 Mbits/sec 0 195
KBytes
[ 4] 6.00-7.00 sec 619 KBytes 5.07 Mbits/sec 0 202
KBytes
[ 4] 7.00-8.00 sec 608 KBytes 4.98 Mbits/sec 0 202
KBytes
[ 4] 8.00-9.00 sec 602 KBytes 4.93 Mbits/sec 0 202
KBytes
[ 4] 9.00-10.00 sec 537 KBytes 4.40 Mbits/sec 0 202
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 5.88 MBytes 4.93
Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 5.68 MBytes 4.76
Mbits/sec receiver
[1] https://community.broadcom.com/thread/3978
[2] http://www.mouser.de/new/broadcom/broadcom-bcm943362wcd4/
Best regards
Jörg Krause
^ permalink raw reply
* [PATCH 1/1] brcmfmac: fix pmksa->bssid usage
From: Nicolas Iooss @ 2016-08-05 20:34 UTC (permalink / raw)
To: Arend van Spriel, Franky Lin, Hante Meuleman, linux-wireless,
brcm80211-dev-list.pdl
Cc: netdev, linux-kernel, Nicolas Iooss
The struct cfg80211_pmksa defines its bssid field as:
const u8 *bssid;
contrary to struct brcmf_pmksa, which uses:
u8 bssid[ETH_ALEN];
Therefore in brcmf_cfg80211_del_pmksa(), &pmksa->bssid takes the address
of this field (of type u8**), not the one of its content (which would be
u8*). Remove the & operator to make brcmf_dbg("%pM") and memcmp()
behave as expected.
This bug have been found using a custom static checker (which checks the
usage of %p... attributes at build time). It has been introduced in
commit 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code"),
which replaced pmksa->bssid by &pmksa->bssid while refactoring the code,
without modifying struct cfg80211_pmksa definition.
Fixes: 6c404f34f2bd ("brcmfmac: Cleanup pmksa cache handling code")
Cc: stable@ger.kernel.org
Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
---
scripts/checkpatch.pl reports a warning: "Prefer ether_addr_equal() or
ether_addr_equal_unaligned() over memcmp()". Because some files in
drivers/net/wireless/broadcom/brcm80211/brcmfmac/ still use memcmp()
to compare addresses and because I do not know whether pmksa->bssid is
always aligned, I did not follow this warning.
drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 2628d5e12c64..aceab77cd95a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -3884,11 +3884,11 @@ brcmf_cfg80211_del_pmksa(struct wiphy *wiphy, struct net_device *ndev,
if (!check_vif_up(ifp->vif))
return -EIO;
- brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", &pmksa->bssid);
+ brcmf_dbg(CONN, "del_pmksa - PMK bssid = %pM\n", pmksa->bssid);
npmk = le32_to_cpu(cfg->pmk_list.npmk);
for (i = 0; i < npmk; i++)
- if (!memcmp(&pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
+ if (!memcmp(pmksa->bssid, &pmk[i].bssid, ETH_ALEN))
break;
if ((npmk > 0) && (i < npmk)) {
--
2.9.2
^ permalink raw reply related
* [PATCH] Staging: rtl8723au: rtw_ieee80211: Fixed operators spacing style issues
From: Shiva Kerdel @ 2016-08-05 20:14 UTC (permalink / raw)
To: Larry.Finger
Cc: Jes.Sorensen, gregkh, amsfield22, linux-wireless, devel,
linux-kernel, Shiva Kerdel
Fixed spaces around operators to fix their coding style issues.
Signed-off-by: Shiva Kerdel <shiva@exdev.nl>
---
drivers/staging/rtl8723au/core/rtw_ieee80211.c | 80 +++++++++++++-------------
1 file changed, 40 insertions(+), 40 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_ieee80211.c b/drivers/staging/rtl8723au/core/rtw_ieee80211.c
index 07a6490..9fa0ef1 100644
--- a/drivers/staging/rtl8723au/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8723au/core/rtw_ieee80211.c
@@ -65,7 +65,7 @@ static u8 WIFI_OFDMRATES[] = {
int rtw_get_bit_value_from_ieee_value23a(u8 val)
{
- unsigned char dot11_rate_table[]=
+ unsigned char dot11_rate_table[] =
{2, 4, 11, 22, 12, 18, 24, 36, 48, 72, 96, 108, 0};
int i = 0;
@@ -140,7 +140,7 @@ u8 *rtw_set_ie23a(u8 *pbuf, int index, uint len, const u8 *source, uint *frlen)
return pbuf + len + 2;
}
-inline u8 *rtw_set_ie23a_ch_switch (u8 *buf, u32 *buf_len, u8 ch_switch_mode,
+inline u8 *rtw_set_ie23a_ch_switch(u8 *buf, u32 *buf_len, u8 ch_switch_mode,
u8 new_ch, u8 ch_switch_cnt)
{
u8 ie_data[3];
@@ -230,14 +230,14 @@ u8 *rtw_get_ie23a_ex(u8 *in_ie, uint in_len, u8 eid, u8 *oui, u8 oui_len,
while (cnt < in_len) {
if (eid == in_ie[cnt] &&
- (!oui || !memcmp(&in_ie[cnt+2], oui, oui_len))) {
+ (!oui || !memcmp(&in_ie[cnt + 2], oui, oui_len))) {
target_ie = &in_ie[cnt];
if (ie)
- memcpy(ie, &in_ie[cnt], in_ie[cnt+1]+2);
+ memcpy(ie, &in_ie[cnt], in_ie[cnt + 1] + 2);
if (ielen)
- *ielen = in_ie[cnt+1]+2;
+ *ielen = in_ie[cnt + 1] + 2;
break;
} else {
cnt += in_ie[cnt + 1] + 2; /* goto next */
@@ -331,7 +331,7 @@ uint rtw_get_rateset_len23a(u8 *rateset)
{
uint i = 0;
- while(1) {
+ while (1) {
if (rateset[i] == 0)
break;
@@ -378,7 +378,7 @@ int rtw_generate_ie23a(struct registry_priv *pregistrypriv)
wireless_mode = pregistrypriv->wireless_mode;
}
- rtw_set_supported_rate23a(pdev_network->SupportedRates, wireless_mode) ;
+ rtw_set_supported_rate23a(pdev_network->SupportedRates, wireless_mode);
rateLen = rtw_get_rateset_len23a(pdev_network->SupportedRates);
@@ -533,7 +533,7 @@ int rtw_parse_wpa2_ie23a(const u8 *rsn_ie, int rsn_ie_len, int *group_cipher,
return _FAIL;
}
- if (*rsn_ie != WLAN_EID_RSN || *(rsn_ie+1) != (u8)(rsn_ie_len - 2)) {
+ if (*rsn_ie != WLAN_EID_RSN || *(rsn_ie + 1) != (u8)(rsn_ie_len - 2)) {
return _FAIL;
}
@@ -791,64 +791,64 @@ u16 rtw_mcs_rate23a(u8 rf_type, u8 bw_40MHz, u8 short_GI_20, u8 short_GI_40,
if (rf_type == RF_1T1R) {
if (mcs->rx_mask[0] & BIT(7))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1500:1350):
- ((short_GI_20)?722:650);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1500 : 1350) :
+ ((short_GI_20) ? 722 : 650);
else if (mcs->rx_mask[0] & BIT(6))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1350:1215):
- ((short_GI_20)?650:585);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1350 : 1215) :
+ ((short_GI_20) ? 650 : 585);
else if (mcs->rx_mask[0] & BIT(5))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1200:1080):
- ((short_GI_20)?578:520);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1200 : 1080) :
+ ((short_GI_20) ? 578 : 520);
else if (mcs->rx_mask[0] & BIT(4))
- max_rate = (bw_40MHz) ? ((short_GI_40)?900:810):
- ((short_GI_20)?433:390);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 900 : 810) :
+ ((short_GI_20) ? 433 : 390);
else if (mcs->rx_mask[0] & BIT(3))
- max_rate = (bw_40MHz) ? ((short_GI_40)?600:540):
- ((short_GI_20)?289:260);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 600 : 540) :
+ ((short_GI_20) ? 289 : 260);
else if (mcs->rx_mask[0] & BIT(2))
- max_rate = (bw_40MHz) ? ((short_GI_40)?450:405):
- ((short_GI_20)?217:195);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 450 : 405) :
+ ((short_GI_20) ? 217 : 195);
else if (mcs->rx_mask[0] & BIT(1))
- max_rate = (bw_40MHz) ? ((short_GI_40)?300:270):
- ((short_GI_20)?144:130);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 300 : 270) :
+ ((short_GI_20) ? 144 : 130);
else if (mcs->rx_mask[0] & BIT(0))
- max_rate = (bw_40MHz) ? ((short_GI_40)?150:135):
- ((short_GI_20)?72:65);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 150 : 135) :
+ ((short_GI_20) ? 72 : 65);
} else {
if (mcs->rx_mask[1]) {
if (mcs->rx_mask[1] & BIT(7))
- max_rate = (bw_40MHz) ? ((short_GI_40)?3000:2700):((short_GI_20)?1444:1300);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 3000 : 2700) : ((short_GI_20) ? 1444 : 1300);
else if (mcs->rx_mask[1] & BIT(6))
- max_rate = (bw_40MHz) ? ((short_GI_40)?2700:2430):((short_GI_20)?1300:1170);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 2700 : 2430) : ((short_GI_20) ? 1300 : 1170);
else if (mcs->rx_mask[1] & BIT(5))
- max_rate = (bw_40MHz) ? ((short_GI_40)?2400:2160):((short_GI_20)?1156:1040);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 2400 : 2160) : ((short_GI_20) ? 1156 : 1040);
else if (mcs->rx_mask[1] & BIT(4))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1800:1620):((short_GI_20)?867:780);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1800 : 1620) : ((short_GI_20) ? 867 : 780);
else if (mcs->rx_mask[1] & BIT(3))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1200:1080):((short_GI_20)?578:520);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1200 : 1080) : ((short_GI_20) ? 578 : 520);
else if (mcs->rx_mask[1] & BIT(2))
- max_rate = (bw_40MHz) ? ((short_GI_40)?900:810):((short_GI_20)?433:390);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 900 : 810) : ((short_GI_20) ? 433 : 390);
else if (mcs->rx_mask[1] & BIT(1))
- max_rate = (bw_40MHz) ? ((short_GI_40)?600:540):((short_GI_20)?289:260);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 600 : 540) : ((short_GI_20) ? 289 : 260);
else if (mcs->rx_mask[1] & BIT(0))
- max_rate = (bw_40MHz) ? ((short_GI_40)?300:270):((short_GI_20)?144:130);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 300 : 270) : ((short_GI_20) ? 144 : 130);
} else {
if (mcs->rx_mask[0] & BIT(7))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1500:1350):((short_GI_20)?722:650);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1500 : 1350) : ((short_GI_20) ? 722 : 650);
else if (mcs->rx_mask[0] & BIT(6))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1350:1215):((short_GI_20)?650:585);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1350 : 1215) : ((short_GI_20) ? 650 : 585);
else if (mcs->rx_mask[0] & BIT(5))
- max_rate = (bw_40MHz) ? ((short_GI_40)?1200:1080):((short_GI_20)?578:520);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 1200 : 1080) : ((short_GI_20) ? 578 : 520);
else if (mcs->rx_mask[0] & BIT(4))
- max_rate = (bw_40MHz) ? ((short_GI_40)?900:810):((short_GI_20)?433:390);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 900 : 810) : ((short_GI_20) ? 433 : 390);
else if (mcs->rx_mask[0] & BIT(3))
- max_rate = (bw_40MHz) ? ((short_GI_40)?600:540):((short_GI_20)?289:260);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 600 : 540) : ((short_GI_20) ? 289 : 260);
else if (mcs->rx_mask[0] & BIT(2))
- max_rate = (bw_40MHz) ? ((short_GI_40)?450:405):((short_GI_20)?217:195);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 450 : 405) : ((short_GI_20) ? 217 : 195);
else if (mcs->rx_mask[0] & BIT(1))
- max_rate = (bw_40MHz) ? ((short_GI_40)?300:270):((short_GI_20)?144:130);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 300 : 270) : ((short_GI_20) ? 144 : 130);
else if (mcs->rx_mask[0] & BIT(0))
- max_rate = (bw_40MHz) ? ((short_GI_40)?150:135):((short_GI_20)?72:65);
+ max_rate = (bw_40MHz) ? ((short_GI_40) ? 150 : 135) : ((short_GI_20) ? 72 : 65);
}
}
return max_rate;
--
2.9.2
^ permalink raw reply related
* Re: [PATCH] ath10k: hide kernel addresses from logs using %pK format specifier
From: Joe Perches @ 2016-08-05 17:57 UTC (permalink / raw)
To: c_mkenna, ath10k, Andrew Morton; +Cc: linux-wireless, mkenna, Kees Cook, LKML
In-Reply-To: <1470318711-28986-1-git-send-email-c_mkenna@qti.qualcomm.com>
On Thu, 2016-08-04 at 19:21 +0530, c_mkenna@qti.qualcomm.com wrote:
> From: Maharaja Kennadyrajan <c_mkenna@qti.qualcomm.com>
>
> With the %pK format specifier we hide the kernel addresses
> with the help of kptr_restrict sysctl.
> In this patch, %p is changed to %pK in the driver code.
>
> The sysctl is documented in Documentation/sysctl/kernel.txt.
Maybe %p should follow %pK and only show kernel .text addresses
by default and any other address as 0 unless the sysctl is set.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox