* Re: ath10k mesh + ap + encryption?
From: Simon Wunderlich @ 2016-09-13 12:30 UTC (permalink / raw)
To: Valo, Kalle
Cc: ath10k@lists.infradead.org, openwrt-devel@lists.openwrt.org,
linux-wireless@vger.kernel.org, Martin Blumenstingl
In-Reply-To: <87d1k8jb34.fsf@kamboji.qca.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]
On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote:
> Simon Wunderlich <sw@simonwunderlich.de> writes:
> > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> >> Simon Wunderlich <sw@simonwunderlich.de> writes:
> >> > we have done some experiments last week on ath10k, trying to run mesh
> >> > (802.11s) and access point at the same time, both encrypted.
> >> >
> >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which
> >> > gave
> >> > us a working encrypted 802.11s network. However, starting an AP at the
> >> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> >> > 802.11s was running unencrypted.
> >> >
> >> > We also tested version 10.2.4.97 (from codeaurora), which is now
> >> > default
> >> > in
> >> > LEDE. However, this version apparently doesn't support 11s mesh at all
> >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> >> > advertises support).
> >> >
> >> > So here are my questions:
> >> > * Did anyone succesfully run AP and mesh, both encrypted at the same
> >> > time?
> >> > * Do you have any pointers how we could fix this? Could it be fixable
> >> > in
> >> > the>
> >> >
> >> > driver (i.e. not in firmware)?
> >> >
> >> > * Does anyone have an idea if 11s will be supported in future
> >> > versions? I
> >> >
> >> > didn't find any changelogs, but having 11s mode no longer in the
> >> > service
> >> > map does not make me optimistic.
> >>
> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> >> have no knowledge if anyone even tests that firmware branch with ath10k.
> >> I recommend to only use firmware releases from ath10k-firmware.git as we
> >> use those internally with ath10k. In any case, don't make any
> >> assumptions about future from that firmware branch as it's so old.
> >
> > This was introduced in December 25th, 2015 after some firmware-related
> > problems. I'm CC'ing Martin Blumenstingl who suggested this change.
> >
> > Since then, ath10k is pulling firmware from here (unless ct firmware is
> > used):
> >
> > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain
> > /
> > 10.2.4/firmware-5.bin_10.2.4.97-1
> >
> > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you
> > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from
> > the numbers. However, 10.2.4.70 has much more sub-revisions.
>
> As I said before, I just deliver the firmware files to the community and
> the firmware team creates the actual releases. But my understanding is
> that these are from different branches which are built independently
> (and might have different features, like in this case the mesh support)
> so I would not make any conclusions if any firmware is "better" just
> from the numbers alone.
you are right ... those numbers are not a good pointer. I found this repo, and
from the checkin dates it looks like 10.2.4.97 is indeed way older (from
September 2015) than 10.2.4.70.42 (April 2016):
https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/log/10.2.4
I would agree that Changelogs would be helpful.
Thanks for the clarification. We will then stick to the 70's branch then.
Does anyone have pointers for the other questions? :) I would believe hat many
people would be interested in running AP + Mesh encrypted at the same time (at
least in the open source community ...).
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ath10k: Spelling and miscellaneous neatening
From: Valo, Kalle @ 2016-09-13 12:43 UTC (permalink / raw)
To: Joe Perches
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <95a6b65277914d88178ed2b15e182455067cca60.1472490319.git.joe@perches.com>
Joe Perches <joe@perches.com> writes:
> Correct some trivial comment typos.
> Remove unnecessary parentheses in a long line.
> Convert a return; before the end of a void function definition to just ;
>
> Signed-off-by: Joe Perches <joe@perches.com>
[...]
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2118,7 +2118,7 @@ err:
> /* TODO: It's probably a good idea to release device from the driver
> * but calling device_release_driver() here will cause a deadlock.
> */
> - return;
> + ;
> }
I don't think this improves anything, I dropped this part from the patch
in my pending branch.
--=20
Kalle Valo=
^ permalink raw reply
* FW: {SOLVED }RE: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )
From: Merchut, Addison @ 2016-09-13 12:51 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
From: Merchut, Addison
Sent: Tuesday, September 13, 2016 7:51 AM
To: 'linuxwifi@intel.com' <linuxwifi@intel.com>; 'linux-wireless@vger.kernel.org' <linux-wireless@vger.kernel.org>
Cc: Nudo, Al <Al.Nudo@pdt.com>; Unetich, Rich <Rich.Unetich@pdt.com>; DeCarlo, Bob <Bob.DeCarlo@pdt.com>
Subject: {SOLVED }RE: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )
I have solved this issue after finding this page: https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release
Thank you for your documentation. It is very friendly and easy to read.
If I may, I suggest that you please point https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi to the core_release page in some equally friendly way.
Thanks again, and keep up the great work .
From: Merchut, Addison
Sent: Monday, September 12, 2016 3:21 PM
To: 'linuxwifi@intel.com' <linuxwifi@intel.com>; 'linux-wireless@vger.kernel.org' <linux-wireless@vger.kernel.org>
Cc: Nudo, Al <Al.Nudo@pdt.com>; Unetich, Rich <Rich.Unetich@pdt.com>; DeCarlo, Bob <Bob.DeCarlo@pdt.com>
Subject: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )
I believe I have an issue with the Intel wireless 7260 pci cards on my linux desktop
I have two wireless cards on a test PC I'm working on. And while I can see both cards, only the top card (in the physical location) is actually getting assigned the logical (interface) name.
This seems to be interment (though I've only had this computer running for two days) because there has been at least one occasion that I have seen both cards assigned an interface name at the same time (via ifconfig and NM). However, when I've had to restart the computer, the names are not always assigned for the 2nd (bottom) card -this is the case most of the time.
Attached is the dmesg for the case where I was able to get both cards to work (dm.txt) and the case where I am not able to get both cards to work (dmbad.txt)
I've switched out the cards (with other 7260 cards), move the cards to other locations, exchanged the locations of the cards, BUT only the top most device is ever assigned the an interface name.
I'm running: 4.7.0-040700-generic GNU/Linux Ubuntu 16.04.1 LTS
The two cards are the same Intel Corporation Wireless 7260:
# cat /sys/bus/pci/devices/0000\:01\:00.0/uevent
DRIVER=iwlwifi
PCI_CLASS=28000
PCI_ID=8086:08B1
PCI_SUBSYS_ID=8086:4070
PCI_SLOT_NAME=0000:01:00.0
MODALIAS=pci:v00008086d000008B1sv00008086sd00004070bc02sc80i00
# cat /sys/bus/pci/devices/0000\:02\:00.0/uevent
DRIVER=iwlwifi
PCI_CLASS=28000
PCI_ID=8086:08B1
PCI_SUBSYS_ID=8086:4070
PCI_SLOT_NAME=0000:02:00.0
MODALIAS=pci:v00008086d000008B1sv00008086sd00004070bc02sc80i00
Only one of the devices is getting assigned a logical name:
#sudo lshw -class network
....
*-network
description: Wireless interface
product: Wireless 7260
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:01:00.0
logical name: wlp1s0
version: 73
serial: 7c:5c:f8:d2:6c:52
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list ethernet physical wireless
configuration: broadcast=yes driver=iwlwifi driverversion=4.7.0-040700-generic firmware=16.242414.0 latency=0 link=no multicast=yes wireless=IEEE 802.11
resources: irq:32 memory:f7d00000-f7d01fff
*-network
description: Network controller
product: Wireless 7260
vendor: Intel Corporation
physical id: 0
bus info: pci@0000:02:00.0
version: 73
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list
configuration: driver=iwlwifi latency=0
resources: irq:33 memory:f7c00000-f7c01fff
dmesg does not show that the 2nd device on bus 0000:02:00.0 has been detected by the wifi driver
{Attached as dmbad.txt}
and ifconfig only shows one device (obviously since lshw showed that only one was getting assigned a logical name)
#ifconfig
...
wlp1s0 Link encap:Ethernet HWaddr 7c:5c:f8:d2:6c:52
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
#ls /lib/firmware | grep 7260
iwlwifi-7260-10.ucode
iwlwifi-7260-12.ucode
iwlwifi-7260-13.ucode
iwlwifi-7260-14.ucode
iwlwifi-7260-16.ucode
iwlwifi-7260-7.ucode
iwlwifi-7260-8.ucode
iwlwifi-7260-9.ucode
#modinfo iwlwifi
filename: /lib/modules/4.7.0-040700-generic/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko
license: GPL
author: Copyright(c) 2003- 2015 Intel Corporation <linuxwifi@intel.com>
description: Intel(R) Wireless WiFi driver for Linux
firmware: iwlwifi-100-5.ucode
firmware: iwlwifi-1000-5.ucode
firmware: iwlwifi-135-6.ucode
firmware: iwlwifi-105-6.ucode
firmware: iwlwifi-2030-6.ucode
firmware: iwlwifi-2000-6.ucode
firmware: iwlwifi-5150-2.ucode
firmware: iwlwifi-5000-5.ucode
firmware: iwlwifi-6000g2b-IWL6000G2B_UCODE_API_MAX.ucode
firmware: iwlwifi-6000g2a-6.ucode
firmware: iwlwifi-6050-5.ucode
firmware: iwlwifi-6000-6.ucode
firmware: iwlwifi-7265D-21.ucode
firmware: iwlwifi-7265-17.ucode
firmware: iwlwifi-3168-21.ucode
firmware: iwlwifi-3160-17.ucode
firmware: iwlwifi-7260-17.ucode
firmware: iwlwifi-8265-21.ucode
firmware: iwlwifi-8000C--21.ucode
firmware: iwlwifi-9260-th-a0-lc-a0--21.ucode
firmware: iwlwifi-9260-th-a0-jf-a0--21.ucode
firmware: iwlwifi-9000-pu-a0-lc-a0--21.ucode
alias: pci:v00008086d00009DF0sv*sd00002A10bc*sc*i*
alias: pci:v00008086d00009DF0sv*sd00000710bc*sc*i*
....
depends: cfg80211
intree: Y
vermagic: 4.7.0-040700-generic SMP mod_unload modversions
parm: swcrypto:using crypto in software (default 0 [hardware]) (int)
parm: 11n_disable:disable 11n functionality, bitmap: 1: full, 2: disable agg TX, 4: disable agg RX, 8 enable agg TX (uint)
parm: amsdu_size:amsdu size 0:4K 1:8K 2:12K (default 0) (int)
parm: fw_restart:restart firmware in case of error (default true) (bool)
parm: antenna_coupling:specify antenna coupling in dB (default: 0 dB) (int)
parm: nvm_file:NVM file name (charp)
parm: d0i3_disable:disable d0i3 functionality (default: Y) (bool)
parm: lar_disable:disable LAR functionality (default: N) (bool)
parm: uapsd_disable:disable U-APSD functionality bitmap 1: BSS 2: P2P Client (default: 3) (uint)
parm: bt_coex_active:enable wifi/bt co-exist (default: enable) (bool)
parm: led_mode:0=system default, 1=On(RF On)/Off(RF Off), 2=blinking, 3=Off (default: 0) (int)
parm: power_save:enable WiFi power management (default: disable) (bool)
parm: power_level:default power save level (range from 1 - 5, default: 1) (int)
parm: fw_monitor:firmware monitor - to debug FW (default: false - needs lots of memory) (bool)
parm: d0i3_timeout:Timeout to D0i3 entry when idle (ms) (uint)
parm: disable_11ac:Disable VHT capabilities (default: false) (bool)
Please let me know if there's anything I can do or if this is a known issue.
Thank you.
Addison
312.620.2094
Skype: addisonpdt
PDT.com
Email secured by Check Point
^ permalink raw reply
* [PATCH] mac80211: remove useless open_count check
From: Johannes Berg @ 2016-09-13 13:40 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
__ieee80211_suspend() checks early on if there's anything
to do by checking open_count, so there's no need to check
again later in the function. Remove the useless check.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/pm.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 00a43a70e1fc..28a3a0957c9e 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -178,8 +178,7 @@ int __ieee80211_suspend(struct ieee80211_hw *hw, struct cfg80211_wowlan *wowlan)
WARN_ON(!list_empty(&local->chanctx_list));
/* stop hardware - this must stop RX */
- if (local->open_count)
- ieee80211_stop_device(local);
+ ieee80211_stop_device(local);
suspend:
local->suspended = true;
--
2.8.1
^ permalink raw reply related
* [PATCH] nl80211: validate number of probe response CSA counters
From: Johannes Berg @ 2016-09-13 13:56 UTC (permalink / raw)
To: linux-wireless; +Cc: Andrei Otcheretianski, Luca Coelho, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Due to an apparent copy/paste bug, the number of counters for the
beacon configuration were checked twice, instead of checking the
number of probe response counters. Fix this to check the number of
probe response counters before parsing those.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef234d2fd854..a65c94f202f8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6998,7 +6998,7 @@ static int nl80211_channel_switch(struct sk_buff *skb, struct genl_info *info)
params.n_counter_offsets_presp = len / sizeof(u16);
if (rdev->wiphy.max_num_csa_counters &&
- (params.n_counter_offsets_beacon >
+ (params.n_counter_offsets_presp >
rdev->wiphy.max_num_csa_counters))
return -EINVAL;
--
2.8.1
^ permalink raw reply related
* Re: [PATCH 2/2] ath10k: add platform regulatory domain support
From: Bartosz Markowski @ 2016-09-13 13:57 UTC (permalink / raw)
To: Valo, Kalle; +Cc: ath10k@lists.infradead.org, linux-wireless@vger.kernel.org
In-Reply-To: <87bmztm8qm.fsf@kamboji.qca.qualcomm.com>
On 12 September 2016 at 17:35, Valo, Kalle <kvalo@qca.qualcomm.com> wrote:
[...]
> > +#ifdef CONFIG_ACPI
> > +#define WRD_METHOD "WRDD"
> > +#define WRDD_WIFI (0x07)
> > +
> > +static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_object *wrdd)
> > +{
>
> I don't think the ifdef is really necessary, acpi.h should handle that
> (hopefully). Also I changed the error handling to use standard error
> values and changed the info messages to dbg, they are too spammy in my
> opinion. Please check carefully my changes in the pending branch:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending&id=fe91745381ec3999d8de6dedb07b396c82539717
I'm OK with the changes, I have not tried that though, except of
reviewing and compiling it (do not have access to the chromebook for
next few days). If you want to wait with it until I test it, it's fine
too.
Bartosz
^ permalink raw reply
* [PATCH] cfg80211: disallow shared key authentication with key index 4
From: Johannes Berg @ 2016-09-13 14:29 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Key index 4 can only be used for an IGTK, so the range checks
for shared key authentication should treat 4 as an error, fix
that in the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/mlme.c | 2 +-
net/wireless/nl80211.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index c284d883c349..d6abb0704db5 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ int cfg80211_mlme_auth(struct cfg80211_registered_device *rdev,
ASSERT_WDEV_LOCK(wdev);
if (auth_type == NL80211_AUTHTYPE_SHARED_KEY)
- if (!key || !key_len || key_idx < 0 || key_idx > 4)
+ if (!key || !key_len || key_idx < 0 || key_idx > 3)
return -EINVAL;
if (wdev->current_bss &&
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index aca8f820d155..739d0a780d83 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7391,7 +7391,7 @@ static int nl80211_authenticate(struct sk_buff *skb, struct genl_info *info)
(key.p.cipher != WLAN_CIPHER_SUITE_WEP104 ||
key.p.key_len != WLAN_KEY_LEN_WEP104))
return -EINVAL;
- if (key.idx > 4)
+ if (key.idx > 3)
return -EINVAL;
} else {
key.p.key_len = 0;
--
2.8.1
^ permalink raw reply related
* [PATCH 4/6] cfg80211: wext: only allow WEP keys to be configured before connected
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473777868-32429-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
When not connected, anything but WEP keys shouldn't be allowed to be
configured for later - only static WEP keys make sense at this point.
Change wext to reject anything else just like nl80211 does.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/wext-compat.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 9f27221c8913..e45a76449b43 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -487,6 +487,9 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
err = 0;
if (wdev->current_bss)
err = rdev_add_key(rdev, dev, idx, pairwise, addr, params);
+ else if (params->cipher != WLAN_CIPHER_SUITE_WEP40 &&
+ params->cipher != WLAN_CIPHER_SUITE_WEP104)
+ return -EINVAL;
if (err)
return err;
--
2.8.1
^ permalink raw reply related
* [PATCH 2/6] nl80211: fix connect keys range check
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473777868-32429-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Only key index 0-3 should be accepted, 4/5 are for IGTKs and
cannot be used as connect keys. Fix the range checking to not
allow such erroneous configurations.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c96e22b906af..6fe14b5d1af3 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -866,7 +866,7 @@ nl80211_parse_connkeys(struct cfg80211_registered_device *rdev,
err = -EINVAL;
if (!parse.p.key)
goto error;
- if (parse.idx < 0 || parse.idx > 4)
+ if (parse.idx < 0 || parse.idx > 3)
goto error;
if (parse.def) {
if (def)
--
2.8.1
^ permalink raw reply related
* [PATCH 6/6] cfg80211: reduce connect key caching struct size
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473777868-32429-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
After the previous patches, connect keys can only (correctly)
be used for storing static WEP keys. Therefore, remove all the
data for dealing with key index 4/5 and reduce the size of the
key material to the maximum for WEP keys.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/core.h | 6 +++---
net/wireless/ibss.c | 6 ++----
net/wireless/nl80211.c | 1 -
net/wireless/util.c | 5 +----
net/wireless/wext-compat.c | 6 +++---
net/wireless/wext-sme.c | 3 +--
6 files changed, 10 insertions(+), 17 deletions(-)
diff --git a/net/wireless/core.h b/net/wireless/core.h
index eee91443924d..5555e3c13ae9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -249,9 +249,9 @@ struct cfg80211_event {
};
struct cfg80211_cached_keys {
- struct key_params params[6];
- u8 data[6][WLAN_MAX_KEY_LEN];
- int def, defmgmt;
+ struct key_params params[4];
+ u8 data[4][WLAN_KEY_LEN_WEP104];
+ int def;
};
enum cfg80211_chan_mode {
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 4a4dda53bdf1..896cbb20b6e1 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -284,10 +284,8 @@ int cfg80211_ibss_wext_join(struct cfg80211_registered_device *rdev,
if (!netif_running(wdev->netdev))
return 0;
- if (wdev->wext.keys) {
+ if (wdev->wext.keys)
wdev->wext.keys->def = wdev->wext.default_key;
- wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
- }
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
@@ -295,7 +293,7 @@ int cfg80211_ibss_wext_join(struct cfg80211_registered_device *rdev,
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 4; i++)
ck->params[i].key = ck->data[i];
}
err = __cfg80211_join_ibss(rdev, wdev->netdev,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 739d0a780d83..8c6cbaac7d89 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -854,7 +854,6 @@ nl80211_parse_connkeys(struct cfg80211_registered_device *rdev,
return ERR_PTR(-ENOMEM);
result->def = -1;
- result->defmgmt = -1;
nla_for_each_nested(key, keys, rem) {
memset(&parse, 0, sizeof(parse));
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 81fa16b36d30..dea2398329c4 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -912,7 +912,7 @@ void cfg80211_upload_connect_keys(struct wireless_dev *wdev)
if (!wdev->connect_keys)
return;
- for (i = 0; i < 6; i++) {
+ for (i = 0; i < 4; i++) {
if (!wdev->connect_keys->params[i].cipher)
continue;
if (rdev_add_key(rdev, dev, i, false, NULL,
@@ -925,9 +925,6 @@ void cfg80211_upload_connect_keys(struct wireless_dev *wdev)
netdev_err(dev, "failed to set defkey %d\n", i);
continue;
}
- if (wdev->connect_keys->defmgmt == i)
- if (rdev_set_default_mgmt_key(rdev, dev, i))
- netdev_err(dev, "failed to set mgtdef %d\n", i);
}
kzfree(wdev->connect_keys);
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index e45a76449b43..7b97d43b27e1 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -408,10 +408,10 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (!wdev->wext.keys) {
wdev->wext.keys = kzalloc(sizeof(*wdev->wext.keys),
- GFP_KERNEL);
+ GFP_KERNEL);
if (!wdev->wext.keys)
return -ENOMEM;
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 4; i++)
wdev->wext.keys->params[i].key =
wdev->wext.keys->data[i];
}
@@ -460,7 +460,7 @@ static int __cfg80211_set_encryption(struct cfg80211_registered_device *rdev,
if (err == -ENOENT)
err = 0;
if (!err) {
- if (!addr) {
+ if (!addr && idx < 4) {
memset(wdev->wext.keys->data[idx], 0,
sizeof(wdev->wext.keys->data[idx]));
wdev->wext.keys->params[idx].key_len = 0;
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index a4e8af3321d2..f6523a4387cc 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -35,7 +35,6 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
if (wdev->wext.keys) {
wdev->wext.keys->def = wdev->wext.default_key;
- wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
if (wdev->wext.default_key != -1)
wdev->wext.connect.privacy = true;
}
@@ -47,7 +46,7 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 4; i++)
ck->params[i].key = ck->data[i];
}
--
2.8.1
^ permalink raw reply related
* [PATCH 1/6] cfg80211: disallow shared key authentication with key index 4
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Key index 4 can only be used for an IGTK, so the range checks
for shared key authentication should treat 4 as an error, fix
that in the code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/mlme.c | 2 +-
net/wireless/nl80211.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index c284d883c349..d6abb0704db5 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ int cfg80211_mlme_auth(struct cfg80211_registered_device *rdev,
ASSERT_WDEV_LOCK(wdev);
if (auth_type == NL80211_AUTHTYPE_SHARED_KEY)
- if (!key || !key_len || key_idx < 0 || key_idx > 4)
+ if (!key || !key_len || key_idx < 0 || key_idx > 3)
return -EINVAL;
if (wdev->current_bss &&
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 83c6445ebf33..c96e22b906af 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7388,7 +7388,7 @@ static int nl80211_authenticate(struct sk_buff *skb, struct genl_info *info)
(key.p.cipher != WLAN_CIPHER_SUITE_WEP104 ||
key.p.key_len != WLAN_KEY_LEN_WEP104))
return -EINVAL;
- if (key.idx > 4)
+ if (key.idx > 3)
return -EINVAL;
} else {
key.p.key_len = 0;
--
2.8.1
^ permalink raw reply related
* [PATCH 5/6] cfg80211: validate key index better
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473777868-32429-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
Don't accept it if a key_idx < 0 snuck through, reject WEP keys with
key index 4 and 5 (which are used for IGTKs) and don't allow IGTKs
with key indices other than 4 and 5. This makes the key data match
expectations better.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/util.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0675f513e7b9..81fa16b36d30 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -218,7 +218,7 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
struct key_params *params, int key_idx,
bool pairwise, const u8 *mac_addr)
{
- if (key_idx > 5)
+ if (key_idx < 0 || key_idx > 5)
return -EINVAL;
if (!pairwise && mac_addr && !(rdev->wiphy.flags & WIPHY_FLAG_IBSS_RSN))
@@ -249,7 +249,13 @@ int cfg80211_validate_key_settings(struct cfg80211_registered_device *rdev,
/* Disallow BIP (group-only) cipher as pairwise cipher */
if (pairwise)
return -EINVAL;
+ if (key_idx < 4)
+ return -EINVAL;
break;
+ case WLAN_CIPHER_SUITE_WEP40:
+ case WLAN_CIPHER_SUITE_WEP104:
+ if (key_idx < 0 || key_idx > 3)
+ return -EINVAL;
default:
break;
}
--
2.8.1
^ permalink raw reply related
* Re: Support of rtl8723bs
From: Larry Finger @ 2016-09-13 15:05 UTC (permalink / raw)
To: Hanno Zulla, Jes Sorensen, Bastien Nocera; +Cc: anthony.wong, linux-wireless
In-Reply-To: <4efa3f1a-a91c-7b19-43e3-508cbbd4676e@hanno.de>
On 09/13/2016 02:47 AM, Hanno Zulla wrote:
> Hi,
>
>> The issues I am aware of is to start out changing the register access
>> macros into function pointers and stick them all into the fileops
>> structure. Provide a set of SDIO ones to match the USB ones. Then you
>> will need some code to detect the device, as that part will obviously be
>> different from the USB device detection.
>>
>> I know there are a few issues to look out for in the hw register init
>> files to look out for too, that does some special casing for SDIO, but
>> that should be limited. I am happy to point someone in the right
>> direction on that when they get to that.
>
> I had a brief look into the sources of other drivers implementing SDIO,
> but not being a kernel-dev, this is out of my league.
>
> If you decide to reprioritize your TODO-List in favour of adding SDIO
> sooner, I'll be gladly testing this for you on my hardware (and buy you
> a beer).
I received a CherryTrail z8300 device yesterday with RTL8723BS wifi and BT. I
have started making the changes that Jes suggested. Once I get something
running, I will post patches here for review, and I will also make them
available in Bastien's repo.
I make no promises on when anything will be available.
Larry
^ permalink raw reply
* [PATCH 3/6] nl80211: only allow WEP keys during connect command
From: Johannes Berg @ 2016-09-13 14:44 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
In-Reply-To: <1473777868-32429-1-git-send-email-johannes@sipsolutions.net>
From: Johannes Berg <johannes.berg@intel.com>
This was already documented that way in nl80211.h, but the
parsing code still accepted other key types. Change it to
really only accept WEP keys as documented.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6fe14b5d1af3..739d0a780d83 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -881,16 +881,19 @@ nl80211_parse_connkeys(struct cfg80211_registered_device *rdev,
parse.idx, false, NULL);
if (err)
goto error;
+ if (parse.p.cipher != WLAN_CIPHER_SUITE_WEP40 &&
+ parse.p.cipher != WLAN_CIPHER_SUITE_WEP104) {
+ err = -EINVAL;
+ goto error;
+ }
result->params[parse.idx].cipher = parse.p.cipher;
result->params[parse.idx].key_len = parse.p.key_len;
result->params[parse.idx].key = result->data[parse.idx];
memcpy(result->data[parse.idx], parse.p.key, parse.p.key_len);
- if (parse.p.cipher == WLAN_CIPHER_SUITE_WEP40 ||
- parse.p.cipher == WLAN_CIPHER_SUITE_WEP104) {
- if (no_ht)
- *no_ht = true;
- }
+ /* must be WEP key if we got here */
+ if (no_ht)
+ *no_ht = true;
}
return result;
--
2.8.1
^ permalink raw reply related
* Re: pull-request mwifiex-firmware 2015-09-12
From: Kyle McMartin @ 2016-09-13 16:16 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless@vger.kernel.org, Cathy Luo, Nishant Sarmukadam,
linux-firmware
In-Reply-To: <bf3662bacb394fc2aac0ff891a5100ea@SC-EXCH04.marvell.com>
On Mon, Sep 12, 2016 at 12:40:23PM +0000, Amitkumar Karwar wrote:
> The following changes since commit e92f8b3f65443764297b947b1843955d9a65dde7:
>
> linux-firmware: update Marvell USB8797-B0 firmware image (2015-11-02 06:25:05 -0500)
>
> are available in the git repository at:
>
> git://git.marvell.com/mwifiex-firmware.git master
>
> for you to fetch changes up to 1e0f28ad5a26b2c86e55dbad3141b2ec2de804f7:
>
> linux-firmware: update WHENCE file for Marvell firmware versions (2016-09-12 17:12:42 +0530)
>
Pulled, thanks.
--Kyle
^ permalink raw reply
* Re: ath10k mesh + ap + encryption?
From: Pedersen, Thomas @ 2016-09-13 17:54 UTC (permalink / raw)
To: Simon Wunderlich, Valo, Kalle
Cc: ath10k@lists.infradead.org, openwrt-devel@lists.openwrt.org,
linux-wireless@vger.kernel.org, Martin Blumenstingl
In-Reply-To: <3247815.ey5ZWkP5uX@prime>
T24gVHVlLCAyMDE2LTA5LTEzIGF0IDE0OjMwICswMjAwLCBTaW1vbiBXdW5kZXJsaWNoIHdyb3Rl
Og0KPiBPbiBUdWVzZGF5LCBTZXB0ZW1iZXIgMTMsIDIwMTYgMTE6MjU6MjEgQU0gQ0VTVCBWYWxv
LCBLYWxsZSB3cm90ZToNCj4gPiANCj4gPiBTaW1vbiBXdW5kZXJsaWNoIDxzd0BzaW1vbnd1bmRl
cmxpY2guZGU+IHdyaXRlczoNCj4gPiA+IA0KPiA+ID4gT24gVHVlc2RheSwgU2VwdGVtYmVyIDEz
LCAyMDE2IDEwOjU5OjMxIEFNIENFU1QgVmFsbywgS2FsbGUNCj4gPiA+IHdyb3RlOg0KPiA+ID4g
PiANCj4gPiA+ID4gU2ltb24gV3VuZGVybGljaCA8c3dAc2ltb253dW5kZXJsaWNoLmRlPiB3cml0
ZXM6DQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gd2UgaGF2ZSBkb25lIHNvbWUgZXhwZXJpbWVudHMg
bGFzdCB3ZWVrIG9uIGF0aDEwaywgdHJ5aW5nIHRvDQo+ID4gPiA+ID4gcnVuIG1lc2gNCj4gPiA+
ID4gPiAoODAyLjExcykgYW5kIGFjY2VzcyBwb2ludCBhdCB0aGUgc2FtZSB0aW1lLCBib3RoIGVu
Y3J5cHRlZC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBXZSBoYXZlIHRlc3RlZCBhIHJlY2VudCBM
RURFIChyZWJvb3QtMTUxOS1nNDJmNTU5ZSkgYnV0IHdpdGgNCj4gPiA+ID4gPiBmaXJtd2FyZS01
LmJpbl8xMC4yLjQuNzAuNDItMiBhbmQgdGhlIGluY2x1ZGVkDQo+ID4gPiA+ID4gd3BhX3N1cHBs
aWNhbnQsIHdoaWNoDQo+ID4gPiA+ID4gZ2F2ZQ0KPiA+ID4gPiA+IHVzIGEgd29ya2luZyBlbmNy
eXB0ZWQgODAyLjExcyBuZXR3b3JrLiBIb3dldmVyLCBzdGFydGluZyBhbg0KPiA+ID4gPiA+IEFQ
IGF0IHRoZQ0KPiA+ID4gPiA+IHNhbWUgdGltZSBkaWRuJ3Qgd29yayAoQVAgZG9lc24ndCBiZWFj
b24pLiBUaGlzIHdhc24ndCBhDQo+ID4gPiA+ID4gcHJvYmxlbSB3aGVuDQo+ID4gPiA+ID4gODAy
LjExcyB3YXMgcnVubmluZyB1bmVuY3J5cHRlZC4NCj4gPiA+ID4gPiANCj4gPiA+ID4gPiBXZSBh
bHNvIHRlc3RlZCB2ZXJzaW9uIDEwLjIuNC45NyAoZnJvbSBjb2RlYXVyb3JhKSwgd2hpY2ggaXMN
Cj4gPiA+ID4gPiBub3cNCj4gPiA+ID4gPiBkZWZhdWx0DQo+ID4gPiA+ID4gaW4NCj4gPiA+ID4g
PiBMRURFLiBIb3dldmVyLCB0aGlzIHZlcnNpb24gYXBwYXJlbnRseSBkb2Vzbid0IHN1cHBvcnQg
MTFzDQo+ID4gPiA+ID4gbWVzaCBhdCBhbGwNCj4gPiA+ID4gPiAoV01JX1NFUlZJQ0VfTUVTSF8x
MVMgaXMgZGlzYWJsZWQgaW4gdGhlIHNlcnZpY2UgbWFwLCBidXQNCj4gPiA+ID4gPiBjZmcvbWFj
ODAyMTENCj4gPiA+ID4gPiBhZHZlcnRpc2VzIHN1cHBvcnQpLg0KPiA+ID4gPiA+IA0KPiA+ID4g
PiA+IFNvIGhlcmUgYXJlIG15IHF1ZXN0aW9uczoNCj4gPiA+ID4gPiDCoCogRGlkIGFueW9uZSBz
dWNjZXNmdWxseSBydW4gQVAgYW5kIG1lc2gsIGJvdGggZW5jcnlwdGVkIGF0DQo+ID4gPiA+ID4g
dGhlIHNhbWUNCj4gPiA+ID4gPiDCoHRpbWU/DQo+ID4gPiA+ID4gwqAqIERvIHlvdSBoYXZlIGFu
eSBwb2ludGVycyBob3cgd2UgY291bGQgZml4IHRoaXM/IENvdWxkIGl0DQo+ID4gPiA+ID4gYmUg
Zml4YWJsZQ0KPiA+ID4gPiA+IMKgaW4NCj4gPiA+ID4gPiDCoHRoZT4NCj4gPiA+ID4gPiANCj4g
PiA+ID4gPiBkcml2ZXIgKGkuZS4gbm90IGluIGZpcm13YXJlKT8NCj4gPiA+ID4gPiANCj4gPiA+
ID4gPiDCoCogRG9lcyBhbnlvbmUgaGF2ZSBhbiBpZGVhIGlmIDExcyB3aWxsIGJlIHN1cHBvcnRl
ZCBpbg0KPiA+ID4gPiA+IGZ1dHVyZQ0KPiA+ID4gPiA+IMKgdmVyc2lvbnM/IEkNCj4gPiA+ID4g
PiANCj4gPiA+ID4gPiBkaWRuJ3QgZmluZCBhbnkgY2hhbmdlbG9ncywgYnV0IGhhdmluZyAxMXMg
bW9kZSBubyBsb25nZXIgaW4NCj4gPiA+ID4gPiB0aGUNCj4gPiA+ID4gPiBzZXJ2aWNlDQo+ID4g
PiA+ID4gbWFwIGRvZXMgbm90IG1ha2UgbWUgb3B0aW1pc3RpYy4NCj4gPiA+ID4gDQo+ID4gPiA+
IFdoeSBpcyBMRURFIHVzaW5nIDEwLjIuNC45Nz8gSXQgc2VlbXMgdG8gYmUgYSBxdWl0ZSBvbGQg
cmVsZWFzZQ0KPiA+ID4gPiBhbmQgSQ0KPiA+ID4gPiBoYXZlIG5vIGtub3dsZWRnZSBpZiBhbnlv
bmUgZXZlbiB0ZXN0cyB0aGF0IGZpcm13YXJlIGJyYW5jaA0KPiA+ID4gPiB3aXRoIGF0aDEway4N
Cj4gPiA+ID4gSSByZWNvbW1lbmQgdG8gb25seSB1c2UgZmlybXdhcmUgcmVsZWFzZXMgZnJvbSBh
dGgxMGstDQo+ID4gPiA+IGZpcm13YXJlLmdpdCBhcyB3ZQ0KPiA+ID4gPiB1c2UgdGhvc2UgaW50
ZXJuYWxseSB3aXRoIGF0aDEway4gSW4gYW55IGNhc2UsIGRvbid0IG1ha2UgYW55DQo+ID4gPiA+
IGFzc3VtcHRpb25zIGFib3V0IGZ1dHVyZSBmcm9tIHRoYXQgZmlybXdhcmUgYnJhbmNoIGFzIGl0
J3Mgc28NCj4gPiA+ID4gb2xkLg0KPiA+ID4gDQo+ID4gPiBUaGlzIHdhcyBpbnRyb2R1Y2VkIGlu
IERlY2VtYmVyIDI1dGgsIDIwMTUgYWZ0ZXIgc29tZSBmaXJtd2FyZS0NCj4gPiA+IHJlbGF0ZWQN
Cj4gPiA+IHByb2JsZW1zLiBJJ20gQ0MnaW5nIE1hcnRpbiBCbHVtZW5zdGluZ2wgd2hvIHN1Z2dl
c3RlZCB0aGlzDQo+ID4gPiBjaGFuZ2UuDQo+ID4gPiANCj4gPiA+IFNpbmNlIHRoZW4sIGF0aDEw
ayBpcyBwdWxsaW5nIGZpcm13YXJlIGZyb20gaGVyZSAodW5sZXNzIGN0DQo+ID4gPiBmaXJtd2Fy
ZSBpcw0KPiA+ID4gdXNlZCk6DQo+ID4gPiANCj4gPiA+IGh0dHBzOi8vc291cmNlLmNvZGVhdXJv
cmEub3JnL3F1aWMvcXNkay9vc3MvZmlybXdhcmUvYXRoMTBrLWZpcm13DQo+ID4gPiBhcmUvcGxh
aW4NCj4gPiA+IC8NCj4gPiA+IDEwLjIuNC9maXJtd2FyZS01LmJpbl8xMC4yLjQuOTctMQ0KPiA+
ID4gDQo+ID4gPiBIb3dldmVyLCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIG51bWJlcmluZz8gMTAu
Mi40Ljk3ID4gMTAuMi40LjcwLA0KPiA+ID4gYnV0IHlvdQ0KPiA+ID4gc2F5IDEwLjIuNC43MC40
Mi0yIGlzIG1vcmUgcmVjZW50PyBJIHdvdWxkIGhhdmUgYXNzdW1lZCBvdGhlcndpc2UNCj4gPiA+
IGZyb20NCj4gPiA+IHRoZSBudW1iZXJzLiBIb3dldmVyLCAxMC4yLjQuNzAgaGFzIG11Y2ggbW9y
ZSBzdWItcmV2aXNpb25zLg0KPiA+IA0KPiA+IEFzIEkgc2FpZCBiZWZvcmUsIEkganVzdCBkZWxp
dmVyIHRoZSBmaXJtd2FyZSBmaWxlcyB0byB0aGUNCj4gPiBjb21tdW5pdHkgYW5kDQo+ID4gdGhl
IGZpcm13YXJlIHRlYW0gY3JlYXRlcyB0aGUgYWN0dWFsIHJlbGVhc2VzLiBCdXQgbXkgdW5kZXJz
dGFuZGluZw0KPiA+IGlzDQo+ID4gdGhhdCB0aGVzZSBhcmUgZnJvbSBkaWZmZXJlbnQgYnJhbmNo
ZXMgd2hpY2ggYXJlIGJ1aWx0DQo+ID4gaW5kZXBlbmRlbnRseQ0KPiA+IChhbmQgbWlnaHQgaGF2
ZSBkaWZmZXJlbnQgZmVhdHVyZXMsIGxpa2UgaW4gdGhpcyBjYXNlIHRoZSBtZXNoDQo+ID4gc3Vw
cG9ydCkNCj4gPiBzbyBJIHdvdWxkIG5vdCBtYWtlIGFueSBjb25jbHVzaW9ucyBpZiBhbnkgZmly
bXdhcmUgaXMgImJldHRlciINCj4gPiBqdXN0DQo+ID4gZnJvbSB0aGUgbnVtYmVycyBhbG9uZS4N
Cj4gDQo+IHlvdSBhcmUgcmlnaHQgLi4uIHRob3NlIG51bWJlcnMgYXJlIG5vdCBhIGdvb2QgcG9p
bnRlci4gSSBmb3VuZCB0aGlzDQo+IHJlcG8sIGFuZMKgDQo+IGZyb20gdGhlIGNoZWNraW4gZGF0
ZXMgaXQgbG9va3MgbGlrZSAxMC4yLjQuOTcgaXMgaW5kZWVkIHdheSBvbGRlcg0KPiAoZnJvbcKg
DQo+IFNlcHRlbWJlciAyMDE1KSB0aGFuIDEwLjIuNC43MC40MiAoQXByaWwgMjAxNik6DQo+IA0K
PiBodHRwczovL3NvdXJjZS5jb2RlYXVyb3JhLm9yZy9xdWljL3FzZGsvb3NzL2Zpcm13YXJlL2F0
aDEway1maXJtd2FyZS8NCj4gbG9nLzEwLjIuNA0KPiANCj4gSSB3b3VsZCBhZ3JlZSB0aGF0IENo
YW5nZWxvZ3Mgd291bGQgYmUgaGVscGZ1bC4NCj4gDQo+IFRoYW5rcyBmb3IgdGhlIGNsYXJpZmlj
YXRpb24uIFdlIHdpbGwgdGhlbiBzdGljayB0byB0aGUgNzAncyBicmFuY2gNCj4gdGhlbi4NCj4g
DQo+IERvZXMgYW55b25lIGhhdmUgcG9pbnRlcnMgZm9yIHRoZSBvdGhlciBxdWVzdGlvbnM/IDop
IEkgd291bGQgYmVsaWV2ZQ0KPiBoYXQgbWFuecKgDQo+IHBlb3BsZSB3b3VsZCBiZSBpbnRlcmVz
dGVkIGluIHJ1bm5pbmcgQVAgKyBNZXNoIGVuY3J5cHRlZCBhdCB0aGUgc2FtZQ0KPiB0aW1lIChh
dMKgDQo+IGxlYXN0IGluIHRoZSBvcGVuIHNvdXJjZSBjb21tdW5pdHkgLi4uKS4NCg0KV2UncmUg
dGVzdGluZyBlbmNyeXB0ZWQgQVAgKyBNZXNoIHF1aXRlIHN1Y2Nlc3NmdWxseSByaWdodCBub3cg
d2l0aA0KdGhpcyBmaXJtd2FyZTrCoGh0dHBzOi8vZ2l0aHViLmNvbS9rdmFsby9hdGgxMGstZmly
bXdhcmUvY29tbWl0LzMwN2NiNDZiDQowNjY2MWViZDMxODY3MjNiNTAwMmRlNzY5YzdhZGQ4Mywg
b2YgY291cnNlIHRoYXQgaXMgZm9yIGEgUUNBNDAxOSBjaGlwLg0KV2hpY2ggY2hpcCBhcmUgeW91
IHVzaW5nPyBJIGNhbiBwb2tlIHRoZSBmaXJtd2FyZSBndXlzIGZvciBwb3NzaWJpbGl0eQ0Kb2Yg
Z2V0dGluZyBhIDEwLjQuMy4yIGZpcm13YXJlIGJ1aWxkIGZvciBpdC4NCg0KdGhvbWFz
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Pedersen, Thomas @ 2016-09-13 17:57 UTC (permalink / raw)
To: Johannes Berg, Ben Greear, linux-wireless
In-Reply-To: <1473662637.4201.2.camel@sipsolutions.net>
T24gTW9uLCAyMDE2LTA5LTEyIGF0IDA4OjQzICswMjAwLCBKb2hhbm5lcyBCZXJnIHdyb3RlOg0K
PiBPbiBXZWQsIDIwMTYtMDktMDcgYXQgMTg6MjAgKzAwMDAsIFBlZGVyc2VuLCBUaG9tYXMgd3Jv
dGU6DQo+ID4gDQo+ID4gT24gMDkvMDYvMjAxNiAxMjowNyBQTSwgQmVuIEdyZWVhciB3cm90ZToN
Cj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBPbiAwOS8wNi8yMDE2IDEyOjAwIFBNLCBUaG9tYXMgUGVk
ZXJzZW4gd3JvdGU6DQo+ID4gPiA+IA0KPiA+ID4gPiANCj4gPiA+ID4gU29tZSBkcml2ZXJzIChh
dGgxMGspIHJlcG9ydCBNQ1MgOSBAIDIwTUh6LCB3aGljaA0KPiA+ID4gPiB0ZWNobmljYWxseSBp
c24ndCBhbGxvd2VkLiBUbyBnZXQgbW9yZSBtZWFuaW5nZnVsIHZhbHVlDQo+ID4gPiA+IHRoYW4g
MCBvdXQgb2YgdGhpcyBob3dldmVyLCBqdXN0IGNhcCB0aGUgYml0cmF0ZSBmb3IgMjBNSHoNCj4g
PiA+ID4gdG8gTUNTIDguDQo+ID4gPiANCj4gPiA+IElmIGl0IGlzIGFjdHVhbGx5IHJlcG9ydGlu
ZyBNQ1M5LCB3aHkgbGllIGFib3V0IGl0P8KgwqBSZXBvcnQgaXQgdXANCj4gPiA+IHRoZSBzdGFj
ayBhcyBhIHByb3BlciB2YWx1ZSBpbnN0ZWFkIG9mIGhpZGluZyB0aGUgaXNzdWU/DQo+ID4gDQo+
ID4gR29vZCBwb2ludCwgd2lsbCBzZW5kIGEgdjIgZXh0cmFwb2xhdGluZyB0aGUgdmFsdWUgdG8g
ODYuNU1iL3MuDQo+IA0KPiBUaGF0IG1ha2VzIG5vIHNlbnNlIGVpdGhlciwgSU1ITy4NCj4gDQo+
IEFyZSB5b3Ugc2F5aW5nIHRoYXQgYXRoMTBrIGFjdHVhbGx5IHNvbWVob3cgbWFuYWdlcyB0byB1
c2UgYW4gaW52YWxpZA0KPiBiaXRyYXRlIG92ZXIgdGhlIGFpcj8hDQo+IA0KPiBJdCBzZWVtcyBt
b3JlIGxpa2VseSB0aGF0IGl0J3MgYWN0dWFsbHkganVzdCBtaXNyZXBvcnRpbmcgd2hhdCBpdCdz
DQo+IGRvaW5nLCBhbmQgdGh1cyB0aGUgaXNzdWUgc2hvdWxkIGJlIGZpeGVkIGluIGF0aDEway4N
Cg0KWWVhaCBzbyBhcHBhcmVudGx5IHRoZSBvdmVyaGVhZCBpbnZvbHZlZCBpbiAyNTYtUUFNIDUv
NiAoTUNTIDkpIHJlc3VsdHMNCmluIGxvd2VyIGVmZmVjdGl2ZSBiaXRyYXRlIHRoYW4ganVzdCB1
c2luZyBNQ1MgOCAodW5sZXNzIHlvdSdyZSB1c2luZyAzDQpzcGF0aWFsIHN0cmVhbXMpLiBTb3Vu
ZHMgbGlrZSBhIHJhdGUgY29udHJvbCBvciByZXBvcnRpbmcgYnVnIHRoZW4uDQpQbGVhc2UgZHJv
cCB0aGlzLg0KDQpUaGFua3MsDQpUaG9tYXM=
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Johannes Berg @ 2016-09-13 18:02 UTC (permalink / raw)
To: Pedersen, Thomas, Ben Greear, linux-wireless
In-Reply-To: <1473789454.27738.7.camel@qca.qualcomm.com>
> Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9)
> results in lower effective bitrate than just using MCS 8 (unless
> you're using 3 spatial streams).
Ah. I took a - very brief - look at why this one is invalid and
couldn't figure it out.
> Sounds like a rate control or reporting bug then.
> Please drop this.
>
Ok, thanks.
johannes
^ permalink raw reply
* Re: brcmfmac43430-sdio.bin in linux-firmware
From: Fabio Estevam @ 2016-09-13 18:12 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, brcm80211-dev-list, Hante Meuleman
In-Reply-To: <e9fde75d-a17a-8a3e-feee-6495eec0f67f@broadcom.com>
Hi Arend,
On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel
<arend.vanspriel@broadcom.com> wrote:
> I could, but this is handled by Cypress now. I have asked for firmware
> release tag so I can release it.
Have you had a chance to release brcmfmac43430-sdio.bin?
Thanks!
^ permalink raw reply
* [PATCH] cfg80211: allow connect keys only with default (TX) key
From: Johannes Berg @ 2016-09-13 18:17 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There's no point in allowing connect keys when one of them
isn't also configured as the TX key, it would just confuse
drivers and probably cause them to pick something for TX.
Disallow this confusing and erroneous configuration.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/ibss.c | 5 ++++-
net/wireless/nl80211.c | 5 +++++
net/wireless/sme.c | 3 +++
net/wireless/wext-sme.c | 2 +-
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 896cbb20b6e1..eafdfa5798ae 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -114,6 +114,9 @@ static int __cfg80211_join_ibss(struct cfg80211_registered_device *rdev,
}
}
+ if (WARN_ON(connkeys && connkeys->def < 0))
+ return -EINVAL;
+
if (WARN_ON(wdev->connect_keys))
kzfree(wdev->connect_keys);
wdev->connect_keys = connkeys;
@@ -289,7 +292,7 @@ int cfg80211_ibss_wext_join(struct cfg80211_registered_device *rdev,
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
- if (wdev->wext.keys) {
+ if (wdev->wext.keys && wdev->wext.keys->def != -1) {
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8c6cbaac7d89..2036a47915d1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -895,6 +895,11 @@ nl80211_parse_connkeys(struct cfg80211_registered_device *rdev,
*no_ht = true;
}
+ if (result->def < 0) {
+ err = -EINVAL;
+ goto error;
+ }
+
return result;
error:
kfree(result);
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index add6824c44fd..c08a3b57dca1 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1043,6 +1043,9 @@ int cfg80211_connect(struct cfg80211_registered_device *rdev,
connect->crypto.ciphers_pairwise[0] = cipher;
}
}
+ } else {
+ if (WARN_ON(connkeys))
+ return -EINVAL;
}
wdev->connect_keys = connkeys;
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index f6523a4387cc..88f1f6931ab8 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -42,7 +42,7 @@ int cfg80211_mgd_wext_connect(struct cfg80211_registered_device *rdev,
if (!wdev->wext.connect.ssid_len)
return 0;
- if (wdev->wext.keys) {
+ if (wdev->wext.keys && wdev->wext.keys->def != -1) {
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
--
2.8.1
^ permalink raw reply related
* Re: [PATCH v4] cfg80211: Add support to configure a beacon data rate
From: Johannes Berg @ 2016-09-13 18:43 UTC (permalink / raw)
To: Purushottam Kushwaha; +Cc: linux-wireless, jouni, usdutt, amarnath
In-Reply-To: <1473759726-14425-1-git-send-email-pkushwah@qti.qualcomm.com>
Hi,
Thanks for the new version. I was going to apply it but while changing
something small - see below - found what I think is another issue?
> +static int validate_beacon_tx_rate(struct cfg80211_ap_settings
> *params)
> +{
> + u32 rate, count_ht, count_vht, i;
> + enum nl80211_band band;
> +
> + band = params->chandef.chan->band;
> + rate = params->beacon_rate.control[band].legacy;
> +
> + /* Allow only one rate */
> + if (rate && (rate & (rate - 1)))
> + return -EINVAL;
I was going to change that to just
if (hweight32(rate) > 1)
return -EINVAL;
I realize that your code is equivalent, but I doubt that we need to be
really efficient here, and IMHO hweight32() is easier to understand.
> + count_ht = 0;
> + for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++) {
> + if (params->beacon_rate.control[band].ht_mcs[i]) {
> + count_ht++;
> + if (count_ht > 1)
> + return -EINVAL;
> + }
> + }
But this is where I got confused - this seems wrong, you should be
checking the hweight8() of each of the ht_mcs[i] values?
Similarly, the VHT one, but with hweight16() of course, no?
I was going to move a "if (rate) return -EINVAL;" check into this and
the VHT loop, so that we only need the count_ht && count_vht and the
"all empty" portion of this:
> + if ((rate && count_ht) ||
> + (rate && count_vht) ||
> + (count_ht && count_vht) ||
> + (!rate && !count_ht && !count_vht))
> + return -EINVAL;
> +
> + return 0;
> +}
johannes
^ permalink raw reply
* Re: ath10k mesh + ap + encryption?
From: Martin Blumenstingl @ 2016-09-13 18:54 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Valo, Kalle, ath10k@lists.infradead.org,
openwrt-devel@lists.openwrt.org, linux-wireless@vger.kernel.org
In-Reply-To: <15353347.MUgkgiNHdu@prime>
Hi Simon,
On Tue, Sep 13, 2016 at 1:13 PM, Simon Wunderlich <sw@simonwunderlich.de> wrote:
> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich <sw@simonwunderlich.de> writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> >
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> >
>> > We also tested version 10.2.4.97 (from codeaurora), which is now default
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> >
>> > So here are my questions:
>> > * Did anyone succesfully run AP and mesh, both encrypted at the same
>> > time?
>> > * Do you have any pointers how we could fix this? Could it be fixable in
>> > the>
>> > driver (i.e. not in firmware)?
>> >
>> > * Does anyone have an idea if 11s will be supported in future versions? I
>> >
>> > didn't find any changelogs, but having 11s mode no longer in the service
>> > map does not make me optimistic.
>>
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
Thanks for clarifying this.
> This was introduced in December 25th, 2015 after some firmware-related
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
> 10.2.4/firmware-5.bin_10.2.4.97-1
I initially updated to version 10.2.4.70.13-2, but we decided to
update to the "latest" firmware back then (see the thread at [0])
With the explanation from Kalle it makes sense to only use the
firmware binaries distributed in his repo (to ensure that the firmware
is tested by QCA's internal team).
> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
> numbers.
That looks strange to me as well
as a side-note: I am currently preparing and testing a patch to update
the ath10k-firmware in LEDE to 10.2.4.70.52
Regards,
Martin
[0] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35623.html
^ permalink raw reply
* [PATCH 1/1] rtl8xxxu: Implement 8192e specific power down sequence
From: Jes.Sorensen @ 2016-09-13 19:03 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
In-Reply-To: <1473793395-28927-1-git-send-email-Jes.Sorensen@redhat.com>
From: Jes Sorensen <Jes.Sorensen@redhat.com>
This powers down the 8192e correctly, or at least to the point where
the firmware will load again, when reloading the driver module.
Signed-off-by: Jes Sorensen <Jes.Sorensen@redhat.com>
---
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 ++++++++++++++++++++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 1 +
2 files changed, 144 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 841522e..df54d27 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1396,6 +1396,114 @@ exit:
return ret;
}
+static int rtl8192eu_active_to_lps(struct rtl8xxxu_priv *priv)
+{
+ struct device *dev = &priv->udev->dev;
+ u8 val8;
+ u16 val16;
+ u32 val32;
+ int retry, retval;
+
+ rtl8xxxu_write8(priv, REG_TXPAUSE, 0xff);
+
+ retry = 100;
+ retval = -EBUSY;
+ /*
+ * Poll 32 bit wide 0x05f8 for 0x00000000 to ensure no TX is pending.
+ */
+ do {
+ val32 = rtl8xxxu_read32(priv, REG_SCH_TX_CMD);
+ if (!val32) {
+ retval = 0;
+ break;
+ }
+ } while (retry--);
+
+ if (!retry) {
+ dev_warn(dev, "Failed to flush TX queue\n");
+ retval = -EBUSY;
+ goto out;
+ }
+
+ /* Disable CCK and OFDM, clock gated */
+ val8 = rtl8xxxu_read8(priv, REG_SYS_FUNC);
+ val8 &= ~SYS_FUNC_BBRSTB;
+ rtl8xxxu_write8(priv, REG_SYS_FUNC, val8);
+
+ udelay(2);
+
+ /* Reset whole BB */
+ val8 = rtl8xxxu_read8(priv, REG_SYS_FUNC);
+ val8 &= ~SYS_FUNC_BB_GLB_RSTN;
+ rtl8xxxu_write8(priv, REG_SYS_FUNC, val8);
+
+ /* Reset MAC TRX */
+ val16 = rtl8xxxu_read16(priv, REG_CR);
+ val16 &= 0xff00;
+ val16 |= (CR_HCI_TXDMA_ENABLE | CR_HCI_RXDMA_ENABLE);
+ rtl8xxxu_write16(priv, REG_CR, val16);
+
+ val16 = rtl8xxxu_read16(priv, REG_CR);
+ val16 &= ~CR_SECURITY_ENABLE;
+ rtl8xxxu_write16(priv, REG_CR, val16);
+
+ val8 = rtl8xxxu_read8(priv, REG_DUAL_TSF_RST);
+ val8 |= DUAL_TSF_TX_OK;
+ rtl8xxxu_write8(priv, REG_DUAL_TSF_RST, val8);
+
+out:
+ return retval;
+}
+
+static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
+{
+ u8 val8;
+ int count, ret = 0;
+
+ /* Turn off RF */
+ rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+
+ /* Switch DPDT_SEL_P output from register 0x65[2] */
+ val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
+ val8 &= ~LEDCFG2_DPDT_SELECT;
+ rtl8xxxu_write8(priv, REG_LEDCFG2, val8);
+
+ /* 0x0005[1] = 1 turn off MAC by HW state machine*/
+ val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+ val8 |= BIT(1);
+ rtl8xxxu_write8(priv, REG_APS_FSMCO + 1, val8);
+
+ for (count = RTL8XXXU_MAX_REG_POLL; count; count--) {
+ val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+ if ((val8 & BIT(1)) == 0)
+ break;
+ udelay(10);
+ }
+
+ if (!count) {
+ dev_warn(&priv->udev->dev, "%s: Disabling MAC timed out\n",
+ __func__);
+ ret = -EBUSY;
+ goto exit;
+ }
+
+exit:
+ return ret;
+}
+
+static int rtl8192eu_emu_to_disabled(struct rtl8xxxu_priv *priv)
+{
+ u8 val8;
+
+ /* 0x04[12:11] = 01 enable WL suspend */
+ val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+ val8 &= ~(BIT(3) | BIT(4));
+ val8 |= BIT(3);
+ rtl8xxxu_write8(priv, REG_APS_FSMCO + 1, val8);
+
+ return 0;
+}
+
static int rtl8192eu_power_on(struct rtl8xxxu_priv *priv)
{
u16 val16;
@@ -1446,6 +1554,40 @@ exit:
return ret;
}
+void rtl8192eu_power_off(struct rtl8xxxu_priv *priv)
+{
+ u8 val8;
+ u16 val16;
+
+ rtl8xxxu_flush_fifo(priv);
+
+ val8 = rtl8xxxu_read8(priv, REG_TX_REPORT_CTRL);
+ val8 &= ~TX_REPORT_CTRL_TIMER_ENABLE;
+ rtl8xxxu_write8(priv, REG_TX_REPORT_CTRL, val8);
+
+ /* Turn off RF */
+ rtl8xxxu_write8(priv, REG_RF_CTRL, 0x00);
+
+ rtl8192eu_active_to_lps(priv);
+
+ /* Reset Firmware if running in RAM */
+ if (rtl8xxxu_read8(priv, REG_MCU_FW_DL) & MCU_FW_RAM_SEL)
+ rtl8xxxu_firmware_self_reset(priv);
+
+ /* Reset MCU */
+ val16 = rtl8xxxu_read16(priv, REG_SYS_FUNC);
+ val16 &= ~SYS_FUNC_CPU_ENABLE;
+ rtl8xxxu_write16(priv, REG_SYS_FUNC, val16);
+
+ /* Reset MCU ready status */
+ rtl8xxxu_write8(priv, REG_MCU_FW_DL, 0x00);
+
+ rtl8xxxu_reset_8051(priv);
+
+ rtl8192eu_active_to_emu(priv);
+ rtl8192eu_emu_to_disabled(priv);
+}
+
static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
{
u32 val32;
@@ -1487,7 +1629,7 @@ struct rtl8xxxu_fileops rtl8192eu_fops = {
.parse_efuse = rtl8192eu_parse_efuse,
.load_firmware = rtl8192eu_load_firmware,
.power_on = rtl8192eu_power_on,
- .power_off = rtl8xxxu_power_off,
+ .power_off = rtl8192eu_power_off,
.reset_8051 = rtl8xxxu_reset_8051,
.llt_init = rtl8xxxu_auto_llt_table,
.init_phy_bb = rtl8192eu_init_phy_bb,
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
index 3555a2f..315ccfb 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h
@@ -676,6 +676,7 @@
#define REG_SCH_TXCMD 0x05d0
/* define REG_FW_TSF_SYNC_CNT 0x04a0 */
+#define REG_SCH_TX_CMD 0x05f8
#define REG_FW_RESET_TSF_CNT_1 0x05fc
#define REG_FW_RESET_TSF_CNT_0 0x05fd
#define REG_FW_BCN_DIS_CNT 0x05fe
--
2.7.4
^ permalink raw reply related
* [PATCH 0/1] Fix problem with rtl8192eu firmware reload
From: Jes.Sorensen @ 2016-09-13 19:03 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Larry.Finger, Jes Sorensen
From: Jes Sorensen <Jes.Sorensen@redhat.com>
Hi,
This one goes on top of my previous patches, albeit it probably
applies out of order.
It resolves the issue where firmware wouldn't load correctly if
reloading the driver module.
Cheers,
Jes
Jes Sorensen (1):
rtl8xxxu: Implment 8192e specific power down sequence
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 ++++++++++++++++++++-
.../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h | 1 +
2 files changed, 144 insertions(+), 1 deletion(-)
--
2.7.4
^ permalink raw reply
* pull-request: mac80211 2016-09-13
From: Johannes Berg @ 2016-09-13 20:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
We found a few more issues, I'm sending you small fixes here. The diffstat
would be even shorter, but one of Felix's patches has to move about 30 lines
of code, which makes it seem much bigger than it really is.
Let me know if there's any problem.
Thanks,
johannes
The following changes since commit 15543692a010192b4264ade0d45390e8bb3dc639:
Merge tag 'mac80211-for-davem-2016-08-30' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2016-08-30 21:34:48 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-09-13
for you to fetch changes up to ad5987b47e96a0fb6d13fea250e936aed000093c:
nl80211: validate number of probe response CSA counters (2016-09-13 20:19:27 +0200)
----------------------------------------------------------------
A few more fixes:
* better mesh path fixing, from Thomas
* fix TIM IE recalculation after sending frames
to a sleeping station, from Felix
* fix sequence number assignment while sending
frames to a sleeping station, also from Felix
* validate number of probe response CSA counter
offsets, fixing a copy/paste bug (from myself)
----------------------------------------------------------------
Felix Fietkau (2):
mac80211: fix tim recalculation after PS response
mac80211: fix sequence number assignment for PS response frames
Johannes Berg (1):
nl80211: validate number of probe response CSA counters
Pedersen, Thomas (1):
mac80211: make mpath path fixing more robust
net/mac80211/mesh_hwmp.c | 3 ++-
net/mac80211/mesh_pathtbl.c | 2 +-
net/mac80211/sta_info.c | 4 +--
net/mac80211/tx.c | 65 +++++++++++++++++++++++----------------------
net/wireless/nl80211.c | 2 +-
5 files changed, 39 insertions(+), 37 deletions(-)
^ 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