Re: [PATCH] rtlwifi: rtl8723be: disable FW control power save
Hi all, I have some new findings that doesn't need to modify the parameter. I'm still testing the new driver and will submit the patch later. Best regards, AceLan Kao. 2015-08-11 9:45 GMT+08:00 Kai Heng Feng : > Hi James, > > I think the newer firmware in conjunction with "fwlps=0" > should work fine in my (limited) testing. > > Thanks, > Kai-Heng Feng > > > On Mon, Aug 10, 2015 at 8:01 PM, James Cameron wrote: >> On Mon, Aug 10, 2015 at 06:47:05PM +0800, Kai Heng Feng wrote: >>> Do you use Ubuntu Trusty (14.04)? >> >> Yes, that's what I'm using. >> >>> The rtl8723be firmware is not up-to-date in Trusty's linux-firmware. >>> You can grab the newer one from the upstream linux-firmware. >> >> Thanks, but both seem to work fine (apart from the issue in this >> thread), and I don't have a list of what has changed. >> >> -- >> James Cameron >> http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: rtl8723be: disable FW control power save
Sorry, no luck, this issue happens from time to time, and always happens when playing youtube video within a day. We need Realtek guys give us some hints, I can do some tests for it. 2015-08-11 21:17 GMT-04:00 AceLan Kao : > Hi all, > > I have some new findings that doesn't need to modify the parameter. > I'm still testing the new driver and will submit the patch later. > > Best regards, > AceLan Kao. > > 2015-08-11 9:45 GMT+08:00 Kai Heng Feng : >> Hi James, >> >> I think the newer firmware in conjunction with "fwlps=0" >> should work fine in my (limited) testing. >> >> Thanks, >> Kai-Heng Feng >> >> >> On Mon, Aug 10, 2015 at 8:01 PM, James Cameron wrote: >>> On Mon, Aug 10, 2015 at 06:47:05PM +0800, Kai Heng Feng wrote: >>>> Do you use Ubuntu Trusty (14.04)? >>> >>> Yes, that's what I'm using. >>> >>>> The rtl8723be firmware is not up-to-date in Trusty's linux-firmware. >>>> You can grab the newer one from the upstream linux-firmware. >>> >>> Thanks, but both seem to work fine (apart from the issue in this >>> thread), and I don't have a list of what has changed. >>> >>> -- >>> James Cameron >>> http://quozl.linux.org.au/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rtlwifi: rtl8723be: disable FW control power save
There are many rtl8723be wifi unstable issues that wifi lost connection
after working for a while. The wifi signal and status it's show connected
also ifconfig have IP but can not connect to internet and filed to ping 8.8.8.8
The problem should result from the power saving controlled by firmware.
I'd suggest to disable it by default and re-enable it after firmware fixes
this issue.
BTW. the firmware I tested from linux-firmware git tree is
rtlwifi/rtl8723befw.bin
be225d6 Update firmware for rtl8723be
Signed-off-by: AceLan Kao
---
drivers/net/wireless/rtlwifi/rtl8723be/sw.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
index 1017f02..02fe2cc 100644
--- a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
+++ b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
@@ -266,7 +266,7 @@ static struct rtl_mod_params rtl8723be_mod_params = {
.sw_crypto = false,
.inactiveps = true,
.swctrl_lps = false,
- .fwctrl_lps = true,
+ .fwctrl_lps = false,
};
static struct rtl_hal_cfg rtl8723be_hal_cfg = {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtlwifi: rtl8723be: disable FW control power save
Hi Larry,
I tried using "ips=0" today and found it's not working.
I ping 8.8.8.8 and got below message within one hour.
ping: sendmsg: No buffer space available
Best regards,
AceLan Kao.
2015-08-08 0:33 GMT+08:00 Larry Finger :
> On 08/06/2015 10:11 PM, AceLan Kao wrote:
>>
>> There are many rtl8723be wifi unstable issues that wifi lost connection
>> after working for a while. The wifi signal and status it's show connected
>> also ifconfig have IP but can not connect to internet and filed to ping
>> 8.8.8.8
>> The problem should result from the power saving controlled by firmware.
>> I'd suggest to disable it by default and re-enable it after firmware fixes
>> this issue.
>>
>> BTW. the firmware I tested from linux-firmware git tree is
>> rtlwifi/rtl8723befw.bin
>> be225d6 Update firmware for rtl8723be
>>
>> Signed-off-by: AceLan Kao
>
>
> NACK for this patch. If you were to make this change, you should also change
> the text in the MODULE_PARM_DESC() for this parameter. It shows a hard-coded
> default.
>
> I am not sure this is a firmware problem as some users report that they need
> to run with the "ips=0" option, not with "fwlps=0" as your patch would
> force. Conversely, the driver works fine as is with other AP/environment
> combinations.
>
> The Realtek engineer has told me that he is aware of problems with the
> dynamic management for all the drivers, and that they are working on major
> replacements; however, there is no timetable for the new code.
>
> If we make a change in the default power settings, I would prefer changing
> inactiveps and its MODULE_PARM_DESC() text; however, that would have a
> negative impact on power usage on the host.
>
> I have BCc'd the Realtek engineer and I hope to get his comments on this
> change.
>
> Larry
>
>> ---
>> drivers/net/wireless/rtlwifi/rtl8723be/sw.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
>> b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
>> index 1017f02..02fe2cc 100644
>> --- a/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
>> +++ b/drivers/net/wireless/rtlwifi/rtl8723be/sw.c
>> @@ -266,7 +266,7 @@ static struct rtl_mod_params rtl8723be_mod_params = {
>> .sw_crypto = false,
>> .inactiveps = true,
>> .swctrl_lps = false,
>> - .fwctrl_lps = true,
>> + .fwctrl_lps = false,
>> };
>>
>> static struct rtl_hal_cfg rtl8723be_hal_cfg = {
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Poor performance on 5G network with Intel 9000 series cards
Hi all, We found that Intel 9000 series wifi cards have tx performance issue on 5G network. Here are the test result. Client(10.101.46.25) is the platform with 9260 wifi card on 5G network, and server(10.101.46.219) is another machine with ethernet network. kernel v4.15-rc5 with firmware API 33 acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er Server listening on TCP port 5001 with pid 2248 Read buffer size: 1.44 KByte TCP window size: 85.3 KByte (default) Client connecting to 10.101.46.219, TCP port 5001 with pid 2248 Write buffer size: 128 KByte TCP window size: 85.0 KByte (default) [ 5] local 10.101.46.25 port 54308 connected with 10.101.46.219 port 5001 [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT [ 5] 0.00-11.06 sec 7.75 MBytes 5.88 Mbits/sec 1/0 77 7K/165143 us [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38816 [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) [ 4] 0.00-10.31 sec 77.0 MBytes 62.7 Mbits/sec 55729 49:23:176:59:1140:294:168:53820 With firmware API 34, no luck acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er Server listening on TCP port 5001 with pid 2138 Read buffer size: 1.44 KByte TCP window size: 85.3 KByte (default) Client connecting to 10.101.46.219, TCP port 5001 with pid 2138 Write buffer size: 128 KByte TCP window size: 187 KByte (default) [ 5] local 10.101.46.25 port 43560 connected with 10.101.46.219 port 5001 [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT [ 5] 0.00-10.01 sec 896 KBytes 733 Kbits/sec 1/0 58 7K/140474 us [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38844 [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) [ 4] 0.00-10.11 sec 79.8 MBytes 66.2 Mbits/sec 57744 37:6:191:52:1236:413:143:55666 Any ideas? Best regards, AceLan Kao.
Re: Poor performance on 5G network with Intel 9000 series cards
Hi all, Forgot to append the device info, here it is. 02:00.0 Network controller [0280]: Intel Corporation Device [8086:2526] (rev 29) Subsystem: Intel Corporation Device [8086:4010] Best regards, AceLan Kao. 2018-01-08 14:25 GMT+08:00 AceLan Kao : > Hi all, > > We found that Intel 9000 series wifi cards have tx performance issue > on 5G network. > Here are the test result. > > Client(10.101.46.25) is the platform with 9260 wifi card on 5G > network, and server(10.101.46.219) is another machine with ethernet > network. > > kernel v4.15-rc5 with firmware API 33 > > acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er > > Server listening on TCP port 5001 with pid 2248 > Read buffer size: 1.44 KByte > TCP window size: 85.3 KByte (default) > > > Client connecting to 10.101.46.219, TCP port 5001 with pid 2248 > Write buffer size: 128 KByte > TCP window size: 85.0 KByte (default) > > [ 5] local 10.101.46.25 port 54308 connected with 10.101.46.219 port 5001 > [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT > [ 5] 0.00-11.06 sec 7.75 MBytes 5.88 Mbits/sec 1/0 77 7K/165143 us > [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38816 > [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) > [ 4] 0.00-10.31 sec 77.0 MBytes 62.7 Mbits/sec 55729 > 49:23:176:59:1140:294:168:53820 > > > > With firmware API 34, no luck > > acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er > > Server listening on TCP port 5001 with pid 2138 > Read buffer size: 1.44 KByte > TCP window size: 85.3 KByte (default) > > > Client connecting to 10.101.46.219, TCP port 5001 with pid 2138 > Write buffer size: 128 KByte > TCP window size: 187 KByte (default) > > [ 5] local 10.101.46.25 port 43560 connected with 10.101.46.219 port 5001 > [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT > [ 5] 0.00-10.01 sec 896 KBytes 733 Kbits/sec 1/0 58 7K/140474 us > [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38844 > [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) > [ 4] 0.00-10.11 sec 79.8 MBytes 66.2 Mbits/sec 57744 > 37:6:191:52:1236:413:143:55666 > > Any ideas? > > Best regards, > AceLan Kao.
Re: [v2] ath9k: add MSI support
Hi Kalle, I'm happy to see Russel's patch can be merged, and I'm willing to rebase and merge those quirks into one commit and submit it again. Although the solution is not perfect, but it's nice to have. Thanks. Best regards, AceLan Kao. 2018-01-09 7:07 GMT+08:00 Daniel Drake : > On Mon, Jan 8, 2018 at 6:24 AM, Kalle Valo wrote: >> (Adding AceLan) >> >> Daniel Drake writes: >> >>> On Wed, Nov 15, 2017 at 7:38 AM, Daniel Drake wrote: >>>> On Tue, Nov 14, 2017 at 8:15 PM, Kalle Valo wrote: >>>>>> Can't be fixed in firmware, but it would be good to have confirmation >>>>>> of the hardware behavivour, and maybe some other solution is possible? >>>>>> Are you following this up within Qualcomm? >>>>> >>>>> No time to do that right now, sorry. >>>> >>>> I got several autoresponders from people on this thread from Qualcomm >>>> Taiwan. Would it be useful for us to drop off a sample of the affected >>>> product at your Taipei or Hsinchu office so that you can investigate >>>> further? >>> >>> Ping - how can we collaborate on this? >> >> Are you asking me? While looking at my todo list for this year I doubt I >> can find time to help with the MSI implementation or bugfixing. > > So far you are the only Qualcomm person to reply to the many mails I > have written on this topic, so I appreciate the response. I have sunk > many hours into this unfortunate situation so I'd really appreciate if > you could point me to someone at Qualcomm who can provide a response. > I am willing to continue doing the hard work, but I do need some > Qualcomm help in getting past brick walls. > >> But my plan is that first I would apply Russel's patch which makes it >> possible to enable MSI with a module parameter: >> >> https://patchwork.kernel.org/patch/249/ > > This isn't enough to fix many of the systems that are affected by this > issue. You add the parameter, enable it, and MSI support totally fails > to deliver any interrupts. Pasting again from earlier: > > I have tested your patch on Acer Aspire ES1-432. It does not work - I > still can't connect to wifi. > /proc/interrupts shows that no MSI interrupts are delivered, the counters are > 0. > > lspci -vv shows: > Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+ > Address: fee0f00c Data: 4142 > Masking: 000e Pending: > > So MSI is enabled and the vector number is 0x42 (decimal 66). > However my kernel log is now totally spammed with: > do_IRQ: 0.64 No irq handler for vector > > My assumption here is that the ath9k hardware implementation of MSI is > buggy, and it is therefore corrupting the MSI vector number by zeroing > out the lower 2 bits (e.g. 66 -> 64). > > It would be very useful if Qualcomm could confirm if this behaviour is > really true. > > For more info please see: >https://marc.info/?l=linux-pci&m=150238260826803&w=2 >https://marc.info/?t=15063128321&r=1&w=2 >https://marc.info/?l=linux-pci&m=150831581725596&w=2 > > Thanks, > Daniel
[PATCH] ath9k: add a quirk to set use_msi automatically
Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
for WLAN device. So adding a quirk to list those machines and set
use_msi automatically.
Adding the following platforms to the quirk.
Dell Inspiron 24-3460
Dell Inspiron 3472
Dell Inspiron 14-3473
Dell Vostro 3262
Dell Vostro 15-3572
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 53 +++
1 file changed, 53 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index 43adead..e479fae 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include "ath9k.h"
@@ -96,6 +97,56 @@ static const struct ieee80211_tpt_blink ath9k_tpt_blink[] = {
};
#endif
+static int __init set_use_msi(const struct dmi_system_id *dmi)
+{
+ ath9k_use_msi = 1;
+ return 1;
+}
+
+static const struct dmi_system_id ath9k_quirks[] __initconst = {
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 24-3460",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
+ },
+ },
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 3262",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3262"),
+ },
+ },
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 3472",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
+ },
+ },
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 15-3572",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
+ },
+ },
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 14-3473",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14-3473"),
+ },
+ },
+ {}
+};
+
static void ath9k_deinit_softc(struct ath_softc *sc);
static void ath9k_op_ps_wakeup(struct ath_common *common)
@@ -1104,6 +1155,8 @@ static int __init ath9k_init(void)
goto err_pci_exit;
}
+ dmi_check_system(ath9k_quirks);
+
return 0;
err_pci_exit:
--
2.7.4
Re: Poor performance on 5G network with Intel 9000 series cards
Yes, I'll update my issue there. Thanks. 2018-01-10 0:42 GMT+08:00 Emmanuel Grumbach : > On Mon, Jan 8, 2018 at 8:34 AM, AceLan Kao wrote: >> >> Hi all, >> >> Forgot to append the device info, here it is. >> >> 02:00.0 Network controller [0280]: Intel Corporation Device [8086:2526] (rev >> 29) >> Subsystem: Intel Corporation Device [8086:4010] >> >> Best regards, >> AceLan Kao. >> >> 2018-01-08 14:25 GMT+08:00 AceLan Kao : >> > Hi all, >> > >> > We found that Intel 9000 series wifi cards have tx performance issue >> > on 5G network. >> > Here are the test result. >> > >> > Client(10.101.46.25) is the platform with 9260 wifi card on 5G >> > network, and server(10.101.46.219) is another machine with ethernet >> > network. >> > > > I think this matches this bug: > https://bugzilla.kernel.org/show_bug.cgi?id=198351 > >> > kernel v4.15-rc5 with firmware API 33 >> > >> > acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er >> > >> > Server listening on TCP port 5001 with pid 2248 >> > Read buffer size: 1.44 KByte >> > TCP window size: 85.3 KByte (default) >> > >> > >> > Client connecting to 10.101.46.219, TCP port 5001 with pid 2248 >> > Write buffer size: 128 KByte >> > TCP window size: 85.0 KByte (default) >> > >> > [ 5] local 10.101.46.25 port 54308 connected with 10.101.46.219 port 5001 >> > [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT >> > [ 5] 0.00-11.06 sec 7.75 MBytes 5.88 Mbits/sec 1/0 77 7K/165143 us >> > [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38816 >> > [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) >> > [ 4] 0.00-10.31 sec 77.0 MBytes 62.7 Mbits/sec 55729 >> > 49:23:176:59:1140:294:168:53820 >> > >> > >> > >> > With firmware API 34, no luck >> > >> > acelan@u-Kabylake-Client-platform ~ % iperf -c 10.101.46.219 -er >> > >> > Server listening on TCP port 5001 with pid 2138 >> > Read buffer size: 1.44 KByte >> > TCP window size: 85.3 KByte (default) >> > >> > >> > Client connecting to 10.101.46.219, TCP port 5001 with pid 2138 >> > Write buffer size: 128 KByte >> > TCP window size: 187 KByte (default) >> > -------- >> > [ 5] local 10.101.46.25 port 43560 connected with 10.101.46.219 port 5001 >> > [ ID] Interval Transfer Bandwidth Write/Err Rtry Cwnd/RTT >> > [ 5] 0.00-10.01 sec 896 KBytes 733 Kbits/sec 1/0 58 7K/140474 us >> > [ 4] local 10.101.46.25 port 5001 connected with 10.101.46.219 port 38844 >> > [ ID] Interval Transfer Bandwidth Reads Dist(bin=0.2K) >> > [ 4] 0.00-10.11 sec 79.8 MBytes 66.2 Mbits/sec 57744 >> > 37:6:191:52:1236:413:143:55666 >> > >> > Any ideas? >> > >> > Best regards, >> > AceLan Kao.
[PATCH 4/6] ath9k: set use_msi=1 on Dell Inspiron 3472
BIOS on Dell Inspiron 3472 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index 6b5d53c..fce9ac7 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -120,6 +120,14 @@ static const struct dmi_system_id ath9k_quirks[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3262"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 3472",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
+ },
+ },
{}
};
--
2.7.4
[PATCH 3/6] ath9k: set use_msi=1 on Dell Vostro 3262
BIOS on Dell Vostro 3262 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index 1667949..6b5d53c 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -112,6 +112,14 @@ static const struct dmi_system_id ath9k_quirks[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 3262",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 3262"),
+ },
+ },
{}
};
--
2.7.4
[PATCH 5/6] ath9k: set use_msi=1 on Dell Vostro 15-3572
BIOS on Dell Vostro 15-3572 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index fce9ac7..e1198e1 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -128,6 +128,14 @@ static const struct dmi_system_id ath9k_quirks[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 3472"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Vostro 15-3572",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
+ },
+ },
{}
};
--
2.7.4
[PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI
for WLAN device. So adding a quirk to list those machines and set
use_msi automatically.
Adding Dell Inspiron 24-3460 to the quirk.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index b6b7a35..1667949 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include
#include "ath9k.h"
@@ -96,6 +97,24 @@ static const struct ieee80211_tpt_blink ath9k_tpt_blink[] = {
};
#endif
+static int __init set_use_msi(const struct dmi_system_id *dmi)
+{
+ ath9k_use_msi = 1;
+ return 1;
+}
+
+static const struct dmi_system_id ath9k_quirks[] __initconst = {
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 24-3460",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 24-3460"),
+ },
+ },
+ {}
+};
+
static void ath9k_deinit_softc(struct ath_softc *sc);
static void ath9k_op_ps_wakeup(struct ath_common *common)
@@ -1104,6 +1123,8 @@ static int __init ath9k_init(void)
goto err_pci_exit;
}
+ dmi_check_system(ath9k_quirks);
+
return 0;
err_pci_exit:
--
2.7.4
[PATCH 6/6] ath9k: set use_msi=1 on Dell Inspiron 14-3473
BIOS on Dell Inspiron 14-3473 blocks legacy interrupts (INTx),
and only allows MSI for WLAN device.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/init.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index e1198e1..d03e1fc 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -136,6 +136,14 @@ static const struct dmi_system_id ath9k_quirks[]
__initconst = {
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15-3572"),
},
},
+ {
+ .callback = set_use_msi,
+ .ident = "Dell Inspiron 14-3473",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron 14-3473"),
+ },
+ },
{}
};
--
2.7.4
[PATCH 1/6] ath9k: add MSI support and use_msi parameter
Adding MSI support for ath9k devices.
This patch is originally from Qualcomm, but they have no intention of
submitting and maintaining ath9k driver now.
The credit should go to Qualcomm.
Signed-off-by: AceLan Kao
---
drivers/net/wireless/ath/ath9k/hw.c | 33 ++--
drivers/net/wireless/ath/ath9k/hw.h | 3 +++
drivers/net/wireless/ath/ath9k/init.c | 4 +++
drivers/net/wireless/ath/ath9k/mac.c | 47 +++
drivers/net/wireless/ath/ath9k/pci.c | 21 +++-
drivers/net/wireless/ath/ath9k/reg.h | 15 +++
6 files changed, 115 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 8c5c2dd..cd0f023 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -922,6 +922,7 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
AR_IMR_RXERR |
AR_IMR_RXORN |
AR_IMR_BCNMISC;
+ u32 msi_cfg = 0;
if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
AR_SREV_9561(ah))
@@ -929,22 +930,30 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw
*ah,
if (AR_SREV_9300_20_OR_LATER(ah)) {
imr_reg |= AR_IMR_RXOK_HP;
- if (ah->config.rx_intr_mitigation)
+ if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+ } else {
imr_reg |= AR_IMR_RXOK_LP;
-
+ msi_cfg |= AR_INTCFG_MSI_RXOK;
+ }
} else {
- if (ah->config.rx_intr_mitigation)
+ if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+ } else {
imr_reg |= AR_IMR_RXOK;
+ msi_cfg |= AR_INTCFG_MSI_RXOK;
+ }
}
- if (ah->config.tx_intr_mitigation)
+ if (ah->config.tx_intr_mitigation) {
imr_reg |= AR_IMR_TXINTM | AR_IMR_TXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_TXINTM | AR_INTCFG_MSI_TXMINTR;
+ } else {
imr_reg |= AR_IMR_TXOK;
+ msi_cfg |= AR_INTCFG_MSI_TXOK;
+ }
ENABLE_REGWRITE_BUFFER(ah);
@@ -952,6 +961,16 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw
*ah,
ah->imrs2_reg |= AR_IMR_S2_GTT;
REG_WRITE(ah, AR_IMR_S2, ah->imrs2_reg);
+ if (ah->msi_enabled) {
+ ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
+ ah->msi_reg |= AR_PCIE_MSI_HW_DBI_WR_EN;
+ ah->msi_reg &= AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
+ REG_WRITE(ah, AR_INTCFG, msi_cfg);
+ ath_dbg(ath9k_hw_common(ah), ANY,
+ "value of AR_INTCFG=0x%X, msi_cfg=0x%X\n",
+ REG_READ(ah, AR_INTCFG), msi_cfg);
+ }
+
if (!AR_SREV_9100(ah)) {
REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0x);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
index 4ac7082..0d6c07c7 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -977,6 +977,9 @@ struct ath_hw {
bool tpc_enabled;
u8 tx_power[Ar5416RateSize];
u8 tx_power_stbc[Ar5416RateSize];
+ bool msi_enabled;
+ u32 msi_mask;
+ u32 msi_reg;
};
struct ath_bus_ops {
diff --git a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
index bb79360..b6b7a35 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(use_chanctx, "Enable channel context for
concurrency");
#endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
+int ath9k_use_msi;
+module_param_named(use_msi, ath9k_use_msi, int, 0444);
+MODULE_PARM_DESC(use_msi, "Use MSI instead of INTx if possible");
+
bool is_ath9k_unloaded;
#ifdef CONFIG_MAC80211_LEDS
diff --git a/drivers/net/wireless/ath/ath9k/mac.c
b/drivers/net/wireless/ath/ath9k/mac.c
index 77c94f9..58d02c1 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -832,6 +832,43 @@ static void __ath9k_hw_enable_interrupts(struct ath_hw *ah)
}
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
+
+ if (ah->msi_enabled) {
+ u32 _msi_reg = 0;
+ u32 i = 0;
+ u32 msi_pend_addr_mask = A
Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Ath9k is an old driver for old chips, and they work fine with legacy INTx. But some new platforms are using it, so I think we should list those new platforms which blocks INTx in the driver. BTW, new chips use ath10k driver. 2017-09-26 14:44 GMT+08:00 Christoph Hellwig : > On Tue, Sep 26, 2017 at 02:41:35PM +0800, AceLan Kao wrote: >> Some platform(BIOS) blocks legacy interrupts (INTx), and only allows MSI >> for WLAN device. So adding a quirk to list those machines and set >> use_msi automatically. >> Adding Dell Inspiron 24-3460 to the quirk. > > Huh? Using MSI should be the default, and skipping MSI should be > a quirk if needed at all (usually it should be autodetected)
Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Hi Christoph, I'm okay with ether ways, but just worrying the regression if we switch to use MSI by default. Hi Daniel, I've tried your patch, but it doesn't work for me. Wifi can scan AP, but can't get connected. It keeps showing [ 48.362297] wlp2s0: authenticate with 3c:ce:73:48:0e:40 [ 48.374445] wlp2s0: send auth to 3c:ce:73:48:0e:40 (try 1/3) [ 49.824071] wlp2s0: send auth to 3c:ce:73:48:0e:40 (try 2/3) [ 50.848143] wlp2s0: send auth to 3c:ce:73:48:0e:40 (try 3/3) [ 51.840078] wlp2s0: authentication with 3c:ce:73:48:0e:40 timed out [ 52.038561] wlp2s0: authenticate with 3c:ce:73:48:04:80 [ 52.058930] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 1/3) [ 52.832063] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 2/3) [ 53.824135] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 3/3) [ 54.816067] wlp2s0: authentication with 3c:ce:73:48:04:80 timed out [ 55.904797] wlp2s0: authenticate with 3c:ce:73:48:04:80 [ 55.921771] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 1/3) [ 56.800151] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 2/3) [ 57.824072] wlp2s0: send auth to 3c:ce:73:48:04:80 (try 3/3) 02:00.0 Network controller [0280]: Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter [168c:0036] (rev 01) Subsystem: Dell QCA9565 / AR9565 Wireless Network Adapter [1028:020e] Kernel driver in use: ath9k Kernel modules: ath9k Do you have a chance to see if my patch works on your side? Best regards, AceLan Kao. 2017-09-26 22:14 GMT+08:00 Kalle Valo : > Christoph Hellwig writes: > >> On Tue, Sep 26, 2017 at 03:26:51PM +0800, AceLan Kao wrote: >>> Ath9k is an old driver for old chips, and they work fine with legacy INTx. >>> But some new platforms are using it, so I think we should list those >>> new platforms which blocks INTx in the driver. >> >> And unless they are broken and need a quirk they should work even better >> with MSI if the device advertises MSI support in the PCI capabilities. > > Daniel Drake (CCed) already found problems with the MSI implementation: > > https://lkml.kernel.org/r/20170925041153.26574-1-dr...@endlessm.com > > -- > Kalle Valo
Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Hi all, Please drop my patches, Qualcomm is working internally and will submit the MSI patch by themselves. Thanks. Hi Daniel, I'll try your patches tomorrow. Best regards, AceLan Kao. 2017-10-02 12:21 GMT+08:00 Daniel Drake : > Hi AceLan, > > On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao wrote: >> Hi Daniel, >> >> I've tried your patch, but it doesn't work for me. >> Wifi can scan AP, but can't get connected. > > Can you please clarify which patch(es) you have tried? > > This is the base patch which adds the infrastructure to request > specific MSI IRQ vectors: > https://marc.info/?l=linux-wireless&m=150631274108016&w=2 > > This is the ath9k MSI patch which makes use of that: > https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 > > If you were already able to use ath9k MSI interrupts without specific > consideration for which MSI vector numbers were used, these are the > possible explanations that spring to mind: > > 1. You got lucky and it picked a vector number that is 4-aligned. You > can check this in the "lspci -vvv" output. You'll see something like: > Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+ > Address: fee0300c Data: 4142 > The lower number is the vector number. In my example here 0x42 (66) is > not 4-aligned so the failure condition will be hit. > > 2. You are using interrupt remapping, which I suspect may provide a > high likelihood of MSI interrupt vectors being 4-aligned. See if > /proc/interrupts shows the IRQ type as IR-PCI-MSI > Unfortunately interrupt remapping is not available here, > https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html > > 3. My assumption that all ath9k hardware corrupts the MSI vector > number could wrong. However we've seen this on different wifi modules > in laptops produced by different OEMs and ODMs, so it seems to be a > somewhat widespread problem at least. > > 4. My assumption that ath9k hardware is corrupting the MSI vector > number could be wrong; maybe another component is to blame, could it > be a BIOS issue? Admittedly I don't really know how I can debug the > layers inbetween seeing the MSI Message Data value disagree with the > vector number being handled inside do_IRQ(). > > Daniel
Re: [PATCH 2/6] ath9k: add a quirk to set use_msi automatically
Hi Daniel, After applied the 2 commits you mentioned in the email, ath9k works. https://marc.info/?l=linux-wireless&m=150631274108016&w=2 https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 Best regards, AceLan Kao. 2017-10-05 14:39 GMT+08:00 AceLan Kao : > Hi all, > > Please drop my patches, Qualcomm is working internally and will submit > the MSI patch by themselves. > Thanks. > > Hi Daniel, > > I'll try your patches tomorrow. > > Best regards, > AceLan Kao. > > 2017-10-02 12:21 GMT+08:00 Daniel Drake : >> Hi AceLan, >> >> On Thu, Sep 28, 2017 at 4:28 PM, AceLan Kao wrote: >>> Hi Daniel, >>> >>> I've tried your patch, but it doesn't work for me. >>> Wifi can scan AP, but can't get connected. >> >> Can you please clarify which patch(es) you have tried? >> >> This is the base patch which adds the infrastructure to request >> specific MSI IRQ vectors: >> https://marc.info/?l=linux-wireless&m=150631274108016&w=2 >> >> This is the ath9k MSI patch which makes use of that: >> https://github.com/endlessm/linux/commit/739c7a924db8f4434a9617657 >> >> If you were already able to use ath9k MSI interrupts without specific >> consideration for which MSI vector numbers were used, these are the >> possible explanations that spring to mind: >> >> 1. You got lucky and it picked a vector number that is 4-aligned. You >> can check this in the "lspci -vvv" output. You'll see something like: >> Capabilities: [50] MSI: Enable+ Count=1/4 Maskable+ 64bit+ >> Address: fee0300c Data: 4142 >> The lower number is the vector number. In my example here 0x42 (66) is >> not 4-aligned so the failure condition will be hit. >> >> 2. You are using interrupt remapping, which I suspect may provide a >> high likelihood of MSI interrupt vectors being 4-aligned. See if >> /proc/interrupts shows the IRQ type as IR-PCI-MSI >> Unfortunately interrupt remapping is not available here, >> https://lists.linuxfoundation.org/pipermail/iommu/2017-August/023717.html >> >> 3. My assumption that all ath9k hardware corrupts the MSI vector >> number could wrong. However we've seen this on different wifi modules >> in laptops produced by different OEMs and ODMs, so it seems to be a >> somewhat widespread problem at least. >> >> 4. My assumption that ath9k hardware is corrupting the MSI vector >> number could be wrong; maybe another component is to blame, could it >> be a BIOS issue? Admittedly I don't really know how I can debug the >> layers inbetween seeing the MSI Message Data value disagree with the >> vector number being handled inside do_IRQ(). >> >> Daniel
