* 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: [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: [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: [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
* 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
* [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
* 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
* [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
* [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
* 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
* 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
* 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: [PATCH] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Kalle Valo @ 2017-01-30 19:10 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, Jurij Smakov, Stable
In-Reply-To: <20170130174057.7681-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> 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.
>
> 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>
This patch is written by Jurij, right? So then there should be a From
line in the commit log making him the author. An example here from Luca
where Sara is the author:
https://patchwork.kernel.org/patch/9544763/
> Cc: Stable <stable@vger.kernel.org>
You could add "# 4.9" here to make Greg's life easier. And no need to CC
stable in the email headers, having it in the commit log is enough.
> 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.
Yeah, this looks like to be valid for 4.10 still. But please mention in
the commit log about the bug symptoms (reliability problems etc).
--
Kalle Valo
^ permalink raw reply
* Re: Searching new home for ath[59]k-devel mailing lists
From: Michael Renzmann @ 2017-01-30 18:40 UTC (permalink / raw)
To: Kalle Valo; +Cc: linux-wireless
In-Reply-To: <877f5g7lwd.fsf@kamboji.qca.qualcomm.com>
Kalle Valo wrote:
>>> Are you planning to update the MAINTAINERS file or should I?
>> It would be great if you could take care of that.
> Ok, I'll send a patch.
Thanks!
>> [1] https://wireless.wiki.kernel.org/en/users/Drivers/ath9k
> I updated that now.
I've applied similar changes to the ath9k_htc and ath5k pages.
Bye, Mike
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Pali Rohár @ 2017-01-30 18:03 UTC (permalink / raw)
To: Tony Lindgren
Cc: Pavel Machek, Kalle Valo, 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>
[-- Attachment #1: Type: Text/Plain, Size: 1925 bytes --]
On Monday 30 January 2017 18:53:09 Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> > On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > > Pali Rohár <pali.rohar@gmail.com> writes:
> > > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > > >> > 2) It was already tested that example NVS data can be used
> > > >> > for N900 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.
> > > >>
> > > >> 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.
> > >
> > > All two of them? :)
> >
> > 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.
wl12xx/wl18xx have probably exactly same problem as wl1251.
> Why don't we just set a custom compatible property for n900 that then
> picks up some other nvs file instead of the default?
But that still does not solve this problem correctly. Every n900 device
have different NVS file. If we allow to load firmware directly from VFS
without userspace helper we would see again same problem.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 2/6] wl1251: Use request_firmware_prefer_user() for loading NVS calibration data
From: Tony Lindgren @ 2017-01-30 17:53 UTC (permalink / raw)
To: Pavel Machek
Cc: Kalle Valo, 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: <20170127194012.GE20571@amd>
* Pavel Machek <pavel@ucw.cz> [170127 11:41]:
> On Fri 2017-01-27 17:23:07, Kalle Valo wrote:
> > Pali Rohár <pali.rohar@gmail.com> writes:
> >
> > > On Friday 27 January 2017 14:26:22 Kalle Valo wrote:
> > >> Pali Rohár <pali.rohar@gmail.com> writes:
> > >>
> > >> > 2) It was already tested that example NVS data can be used for N900 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.
> > >>
> > >> 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.
> >
> > All two of them? :)
>
> 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?
Regards,
Tony
^ permalink raw reply
* [PATCH] rtlwifi: rtl8192ce: Fix loading of incorrect firmware
From: Larry Finger @ 2017-01-30 17:40 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Larry Finger, Jurij Smakov, Stable
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.
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>
---
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
* Re: Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Dave Taht @ 2017-01-30 16:49 UTC (permalink / raw)
To: Toke Høiland-Jørgensen; +Cc: Klaus Kinski, linux-wireless
In-Reply-To: <87lgtsjz6o.fsf@toke.dk>
On Mon, Jan 30, 2017 at 8:17 AM, Toke H=C3=B8iland-J=C3=B8rgensen <toke@tok=
e.dk> wrote:
> Klaus Kinski <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> writes:
>
>> Hello all,
>>
>> this is a blast from the past, but something that still bothers me.
>> I have two systems with Atheros/QCA cards:
>>
>> System A:
>> OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>>
>> WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>>
>> System B:
>> OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from bac=
kports-4.2
>>
>> WLAN card: AR9280 (Compex WLE200NX)
>>
>> While doing the performance measurements both systems are connected to a=
reference system
>>
>> with a HF cable, so there should be no outside influences.
>>
>> Both systems are running in 802.11a mode on channel 40.
>> The following table shows 802.11 data packets sent from system A and B g=
enerated by
>>
>> iperf in UDP mode over a 2s interval:
>
> What version of iperf, and configured to which rate? Some versions of
> iperf will send its traffic in very large bursts (see
> http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=3D1)
> which could cause the queue inside ath9k to overflow (it is only 123
> packets pre-4.10).
>
> Did you try the latest mac80211/ath9k from 4.10? The queueing structure
> changed dramatically, which would impact this, at least if it's a queue
> overflow problem...
Packet captures would be helpful. Aircaps, if possible, also.
> -Toke
--=20
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
http://blog.cerowrt.org
^ permalink raw reply
* 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 16:17 UTC (permalink / raw)
To: Klaus Kinski; +Cc: linux-wireless
In-Reply-To: <HE1PR0701MB1803E46BC8EC38D682361523FC4B0@HE1PR0701MB1803.eurprd07.prod.outlook.com>
Klaus Kinski <jpo234-1ViLX0X+lBKELgA04lAiVw@public.gmane.org> writes:
> Hello all,
>
> this is a blast from the past, but something that still bothers me.
> I have two systems with Atheros/QCA cards:
>
> System A:
> OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
>
> WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
>
> System B:
> OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from backports-4.2
>
> WLAN card: AR9280 (Compex WLE200NX)
>
> While doing the performance measurements both systems are connected to a reference system
>
> with a HF cable, so there should be no outside influences.
>
> Both systems are running in 802.11a mode on channel 40.
> The following table shows 802.11 data packets sent from system A and B generated by
>
> iperf in UDP mode over a 2s interval:
What version of iperf, and configured to which rate? Some versions of
iperf will send its traffic in very large bursts (see
http://burntchrome.blogspot.se/2016/09/iperf3-and-microbursts.html?m=1)
which could cause the queue inside ath9k to overflow (it is only 123
packets pre-4.10).
Did you try the latest mac80211/ath9k from 4.10? The queueing structure
changed dramatically, which would impact this, at least if it's a queue
overflow problem...
-Toke
^ permalink raw reply
* Packet throughput (and those iperf data rate) with mac80211/ath9k is 20% worse than net80211/madwifi
From: Klaus Kinski @ 2017-01-30 15:57 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
Hello all,
this is a blast from the past, but something that still bothers me.
I have two systems with Atheros/QCA cards:
System A:
OS and driver: Linux 3.18.36 with last Madwifi/sample code from trunk
WLAN card: AR5413 (Senao EMP-8602 PLUS-S)
System B:
OS and driver: Linux 3.18.36 with mac80211/minstrel and ath9k from backports-4.2
WLAN card: AR9280 (Compex WLE200NX)
While doing the performance measurements both systems are connected to a reference system
with a HF cable, so there should be no outside influences.
Both systems are running in 802.11a mode on channel 40.
The following table shows 802.11 data packets sent from system A and B generated by
iperf in UDP mode over a 2s interval:
Data rate madwifi %of total ath9k minstrel %of total
6.0 855 2,31 37 0,12
9.0 0 0,00 22 0,07
12.0 0 0,00 23 0,07
18.0 0 0,00 20 0,06
24.0 9 0,02 21 0,07
36.0 855 2,31 20 0,06
48.0 856 2,31 24 0,08
54.0 34413 93,04 31566 99,47
total 36988 100,00 31733 100,00
It shows how many packets where sent at what data rate and the percentage of these packets
from the total. Both stacks are sending most packets with 54Mbit/s (93% and 99%).
Overall Madwifi sends 36988 (= 100%) data packets whereas mac80211 only sends 31733 (= 85%) data packets.
Does anybody know where this difference comes from? It's not the CPU; both systems
have plenty enough for the task. I'm pretty sure that the reason is in the stack,
probably mac80211.
I have asked basically the same question almost 6 years ago (see http://narkive.com/F8xI8bUp.1 ).
An interesting proposal at that time came from Adrian Chadd in http://narkive.com/F8xI8bUp.15:
does madwifi have that net80211 "aggressive mode" by default, where it
overrides the best-effort WME queue parameters to allow for bursting?
I could not find a mac80211 option to control this "aggressive mode". Is there one? Or a patch
to test it out?
Thanks in advance
Joerg
^ permalink raw reply
* [PATCH 1/2] brcmfmac: check brcmf_bus_get_memdump result for error
From: Rafał Miłecki @ 2017-01-30 15:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
From: Rafał Miłecki <rafal@milecki.pl>
This method may be unsupported (see: USB bus) or may just fail (see:
SDIO bus).
While at it rework logic in brcmf_sdio_bus_get_memdump function to avoid
too many conditional code nesting levels.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
.../wireless/broadcom/brcm80211/brcmfmac/debug.c | 23 +++++++++++++++-------
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index e64557c35553..6f8a4b074c31 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -32,16 +32,25 @@ static int brcmf_debug_create_memdump(struct brcmf_bus *bus, const void *data,
{
void *dump;
size_t ramsize;
+ int err;
ramsize = brcmf_bus_get_ramsize(bus);
- if (ramsize) {
- dump = vzalloc(len + ramsize);
- if (!dump)
- return -ENOMEM;
- memcpy(dump, data, len);
- brcmf_bus_get_memdump(bus, dump + len, ramsize);
- dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
+ if (!ramsize)
+ return -ENOTSUPP;
+
+ dump = vzalloc(len + ramsize);
+ if (!dump)
+ return -ENOMEM;
+
+ memcpy(dump, data, len);
+ err = brcmf_bus_get_memdump(bus, dump + len, ramsize);
+ if (err) {
+ vfree(dump);
+ return err;
}
+
+ dev_coredumpv(bus->dev, dump, len + ramsize, GFP_KERNEL);
+
return 0;
}
--
2.11.0
^ permalink raw reply related
* [PATCH 2/2] brcmfmac: be more verbose when PSM's watchdog fires
From: Rafał Miłecki @ 2017-01-30 15:09 UTC (permalink / raw)
To: Kalle Valo
Cc: Arend van Spriel, Franky Lin, Hante Meuleman,
Pieter-Paul Giesberts, Franky Lin, linux-wireless,
brcm80211-dev-list.pdl, Rafał Miłecki
In-Reply-To: <20170130150952.7133-1-zajec5@gmail.com>
From: Rafał Miłecki <rafal@milecki.pl>
It's important to inform user so he knows things went wrong. He may also
want to get memory dump for further debugging purposes.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
index 6f8a4b074c31..f4644cf371c7 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/debug.c
@@ -58,10 +58,18 @@ static int brcmf_debug_psm_watchdog_notify(struct brcmf_if *ifp,
const struct brcmf_event_msg *evtmsg,
void *data)
{
+ int err;
+
brcmf_dbg(TRACE, "enter: bsscfgidx=%d\n", ifp->bsscfgidx);
- return brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
- evtmsg->datalen);
+ brcmf_err("PSM's watchdog has fired!\n");
+
+ err = brcmf_debug_create_memdump(ifp->drvr->bus_if, data,
+ evtmsg->datalen);
+ if (err)
+ brcmf_err("Failed to get memory dump, %d\n", err);
+
+ return err;
}
void brcmf_debugfs_init(void)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] wlcore: let AP support allmulticast for MDNS. It can be enabled by bringing up the interface with ip command with the argument allmulticast on
From: Kalle Valo @ 2017-01-30 14:24 UTC (permalink / raw)
To: Iain Hunter; +Cc: linux-wireless, Iain Hunter
In-Reply-To: <20170130125417.6188-1-i-hunter1@ti.com>
Iain Hunter <drhunter95@gmail.com> writes:
> Let 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>
I see your patch now in patchwork (twice actually):
https://patchwork.kernel.org/patch/9545223/
But there's a problem with the title, you just copied the commit log as
the title. The format should be something like this (also please word
wrap the commit log):
----------------------------------------------------------------------
wlcore: disable firmware multicast filter in AP mode
Let 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: Ed Example <ed@example.org>
----------------------------------------------------------------------
You can see examples from patchwork, like this iwlwifi patch:
https://patchwork.kernel.org/patch/9544763/
--
Kalle Valo
^ permalink raw reply
* [PATCH] wlcore: disable multicast filter in AP mode
From: Iain Hunter @ 2017-01-30 14:49 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, Iain Hunter
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>
---
drivers/net/wireless/ti/wlcore/main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..1ab0561ab13 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -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);
+
+ }
+
}
/*
--
2.11.0
^ permalink raw reply related
* [PATCH] wlcore: let AP support allmulticast for MDNS. It can be enabled by bringing up the interface with ip command with the argument allmulticast on
From: Iain Hunter @ 2017-01-30 12:37 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Iain Hunter
Let AP support allmulticast for MDNS.
It can be enabled by bringing up the interface with ip command and the argument allmulticast on
Signed-off-by: Iain Hunter <i-hunter1@ti.com>
---
drivers/net/wireless/ti/wlcore/main.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/net/wireless/ti/wlcore/main.c b/drivers/net/wireless/ti/wlcore/main.c
index 3241e9eba73..1ab0561ab13 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -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);
+
+ }
+
}
/*
--
2.11.0
^ permalink raw reply related
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