date:20160806

Re: pull request: iwlwifi 2016-04-12

2016-08-06 Thread Emmanuel Grumbach

On Sun, Aug 7, 2016 at 7:35 AM, Grumbach, Emmanuel
 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 
> 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 
> 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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

pull request: iwlwifi 2016-04-12

2016-08-06 Thread Grumbach, Emmanuel

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:

commit cd49727e1a2bccc4ff008dde24c2f8430dd9e368
Author: Ayala Beker 
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 
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(-)

Re: TCP data throughput for BCM43362

2016-08-06 Thread Jörg Krause

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 
wrote:





Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
arend.vanspr...@broadcom.com>:


Op 5 aug. 2016 22:46 schreef "Jörg Krause"
:



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/sec0   56.6
KBytes
[  4]   1.00-2.00   sec   622 KBytes  5.10
Mbits/sec0   84.8
KBytes
[  4]   2.00-3.00   sec   625 KBytes  5.12
Mbits/sec0113
KBytes
[  4]   3.00-4.00   sec   571 KBytes  4.68
Mbits/sec0140
KBytes
[  4]   4.00-5.00   sec   594 KBytes  4.87
Mbits/sec0167
KBytes
[  4]   5.00-6.00   sec   628 KBytes  5.14
Mbits/sec0195
KBytes
[  4]   6.00-7.00   sec   619 KBytes  5.07
Mbits/sec0202
KBytes
[  4]   7.00-8.00   sec   608 KBytes  4.98
Mbits/sec0202
KBytes
[  4]   8.00-9.00   sec   602 KBytes  4.93
Mbits/sec0202
KBytes
[  4]   9.00-10.00  sec   537 KBytes  4.40
Mbits/sec0202
KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval   Transfer Bandwidth   Retr
[  4]   0.00-10.00  sec  5.88 MBytes  4.93
Mbits/sec0 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/sec0 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: TCP data throughput for BCM43362

2016-08-06 Thread Jörg Krause

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  cks>
> wrote:
> 
> > 
> > 
> > 
> > Am 5. August 2016 23:01:10 MESZ, schrieb Arend Van Spriel <
> > arend.vanspr...@broadcom.com>:
> > > 
> > > Op 5 aug. 2016 22:46 schreef "Jörg Krause"
> > > :
> > > > 
> > > > 
> > > > 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/sec0   56.6
> > > > KBytes
> > > > [  4]   1.00-2.00   sec   622 KBytes  5.10
> > > > Mbits/sec0   84.8
> > > > KBytes
> > > > [  4]   2.00-3.00   sec   625 KBytes  5.12
> > > > Mbits/sec0113
> > > > KBytes
> > > > [  4]   3.00-4.00   sec   571 KBytes  4.68
> > > > Mbits/sec0140
> > > > KBytes
> > > > [  4]   4.00-5.00   sec   594 KBytes  4.87
> > > > Mbits/sec0167
> > > > KBytes
> > > > [  4]   5.00-6.00   sec   628 KBytes  5.14
> > > > Mbits/sec0195
> > > > KBytes
> > > > [  4]   6.00-7.00   sec   619 KBytes  5.07
> > > > Mbits/sec0202
> > > > KBytes
> > > > [  4]   7.00-8.00   sec   608 KBytes  4.98
> > > > Mbits/sec0202
> > > > KBytes
> > > > [  4]   8.00-9.00   sec   602 KBytes  4.93
> > > > Mbits/sec0202
> > > > KBytes
> > > > [  4]   9.00-10.00  sec   537 KBytes  4.40
> > > > Mbits/sec0202
> > > > KBytes
> > > > - - - - - - - - - - - - - - - - - - - - - - - - -
> > > > [ ID] Interval   Transfer Bandwidth   Retr
> > > > [  4]   0.00-10.00  sec  5.88 MBytes  4.93
> > > > Mbits/sec0 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] cfg80211: Add support for user configurable beacon data rate

2016-08-06 Thread Undekari, Sunil Dutt

> 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 ? 

Regards,
Sunil



-Original Message-
From: Johannes Berg [mailto:johan...@sipsolutions.net] 
Sent: Friday, August 5, 2016 2:33 PM
To: Kushwaha, Purushottam 
Cc: linux-wireless@vger.kernel.org; Malinen, Jouni ; 
Undekari, Sunil Dutt ; Kondabattini, Ganesh 
; Kalikot Veetil, Mahesh Kumar 
; Hullur Subramanyam, Amarnath 

Subject: Re: [PATCH] cfg80211: Add support for user configurable beacon data 
rate

On Fri, 2016-08-05 at 10:05 +0530, Purushottam Kushwaha wrote:
> 
> +static int nl80211_parse_tx_bitrate_mask(struct genl_info *info,
> +  struct cfg80211_bitrate_mask *mask);

I think you should move the function instead.

> @@ -3457,6 +3459,11 @@ static int nl80211_start_ap(struct sk_buff 
> *skb, struct genl_info *info)
>   err = cfg80211_validate_beacon_int(rdev,
> params.beacon_interval);
>   if (err)
>   return err;
> + if (info->attrs[NL80211_ATTR_TX_RATES]) {
> + err = nl80211_parse_tx_bitrate_mask(info,
> _rate);
> + if (err)
> + return err;
> + }

Doesn't this have to check that it actually got information for the right band?

johannes
N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

[PATCH] ath10k: fix group privacy action frame decryption for qca4019

2016-08-06 Thread 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 
---
 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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to

brcmfmac43430-sdio.bin in linux-firmware

2016-08-06 Thread Fabio Estevam

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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cfg80211: Add support for user configurable beacon data rate

2016-08-06 Thread Johannes Berg

On Sat, 2016-08-06 at 04:38 +, 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch] ath9k: indent an if statement

2016-08-06 Thread Julian Calaby

Hi All,

On Thu, Aug 4, 2016 at 4:43 AM, Dan Carpenter  wrote:
> It looks like this code is correct, but it just needs to be indented a
> bit.
>
> Signed-off-by: Dan Carpenter 

Looks right to me.

Reviewed-by: Julian Calaby 

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-06 Thread Jason Cooper

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-06 Thread Stephan Mueller

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 
> > ---
> 
> 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 

Thank you.
> 
> thx,
> 
> Jason.



-- 
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

2016-08-06 Thread Jason Cooper

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 
> ---

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 

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pull request: iwlwifi 2016-04-12

pull request: iwlwifi 2016-04-12

Re: TCP data throughput for BCM43362

Re: TCP data throughput for BCM43362

RE: [PATCH] cfg80211: Add support for user configurable beacon data rate

[PATCH] ath10k: fix group privacy action frame decryption for qca4019

brcmfmac43430-sdio.bin in linux-firmware

Re: [PATCH] cfg80211: Add support for user configurable beacon data rate

Re: [patch] ath9k: indent an if statement

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

12 matches

Site Navigation

Mail list logo

Footer information