* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Toke Høiland-Jørgensen @ 2017-01-30 19:43 UTC (permalink / raw)
To: Klaus Kinski; +Cc: Dave Taht, linux-wireless
In-Reply-To: <HE1PR0701MB1803A03DD96F300119936D0EFC4B0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
Klaus Kinski <jpo234@outlook.de> writes:
> The captures I used to create the statistics are here:
> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>
> An obvious difference is, that Madwifi sends 5 packets in a row
> without waiting for an ACK whereas ath9k/mac80211 always seems to wait
> for an ACK. This seems to point to the "net80211 aggressive mode
> theory" https://wiki.freebsd.org/WifiAggressiveMode, IMHO.
I'm not too familiar with that part of the stack, but that seems
reasonable, yeah. AFAIK the "aggresive mode" is a pre-802.11n feature,
though, which is why you won't see that in ath9k. In 802.11n this kind
of bursting was replaced by aggregation, which you're not getting any of
since you're running in 802.11a mode, obviously.
The lack of bursting will translate to slightly lower throughput, which
will be why you see fewer packets transmitted by ath9k. Of course, if
your receiver supported aggregation, the numbers would look dramatically
better in ath9k's favour... ;)
-Toke
^ permalink raw reply
* Re: pull-request: wireless-drivers 2017-01-29
From: David Miller @ 2017-01-30 20:19 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87a8a9udk1.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sun, 29 Jan 2017 16:49:02 +0200
> small but important fixes for 4.10. Hopefully is the last pull request
> for 4.10.
>
> Please let me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* new patch state in patchwork...
From: David Miller @ 2017-01-30 20:38 UTC (permalink / raw)
To: netdev; +Cc: linux-wireless, netfilter-devel
I noticed there is a new state "Needs Review / ACK" in patchwork.
I am going to use this for situations where I am explicitly waiting
either for a maintainer, or someone referenced directly in the patch
discussion, to review and ACK/NACK the change.
Just FYI...
^ permalink raw reply
* [PATCH V2] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Larry Finger @ 2017-01-30 20:52 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Jurij Smakov, Larry Finger
From: Jurij Smakov <jurij@wooyd.org>
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
and required higher signal strengths to work at all
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
of the problems. This patch fixes all of those problems.
Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
---
V2 - answer the comments of Kalle
---
Kalle,
This patch should be pushed upstream as soon as possible. Note that it
does not cause a kernel panic. It does, however, reduce the reliability
of the wireless connection.
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index b875a72..9a94e45 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -96,7 +96,7 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
- char *fw_name = "rtlwifi/rtl8192cfwU.bin";
+ char *fw_name;
rtl8192ce_bt_reg_init(hw);
@@ -167,8 +167,13 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
+ if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
+ !IS_92C_SERIAL(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU.bin";
+ else if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
fw_name = "rtlwifi/rtl8192cfwU_B.bin";
+ else
+ fw_name = "rtlwifi/rtl8192cfw.bin";
rtlpriv->max_fw_size = 0x4000;
pr_info("Using firmware %s\n", fw_name);
--
2.10.2
^ permalink raw reply related
* [PATCH V2] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Larry Finger @ 2017-01-30 21:41 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Jurij Smakov, Larry Finger
From: Jurij Smakov <jurij@wooyd.org>
In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
d86e64768859, an error in the edit results in the wrong firmware
being loaded for some models of the RTL8188/8192CE. In this condition,
the connection suffered from high ping latency, slow transfer rates,
and required higher signal strengths to work at all
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
of the problems. This patch fixes all of those problems.
Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
Signed-off-by: Jurij Smakov <jurij@wooyd.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Stable <stable@vger.kernel.org> # 4.9+
---
V2 - answer the comments of Kalle
---
Kalle,
This patch should be pushed upstream as soon as possible. Note that it
does not cause a kernel panic. It does, however, reduce the reliability
of the wireless connection.
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
index b875a72..9a94e45 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c
@@ -96,7 +96,7 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
struct rtl_priv *rtlpriv = rtl_priv(hw);
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
struct rtl_hal *rtlhal = rtl_hal(rtl_priv(hw));
- char *fw_name = "rtlwifi/rtl8192cfwU.bin";
+ char *fw_name;
rtl8192ce_bt_reg_init(hw);
@@ -167,8 +167,13 @@ int rtl92c_init_sw_vars(struct ieee80211_hw *hw)
}
/* request fw */
- if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
+ if (IS_VENDOR_UMC_A_CUT(rtlhal->version) &&
+ !IS_92C_SERIAL(rtlhal->version))
+ fw_name = "rtlwifi/rtl8192cfwU.bin";
+ else if (IS_81XXC_VENDOR_UMC_B_CUT(rtlhal->version))
fw_name = "rtlwifi/rtl8192cfwU_B.bin";
+ else
+ fw_name = "rtlwifi/rtl8192cfw.bin";
rtlpriv->max_fw_size = 0x4000;
pr_info("Using firmware %s\n", fw_name);
--
2.10.2
^ permalink raw reply related
* Intel Pro 4965 wireless
From: Mel Stimmel @ 2017-01-31 2:04 UTC (permalink / raw)
To: linux-wireless; +Cc: "mailto:ilw"
I have a problem that recently arose with my Thinkpad model T61
running Ubuntu 16.04 with the Intel Pro 4965 installed.
This system was working just fine until sometime in Dec., when
after one of the routine updates, the software can't see/find/recognize
the wireless adapter. It's not the adapter, as if I boot the system from
an older CD (show and tell mode) the wifi works just fine.
When I do the command LSHW, it shows the driver as iwl4965, and the
version as 3.13.0-93-generic.
I've been in the computer business since 1958 but are a newby to
Linux so don't any/many of the commands and/or it's inner workings.
Any help that y'all could provide would be greatly appreciated.
Mel Stimmel
--
Have a GREAT DAY!
Mel
^ permalink raw reply
* [PATCHv3] ath10k: fix boot failure in UTF mode/testmode
From: c_traja @ 2017-01-31 4:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, tamizhchelvam, Tamizh chelvam, stable
From: Tamizh chelvam <c_traja@qti.qualcomm.com>
Rx filter reset and the dynamic tx switch mode (EXT_RESOURCE_CFG)
configuration are causing the following errors when UTF firmware
is loaded to the target.
Error message 1:
[ 598.015629] ath10k_pci 0001:01:00.0: failed to ping firmware: -110
[ 598.020828] ath10k_pci 0001:01:00.0: failed to reset rx filter: -110
[ 598.141556] ath10k_pci 0001:01:00.0: failed to start core (testmode): -110
Error message 2:
[ 668.615839] ath10k_ahb a000000.wifi: failed to send ext resource cfg command : -95
[ 668.618902] ath10k_ahb a000000.wifi: failed to start core (testmode): -95
Avoiding these configurations while bringing the target in
testmode is solving the problem.
Cc: stable@vger.kernel.org
Signed-off-by: Tamizh chelvam <c_traja@qti.qualcomm.com>
---
v3:
*Added Cc:stable@vger.kernel.org in commit log
drivers/net/wireless/ath/ath10k/core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index c2afcca..c27e7ea 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1996,7 +1996,8 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
ath10k_dbg(ar, ATH10K_DBG_BOOT, "firmware %s booted\n",
ar->hw->wiphy->fw_version);
- if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map)) {
+ if (test_bit(WMI_SERVICE_EXT_RES_CFG_SUPPORT, ar->wmi.svc_map) &&
+ mode == ATH10K_FIRMWARE_MODE_NORMAL) {
val = 0;
if (ath10k_peer_stats_enabled(ar))
val = WMI_10_4_PEER_STATS;
@@ -2049,10 +2050,13 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
* possible to implicitly make it correct by creating a dummy vdev and
* then deleting it.
*/
- status = ath10k_core_reset_rx_filter(ar);
- if (status) {
- ath10k_err(ar, "failed to reset rx filter: %d\n", status);
- goto err_hif_stop;
+ if (mode == ATH10K_FIRMWARE_MODE_NORMAL) {
+ status = ath10k_core_reset_rx_filter(ar);
+ if (status) {
+ ath10k_err(ar,
+ "failed to reset rx filter: %d\n", status);
+ goto err_hif_stop;
+ }
}
/* If firmware indicates Full Rx Reorder support it must be used in a
--
1.7.9.5
^ permalink raw reply related
* Unsupported NVRAM on D-Link DIR-885L (affects brcmfmac)
From: Rafał Miłecki @ 2017-01-31 6:24 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, brcm80211 development,
Arend Van Spriel, Hante Meuleman
Cc: Hauke Mehrtens
I just noticed my DIR-885L has some weird NVRAM format. Linux doesn't
support it, it reads only part of it, which may affect brcmfmac.
There goes the most interesting part:
00000000 46 4c 53 48 50 3e 00 00 3f 01 00 00 4b 01 00 00 |FLSHP>..?...K.=
..|
00000010 00 00 00 00 31 3a 70 61 35 67 38 30 61 33 3d 30 |....1:pa5g80a3=
=3D0|
00000020 78 31 64 36 36 2c 30 78 65 34 35 66 2c 30 78 32 |x1d66,0xe45f,0=
x2|
00000030 32 37 61 2c 30 78 32 33 36 65 2c 30 78 31 64 30 |27a,0x236e,0x1=
d0|
00000040 30 2c 30 78 65 62 38 38 2c 30 78 33 32 39 36 2c |0,0xeb88,0x329=
6,|
(...)
00003e00 3d 36 35 35 33 35 00 31 3a 72 78 67 61 69 6e 65 |=3D65535.1:rxg=
aine|
00003e10 72 72 32 67 61 30 3d 36 33 00 30 3a 75 6c 62 70 |rr2ga0=3D63.0:=
ulbp|
00003e20 64 6f 66 66 73 35 67 62 34 61 31 3d 36 35 35 33 |doffs5gb4a1=3D=
6553|
00003e30 35 00 30 3a 6d 63 73 62 77 32 30 35 67 68 70 6f |5.0:mcsbw205gh=
po|
00003e40 3d 32 38 35 38 38 33 35 39 36 38 00 00 00 00 00 |=3D2858835968.=
....|
00003e50 6f 66 66 73 65 74 32 30 69 6e 34 30 6d 32 67 3d |offset20in40m2=
g=3D|
00003e60 36 35 35 33 35 00 65 74 30 6d 61 63 61 64 64 72 |65535.et0macad=
dr|
00003e70 3d 30 30 3a 30 30 3a 30 30 3a 30 30 3a 30 30 3a |=3D00:00:00:00=
:00:|
00003e80 30 30 00 31 3a 72 78 67 61 69 6e 73 32 67 74 72 |00.1:rxgains2g=
tr|
Header has length field 50 3e 00 00 which means 0x3e50 bytes. I was
surprised to see more entries after then "end" of the NVRAM.
What's interesting CFE (bootloader) also can't read these entries.
Any idea what format is that?
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH V2] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Kalle Valo @ 2017-01-31 6:27 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Jurij Smakov
In-Reply-To: <20170130214136.28170-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> From: Jurij Smakov <jurij@wooyd.org>
>
> In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
> d86e64768859, an error in the edit results in the wrong firmware
> being loaded for some models of the RTL8188/8192CE. In this condition,
> the connection suffered from high ping latency, slow transfer rates,
> and required higher signal strengths to work at all
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
> https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
> https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
> of the problems. This patch fixes all of those problems.
>
> Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
> Signed-off-by: Jurij Smakov <jurij@wooyd.org>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.9+
> ---
> V2 - answer the comments of Kalle
Perfect, thanks. Now it should be obvious why this patch needs to be in
4.10.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Kalle Valo @ 2017-01-31 6:35 UTC (permalink / raw)
To: Tony Lindgren
Cc: Pavel Machek, Pali Rohár, Arend Van Spriel, Ming Lei,
Luis R. Rodriguez, Greg Kroah-Hartman, David Gnedt, Michal Kazior,
Daniel Wagner, Sebastian Reichel, Ivaylo Dimitrov, Aaro Koskinen,
Grazvydas Ignotas, linux-kernel, linux-wireless, netdev
In-Reply-To: <20170130175309.GY7403@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Pavel Machek <pavel@ucw.cz> [170127 11:41]:
>> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
>> > Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>> >=20
>> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
>> > >> Pali Roh=C3=A1r <pali.rohar@gmail.com> writes:
>> > >>=20
>> > >> > 2) It was already tested that example NVS data can be used for N9=
00 e.g.
>> > >> > for SSH connection. If real correct data are not available it is =
better
>> > >> > to use at least those example (and probably log warning message) =
so user
>> > >> > can connect via SSH and start investigating where is problem.
>> > >>=20
>> > >> I disagree. Allowing default calibration data to be used can be
>> > >> unnoticed by user and left her wondering why wifi works so badly.
>> > >
>> > > So there are only two options:
>> > >
>> > > 1) Disallow it and so these users will have non-working wifi.
>> > >
>> > > 2) Allow those data to be used as fallback mechanism.
>> > >
>> > > And personally I'm against 1) because it will break wifi support for
>> > > *all* Nokia N900 devices right now.
>> >=20
>> > All two of them? :)
>>=20
>> Umm. You clearly want a flock of angry penguins at your doorsteps :-).
>
> Well this silly issue of symlinking and renaming nvs files in a standard
> Linux distro was also hitting me on various devices with wl12xx/wl18xx
> trying to use the same rootfs.
>
> Why don't we just set a custom compatible property for n900 that then
> picks up some other nvs file instead of the default?
Please don't. An ugly kernel workaround in kernel because of user space
problems is a bad idea. wl1251 should just ask for NVS file from user
space, it shouldn't care if it's a "default" file or something else.
That's a user space policy decision.
Why can't you do something like this:
* rename the NVS file linux-firmware to wl1251-nvs.bin.example
* before distro updates linux-firmware create yours own deb/rpm/whatever
package "wl1251-firmware" which installs your flavor of nvs file (or
the user fallback helper if more dynamic functionality is preferred)
--=20
Kalle Valo
^ permalink raw reply
* Re: [V2] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Kalle Valo @ 2017-01-31 7:06 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Jurij Smakov, Larry Finger
In-Reply-To: <20170130214136.28170-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> From: Jurij Smakov <jurij@wooyd.org>
>
> In commit cf4747d7535a ("rtlwifi: Fix regression caused by commit
> d86e64768859, an error in the edit results in the wrong firmware
> being loaded for some models of the RTL8188/8192CE. In this condition,
> the connection suffered from high ping latency, slow transfer rates,
> and required higher signal strengths to work at all
>
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=853073,
> https://bugzilla.opensuse.org/show_bug.cgi?id=1017471, and
> https://github.com/lwfinger/rtlwifi_new/issues/203 for descriptions
> of the problems. This patch fixes all of those problems.
>
> Fixes: cf4747d7535a ("rtlwifi: Fix regression caused by commit d86e64768859")
> Signed-off-by: Jurij Smakov <jurij@wooyd.org>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Cc: Stable <stable@vger.kernel.org> # 4.9+
Patch applied to wireless-drivers.git, thanks.
52f5631a4c05 rtlwifi: rtl8192ce: Fix loading of incorrect firmware
--
https://patchwork.kernel.org/patch/9546113/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: rt2x00: fix clk_get call
From: Kalle Valo @ 2017-01-31 7:09 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linux-wireless, Helmut Schaa, Daniel Golle, Felix Fietkau
In-Reply-To: <20170129114052.GB7489@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> clk_get() takes two arguments and might return ERR_PTR(), so we
> have to nullify pointer on that case, to do not break further call
> to clk_get_rate().
>
> Reported-by: Felix Fietkau <nbd@nbd.name>
> Fixes: 34db70b92fae ("rt2x00: add copy of clk for soc devices")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
33e962c8871f rt2x00: fix clk_get call
--
https://patchwork.kernel.org/patch/9543961/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: iwlwifi: alloc memory dynamically also for DVM
From: Kalle Valo @ 2017-01-31 7:11 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, Sara Sharon, Luca Coelho
In-Reply-To: <20170130103432.24613-1-luca@coelho.fi>
Luciano Coelho <luca@coelho.fi> wrote:
> From: Sara Sharon <sara.sharon@intel.com>
>
> For old firmwares the memory wasn't allocated, resulting in panic.
> Make it dynamically allocated as well. Allow any order of functions
> call.
>
> Fixes: eef187a7b8a1 ("iwlwifi: enlarge number of ucode sections")
> Signed-off-by: Sara Sharon <sara.sharon@intel.com>
> Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
> Tested-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to wireless-drivers-next.git, thanks.
d546530e5694 iwlwifi: alloc memory dynamically also for DVM
--
https://patchwork.kernel.org/patch/9544763/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [fix?] bcma: use (get|put)_device when probing/removing device driver
From: Kalle Valo @ 2017-01-31 7:15 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <20170128133122.12360-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows tracking device state and e.g. makes devm work as expected.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Cc: Stable <stable@vger.kernel.org>
At this stage of the cycle I think 4.11 is more approriate for this fix.
--
https://patchwork.kernel.org/patch/9543283/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [V2, 2/5] brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
From: Kalle Valo @ 2017-01-31 7:25 UTC (permalink / raw)
To: Arend Van Spriel; +Cc: linux-wireless, Arend van Spriel
In-Reply-To: <1485520068-5807-3-git-send-email-arend.vanspriel@broadcom.com>
Arend Van Spriel <arend.vanspriel@broadcom.com> wrote:
> The driver advertises support for WOWLAN_NETDETECT but did not specify
> maximum amount of netdetect match sets. This was no issue due to a bug
> in nl80211. As that has been fixed, brcmfmac also needs fixing.
>
> Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
> Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
> Reviewed-by: Franky Lin <franky.lin@broadcom.com>
> Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
4 patches applied to wireless-drivers-next.git, thanks.
2ef0359031b9 brcmfmac: provide a value for struct wowlan_support::max_nd_match_sets
d29afe91af59 brcmfmac: fix handling firmware results for wowl netdetect
0b57010fc18e brcmfmac: allow wowlan support to be per device
2a2a5d1835b6 brcmfmac: add .update_connect_params() callback
--
https://patchwork.kernel.org/patch/9541755/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rt2x00: avoid introducing a USB dependency in the rt2x00lib module
From: Kalle Valo @ 2017-01-31 7:26 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, vishalthanki, nbd
In-Reply-To: <20170127141416.GA6491@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> As reported by Felix:
>
> Though protected by an ifdef, introducing an usb symbol dependency in
> the rt2x00lib module is a major inconvenience for distributions that
> package kernel modules split into individual packages.
>
> Get rid of this unnecessary dependency by calling the usb related
> function from a more suitable place.
>
> Reported-by: Felix Fietkau <nbd@nbd.name>
> Fixes: 8b4c0009313f ("rt2x00usb: Use usb anchor to manage URB")
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Does not apply:
fatal: sha1 information is lacking or useless (drivers/net/wireless/ralink/rt2x00/rt2x00dev.c).
error: could not build fake ancestor
Applying: rt2x00: avoid introducing a USB dependency in the rt2x00lib module
Patch failed at 0001 rt2x00: avoid introducing a USB dependency in the rt2x00lib module
The copy of the patch that failed is found in: .git/rebase-apply/patch
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9541945/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [fix?] bcma: use (get|put)_device when probing/removing device driver
From: Kalle Valo @ 2017-01-31 7:27 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <20170128133122.12360-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> This allows tracking device state and e.g. makes devm work as expected.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
> Cc: Stable <stable@vger.kernel.org>
Patch applied to wireless-drivers-next.git, thanks.
a971df0b9d04 bcma: use (get|put)_device when probing/removing device driver
--
https://patchwork.kernel.org/patch/9543283/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [v2] rt2800: enable rt3290 unconditionally on pci probe
From: Kalle Valo @ 2017-01-31 7:28 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa
In-Reply-To: <1485774767-6655-1-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> When we restart system using sysrq RT3290 device do not initalize
> properly, hance always enable it via WLAN_FUN_CTRL register on
> probe.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=85461
> Reported-and-tested-by: Giedrius Statkevičius <edrius.statkevicius@gmail.com>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
6715208d0a95 rt2800: enable rt3290 unconditionally on pci probe
--
https://patchwork.kernel.org/patch/9544879/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: bcma: make OF code more generic (not platform_device specific)
From: Kalle Valo @ 2017-01-31 7:30 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, Rafał Miłecki
In-Reply-To: <20170128221134.9028-1-zajec5@gmail.com>
Rafał Miłecki wrote:
> From: Rafał Miłecki <rafal@milecki.pl>
>
> OF allows not only specifying platform devices but also describing
> devices on standard buses like PCI or USB. This change will allow
> reading info from DT for bcma buses hosted on PCI cards.
>
> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Patch applied to wireless-drivers-next.git, thanks.
b1a4c9a19659 bcma: make OF code more generic (not platform_device specific)
--
https://patchwork.kernel.org/patch/9543515/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] wlcore: disable multicast filter in AP mode
From: Kalle Valo @ 2017-01-31 7:22 UTC (permalink / raw)
To: Iain Hunter; +Cc: linux-wireless, Iain Hunter
In-Reply-To: <20170130144936.6699-1-i-hunter1@ti.com>
Iain Hunter <drhunter95@gmail.com> writes:
> Enable AP support allmulticast for MDNS. It can be enabled by bringing up
>
> the interface with ip command with the argument allmulticast on
>
> Signed-off-by: Iain Hunter <i-hunter1@ti.com>
The commit log looks now ok, except there's an unnecessare empty line.
But I can fix that.
> @@ -3281,6 +3281,20 @@ static void wl1271_op_configure_filter(struct ieee80211_hw *hw,
> if (ret < 0)
> goto out_sleep;
> }
> +
> + /*
> + * If interface in AP mode and created with allmulticast then disable
> + * the firmware filters so that all multicast packets are passed
> + * This is mandatory for MDNS based discovery protocols
> + */
> + if (wlvif->bss_type == BSS_TYPE_AP_BSS) {
> + if (*total & FIF_ALLMULTI)
> + ret = wl1271_acx_group_address_tbl(wl, wlvif,
> + false,
> + NULL, 0);
> +
> + }
> +
> }
Sorry, I missed this earlier but here you don't check ret value at all.
I think you should bail out from the look if an error happens, like
other commands in the same loop does.
--
Kalle Valo
^ permalink raw reply
* Re: Intel Pro 4965 wireless
From: Luca Coelho @ 2017-01-31 7:36 UTC (permalink / raw)
To: Mel Stimmel, linux-wireless, sgruszka
In-Reply-To: <b4724c04-1377-fda3-a65e-8c84fe60838a@earthlink.net>
Hi,
On Mon, 2017-01-30 at 21:04 -0500, Mel Stimmel wrote:
> I have a problem that recently arose with my Thinkpad model T61
> running Ubuntu 16.04 with the Intel Pro 4965 installed.
> This system was working just fine until sometime in Dec., when
> after one of the routine updates, the software can't see/find/recognize
> the wireless adapter. It's not the adapter, as if I boot the system from
> an older CD (show and tell mode) the wifi works just fine.
> When I do the command LSHW, it shows the driver as iwl4965, and the
> version as 3.13.0-93-generic.
> I've been in the computer business since 1958 but are a newby to
> Linux so don't any/many of the commands and/or it's inner workings.
> Any help that y'all could provide would be greatly appreciated.
Adding Stanislaw, who is the maintainer of iwlegacy (which is the driver
that supports iwl4965).
--
Cheers,
Luca.
^ permalink raw reply
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Wojciech Dubowik @ 2017-01-31 7:54 UTC (permalink / raw)
To: Klaus Kinski; +Cc: Toke Høiland-Jørgensen, Dave Taht, linux-wireless
In-Reply-To: <87o9yo2v0s.fsf@toke.dk>
Madwifi has default best effort queue "tuned" for throughout
and its parameters are different from mac80211 defaults when
qos (WME) is disabled.
You would have to dump qos settings for both systems before
comparing them. I guess the easiest way is to make sure QoS
is enabled and send video type of packets with iperf ... -S 0xa0
Wojtek
On 30/01/17 20:43, Toke Høiland-Jørgensen wrote:
> Klaus Kinski <jpo234@outlook.de> writes:
>
>> The captures I used to create the statistics are here:
>> https://drive.google.com/open?id=0ByFGz3ZH6JcYMGp0a05lYzBPNzA
>>
>> An obvious difference is, that Madwifi sends 5 packets in a row
>> without waiting for an ACK whereas ath9k/mac80211 always seems to wait
>> for an ACK. This seems to point to the "net80211 aggressive mode
>> theory" https://wiki.freebsd.org/WifiAggressiveMode, IMHO.
> I'm not too familiar with that part of the stack, but that seems
> reasonable, yeah. AFAIK the "aggresive mode" is a pre-802.11n feature,
> though, which is why you won't see that in ath9k. In 802.11n this kind
> of bursting was replaced by aggregation, which you're not getting any of
> since you're running in 802.11a mode, obviously.
>
> The lack of bursting will translate to slightly lower throughput, which
> will be why you see fewer packets transmitted by ath9k. Of course, if
> your receiver supported aggregation, the numbers would look dramatically
> better in ath9k's favour... ;)
>
> -Toke
^ permalink raw reply
* Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI
From: Thiagarajan, Vasanthakumar @ 2017-01-31 8:40 UTC (permalink / raw)
To: Jean-Pierre Tosoni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <014301d27737$b693eca0$23bbc5e0$@acksys.fr>
On Wednesday 25 January 2017 11:50 PM, Jean-Pierre Tosoni wrote:
>> -----Message d'origine-----
>> De : linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
>> owner@vger.kernel.org] De la part de Vasanthakumar Thiagarajan
>> Envoy=E9 : mercredi 25 janvier 2017 12:31
>> =C0 : johannes@sipsolutions.net
>> Cc : linux-wireless@vger.kernel.org; Vasanthakumar Thiagarajan
>> Objet : [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel
>> in non-ETSI
>>
>> For non-ETSI regulatory domain, CAC result on DFS channel may not be val=
id
>> once moving out of that channel (as done during remain-on-channel,
>> scannning and off-channel tx).
>> Running CAC on an operating DFS channel after every off-channel operatio=
n
>> will only add complexity and disturb the current link. Better do not all=
ow
>> any off-channel switch from a DFS operating channel in non-ETSI domain.
>>
>
> Moving out should be forbidden only to "master" devices i.e. AP, mesh,
> ad-hoc.
> "Slave" devices i.e. client stations, are not responsible for detecting
> radars, hence, they can do an off-channel scan and go back to a "DFS
> operating channel" without waiting for CAC.
>
> It looks like your patch would forbid multichannel scan ?
>
>
No, this patch forbids off-channel switch only for DFS master device.
cfg80211_beaconing_iface_active() checks if it is a beaconing interface.
I'll mention this in the commit log.
Vasanth
^ permalink raw reply
* Re: [RFC 1/3] cfg80211: Make pre-CAC results valid only for ETSI domain
From: Thiagarajan, Vasanthakumar @ 2017-01-31 9:10 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1485423244.11038.4.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMjYgSmFudWFyeSAyMDE3IDAzOjA0IFBNLCBKb2hhbm5lcyBCZXJnIHdyb3Rl
Og0KPg0KPj4gKwkJLyogU2hvdWxkIHdlIGFwcGx5IHRoZSBncmFjZSBwZXJpb2QgZHVyaW5nIGJl
YWNvbmluZw0KPj4gaW50ZXJmYWNlDQo+PiArCQkgKiBzaHV0ZG93biBhbHNvPw0KPj4gKwkJICov
DQo+PiArCQljZmc4MDIxMV9zY2hlZF9kZnNfY2hhbl91cGRhdGUocmRldik7DQo+DQo+IEl0IG1p
Z2h0IG1ha2Ugc29tZSBzZW5zZSwgc2F5IGlmIGhvc3RhcGQgY3Jhc2hlcyBhbmQgeW91IHJlc3Rh
cnQgaXQNCj4gYXV0b21hdGljYWxseSBvciBzb21ldGhpbmc/DQoNClN1cmUuIEluaXRpYWxseSBp
dCBsb29rZWQgdHJpY2t5IHRvIGhhbmRsZSB0aGlzLiBCdXQgSSBndWVzcyB3ZSBjYW4gc3RvcmUN
CnRoZSBERlMgY2hhbm5lbCBhbmQgdGhlIHRpbWUgc3RhbXAgKHJkZXYgc3BlY2lmaWMpIHdoZW4g
dGhlIGJlYWNvbmluZyBpbnRlcmZhY2UNCmlzIGJyb3VnaHQgZG93bi4gY2ZnODAyMTFfZGZzX2No
YW5uZWxzX3VwZGF0ZV93b3JrKCkgY2FuIHVzZSB0aGVzZSBpbmZvcm1hdGlvbg0KYW5kIGFwcGx5
IHRoZSBncmFjZSBwZXJpb2QgYmVmb3JlIHNldHRpbmcgdGhlIERGUyBjaGFubmVsIHN0YXRlIGJh
Y2sgdG8gJ3VzYWJsZScuDQoNCj4NCj4+ICAgCXJldHVybiBlcnI7DQo+PiBkaWZmIC0tZ2l0IGEv
bmV0L3dpcmVsZXNzL2NoYW4uYyBiL25ldC93aXJlbGVzcy9jaGFuLmMNCj4+IGluZGV4IDU0OTdk
MDIyLi4wOTAzMDlhIDEwMDY0NA0KPj4gLS0tIGEvbmV0L3dpcmVsZXNzL2NoYW4uYw0KPj4gKysr
IGIvbmV0L3dpcmVsZXNzL2NoYW4uYw0KPj4gQEAgLTQ1Niw2ICs0NTYsMTAyIEBAIGJvb2wgY2Zn
ODAyMTFfY2hhbmRlZl9kZnNfdXNhYmxlKHN0cnVjdCB3aXBoeQ0KPj4gKndpcGh5LA0KPj4gICAJ
cmV0dXJuIChyMSArIHIyID4gMCk7DQo+PiAgIH0NCj4+DQo+PiArc3RhdGljIGJvb2wgY2ZnODAy
MTFfNWdoel9zdWJfY2hhbihzdHJ1Y3QgY2ZnODAyMTFfY2hhbl9kZWYNCj4+ICpjaGFuZGVmLA0K
Pj4gKwkJCQkgICBzdHJ1Y3QgaWVlZTgwMjExX2NoYW5uZWwgKmNoYW4pDQo+DQo+IFRoaXMgY291
bGQgdXNlIHNvbWUgZXhwbGFuYXRpb24sIGFuZCBJIGRvbid0IHNlZSBhbnl0aGluZyB0aGF0J3Mg
cmVhbGx5DQo+IDUgR0h6IHNwZWNpZmljIGluIGhlcmUsIHNvIHdoeSB0aGF0IGluIHRoZSBmdW5j
dGlvbiBuYW1lPw0KDQpTdXJlLg0KDQo+DQo+PiArCXUzMiBzdGFydF9mcmVxX3NlZzAgPSAwLCBl
bmRfZnJlcV9zZWcwID0gMDsNCj4+ICsJdTMyIHN0YXJ0X2ZyZXFfc2VnMSA9IDAsIGVuZF9mcmVx
X3NlZzEgPSAwOw0KPj4gKw0KPj4gKwlpZiAoY2hhbmRlZi0+Y2hhbi0+Y2VudGVyX2ZyZXEgPT0g
Y2hhbi0+Y2VudGVyX2ZyZXEpDQo+PiArCQlyZXR1cm4gdHJ1ZTsNCj4+ICsNCj4+ICsJc3dpdGNo
IChjaGFuZGVmLT53aWR0aCkgew0KPj4gKwljYXNlIE5MODAyMTFfQ0hBTl9XSURUSF80MDoNCj4+
ICsJCXN0YXJ0X2ZyZXFfc2VnMCA9IGNoYW5kZWYtPmNlbnRlcl9mcmVxMSAtIDIwOw0KPj4gKwkJ
ZW5kX2ZyZXFfc2VnMCA9IGNoYW5kZWYtPmNlbnRlcl9mcmVxMSArIDIwOw0KPj4gKwkJYnJlYWs7
DQo+PiArCWNhc2UgTkw4MDIxMV9DSEFOX1dJRFRIXzgwUDgwOg0KPj4gKwkJc3RhcnRfZnJlcV9z
ZWcxID0gY2hhbmRlZi0+Y2VudGVyX2ZyZXEyIC0gNDA7DQo+PiArCQllbmRfZnJlcV9zZWcxID0g
Y2hhbmRlZi0+Y2VudGVyX2ZyZXEyICsgNDA7DQo+PiArCQkvKiBmYWxsIHRocm91Z2ggKi8NCj4+
ICsJY2FzZSBOTDgwMjExX0NIQU5fV0lEVEhfODA6DQo+PiArCQlzdGFydF9mcmVxX3NlZzAgPSBj
aGFuZGVmLT5jZW50ZXJfZnJlcTEgLSA0MDsNCj4+ICsJCWVuZF9mcmVxX3NlZzAgPSBjaGFuZGVm
LT5jZW50ZXJfZnJlcTEgKyA0MDsNCj4+ICsJCWJyZWFrOw0KPj4gKwljYXNlIE5MODAyMTFfQ0hB
Tl9XSURUSF8xNjA6DQo+PiArCQlzdGFydF9mcmVxX3NlZzAgPSBjaGFuZGVmLT5jZW50ZXJfZnJl
cTEgLSA4MDsNCj4+ICsJCWVuZF9mcmVxX3NlZzAgPSBjaGFuZGVmLT5jZW50ZXJfZnJlcTEgKyA4
MDsNCj4+ICsJCWJyZWFrOw0KPj4gKwljYXNlIE5MODAyMTFfQ0hBTl9XSURUSF8yMF9OT0hUOg0K
Pj4gKwljYXNlIE5MODAyMTFfQ0hBTl9XSURUSF8yMDoNCj4+ICsJY2FzZSBOTDgwMjExX0NIQU5f
V0lEVEhfNToNCj4+ICsJY2FzZSBOTDgwMjExX0NIQU5fV0lEVEhfMTA6DQo+PiArCQlicmVhazsN
Cj4+ICsJfQ0KPj4gKw0KPj4gKwlpZiAoY2hhbi0+Y2VudGVyX2ZyZXEgPiBzdGFydF9mcmVxX3Nl
ZzAgJiYNCj4+ICsJICAgIGNoYW4tPmNlbnRlcl9mcmVxIDwgZW5kX2ZyZXFfc2VnMCkNCj4+ICsJ
CXJldHVybiB0cnVlOw0KPj4gKw0KPj4gKwlyZXR1cm4gY2hhbi0+Y2VudGVyX2ZyZXEgPiBzdGFy
dF9mcmVxX3NlZzEgJiYNCj4+ICsJCWNoYW4tPmNlbnRlcl9mcmVxIDwgZW5kX2ZyZXFfc2VnMTsN
Cj4+ICt9DQo+DQo+IEl0J3MgYWxzbyB3cml0dGVuIHByZXR0eSBvZGRseS4uLiBUaGUgNS8xMC8y
MCBjYXNlcyBjb3VsZCByZXR1cm4NCj4gaW1tZWRpYXRlbHksIHRoZSBzdGFydC9lbmQgY291bGQg
YmUgcmVwbGFjZWQgYnkgd2lkdGgsIGFuZCB0aGUNCj4gaW5pdGlhbGl6YXRpb25zIHdvdWxkbid0
IGJlIG5lZWRlZCBhdCBhbGwgLi4uIEkgdGhpbmsgd2UgY2FuIGRvIGJldHRlcg0KPiBoZXJlLg0K
DQpTdXJlLCBJJ2xsIGltcHJvdmUgdGhpcyBmdW5jdGlvbi4NCg0KPg0KPj4gK2Jvb2wgY2ZnODAy
MTFfNWdoel9hbnlfd2lwaHlfb3Blcl9jaGFuKHN0cnVjdCB3aXBoeSAqd2lwaHksDQo+PiArCQkJ
CSAgICAgICBzdHJ1Y3QgaWVlZTgwMjExX2NoYW5uZWwNCj4+ICpjaGFuKQ0KPg0KPiBBZ2Fpbiwg
bm90aGluZyA1IEdIeiBzcGVjaWZpYy4NCg0KT2suDQoNCj4NCj4+ICsJc3RydWN0IHdpcmVsZXNz
X2RldiAqd2RldjsNCj4+ICsNCj4+ICsJQVNTRVJUX1JUTkwoKTsNCj4+ICsNCj4+ICsJaWYgKCEo
Y2hhbi0+ZmxhZ3MgJiBJRUVFODAyMTFfQ0hBTl9SQURBUikpDQo+PiArCQlyZXR1cm4gZmFsc2U7
DQo+PiArDQo+PiArCWxpc3RfZm9yX2VhY2hfZW50cnkod2RldiwgJndpcGh5LT53ZGV2X2xpc3Qs
IGxpc3QpIHsNCj4+ICsJCWlmICghY2ZnODAyMTFfYmVhY29uaW5nX2lmYWNlX2FjdGl2ZSh3ZGV2
KSkNCj4+ICsJCQljb250aW51ZTsNCj4+ICsNCj4+ICsJCWlmIChjZmc4MDIxMV81Z2h6X3N1Yl9j
aGFuKCZ3ZGV2LT5jaGFuZGVmLCBjaGFuKSkNCj4+ICsJCQlyZXR1cm4gdHJ1ZTsNCj4+ICsJfQ0K
Pj4gKw0KPj4gKwlyZXR1cm4gZmFsc2U7DQo+PiArfQ0KPj4NCj4+ICAgc3RhdGljIGJvb2wgY2Zn
ODAyMTFfZ2V0X2NoYW5zX2Rmc19hdmFpbGFibGUoc3RydWN0IHdpcGh5ICp3aXBoeSwNCj4+ICAg
CQkJCQkgICAgIHUzMiBjZW50ZXJfZnJlcSwNCj4+IGRpZmYgLS1naXQgYS9uZXQvd2lyZWxlc3Mv
Y29yZS5oIGIvbmV0L3dpcmVsZXNzL2NvcmUuaA0KPj4gaW5kZXggNThjYTIwNi4uMzI3ZmU5NSAx
MDA2NDQNCj4+IC0tLSBhL25ldC93aXJlbGVzcy9jb3JlLmgNCj4+ICsrKyBiL25ldC93aXJlbGVz
cy9jb3JlLmgNCj4+IEBAIC00NTksNiArNDU5LDEzIEBAIHZvaWQgY2ZnODAyMTFfc2V0X2Rmc19z
dGF0ZShzdHJ1Y3Qgd2lwaHkgKndpcGh5LA0KPj4gICBjZmc4MDIxMV9jaGFuZGVmX2Rmc19jYWNf
dGltZShzdHJ1Y3Qgd2lwaHkgKndpcGh5LA0KPj4gICAJCQkgICAgICBjb25zdCBzdHJ1Y3QgY2Zn
ODAyMTFfY2hhbl9kZWYNCj4+ICpjaGFuZGVmKTsNCj4+DQo+PiArdm9pZCBjZmc4MDIxMV9zY2hl
ZF9kZnNfY2hhbl91cGRhdGUoc3RydWN0DQo+PiBjZmc4MDIxMV9yZWdpc3RlcmVkX2RldmljZSAq
cmRldik7DQo+PiArDQo+PiArYm9vbCBjZmc4MDIxMV81Z2h6X2FueV93aXBoeV9vcGVyX2NoYW4o
c3RydWN0IHdpcGh5ICp3aXBoeSwNCj4+ICsJCQkJICAgICAgIHN0cnVjdCBpZWVlODAyMTFfY2hh
bm5lbA0KPj4gKmNoYW4pOw0KPj4gKw0KPj4gK2Jvb2wgY2ZnODAyMTFfYmVhY29uaW5nX2lmYWNl
X2FjdGl2ZShzdHJ1Y3Qgd2lyZWxlc3NfZGV2ICp3ZGV2KTsNCj4+ICsNCj4+ICAgc3RhdGljIGlu
bGluZSB1bnNpZ25lZCBpbnQgZWxhcHNlZF9qaWZmaWVzX21zZWNzKHVuc2lnbmVkIGxvbmcNCj4+
IHN0YXJ0KQ0KPj4gICB7DQo+PiAgIAl1bnNpZ25lZCBsb25nIGVuZCA9IGppZmZpZXM7DQo+PiBk
aWZmIC0tZ2l0IGEvbmV0L3dpcmVsZXNzL2lic3MuYyBiL25ldC93aXJlbGVzcy9pYnNzLmMNCj4+
IGluZGV4IDM2NGY5MDAuLjEwYmYwNDAgMTAwNjQ0DQo+PiAtLS0gYS9uZXQvd2lyZWxlc3MvaWJz
cy5jDQo+PiArKysgYi9uZXQvd2lyZWxlc3MvaWJzcy5jDQo+PiBAQCAtMTkwLDYgKzE5MCw3IEBA
IHN0YXRpYyB2b2lkIF9fY2ZnODAyMTFfY2xlYXJfaWJzcyhzdHJ1Y3QNCj4+IG5ldF9kZXZpY2Ug
KmRldiwgYm9vbCBub3dleHQpDQo+PiAgIAlpZiAoIW5vd2V4dCkNCj4+ICAgCQl3ZGV2LT53ZXh0
Lmlic3Muc3NpZF9sZW4gPSAwOw0KPj4gICAjZW5kaWYNCj4+ICsJY2ZnODAyMTFfc2NoZWRfZGZz
X2NoYW5fdXBkYXRlKHJkZXYpOw0KPj4gICB9DQo+Pg0KPj4gICB2b2lkIGNmZzgwMjExX2NsZWFy
X2lic3Moc3RydWN0IG5ldF9kZXZpY2UgKmRldiwgYm9vbCBub3dleHQpDQo+PiBkaWZmIC0tZ2l0
IGEvbmV0L3dpcmVsZXNzL21lc2guYyBiL25ldC93aXJlbGVzcy9tZXNoLmMNCj4+IGluZGV4IDJk
ODUxOGEuLmVjMGIxYzIgMTAwNjQ0DQo+PiAtLS0gYS9uZXQvd2lyZWxlc3MvbWVzaC5jDQo+PiAr
KysgYi9uZXQvd2lyZWxlc3MvbWVzaC5jDQo+PiBAQCAtMjYyLDYgKzI2Miw3IEBAIGludCBfX2Nm
ZzgwMjExX2xlYXZlX21lc2goc3RydWN0DQo+PiBjZmc4MDIxMV9yZWdpc3RlcmVkX2RldmljZSAq
cmRldiwNCj4+ICAgCQl3ZGV2LT5iZWFjb25faW50ZXJ2YWwgPSAwOw0KPj4gICAJCW1lbXNldCgm
d2Rldi0+Y2hhbmRlZiwgMCwgc2l6ZW9mKHdkZXYtPmNoYW5kZWYpKTsNCj4+ICAgCQlyZGV2X3Nl
dF9xb3NfbWFwKHJkZXYsIGRldiwgTlVMTCk7DQo+PiArCQljZmc4MDIxMV9zY2hlZF9kZnNfY2hh
bl91cGRhdGUocmRldik7DQo+PiAgIAl9DQo+Pg0KPj4gICAJcmV0dXJuIGVycjsNCj4+IGRpZmYg
LS1naXQgYS9uZXQvd2lyZWxlc3MvbWxtZS5jIGIvbmV0L3dpcmVsZXNzL21sbWUuYw0KPj4gaW5k
ZXggMjJiM2Q5OS4uM2M3ZTE1NSAxMDA2NDQNCj4+IC0tLSBhL25ldC93aXJlbGVzcy9tbG1lLmMN
Cj4+ICsrKyBiL25ldC93aXJlbGVzcy9tbG1lLmMNCj4+IEBAIC03NDUsNiArNzQ1LDEyIEBAIGJv
b2wgY2ZnODAyMTFfcnhfbWdtdChzdHJ1Y3Qgd2lyZWxlc3NfZGV2ICp3ZGV2LA0KPj4gaW50IGZy
ZXEsIGludCBzaWdfbWJtLA0KPj4gICB9DQo+PiAgIEVYUE9SVF9TWU1CT0woY2ZnODAyMTFfcnhf
bWdtdCk7DQo+Pg0KPj4gK3ZvaWQgY2ZnODAyMTFfc2NoZWRfZGZzX2NoYW5fdXBkYXRlKHN0cnVj
dA0KPj4gY2ZnODAyMTFfcmVnaXN0ZXJlZF9kZXZpY2UgKnJkZXYpDQo+PiArew0KPj4gKwljYW5j
ZWxfZGVsYXllZF93b3JrKCZyZGV2LT5kZnNfdXBkYXRlX2NoYW5uZWxzX3drKTsNCj4+ICsJcXVl
dWVfZGVsYXllZF93b3JrKGNmZzgwMjExX3dxLCAmcmRldi0NCj4+PiBkZnNfdXBkYXRlX2NoYW5u
ZWxzX3drLCAwKTsNCj4+ICt9DQo+DQo+IFRoaXMgdXNlcyAwLg0KPg0KPj4gQEAgLTgyMCw5ICs4
NDQsNyBAQCB2b2lkIGNmZzgwMjExX3JhZGFyX2V2ZW50KHN0cnVjdCB3aXBoeSAqd2lwaHksDQo+
PiAgIAkgKi8NCj4+ICAgCWNmZzgwMjExX3NldF9kZnNfc3RhdGUod2lwaHksIGNoYW5kZWYsDQo+
PiBOTDgwMjExX0RGU19VTkFWQUlMQUJMRSk7DQo+Pg0KPj4gLQl0aW1lb3V0ID0gbXNlY3NfdG9f
amlmZmllcyhJRUVFODAyMTFfREZTX01JTl9OT1BfVElNRV9NUyk7DQo+PiAtCXF1ZXVlX2RlbGF5
ZWRfd29yayhjZmc4MDIxMV93cSwgJnJkZXYtDQo+Pj4gZGZzX3VwZGF0ZV9jaGFubmVsc193aywN
Cj4+IC0JCQkgICB0aW1lb3V0KTsNCj4+ICsJY2ZnODAyMTFfc2NoZWRfZGZzX2NoYW5fdXBkYXRl
KHJkZXYpOw0KPg0KPiBCdXQgdGhpcyBkaWRuJ3QgLSB3aHkgZG9lcyB0aGF0IGNoYW5nZT8NCg0K
U2luY2UgY2ZnODAyMTFfZGZzX2NoYW5uZWxzX3VwZGF0ZV93b3JrKCkgY2FuIGJlIHNjaGVkdWxl
ZCBtdWx0aXBsZSB0aW1lcyB0byBydW4gYXQNCmRpZmZlcmVudCBwb2ludCBvZiB0aW1lICgyIHNl
Y3MgLSB0byBleHBpcmUgY2FjIGZvciBub24tRVRTSSwgMzAgKiA2MCBzZWNzIC0gdG8gY2xlYXIN
Ck5PTCksIGNmZzgwMjExX3NjaGVkX2Rmc19jaGFuX3VwZGF0ZShyZGV2KSBpcyBhZGRlZCB0byBt
YWtlIHN1cmUgdGhlIHdvcmtlciBjYW4gYWxzbw0KYmUgZmlyZWQgYXQgbmVhcmVyIHRpbWUgc3Rh
bXAgd2hlbiBpdCBpcyBhbHJlYWR5IHBlbmRpbmcgdG8gcnVuIGF0IGFmdGVyIGEgcmVsYXRpdmVs
eQ0KbGF0ZXIgcG9pbnQgb2YgdGltZS4gY2ZnODAyMTFfZGZzX2NoYW5uZWxzX3VwZGF0ZV93b3Jr
KCkgdXNlcyB0aGUgdGltZSBzdGFtcCBvZiBjaGFubmVsDQpERlMgc3RhdGUgKGRmc19zdGF0ZV9l
bnRlcmVkKSB0byBzZXQgdGhlIG5leHQgREZTIHN0YXRlIGFuZC9vciByZS1zY2hlZHVsZSB0aGUg
d29ya2VyDQpsYXRlci4NCg0KPg0KPj4gK3Vuc2lnbmVkIGxvbmcgcmVndWxhdG9yeV9nZXRfcHJl
X2NhY190aW1lb3V0KHN0cnVjdCB3aXBoeSAqd2lwaHkpDQo+PiArew0KPj4gKwlpZiAoIXJlZ3Vs
YXRvcnlfcHJlX2NhY19hbGxvd2VkKHdpcGh5KSkNCj4+ICsJCXJldHVybiBSRUdfUFJFX0NBQ19F
WFBJUllfR1JBQ0VfTVM7DQo+PiArDQo+PiArCS8qDQo+PiArCSAqIFJldHVybiB0aGUgbWF4aW11
bSBwcmUtQ0FDIHRpbWVvdXQgd2hlbiBwcmUtQ0FDIGlzDQo+PiBhbGxvd2VkDQo+PiArCSAqIGlu
IHRoZSBjdXJyZW50IGRmcyBkb21haW4gKEVUU0kpLg0KPj4gKwkgKi8NCj4+ICsJcmV0dXJuIC0x
Ow0KPj4gK30NCj4NCj4gRG9uJ3QgZXZlciByZXR1cm4gLTEsIHRoYXQncyAtRVBFUk0gYW5kIG5v
dCByZWFsbHkgd2hhdCB5b3Ugd2FudA0KPiBhbnl3YXkuDQo+DQoNClN1cmUsIHNpbmNlIHRoZSBy
ZXR1cm4gdGltZSBpcyB1bnNpZ25lZCBsb25nIEkgY2hvc2UgdG8gdXNlIC0xLiBJJ2xsIHJlbW92
ZQ0KdGhpcyBmdW5jdGlvbiBhcyBtZW50aW9uZWQgaW4gYmVsb3cgY29tbWVudC4NCg0KDQo+IElu
IGZhY3QsIHRoaXMgZG9lc24ndCBldmVuIG1ha2Ugc2Vuc2UsIHNpbmNlIHRoZSBvbmx5IGNhbGxl
ciBhbHJlYWR5DQo+IGNoZWNrcyByZWd1bGF0b3J5X3ByZV9jYWNfYWxsb3dlZCgpIGJlZm9yZSBj
YWxsaW5nIHRoaXMuDQoNClN1cmUuIEkgb3JpZ2luYWxseSB0aG91Z2h0IGEgaGVscGVyIGxpa2Ug
dGhpcyB3b3VsZCBiZSB1c2VkIG11bHRpcGxlIHBsYWNlcy4NCkJ1dCBpdCBpcyBub3QgdGhlIGNh
c2Ugbm93IGFuZCBiZWluZyB1c2VkIGluIHNpbmdsZSBwbGFjZS4NCg0KDQpUaGFua3MsDQoNClZh
c2FudGg=
^ permalink raw reply
* Re: [RFC 2/3] cfg80211: Disallow moving out of operating DFS channel in non-ETSI
From: Thiagarajan, Vasanthakumar @ 2017-01-31 9:12 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1485423406.11038.6.camel@sipsolutions.net>
T24gVGh1cnNkYXkgMjYgSmFudWFyeSAyMDE3IDAzOjA2IFBNLCBKb2hhbm5lcyBCZXJnIHdyb3Rl
Og0KPg0KPj4gK3N0YXRpYyBib29sIGNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxsb3dlZChz
dHJ1Y3Qgd2lyZWxlc3NfZGV2DQo+PiAqd2RldikNCj4+ICt7DQo+PiArCWlmICghY2ZnODAyMTFf
YmVhY29uaW5nX2lmYWNlX2FjdGl2ZSh3ZGV2KSkNCj4+ICsJCXJldHVybiB0cnVlOw0KPj4gKw0K
Pj4gKwlpZiAoISh3ZGV2LT5jaGFuZGVmLmNoYW4tPmZsYWdzICYgSUVFRTgwMjExX0NIQU5fUkFE
QVIpKQ0KPj4gKwkJcmV0dXJuIHRydWU7DQo+DQo+IFRoYXQgY291bGQgdXNlIHNvbWUgbG9ja2lu
ZyBhc3NlcnRpb25zLiBNYXliZSBhbHNvIGluIHRoZQ0KPiBjZmc4MDIxMV9iZWFjb25pbmdfaWZh
Y2VfYWN0aXZlKCkgZnVuY3Rpb24geW91IGludHJvZHVjZWQgaW4gdGhlDQo+IHByZXZpb3VzIHBh
dGNoLg0KDQpPay4NCg0KPg0KPj4gKwlpZiAoIWNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxs
b3dlZCh3ZGV2KSkgew0KPj4gKwkJc3RydWN0IGllZWU4MDIxMV9jaGFubmVsICpjaGFuOw0KPj4g
Kw0KPj4gKwkJaWYgKHJlcXVlc3QtPm5fY2hhbm5lbHMgIT0gMSkgew0KPj4gKwkJCWVyciA9IC1F
QlVTWTsNCj4+ICsJCQlnb3RvIG91dF9mcmVlOw0KPj4gKwkJfQ0KPj4gKw0KPj4gKwkJY2hhbiA9
IHJlcXVlc3QtPmNoYW5uZWxzWzBdOw0KPj4gKwkJaWYgKGNoYW4tPmNlbnRlcl9mcmVxICE9IHdk
ZXYtPmNoYW5kZWYuY2hhbi0NCj4+PiBjZW50ZXJfZnJlcSkgew0KPj4gKwkJCWVyciA9IC1FQlVT
WTsNCj4+ICsJCQlnb3RvIG91dF9mcmVlOw0KPj4gKwkJfQ0KPj4gKwl9DQo+DQo+IEknbSBub3Qg
Y29udmluY2VkIHlvdSBldmVuIGhvbGQgdGhlIHJlbGV2YW50IGxvY2tzIGhlcmUsIHRob3VnaCBv
ZmYgdGhlDQo+IHRvcCBvZiBteSBoZWFkIEknbSBub3QgZXZlbiBzdXJlIHdoaWNoIGFyZSBuZWVk
ZWQuDQoNClRoYW5rcyBmb3IgcG9pbnRpbmcgaXQsIGl0IHNob3VsZCBiZSB3aXRoaW4gd2Rldl9s
b2NrKCkuDQoNCj4NCj4+ICAgCWkgPSAwOw0KPj4gICAJaWYgKG5fc3NpZHMpIHsNCj4+ICAgCQlu
bGFfZm9yX2VhY2hfbmVzdGVkKGF0dHIsIGluZm8tDQo+Pj4gYXR0cnNbTkw4MDIxMV9BVFRSX1ND
QU5fU1NJRFNdLCB0bXApIHsNCj4+IEBAIC05MDUzLDYgKzkwNzksNyBAQCBzdGF0aWMgaW50IG5s
ODAyMTFfcmVtYWluX29uX2NoYW5uZWwoc3RydWN0DQo+PiBza19idWZmICpza2IsDQo+PiAgIAlz
dHJ1Y3QgY2ZnODAyMTFfcmVnaXN0ZXJlZF9kZXZpY2UgKnJkZXYgPSBpbmZvLT51c2VyX3B0clsw
XTsNCj4+ICAgCXN0cnVjdCB3aXJlbGVzc19kZXYgKndkZXYgPSBpbmZvLT51c2VyX3B0clsxXTsN
Cj4+ICAgCXN0cnVjdCBjZmc4MDIxMV9jaGFuX2RlZiBjaGFuZGVmOw0KPj4gKwljb25zdCBzdHJ1
Y3QgY2ZnODAyMTFfY2hhbl9kZWYgKmNvbXBhdF9jaGFuZGVmOw0KPj4gICAJc3RydWN0IHNrX2J1
ZmYgKm1zZzsNCj4+ICAgCXZvaWQgKmhkcjsNCj4+ICAgCXU2NCBjb29raWU7DQo+PiBAQCAtOTA4
MSw2ICs5MTA4LDE0IEBAIHN0YXRpYyBpbnQgbmw4MDIxMV9yZW1haW5fb25fY2hhbm5lbChzdHJ1
Y3QNCj4+IHNrX2J1ZmYgKnNrYiwNCj4+ICAgCWlmIChlcnIpDQo+PiAgIAkJcmV0dXJuIGVycjsN
Cj4+DQo+PiArCWlmICghKGNmZzgwMjExX29mZl9jaGFubmVsX29wZXJfYWxsb3dlZCh3ZGV2KSB8
fA0KPj4gKwkgICAgICBjZmc4MDIxMV9jaGFuZGVmX2lkZW50aWNhbCgmd2Rldi0+Y2hhbmRlZiwg
JmNoYW5kZWYpKSkNCj4NCj4gSSdkIHByZWZlciB0byB3cml0ZSB0aGF0IGFzICFvZmZfY2hhbm5l
bCAmJiAhY2hhbmRlZl9pZGVudGljYWwsIHNlZW1zDQo+IGVhc2llciB0byB1bmRlcnN0YW5kIGhl
cmUuDQoNCk9rLg0KDQoNClRoYW5rcywNCg0KVmFzYW50aA0K
^ 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