rt2800usb firmware rt2870.bin 0.36 not scanning
I have a D-Link DWA-140 USB Wi-Fi device which is rt2800 based (5392 chipset). I'm trying to use it on a BeagleBone Black based system with 3.14.x kernel built with Yocto. We're using ConnMan 1.30 at the moment. We've been finding some instabilities with it periodically disconnecting from some networks. So we tried upgrading the firmware file rt2870.bin from version 0.29 to 0.36. That seems to be more stable with the network. However, we're finding that it initially doesn't connect, until the Wi-Fi has been disabled and then re-enabled. 'connmanctl scan wifi' and 'iwlist scan' don't return anything until Wi-Fi has been disabled and then re-enabled. Have there been any Linux driver changes needed to support this 0.36 firmware? Does anyone have any pointers on where to look to understand this behaviour between 0.29 and 0.36 firmware? -- Craig McQueen -- 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: wireless-testing on 4.7
On Thu, 2016-06-02 at 23:09 -0600, Reinoud Koornstra wrote: > On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho wrote: > > This shows that you have iwlwifi-7260-16.ucode in your file system. > > But here we are reading it much later. So it's possible that the > > kernel cannot access the firmware at a very early stage (because > > the > > filesystem that contains it is not mounted yet) when you use in- > > kernel. > > > > So, first of all, please make sure they're built as modules. We > > can > > continue from there then. > > Your suggestion worked. When it's compiled as module, the > iwlwifi-7260-16.ucode loads fine. > No problems detected so far. Great! :) > It does make me think whether this is desired behavior though that > due > to the later reading we cannot have iwlwifi build in the kernel. It should work, but then you have to make sure the firmware is available at very early stages of boot. If you add it to the proper place in your initrd, the kernel should find it when the driver requests it. I didn't want to go into the details of this, because in most cases the best option is to have the driver as a module. If you really need it in-kernel, then you need to make sure all the needed pieces are available very early as well. -- Cheers, Luca. -- 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: ath9k gpio request
Done, https://patchwork.kernel.org/patch/9151847/.
Thanks,
Miaoqing
From: Kalle Valo
Sent: Friday, June 3, 2016 1:33 PM
To: Pan, Miaoqing
Cc: Sudip Mukherjee; Stephen Rothwell; ath9k-devel; linux-n...@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-wireless@vger.kernel.org;
ath9k-de...@lists.ath9k.org; net...@vger.kernel.org; Miaoqing Pan
Subject: Re: ath9k gpio request
Sudip Mukherjee writes:
> On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote:
>> Seems there are something wrong in the datasheet, try
>>
>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>> @@ -1122,8 +1122,8 @@ enum {
>> #define AR9300_NUM_GPIO 16
>> #define AR9330_NUM_GPIO 16
>> #define AR9340_NUM_GPIO 23
>> -#define AR9462_NUM_GPIO 10
>> -#define AR9485_NUM_GPIO 12
>> +#define AR9462_NUM_GPIO 14
>> +#define AR9485_NUM_GPIO 11
>> #define AR9531_NUM_GPIO 18
>> #define AR9550_NUM_GPIO 24
>> #define AR9561_NUM_GPIO 23
>> @@ -1139,8 +1139,8 @@ enum {
>> #define AR9300_GPIO_MASK0xF4FF
>> #define AR9330_GPIO_MASK0xF4FF
>> #define AR9340_GPIO_MASK0x000F
>> -#define AR9462_GPIO_MASK0x03FF
>> -#define AR9485_GPIO_MASK0x0FFF
>> +#define AR9462_GPIO_MASK0x3FFF
>> +#define AR9485_GPIO_MASK0x07FF
>> #define AR9531_GPIO_MASK0x000F
>> #define AR9550_GPIO_MASK0x000F
>> #define AR9561_GPIO_MASK0x000F
>
> solves the problem.
>
> Tested-by: Sudip Mukherjee
Great, thanks for testing everyone. Miaoqing, please send a proper patch
ASAP and I'll push it to 4.7.
--
Kalle Valo
--
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] ath9k: fix GPIO mask for AR9462 and AR9565
From: Miaoqing Pan
The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
Also fix the mask for AR9565.
WARNING: CPU: 1 PID: 199 at ../drivers/net/wireless/ath/ath9k/hw.c:2778
ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
CPU: 1 PID: 199 Comm: kworker/u16:9 Not tainted 4.7.0-rc1-next-20160530+ #5
Hardware name: Acer TravelMate P243/BA40_HC, BIOS V1.01 04/20/2012
Workqueue: events_power_efficient rfkill_poll
88002cf73d28 813b8ddc
88002cf73d68 8107a331 0ada0086
880148d9c018 000b 880147e68720 0200
Call Trace:
[] dump_stack+0x63/0x87
[] __warn+0xd1/0xf0
[] warn_slowpath_null+0x1d/0x20
[] ath9k_hw_gpio_get+0x1a9/0x1b0 [ath9k_hw]
[] ath9k_rfkill_poll_state+0x34/0x60 [ath9k]
[] ieee80211_rfkill_poll+0x33/0x40 [mac80211]
[] cfg80211_rfkill_poll+0x2a/0xc0 [cfg80211]
[] rfkill_poll+0x24/0x50
[] process_one_work+0x153/0x3f0
[] worker_thread+0x12b/0x4b0
[] ? rescuer_thread+0x340/0x340
[] kthread+0xc9/0xe0
[] ret_from_fork+0x1f/0x40
[] ? kthread_park+0x60/0x60
Signed-off-by: Miaoqing Pan
---
drivers/net/wireless/ath/ath9k/reg.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/reg.h
b/drivers/net/wireless/ath/ath9k/reg.h
index 9272ca9..80ff69f 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1122,12 +1122,12 @@ enum {
#define AR9300_NUM_GPIO 16
#define AR9330_NUM_GPIO 16
#define AR9340_NUM_GPIO 23
-#define AR9462_NUM_GPIO 10
+#define AR9462_NUM_GPIO 14
#define AR9485_NUM_GPIO 12
#define AR9531_NUM_GPIO 18
#define AR9550_NUM_GPIO 24
#define AR9561_NUM_GPIO 23
-#define AR9565_NUM_GPIO 12
+#define AR9565_NUM_GPIO 14
#define AR9580_NUM_GPIO 16
#define AR7010_NUM_GPIO 16
@@ -1139,12 +1139,12 @@ enum {
#define AR9300_GPIO_MASK0xF4FF
#define AR9330_GPIO_MASK0xF4FF
#define AR9340_GPIO_MASK0x000F
-#define AR9462_GPIO_MASK0x03FF
+#define AR9462_GPIO_MASK0x3FFF
#define AR9485_GPIO_MASK0x0FFF
#define AR9531_GPIO_MASK0x000F
#define AR9550_GPIO_MASK0x000F
#define AR9561_GPIO_MASK0x000F
-#define AR9565_GPIO_MASK0x0FFF
+#define AR9565_GPIO_MASK0x3FFF
#define AR9580_GPIO_MASK0xF4FF
#define AR7010_GPIO_MASK0x
--
1.9.1
--
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: ath9k gpio request
Sudip Mukherjee writes:
> On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote:
>> Seems there are something wrong in the datasheet, try
>>
>> --- a/drivers/net/wireless/ath/ath9k/reg.h
>> +++ b/drivers/net/wireless/ath/ath9k/reg.h
>> @@ -1122,8 +1122,8 @@ enum {
>> #define AR9300_NUM_GPIO 16
>> #define AR9330_NUM_GPIO 16
>> #define AR9340_NUM_GPIO 23
>> -#define AR9462_NUM_GPIO 10
>> -#define AR9485_NUM_GPIO 12
>> +#define AR9462_NUM_GPIO 14
>> +#define AR9485_NUM_GPIO 11
>> #define AR9531_NUM_GPIO 18
>> #define AR9550_NUM_GPIO 24
>> #define AR9561_NUM_GPIO 23
>> @@ -1139,8 +1139,8 @@ enum {
>> #define AR9300_GPIO_MASK0xF4FF
>> #define AR9330_GPIO_MASK0xF4FF
>> #define AR9340_GPIO_MASK0x000F
>> -#define AR9462_GPIO_MASK0x03FF
>> -#define AR9485_GPIO_MASK0x0FFF
>> +#define AR9462_GPIO_MASK0x3FFF
>> +#define AR9485_GPIO_MASK0x07FF
>> #define AR9531_GPIO_MASK0x000F
>> #define AR9550_GPIO_MASK0x000F
>> #define AR9561_GPIO_MASK0x000F
>
> solves the problem.
>
> Tested-by: Sudip Mukherjee
Great, thanks for testing everyone. Miaoqing, please send a proper patch
ASAP and I'll push it to 4.7.
--
Kalle Valo
--
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: wireless-testing on 4.7
On Thu, Jun 2, 2016 at 2:16 AM, Luca Coelho wrote: > On Thu, 2016-06-02 at 02:02 -0600, Reinoud Koornstra wrote: >> On Wed, Jun 1, 2016 at 10:27 PM, Coelho, Luciano >> wrote: >> > On Wed, 2016-06-01 at 16:08 -0600, Reinoud Koornstra wrote: >> > > On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano >> > > wrote: >> > > > On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote: >> > > > > + Luca, Emmanuel >> > > > >> > > > Thanks, Bob! >> > > > >> > > > >> > > > > On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra >> > > > > wrote: >> > > > > > Today I compiled 4.6+ and pulled sources today >> > > > > > iwlwifi isn't super smooth. >> > > > > >> > > > > I assume you mean wireless-testing, based on 4.7-rc1 (as this >> > > > > email >> > > > > is >> > > > > in reply to my announcement of same). >> > > > >> > > > Yes, we need to know exactly what kernel you're using so we know >> > > > what >> > > > we're debugging. >> > > > >> > > >> > > Yesterday this is what I did to obtain the latest source: >> > > >> > > git clone >> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git >> > > kernel_current >> > > >> > > This is the latest commit in that tree: >> > > >> > > commit 367d3fd50566a313946fa9c5b2116a81bf3807e4 >> > > Merge: 5eca831 cf0d44d >> > > Author: Linus Torvalds >> > > Date: Tue May 31 09:43:24 2016 -0700 >> > > >> > >Merge branch 'for-linus' of >> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux >> > > >> > >Pull s390 fixes from Martin Schwidefsky: >> > > "Three bugs fixes and an update for the default configuration" >> > > >> > >* 'for-linus' of >> > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: >> > > s390: fix info leak in do_sigsegv >> > > s390/config: update default configuration >> > > s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop >> > > s390/bpf: reduce maximum program size to 64 KB >> > >> > Ah, okay. This has nothing to do with the wireless-testing tree. This >> > is random commit in Linus' tree. I suggest that you use a release tag >> > or such. For instance you could do this in Linus' tree to get the >> > current release candidate for 4.7: >> > >> > git checkout v4.7-rc1 >> > >> > Or you could use the wireless-testing tree that Bob is maintaining, >> > which is always based on an official release candidate (currently the >> > above mentioned v4.7-rc1 release) plus the latest and greatest (and >> > probably "brokenest" :P) wireless changes: >> > >> > git clone >> > git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git >> > >> >> Ok, i got this tree. >> From the start it didn't work. >> >> [0.00] Linux version 4.7.0-rc1-wt+ >> [SNIP] >> [2.156875] iwlwifi :04:00.0: Direct firmware load for >> iwlwifi-7260-17.ucode failed with error -2 >> [2.157681] iwlwifi :04:00.0: Direct firmware load for >> iwlwifi-7260-16.ucode failed with error -2 >> [2.158438] iwlwifi :04:00.0: no suitable firmware found! > > This is happening pretty early, did you compile the iwlwifi driver into > the kernel (instead of compiling them as modules)? There have been > problems when it's in-kernel, so we recommend that you compile them as > modules (unless strictly necessary). > > >> I've attached the dmesg in it's entirety. >> Booting back to 4.6: >> >> [ 17.987698] iwlwifi :04:00.0: loaded firmware version >> 16.242414.0 op_mode iwlmvm >> [ 18.269667] iwlwifi :04:00.0: Detected Intel(R) Dual Band >> Wireless AC 7260, REV=0x144 > > This shows that you have iwlwifi-7260-16.ucode in your file system. > But here we are reading it much later. So it's possible that the > kernel cannot access the firmware at a very early stage (because the > filesystem that contains it is not mounted yet) when you use in-kernel. > > So, first of all, please make sure they're built as modules. We can > continue from there then. Your suggestion worked. When it's compiled as module, the iwlwifi-7260-16.ucode loads fine. No problems detected so far. It does make me think whether this is desired behavior though that due to the later reading we cannot have iwlwifi build in the kernel. Thanks, Reinoud. > > -- > Cheers, > Luca. -- 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: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 02:38:04PM -0400, John W. Linville wrote: > It has recently come to my attention that the old wireless-legacy.git > tree is no longer available on kernel.org. I honestly have no idea > what happened to it -- for all I know I fat-fingered it some time > ago or whatever. Anyway, apparently there are some references in it > "out there" and it would be good if we had a copy available somewhere > public. > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > IT! Please let me know that you've got it and I will arrange to get > a copy of it from you in order to make it available publicly again. > > I appreciate your support! > http://www.filewatcher.com/_/?q=wireless-legacy.git, maybe ? Guenter -- 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: iw reg overwritten after connecting to AP
Hi Krishna, On Thu, Jun 2, 2016 at 10:21 PM, Krishna Chaitanya wrote: > On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek wrote: >> >> Hello, >> >> I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB >> enabled. I have set one country in db.txt which during startup I set >> via 'iw reg set XX'. When connected to some AP which sends country >> code (e.g. SK) region is overwritten to 00 (in kernel log there is >> some timeout message - I suppose it's communication with crda daemon >> which I'm not using). Is there a way how to override this behavior (to >> keep my regulatory persistent). Many thanks. >> > You need to disable country_ie hints, you driver has to advertise > REGULATORY_WIPHY_SELF_MANAGED in the wiphy.regualtory_flags > to disable beacon and country_ie hints. I would like to keep beacon hinting (maybe disable only country_ie). I have same setup but with 3.9 kernel and regulatory isn't overwritten. > > Which driver are you using? I'm using mwifiex driver Thanks, BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- 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: iw reg overwritten after connecting to AP
On Thu, Jun 2, 2016 at 7:34 PM, Belisko Marek wrote: > > Hello, > > I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB > enabled. I have set one country in db.txt which during startup I set > via 'iw reg set XX'. When connected to some AP which sends country > code (e.g. SK) region is overwritten to 00 (in kernel log there is > some timeout message - I suppose it's communication with crda daemon > which I'm not using). Is there a way how to override this behavior (to > keep my regulatory persistent). Many thanks. > You need to disable country_ie hints, you driver has to advertise REGULATORY_WIPHY_SELF_MANAGED in the wiphy.regualtory_flags to disable beacon and country_ie hints. Which driver are you using? -- 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: Anyone have a clone of wireless-legacy.git?
On Thu, Jun 02, 2016 at 08:48:08PM +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" wrote: > > > It has recently come to my attention that the old wireless-legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in it > > "out there" and it would be good if we had a copy available somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > > IT! Please let me know that you've got it and I will arrange to get > > a copy of it from you in order to make it available publicly again. > > Before you do that please make sure you get multiple copies from > unconnected sources and confirm none of them are trojanned. I will endeavour to ensurance provenance, certainly. John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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: Anyone have a clone of wireless-legacy.git?
> Not really necessary - at least one commit ID in it is well > documented: > > https://www.softwarefreedom.org/resources/2007/ath5k-code-analysis.html > > That might very well be one of the last commits in that tree. > Actually, no - it says ath5k branch. I don't seem to have it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Anyone have a clone of wireless-legacy.git?
On Thu, 2016-06-02 at 20:48 +0100, One Thousand Gnomes wrote: > On Thu, 2 Jun 2016 14:38:04 -0400 > "John W. Linville" wrote: > > > > > It has recently come to my attention that the old wireless- > > legacy.git > > tree is no longer available on kernel.org. I honestly have no idea > > what happened to it -- for all I know I fat-fingered it some time > > ago or whatever. Anyway, apparently there are some references in > > it > > "out there" and it would be good if we had a copy available > > somewhere > > public. > > > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT > > DELETE > > IT! Please let me know that you've got it and I will arrange to > > get > > a copy of it from you in order to make it available publicly again. > Before you do that please make sure you get multiple copies from > unconnected sources and confirm none of them are trojanned. > Not really necessary - at least one commit ID in it is well documented: https://www.softwarefreedom.org/resources/2007/ath5k-code-analysis.html That might very well be one of the last commits in that tree. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Anyone have a clone of wireless-legacy.git?
On Thu, 2 Jun 2016 14:38:04 -0400 "John W. Linville" wrote: > It has recently come to my attention that the old wireless-legacy.git > tree is no longer available on kernel.org. I honestly have no idea > what happened to it -- for all I know I fat-fingered it some time > ago or whatever. Anyway, apparently there are some references in it > "out there" and it would be good if we had a copy available somewhere > public. > > If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE > IT! Please let me know that you've got it and I will arrange to get > a copy of it from you in order to make it available publicly again. Before you do that please make sure you get multiple copies from unconnected sources and confirm none of them are trojanned. Alan -- 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 v2] wireless-regdb: Republic of Korea: Add 60GHz regulatory rules
Add 60GHz regulatory rules for Korea (KR). Source is http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99 Signed-off-by: Maya Erez --- db.txt | 4 1 file changed, 4 insertions(+) diff --git a/db.txt b/db.txt index da16f7c..48df9a5 100644 --- a/db.txt +++ b/db.txt @@ -664,6 +664,10 @@ country KR: DFS-JP (5250 - 5330 @ 80), (20), DFS, AUTO-BW (5490 - 5710 @ 160), (30), DFS (5735 - 5835 @ 80), (30) + # 60 GHz band channels 1-4, + # ref: http://www.law.go.kr/%ED%96%89%EC%A0%95%EA%B7%9C%EC%B9%99/%EB%AC%B4%EC%84%A0%EC%84%A4%EB%B9%84%EA%B7%9C%EC%B9%99 + (57000 - 66000 @ 2160), (43) + country KW: DFS-ETSI (2402 - 2482 @ 40), (20) -- 1.8.5.2 -- 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
Anyone have a clone of wireless-legacy.git?
It has recently come to my attention that the old wireless-legacy.git tree is no longer available on kernel.org. I honestly have no idea what happened to it -- for all I know I fat-fingered it some time ago or whatever. Anyway, apparently there are some references in it "out there" and it would be good if we had a copy available somewhere public. If you have an old clone of wireless-legacy.git, PLEASE DO NOT DELETE IT! Please let me know that you've got it and I will arrange to get a copy of it from you in order to make it available publicly again. I appreciate your support! John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On 06/02/2016 10:41 AM, Rajkumar Manoharan wrote: On 2016-06-02 22:53, Ben Greear wrote: On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote: On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote: On 06/02/2016 07:24 AM, Valo, Kalle wrote: Kalle Valo writes: there's a regression in ath10k: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Reporter bisected it to this: 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 Author: Rajkumar Manoharan Date: Tue Mar 22 17:22:19 2016 +0530 ath10k: combine txrx and replenish task [...] I found a lot of problems with this code as well, and the 5 patches starting from the URL below fixed the issues for me. Ben, Can you please explain the sort of issues you have observed with this change? I imported a bunch of upstream patches at once, so not sure exactly what commit caused it. And, this was about 2 months ago... Upon review, I'm not sure I even have the patch this particular bug was bisected to, so maybe that is some other issue. Please keep track of buggy commit and report them asap. I posted to the list at the time. When I was debugging this, there were so many conflicting issues that it was hard to find a single regression point. But, the problems I saw were deadlocks and memory corruption. A lot of it was because I was debugging new firmware at the time and so peer creation was failing sometimes, and things like that. The error handling in ath10k for this was faulty and racy and such. We have not seen any performance regressions, but we mostly run on very powerful CPUs. Please take a look at those 5 patches. A good review would be much appreciated, and by reading them you will better be able to see the problems I was hitting and trying to fix. Below two patches are critical and I already shared my feedback. https://patchwork.kernel.org/patch/8727841/ https://patchwork.kernel.org/patch/9073471/ Others are LGTM. Not sure what LGTM means. This one fixes memory corruption: http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/htt_tx.c;h=58e88d392fb56a65304db17d11a9eaf0b0397dc7;hp=07b960e9704f509b3dddf1e45730e76a4c39e51e;hb=fddb6661a0f5772853fbb9feb7232f325d5f74c5;hpb=ed1757f8345064181664e4a62e2b917e694a665e This one fixes use-after-free memory bugs: http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/mac.c;h=5e5cc9c6c1d82524b9b77a7c6d2c1341c5268732;hp=8783119b9ba84e0ddb292d521e6513bf7d68a40b;hb=5ae13cea64004afc673ecc22cd70ac51179168c6;hpb=fddb6661a0f5772853fbb9feb7232f325d5f74c5 As does this one: http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=blobdiff;f=drivers/net/wireless/ath/ath10k/mac.c;h=020dd25752224d9786da37a6dfd10a69e646b138;hp=5e5cc9c6c1d82524b9b77a7c6d2c1341c5268732;hb=c4b9566416a5e7b8d4c446d1bad34aabcbeff9f5;hpb=9bd9c11c1a2e61261c268ac2b6d791d4f6b6fe26 In case you want to look at the full context of those patches, you can find them here (around 24 patches down from the top...) Quite a big list :) http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary For now, I am sticking with 4.4 + what I pulled in, but will rebase against upstream someday soon-ish and then we can start testing it all over again :) Will go through the list. Better to post them to public if not. Many of these patches are related to features only in my firmware. The ~20 patch patch-bomb was a start at adding some of the hopefully less controversial support. If I can ever get that upstream, then I will pick off another set of patches and try to get them ready for upstream. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On 2016-06-02 22:53, Ben Greear wrote: On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote: On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote: On 06/02/2016 07:24 AM, Valo, Kalle wrote: Kalle Valo writes: there's a regression in ath10k: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Reporter bisected it to this: 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 Author: Rajkumar Manoharan Date: Tue Mar 22 17:22:19 2016 +0530 ath10k: combine txrx and replenish task [...] I found a lot of problems with this code as well, and the 5 patches starting from the URL below fixed the issues for me. Ben, Can you please explain the sort of issues you have observed with this change? I imported a bunch of upstream patches at once, so not sure exactly what commit caused it. And, this was about 2 months ago... Upon review, I'm not sure I even have the patch this particular bug was bisected to, so maybe that is some other issue. Please keep track of buggy commit and report them asap. But, the problems I saw were deadlocks and memory corruption. A lot of it was because I was debugging new firmware at the time and so peer creation was failing sometimes, and things like that. The error handling in ath10k for this was faulty and racy and such. We have not seen any performance regressions, but we mostly run on very powerful CPUs. Please take a look at those 5 patches. A good review would be much appreciated, and by reading them you will better be able to see the problems I was hitting and trying to fix. Below two patches are critical and I already shared my feedback. https://patchwork.kernel.org/patch/8727841/ https://patchwork.kernel.org/patch/9073471/ Others are LGTM. In case you want to look at the full context of those patches, you can find them here (around 24 patches down from the top...) Quite a big list :) http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary For now, I am sticking with 4.4 + what I pulled in, but will rebase against upstream someday soon-ish and then we can start testing it all over again :) Will go through the list. Better to post them to public if not. -Rajkumar -- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On 06/02/2016 10:03 AM, Manoharan, Rajkumar wrote:
On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote:
On 06/02/2016 07:24 AM, Valo, Kalle wrote:
Kalle Valo writes:
there's a regression in ath10k:
https://bugzilla.kernel.org/show_bug.cgi?id=119151
Reporter bisected it to this:
5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
Author: Rajkumar Manoharan
Date: Tue Mar 22 17:22:19 2016 +0530
ath10k: combine txrx and replenish task
Since tx completion and rx indication processing are moved out
of txrx tasklet and rx ring lock contention also removed from txrx
for rx_ind messages, it would be efficient to combine both replenish
and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
(low and high end systems). With this adjustment in AP135, TCP DL is
improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
to 803 Mbps. Also no watchdog are observed on UDP BiDi.
Signed-off-by: Rajkumar Manoharan
Signed-off-by: Kalle Valo
Adding Mike, the bug reporter.
Mike,
Sorry for the regression. Since the patch combines both txrx and replenish
tasklet,
it is validated in low end embedded devices like AP135 (single core 720 MHz
MIPS processor).
It seems yours is octa core processor. So CPU is not bottleneck here. Need
your help to fix this issue asap.
Can you please try reducing rx refill threshold as below.
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 2aa407160859..d35d3d48ae6c 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1734,7 +1734,7 @@ struct htt_rx_desc {
/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
* aggregated traffic more nicely. */
-#define ATH10K_HTT_MAX_NUM_REFILL 100
+#define ATH10K_HTT_MAX_NUM_REFILL 16
From your log attachment from bug report, I found few timed out messages.
May 30 21:09:26 axion kernel: wlan0: deauthenticating from a0:63:91:a7:3c:9f by
local choice (Reason: 3=DEAUTH_LEAVING)
May 30 21:09:32 axion kernel: ath10k_pci :3c:00.0: failed to flush transmit
queue (skip 0 ar-state 1): 0
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: failed to delete peer
a0:63:91:a7:3c:9f for vdev 0: -110
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: found sta peer
a0:63:91:a7:3c:9f entry on vdev 0 after it was supposed
Try disabling pci power save for qca6174 as below.
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 852f2c18cd11..5e3ba37a8c6a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2979,7 +2979,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
hw_rev = ATH10K_HW_QCA6174;
- pci_ps = true;
+ pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca6174_chip_reset;
I found a lot of problems with this code as well, and the 5 patches
starting from the URL below fixed the issues for me.
Ben,
Can you please explain the sort of issues you have observed with this change?
I imported a bunch of upstream patches at once, so not sure exactly what commit
caused it. And, this was about 2 months ago... Upon review, I'm not sure I
even have
the patch this particular bug was bisected to, so maybe that is some other
issue.
But, the problems I saw were deadlocks and memory corruption. A lot of it was
because I was debugging new firmware at the time and so peer creation was
failing
sometimes, and things like that. The error handling in ath10k for this was
faulty and racy and such. We have not seen any performance regressions,
but we mostly run on very powerful CPUs.
Please take a look at those 5 patches. A good review would be much appreciated,
and by reading them you will better be able to see the problems I was hitting
and trying to fix.
In case you want to look at the full context of those patches, you can find
them here (around 24 patches down from the top...)
http://dmz2.candelatech.com/?p=linux-4.4.dev.y/.git;a=summary
For now, I am sticking with 4.4 + what I pulled in, but will rebase against
upstream someday
soon-ish and then we can start testing it all over again :)
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
--
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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On Thursday, June 2, 2016 8:51 PM, Ben Greear wrote:
> On 06/02/2016 07:24 AM, Valo, Kalle wrote:
>> Kalle Valo writes:
>>
>>> there's a regression in ath10k:
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=119151
>>>
>>> Reporter bisected it to this:
>>>
>>> 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit
>>> commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183
>>> Author: Rajkumar Manoharan
>>> Date: Tue Mar 22 17:22:19 2016 +0530
>>>
>>> ath10k: combine txrx and replenish task
>>>
>>> Since tx completion and rx indication processing are moved out
>>> of txrx tasklet and rx ring lock contention also removed from txrx
>>> for rx_ind messages, it would be efficient to combine both replenish
>>> and txrx tasks. Refill threshold is adjusted for both AP135 and AP148
>>> (low and high end systems). With this adjustment in AP135, TCP DL is
>>> improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps
>>> to 803 Mbps. Also no watchdog are observed on UDP BiDi.
>>>
>>> Signed-off-by: Rajkumar Manoharan
>>> Signed-off-by: Kalle Valo
>>
>> Adding Mike, the bug reporter.
>
Mike,
Sorry for the regression. Since the patch combines both txrx and replenish
tasklet,
it is validated in low end embedded devices like AP135 (single core 720 MHz
MIPS processor).
It seems yours is octa core processor. So CPU is not bottleneck here. Need
your help to fix this issue asap.
Can you please try reducing rx refill threshold as below.
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 2aa407160859..d35d3d48ae6c 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1734,7 +1734,7 @@ struct htt_rx_desc {
/* Refill a bunch of RX buffers for each refill round so that FW/HW can handle
* aggregated traffic more nicely. */
-#define ATH10K_HTT_MAX_NUM_REFILL 100
+#define ATH10K_HTT_MAX_NUM_REFILL 16
>From your log attachment from bug report, I found few timed out messages.
May 30 21:09:26 axion kernel: wlan0: deauthenticating from a0:63:91:a7:3c:9f by
local choice (Reason: 3=DEAUTH_LEAVING)
May 30 21:09:32 axion kernel: ath10k_pci :3c:00.0: failed to flush transmit
queue (skip 0 ar-state 1): 0
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: failed to delete peer
a0:63:91:a7:3c:9f for vdev 0: -110
May 30 21:09:35 axion kernel: ath10k_pci :3c:00.0: found sta peer
a0:63:91:a7:3c:9f entry on vdev 0 after it was supposed
Try disabling pci power save for qca6174 as below.
diff --git a/drivers/net/wireless/ath/ath10k/pci.c
b/drivers/net/wireless/ath/ath10k/pci.c
index 852f2c18cd11..5e3ba37a8c6a 100644
--- a/drivers/net/wireless/ath/ath10k/pci.c
+++ b/drivers/net/wireless/ath/ath10k/pci.c
@@ -2979,7 +2979,7 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
case QCA6164_2_1_DEVICE_ID:
case QCA6174_2_1_DEVICE_ID:
hw_rev = ATH10K_HW_QCA6174;
- pci_ps = true;
+ pci_ps = false;
pci_soft_reset = ath10k_pci_warm_reset;
pci_hard_reset = ath10k_pci_qca6174_chip_reset;
>
> I found a lot of problems with this code as well, and the 5 patches
> starting from the URL below fixed the issues for me.
>
Ben,
Can you please explain the sort of issues you have observed with this change?
-Rajkumar--
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: ath9k gpio request
On Thursday 02 June 2016 01:32 PM, Pan, Miaoqing wrote:
Seems there are something wrong in the datasheet, try
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1122,8 +1122,8 @@ enum {
#define AR9300_NUM_GPIO 16
#define AR9330_NUM_GPIO 16
#define AR9340_NUM_GPIO 23
-#define AR9462_NUM_GPIO 10
-#define AR9485_NUM_GPIO 12
+#define AR9462_NUM_GPIO 14
+#define AR9485_NUM_GPIO 11
#define AR9531_NUM_GPIO 18
#define AR9550_NUM_GPIO 24
#define AR9561_NUM_GPIO 23
@@ -1139,8 +1139,8 @@ enum {
#define AR9300_GPIO_MASK0xF4FF
#define AR9330_GPIO_MASK0xF4FF
#define AR9340_GPIO_MASK0x000F
-#define AR9462_GPIO_MASK0x03FF
-#define AR9485_GPIO_MASK0x0FFF
+#define AR9462_GPIO_MASK0x3FFF
+#define AR9485_GPIO_MASK0x07FF
#define AR9531_GPIO_MASK0x000F
#define AR9550_GPIO_MASK0x000F
#define AR9561_GPIO_MASK0x000F
solves the problem.
Tested-by: Sudip Mukherjee
Regards
Sudip
--
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] Support for 32 bit iwpriv on 64 bits kernels
On Thu, 2016-06-02 at 20:51 +0530, Dibyajyoti Ghosh wrote: > This patch adds pointer conversion from 32 bit to 64 bit and vice > versa, > if the ioctl is issued from 32 bit iwpriv to 64 bit Kernel. > Huh? the kernel should handle that, no? And didn't you just submit a patch for it, so you break it again with this change? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On Thu, Jun 02, 2016 at 08:21:41AM -0700, Ben Greear wrote: > On 06/02/2016 07:24 AM, Valo, Kalle wrote: > >Kalle Valo writes: > > > >>there's a regression in ath10k: > >> > >>https://bugzilla.kernel.org/show_bug.cgi?id=119151 > >> > >>Reporter bisected it to this: > >> > >>5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit > >>commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 > >>Author: Rajkumar Manoharan > >>Date: Tue Mar 22 17:22:19 2016 +0530 > >> > >>ath10k: combine txrx and replenish task > >> > >>Since tx completion and rx indication processing are moved out > >>of txrx tasklet and rx ring lock contention also removed from txrx > >>for rx_ind messages, it would be efficient to combine both replenish > >>and txrx tasks. Refill threshold is adjusted for both AP135 and AP148 > >>(low and high end systems). With this adjustment in AP135, TCP DL is > >>improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps > >>to 803 Mbps. Also no watchdog are observed on UDP BiDi. > >> > >>Signed-off-by: Rajkumar Manoharan > >>Signed-off-by: Kalle Valo > > > >Adding Mike, the bug reporter. > > > I found a lot of problems with this code as well, and the 5 patches > starting from the URL below fixed the issues for me. > > They are stuck as 'NA' in patchwork, but I don't know why. > > http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html > > You probably need this patch as well, or ath10k will crash when you > enable the debug-mask: > > http://permalink.gmane.org/gmane.linux.kernel.wireless.general/151890 > > It is also 'NA' in patchwork. [shafi] i think this is already in the pending branch https://patchwork.kernel.org/patch/9073471/ > > Thanks, > Ben > > -- > Ben Greear > Candela Technologies Inc http://www.candelatech.com > > ___ > ath10k mailing list > ath...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/ath10k -- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On 06/02/2016 08:26 AM, Valo, Kalle wrote: Ben Greear writes: I found a lot of problems with this code as well, and the 5 patches starting from the URL below fixed the issues for me. They are stuck as 'NA' in patchwork, but I don't know why. http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html ath10k has a separate patchwork instance, did you look at the correct one? I have quite a lot of patches from you in deferred state because of the patch bomb, but I'm hoping to go through them soon. https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date Ok, they are deferred then. The series of 5 is likely quite useful and fixes some nasty bugs, and the first patch of the big bomb is also a trivial crash fix for a regression you added (as best as I can tell). The rest of the patch bomb is less critical, but making some progress on that would make me feel good about working on ath10k patches again. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
Ben Greear writes: > I found a lot of problems with this code as well, and the 5 patches > starting from the URL below fixed the issues for me. > > They are stuck as 'NA' in patchwork, but I don't know why. > > http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html ath10k has a separate patchwork instance, did you look at the correct one? I have quite a lot of patches from you in deferred state because of the patch bomb, but I'm hoping to go through them soon. https://patchwork.kernel.org/project/ath10k/list/?state=10&delegate=25621&order=date -- Kalle Valo-- 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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
On 06/02/2016 07:24 AM, Valo, Kalle wrote: Kalle Valo writes: there's a regression in ath10k: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Reporter bisected it to this: 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 Author: Rajkumar Manoharan Date: Tue Mar 22 17:22:19 2016 +0530 ath10k: combine txrx and replenish task Since tx completion and rx indication processing are moved out of txrx tasklet and rx ring lock contention also removed from txrx for rx_ind messages, it would be efficient to combine both replenish and txrx tasks. Refill threshold is adjusted for both AP135 and AP148 (low and high end systems). With this adjustment in AP135, TCP DL is improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps to 803 Mbps. Also no watchdog are observed on UDP BiDi. Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo Adding Mike, the bug reporter. I found a lot of problems with this code as well, and the 5 patches starting from the URL below fixed the issues for me. They are stuck as 'NA' in patchwork, but I don't know why. http://lists.infradead.org/pipermail/ath10k/2016-April/007218.html You probably need this patch as well, or ath10k will crash when you enable the debug-mask: http://permalink.gmane.org/gmane.linux.kernel.wireless.general/151890 It is also 'NA' in patchwork. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- 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] Support for 32 bit iwpriv on 64 bits kernels
This patch adds pointer conversion from 32 bit to 64 bit and vice versa,
if the ioctl is issued from 32 bit iwpriv to 64 bit Kernel.
Signed-off-by: Dibyajyoti Ghosh
---
wireless_tools.29/iwpriv.c | 41 +
1 file changed, 41 insertions(+)
diff --git a/wireless_tools.29/iwpriv.c b/wireless_tools.29/iwpriv.c
index 4172fe2..a0b1b02 100644
--- a/wireless_tools.29/iwpriv.c
+++ b/wireless_tools.29/iwpriv.c
@@ -243,6 +243,7 @@ iw_usage(void)
fprintf(stderr, "Usage: iwpriv interface [private-command
[private-arguments]]\n");
}
+#include
/* SETTING ROUTINES **/
/*--*/
@@ -259,12 +260,20 @@ set_private_cmd(int skfd, /*
Socket */
int priv_num) /* Number of descriptions */
{
struct iwreq wrq;
+ struct compat_iw_point {
+__u64 pointer;
+__u16 length;
+__u16 flags;
+ };
u_char buffer[4096]; /* Only that big in v25 and later */
int i = 0; /* Start with first command arg */
int k; /* Index in private description table */
int temp;
int subcmd = 0; /* sub-ioctl index */
int offset = 0; /* Space for sub-ioctl index */
+ FILE *in;
+ char buff[4];
+ int kspace, uspace;
/* Check if we have a token index.
* Do it now so that sub-ioctl takes precedence, and so that we
@@ -457,6 +466,26 @@ set_private_cmd(intskfd, /*
Socket */
}
}
+ in = popen("getconf LONG_BIT", "r");
+ fgets(buff, sizeof(buff), in);
+ pclose(in);
+ kspace = atoi(buff);
+ uspace = sizeof(char *) * 8;
+
+ struct compat_iw_point *iwp_compat = (struct compat_iw_point *)&wrq.u.data;
+ __u16 len = wrq.u.data.length;
+ __u16 flags = wrq.u.data.flags;
+
+ /* If 32 bit app is running on 64 bit kernel
+ * convert 32 bit iw_point type payload to 64 bit
+ */
+ if(uspace == 32 && kspace == 64)
+{
+ iwp_compat->pointer = (__u64)((__u32)wrq.u.data.pointer);
+ iwp_compat->length = len;
+ iwp_compat->flags = flags;
+}
+
/* Perform the private ioctl */
if(ioctl(skfd, priv[k].cmd, &wrq) < 0)
{
@@ -465,6 +494,18 @@ set_private_cmd(intskfd, /*
Socket */
return(-1);
}
+ /* If 32 bit app is running on 64 bit kernel, convert the
+ * 64 bit result back to 32 bit to fit the app
+ */
+ if(uspace == 32 && kspace == 64)
+{
+ flags = iwp_compat->flags;
+ len = iwp_compat->length;
+ wrq.u.data.pointer = (__u32)iwp_compat->pointer;
+ wrq.u.data.length = iwp_compat->length;
+ wrq.u.data.flags = iwp_compat->flags;
+}
+
/* If we have to get some data */
if((priv[k].get_args & IW_PRIV_TYPE_MASK) &&
(priv[k].get_args & IW_PRIV_SIZE_MASK))
--
1.9.1
--
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: ath10k: enable ipq4019 device probe in ahb module
c_tr...@qti.qualcomm.com wrote: > From: Raja Mani > > All the necessary patches to make wifi running (over AHB) > on ipq4019 SoC are ready now. It's good to enable > ipq4019 wifi device probing in ahb module and > remove work in progress debug print. > > Device tree change is there in the public review by > below commit message > "qcom: ipq4019: add wifi nodes to ipq4019 SoC device tree" > > Signed-off-by: Tamizh chelvam > Signed-off-by: Raja Mani Thanks, 1 patch applied to ath.git: 280e762e9c72 ath10k: enable ipq4019 device probe in ahb module -- Sent by pwcli https://patchwork.kernel.org/patch/9141355/ -- 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: [1/5] ath10k: fix operating irq mode for ahb device
Rajkumar Manoharan wrote:
> Earlier when operating irq mode is legacy, interrupts are disabled
> and re-enabled based on num_msi_intrs. commit cfe9011a05a8 ("ath10k:
> remove MSI range support") replaced num_msi_intrs by oper_irq_mode.
> Since oper_irq_mode is not initialized for ahb devices (i.e qca4019),
> device boot up is failed during probe.
>
> Fixes: cfe9011a05a8 ("ath10k: remove MSI range support")
> Signed-off-by: Rajkumar Manoharan
Thanks, 5 patches applied to ath.git:
2e550b6d277b ath10k: fix operating irq mode for ahb device
10f8ec64a2a6 ath10k: remove unused phy_mode_to_band
b855de0f5792 ath10k: update module description
64e001f41676 ath10k: add new ATH10K_FW_FEATURE_BTCOEX_PARAM
39136248cf8d ath10k: add pdev param support to enable/disable btcoex
--
Sent by pwcli
https://patchwork.kernel.org/patch/9138581/
--
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: ath10k: Fix error while writing 'simulate_fw_crash' debugfs
Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Fix invalid argument error while writing 'simulate_fw_crash', > though the funcionality is working fine we get an error 'invalid > argument' because 'count' value is not returned properly > (no reason to reduce the count value for removing the newline) > > Fixes the below write error: > > /sys/kernel/debug/ieee80211/phy0/ath10k# echo hw-restart > > simulate_fw_crash > -bash: echo: write error: Invalid argument > > Also move the 'conf_mutex' as it is really not required for > fetching the userspace buffer. > > Reported-by: Maharaja Kennadyrajan > Signed-off-by: Mohammed Shafi Shajakhan > Signed-off-by: Maharaja Kennadyrajan Thanks, 1 patch applied to ath.git: f5e307515b2b ath10k: fix error while writing 'simulate_fw_crash' debugfs -- Sent by pwcli https://patchwork.kernel.org/patch/9136787/ -- 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: ath10k: fix diag_read to collect data for larger memory
Ashok Raj Nagarajan wrote:
> diag_read uses dma_alloc_coherent to allocate memory requested by the
> caller. If this memory requested is larger, more than DIAG_TRANSFER_LIMIT
> (2K), then it is likely that we may not get the requested memory and we
> would fail.
>
> To solve this, request dma_alloc_coherent for only DIAG_TRANSFER_LIMIT, and
> reuse this buffer multiple times as needed to copy the data requested in
> smaller chunks of size not more than DIAG_TRANSFER_LIMIT. Previously we
> were reading into the caller's only after getting the complete requested
> data.
>
> Fixes: 68c03249f388 ('ath10k: convert pci_alloc_consistent() to
> dma_alloc_coherent()')
> Signed-off-by: Ashok Raj Nagarajan
Thanks, 1 patch applied to ath.git:
1e56d5127d5c ath10k: fix diag_read to collect data for larger memory
--
Sent by pwcli
https://patchwork.kernel.org/patch/9135561/
--
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 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
Arend van Spriel writes:
Reported-by: Grey Christoforo
>>>
>>> I'll add a fixes line before I commit:
>>>
>>> Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
>
> I realized it was missing. Not yet used to that tag. So I already sent a
> V2 patch.
Yeah, saw that and dropped this one. Thanks.
--
Kalle Valo
--
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 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
On 02-06-16 11:44, Kalle Valo wrote:
> Kalle Valo writes:
>
>> Arend van Spriel writes:
>>
>>> From: Franky Lin
>>>
>>> A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
>>> handling events in receive path") which moves eth_type_trans() call
>>> to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
>>> brcmf_netif_rx() directly. In such case the Ethernet header was not
>>> stripped out resulting in null pointer dereference in the networking
>>> stack.
>>>
>>> BUG: unable to handle kernel NULL pointer dereference at 0048
>>> IP: [] enqueue_to_backlog+0x56/0x260
>>> PGD 0
>>> Oops: [#1] PREEMPT SMP
>>> Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
>>> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
>>> [...]
>>> rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
>>> CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
>>> Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
>>> task: 8804a0c5bd00 ti: 88049e124000 task.ti: 88049e124000
>>> RIP: 0010:[] []
>>> enqueue_to_backlog+0x56/0x260
>>> RSP: 0018:88049e127ca0 EFLAGS: 00010046
>>> RAX: RBX: 8804bddd7c40 RCX: 002f
>>> RDX: RSI: 0007 RDI: 8804bddd7d4c
>>> RBP: 88049e127ce8 R08: R09:
>>> R10: 8804bddd12c0 R11: 149e R12: 00017c40
>>> R13: 88049e127d08 R14: 8804a9bd6d00 R15: 8804bddd7d4c
>>> FS: () GS:8804bddc() knlGS:
>>> CS: 0010 DS: ES: CR0: 80050033
>>> CR2: 0048 CR3: 01806000 CR4: 003406e0
>>> DR0: DR1: DR2:
>>> DR3: DR6: fffe0ff0 DR7: 0400
>>> Stack:
>>> 8804bdddad00 8804ad089e00 0282
>>> 8804a9bd6d00 8804a1b27e00 8804a9bd6d00
>>> 88002ee88000 88049e127d28 814c3f3b 81311fc3
>>> Call Trace:
>>> [] netif_rx_internal+0x4b/0x170
>>> [] ? swiotlb_tbl_unmap_single+0xf3/0x120
>>> [] netif_rx_ni+0x27/0xc0
>>> [] brcmf_netif_rx+0x49/0x70 [brcmfmac]
>>> [] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
>>> [] ? __xen_set_pgd_hyper+0x57/0xd0
>>> [] ? irq_forced_thread_fn+0x70/0x70
>>> [] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
>>> [] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
>>> [] irq_thread_fn+0x20/0x50
>>> [] irq_thread+0x12d/0x1c0
>>> [] ? __schedule+0x2f5/0x7a0
>>> [] ? wake_threads_waitq+0x30/0x30
>>> [] ? irq_thread_dtor+0xb0/0xb0
>>> [] kthread+0xd8/0xf0
>>> [] ret_from_fork+0x1f/0x40
>>> [] ? kthread_worker_fn+0x170/0x170
>>> Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
>>> 44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
>>> 8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
>>> RIP [] enqueue_to_backlog+0x56/0x260
>>> RSP
>>> CR2: 0048
>>>
>>> Reported-by: Grey Christoforo
>>
>> I'll add a fixes line before I commit:
>>
>> Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
I realized it was missing. Not yet used to that tag. So I already sent a
V2 patch.
Regards,
Arend
--
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: Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
Kalle Valo writes: > there's a regression in ath10k: > > https://bugzilla.kernel.org/show_bug.cgi?id=119151 > > Reporter bisected it to this: > > 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit > commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 > Author: Rajkumar Manoharan > Date: Tue Mar 22 17:22:19 2016 +0530 > > ath10k: combine txrx and replenish task > > Since tx completion and rx indication processing are moved out > of txrx tasklet and rx ring lock contention also removed from txrx > for rx_ind messages, it would be efficient to combine both replenish > and txrx tasks. Refill threshold is adjusted for both AP135 and AP148 > (low and high end systems). With this adjustment in AP135, TCP DL is > improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps > to 803 Mbps. Also no watchdog are observed on UDP BiDi. > > Signed-off-by: Rajkumar Manoharan > Signed-off-by: Kalle Valo Adding Mike, the bug reporter. -- Kalle Valo-- 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 v2 1/2] ath10k: remove duplicate and unused rx rate flags
On Thu, Jun 02, 2016 at 01:45:15PM +, Valo, Kalle wrote: > Mohammed Shafi Shajakhan writes: > > > From: Mohammed Shafi Shajakhan > > > > All these flags are not used and their use is completely > > covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck', > > and RX_PPDU_START_RATE_FLAG > > > > Signed-off-by: Mohammed Shafi Shajakhan > > Patchwork-Id: 9129361 > > Signed-off-by: Kalle Valo > > I guess you took this patch from the pending branch? :) The Patchwork-Id > line is something which my script adds for patches in the pending > branch, and removes them before applying them to ath-next, but this line > should not be visible when submitting patches. > [shafi] yes i am sorry :-( will send v3. regards, shafi -- 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 v3 1/2] ath10k: remove duplicate and unused rx rate flags
From: Mohammed Shafi Shajakhan
All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG
Signed-off-by: Mohammed Shafi Shajakhan
---
drivers/net/wireless/ath/ath10k/rx_desc.h | 39 -
1 file changed, 39 deletions(-)
[v3: removing patch id]
diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h
b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 9ceebea..034e7a5 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
* Reserved: HW should fill with zero. FW should ignore.
*/
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK 1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6 3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9 7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11 0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2 2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1 3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11 4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2 6
-
#define HTT_RX_PPDU_START_PREAMBLE_LEGACY0x04
#define HTT_RX_PPDU_START_PREAMBLE_HT0x08
#define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF 0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
/* No idea what this flag means. It seems to be always set in rate. */
#define RX_PPDU_START_RATE_FLAG BIT(3)
-enum rx_ppdu_start_rate {
- RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_48M,
- RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_24M,
- RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_12M,
- RX_PPDU_START_RATE_OFDM_6M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_6M,
- RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_54M,
- RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_36M,
- RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_18M,
- RX_PPDU_START_RATE_OFDM_9M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_9M,
-
- RX_PPDU_START_RATE_CCK_LP_11M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_11M,
- RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_5_5M,
- RX_PPDU_START_RATE_CCK_LP_2M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_2M,
- RX_PPDU_START_RATE_CCK_LP_1M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_1M,
- RX_PPDU_START_RATE_CCK_SP_11M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_11M,
- RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_5_5M,
- RX_PPDU_START_RATE_CCK_SP_2M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_2M,
-};
-
struct rx_ppdu_start {
struct {
u8 pri20_mhz;
--
1.7.9.5
--
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 v3 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets
From: Mohammed Shafi Shajakhan
CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below
ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,
This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards
Signed-off-by: Mohammed Shafi Shajakhan
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]
[v3: removed patch id]
drivers/net/wireless/ath/ath10k/core.c |3 +++
drivers/net/wireless/ath/ath10k/core.h |6 +
drivers/net/wireless/ath/ath10k/hw.h | 10
drivers/net/wireless/ath/ath10k/mac.c | 39 ++--
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
*/
bool continuous_frag_desc;
+ /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+ bool cck_rate_map_rev2;
+
u32 channel_counters_freq_hz;
/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
};
+enum ath10k_hw_rate_rev2_cck {
+ ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+ ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ ATH10K_HW_RATE_REV2_CCK_LP_11M,
+ ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
enum ath10k_hw_4addr_pad {
ATH10K_HW_4ADDR_PAD_AFTER,
ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
};
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+ { .bitrate = 10,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+ { .bitrate = 20,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+ { .bitrate = 55,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+ { .bitrate = 110,
+
iw reg overwritten after connecting to AP
Hello, I'm using kernel 4.1 with option CONFIG_CFG80211_INTERNAL_REGDB enabled. I have set one country in db.txt which during startup I set via 'iw reg set XX'. When connected to some AP which sends country code (e.g. SK) region is overwritten to 00 (in kernel log there is some timeout message - I suppose it's communication with crda daemon which I'm not using). Is there a way how to override this behavior (to keep my regulatory persistent). Many thanks. BR, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com -- 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
Bug 119151 - [regression] ath10k no longer authenitcates and freezes system
Hi, there's a regression in ath10k: https://bugzilla.kernel.org/show_bug.cgi?id=119151 Reporter bisected it to this: 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 is the first bad commit commit 5c86d97bcc1d42ce7f75685a61be4dad34ee8183 Author: Rajkumar Manoharan Date: Tue Mar 22 17:22:19 2016 +0530 ath10k: combine txrx and replenish task Since tx completion and rx indication processing are moved out of txrx tasklet and rx ring lock contention also removed from txrx for rx_ind messages, it would be efficient to combine both replenish and txrx tasks. Refill threshold is adjusted for both AP135 and AP148 (low and high end systems). With this adjustment in AP135, TCP DL is improved from 603 Mbps to 620 Mbps and UDP DL is improved from 758 Mbps to 803 Mbps. Also no watchdog are observed on UDP BiDi. Signed-off-by: Rajkumar Manoharan Signed-off-by: Kalle Valo -- Kalle Valo-- 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 v2 1/2] ath10k: remove duplicate and unused rx rate flags
Mohammed Shafi Shajakhan writes: > From: Mohammed Shafi Shajakhan > > All these flags are not used and their use is completely > covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck', > and RX_PPDU_START_RATE_FLAG > > Signed-off-by: Mohammed Shafi Shajakhan > Patchwork-Id: 9129361 > Signed-off-by: Kalle Valo I guess you took this patch from the pending branch? :) The Patchwork-Id line is something which my script adds for patches in the pending branch, and removes them before applying them to ath-next, but this line should not be visible when submitting patches. -- Kalle Valo-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT] ath10k: disable wake_tx_queue for older devices
Michal Kazior writes: > Some setups suffer performance regressions with > current wake_tx_queue implementation. > > Signed-off-by: Michal Kazior > --- > Hi Roman, > > Can you give this patch a try and see if it helps > with your performance problems, please? Did anyone seeing the performance regression manage to test this? It would be good to get feedback, good or bad, before I push this to 4.7. Full patch here: https://patchwork.kernel.org/patch/9111981/ -- Kalle Valo-- 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] ath5k: fix misplaced default label in sifs switch
In this switch statement, the default case does not always assign sifs. In practice, ah->ah_bwmode cannot take values besides the other labels, so this is not an actual problem, but it looks odd and smatch complains thus: ath5k_hw_get_default_sifs() warn: missing break? reassigning 'sifs' Silence the warning by moving default label up a line. Signed-off-by: Bob Copeland --- drivers/net/wireless/ath/ath5k/pcu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/ath5k/pcu.c b/drivers/net/wireless/ath/ath5k/pcu.c index fc47b70..f23c851 100644 --- a/drivers/net/wireless/ath/ath5k/pcu.c +++ b/drivers/net/wireless/ath/ath5k/pcu.c @@ -219,8 +219,8 @@ ath5k_hw_get_default_sifs(struct ath5k_hw *ah) sifs = AR5K_INIT_SIFS_QUARTER_RATE; break; case AR5K_BWMODE_DEFAULT: - sifs = AR5K_INIT_SIFS_DEFAULT_BG; default: + sifs = AR5K_INIT_SIFS_DEFAULT_BG; if (channel->band == NL80211_BAND_5GHZ) sifs = AR5K_INIT_SIFS_DEFAULT_A; break; -- 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
[PATCH] ath10k: Fix some of the macro definitions of HTT_RX_IND message
Only five bits are defined to pass tid information in HTT_RX_IND
message, so the mask which can be used to extract tid should be 0x1f
instead of the current 0x3f. Also, macros which can be used to extract
flush_valid and release_valid bits have to be left shifted one bit less
because these information follow the tid right after. This patch does
not really fix anything functionally because these macros are not used
currently.
Signed-off-by: Vasanthakumar Thiagarajan
---
drivers/net/wireless/ath/ath10k/htt.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h
b/drivers/net/wireless/ath/ath10k/htt.h
index 911c535..430a83e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -485,10 +485,10 @@ struct htt_mgmt_tx_completion {
__le32 status;
} __packed;
-#define HTT_RX_INDICATION_INFO0_EXT_TID_MASK (0x3F)
+#define HTT_RX_INDICATION_INFO0_EXT_TID_MASK (0x1F)
#define HTT_RX_INDICATION_INFO0_EXT_TID_LSB (0)
-#define HTT_RX_INDICATION_INFO0_FLUSH_VALID (1 << 6)
-#define HTT_RX_INDICATION_INFO0_RELEASE_VALID (1 << 7)
+#define HTT_RX_INDICATION_INFO0_FLUSH_VALID (1 << 5)
+#define HTT_RX_INDICATION_INFO0_RELEASE_VALID (1 << 6)
#define HTT_RX_INDICATION_INFO1_FLUSH_START_SEQNO_MASK 0x003F
#define HTT_RX_INDICATION_INFO1_FLUSH_START_SEQNO_LSB0
--
1.9.1
--
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: 4.7-rc1 wifi driver bug report
On Wed, Jun 1, 2016 at 10:22 PM, Arend Van Spriel wrote: > On 31-5-2016 13:46, Grey Christoforo wrote: >> Hi, >> >> I found the following in my dmesg today when I tried out 4.7-rc1 on my >> Dell XPS15 9550. My WiFi doesn't work. >> >> Relevant bits of my lsusb & lspci are: >> >> $ lsusb >> ... >> Bus 001 Device 002: ID 0a5c:6410 Broadcom Corp. >> ... >> $ lspci >> ... >> 02:00.0 Network controller: Broadcom Corporation BCM43602 802.11ac >> Wireless LAN SoC (rev 01) >> ... >> >> and here's the first BUG from from dmesg: > > Hi Grey, > > I have submitted a patch for this a moment ago. You can find it here [1] > as well. Let me know if it works for you. > > Regards, > Arend > > [1] > http://mid.gmane.org/1464815616-21551-1-git-send-email-ar...@broadcom.com Hi Arend, That patch solves the issue for me. Thanks very much! ¬grey -- 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] x86: Add early quirk to reset Apple AirPort card
On Sun, 29 May, at 01:35:28AM, Lukas Wunner wrote: > The EFI firmware on Macs contains a full-fledged network stack for > downloading OS X images from osrecovery.apple.com. Unfortunately > on Macs introduced 2011 and 2012, EFI brings up the Broadcom 4331 > wireless card on every boot and leaves it enabled even after > ExitBootServices has been called. The card continues to assert its IRQ > line, causing spurious interrupts if the IRQ is shared. It also corrupts > memory by DMAing received packets, allowing for remote code execution > over the air. This only stops when a driver is loaded for the wireless > card, which may be never if the driver is not installed or blacklisted. [... Snip a very thorough changelog ...] This patch looks fine to me from an EFI perspective. Acked-by: Matt Fleming -- 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 4.7 FIX] brcmfmac: fix lockup when removing P2P interface after event timeout
Rafał Miłecki writes: > Removing P2P interface is handled by sending a proper request to the > firmware. On success firmware triggers an event and driver's handler > removes a matching interface. > > However on event timeout we remove interface directly from the cfg80211 > callback. Current code doesn't handle this case correctly as it always > assumes rtnl to be unlocked. > > Fix it by adding an extra rtnl_locked parameter to functions and calling > unregister_netdevice when needed. > > Signed-off-by: Rafał Miłecki Arend, are you ok to push this to 4.7? -- Kalle Valo -- 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 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
Kalle Valo writes:
> Arend van Spriel writes:
>
>> From: Franky Lin
>>
>> A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
>> handling events in receive path") which moves eth_type_trans() call
>> to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
>> brcmf_netif_rx() directly. In such case the Ethernet header was not
>> stripped out resulting in null pointer dereference in the networking
>> stack.
>>
>> BUG: unable to handle kernel NULL pointer dereference at 0048
>> IP: [] enqueue_to_backlog+0x56/0x260
>> PGD 0
>> Oops: [#1] PREEMPT SMP
>> Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
>> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
>> [...]
>> rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
>> CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
>> Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
>> task: 8804a0c5bd00 ti: 88049e124000 task.ti: 88049e124000
>> RIP: 0010:[] []
>> enqueue_to_backlog+0x56/0x260
>> RSP: 0018:88049e127ca0 EFLAGS: 00010046
>> RAX: RBX: 8804bddd7c40 RCX: 002f
>> RDX: RSI: 0007 RDI: 8804bddd7d4c
>> RBP: 88049e127ce8 R08: R09:
>> R10: 8804bddd12c0 R11: 149e R12: 00017c40
>> R13: 88049e127d08 R14: 8804a9bd6d00 R15: 8804bddd7d4c
>> FS: () GS:8804bddc() knlGS:
>> CS: 0010 DS: ES: CR0: 80050033
>> CR2: 0048 CR3: 01806000 CR4: 003406e0
>> DR0: DR1: DR2:
>> DR3: DR6: fffe0ff0 DR7: 0400
>> Stack:
>> 8804bdddad00 8804ad089e00 0282
>> 8804a9bd6d00 8804a1b27e00 8804a9bd6d00
>> 88002ee88000 88049e127d28 814c3f3b 81311fc3
>> Call Trace:
>> [] netif_rx_internal+0x4b/0x170
>> [] ? swiotlb_tbl_unmap_single+0xf3/0x120
>> [] netif_rx_ni+0x27/0xc0
>> [] brcmf_netif_rx+0x49/0x70 [brcmfmac]
>> [] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
>> [] ? __xen_set_pgd_hyper+0x57/0xd0
>> [] ? irq_forced_thread_fn+0x70/0x70
>> [] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
>> [] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
>> [] irq_thread_fn+0x20/0x50
>> [] irq_thread+0x12d/0x1c0
>> [] ? __schedule+0x2f5/0x7a0
>> [] ? wake_threads_waitq+0x30/0x30
>> [] ? irq_thread_dtor+0xb0/0xb0
>> [] kthread+0xd8/0xf0
>> [] ret_from_fork+0x1f/0x40
>> [] ? kthread_worker_fn+0x170/0x170
>> Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
>> 44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
>> 8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
>> RIP [] enqueue_to_backlog+0x56/0x260
>> RSP
>> CR2: 0048
>>
>> Reported-by: Grey Christoforo
>
> I'll add a fixes line before I commit:
>
> Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
>
>> Reviewed-by: Pieter-Paul Giesberts
>> Reviewed-by: Arend Van Spriel
>> Reviewed-by: Hante Meuleman
>> Signed-off-by: Franky Lin
>> [ar...@broadcom.com: rephrased the commit message]
>> Signed-off-by: Arend van Spriel
>>
>> Signed-off-by: Arend van Spriel
>
> And a reminder to myself to remove the two extra S-o-b lines :)
Oh, forgot to mention that I'm planning to push this to 4.7.
--
Kalle Valo
--
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 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
Arend van Spriel writes:
> From: Franky Lin
>
> A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
> handling events in receive path") which moves eth_type_trans() call
> to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
> brcmf_netif_rx() directly. In such case the Ethernet header was not
> stripped out resulting in null pointer dereference in the networking
> stack.
>
> BUG: unable to handle kernel NULL pointer dereference at 0048
> IP: [] enqueue_to_backlog+0x56/0x260
> PGD 0
> Oops: [#1] PREEMPT SMP
> Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
> iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
> [...]
> rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
> CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
> Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
> task: 8804a0c5bd00 ti: 88049e124000 task.ti: 88049e124000
> RIP: 0010:[] []
> enqueue_to_backlog+0x56/0x260
> RSP: 0018:88049e127ca0 EFLAGS: 00010046
> RAX: RBX: 8804bddd7c40 RCX: 002f
> RDX: RSI: 0007 RDI: 8804bddd7d4c
> RBP: 88049e127ce8 R08: R09:
> R10: 8804bddd12c0 R11: 149e R12: 00017c40
> R13: 88049e127d08 R14: 8804a9bd6d00 R15: 8804bddd7d4c
> FS: () GS:8804bddc() knlGS:
> CS: 0010 DS: ES: CR0: 80050033
> CR2: 0048 CR3: 01806000 CR4: 003406e0
> DR0: DR1: DR2:
> DR3: DR6: fffe0ff0 DR7: 0400
> Stack:
> 8804bdddad00 8804ad089e00 0282
> 8804a9bd6d00 8804a1b27e00 8804a9bd6d00
> 88002ee88000 88049e127d28 814c3f3b 81311fc3
> Call Trace:
> [] netif_rx_internal+0x4b/0x170
> [] ? swiotlb_tbl_unmap_single+0xf3/0x120
> [] netif_rx_ni+0x27/0xc0
> [] brcmf_netif_rx+0x49/0x70 [brcmfmac]
> [] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
> [] ? __xen_set_pgd_hyper+0x57/0xd0
> [] ? irq_forced_thread_fn+0x70/0x70
> [] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
> [] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
> [] irq_thread_fn+0x20/0x50
> [] irq_thread+0x12d/0x1c0
> [] ? __schedule+0x2f5/0x7a0
> [] ? wake_threads_waitq+0x30/0x30
> [] ? irq_thread_dtor+0xb0/0xb0
> [] kthread+0xd8/0xf0
> [] ret_from_fork+0x1f/0x40
> [] ? kthread_worker_fn+0x170/0x170
> Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
> 44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
> 8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
> RIP [] enqueue_to_backlog+0x56/0x260
> RSP
> CR2: 0048
>
> Reported-by: Grey Christoforo
I'll add a fixes line before I commit:
Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
> Reviewed-by: Pieter-Paul Giesberts
> Reviewed-by: Arend Van Spriel
> Reviewed-by: Hante Meuleman
> Signed-off-by: Franky Lin
> [ar...@broadcom.com: rephrased the commit message]
> Signed-off-by: Arend van Spriel
>
> Signed-off-by: Arend van Spriel
And a reminder to myself to remove the two extra S-o-b lines :)
--
Kalle Valo
--
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: ath9k gpio request
On 2 June 2016 at 10:02, Pan, Miaoqing wrote:
> Seems there are something wrong in the datasheet, try
>
> --- a/drivers/net/wireless/ath/ath9k/reg.h
> +++ b/drivers/net/wireless/ath/ath9k/reg.h
> @@ -1122,8 +1122,8 @@ enum {
> #define AR9300_NUM_GPIO 16
> #define AR9330_NUM_GPIO 16
> #define AR9340_NUM_GPIO 23
> -#define AR9462_NUM_GPIO 10
> -#define AR9485_NUM_GPIO 12
> +#define AR9462_NUM_GPIO 14
> +#define AR9485_NUM_GPIO 11
> #define AR9531_NUM_GPIO 18
> #define AR9550_NUM_GPIO 24
> #define AR9561_NUM_GPIO 23
> @@ -1139,8 +1139,8 @@ enum {
> #define AR9300_GPIO_MASK0xF4FF
> #define AR9330_GPIO_MASK0xF4FF
> #define AR9340_GPIO_MASK0x000F
> -#define AR9462_GPIO_MASK0x03FF
> -#define AR9485_GPIO_MASK0x0FFF
> +#define AR9462_GPIO_MASK0x3FFF
> +#define AR9485_GPIO_MASK0x07FF
> #define AR9531_GPIO_MASK0x000F
> #define AR9550_GPIO_MASK0x000F
> #define AR9561_GPIO_MASK0x000F
>
Thanks, changes in reg.h solve the problem (my card AR9462 rev 01).
BR
Janusz
> Thanks,
> Miaoqing
>
>
> From: Sudip Mukherjee
> Sent: Wednesday, June 1, 2016 8:18 PM
> To: Pan, Miaoqing; Kalle Valo
> Cc: Stephen Rothwell; ath9k-devel; linux-n...@vger.kernel.org;
> linux-ker...@vger.kernel.org; linux-wireless@vger.kernel.org;
> ath9k-de...@lists.ath9k.org; net...@vger.kernel.org; Miaoqing Pan
> Subject: Re: ath9k gpio request
>
> On Wednesday 01 June 2016 04:42 PM, Sudip Mukherjee wrote:
>> On Wednesday 01 June 2016 12:24 PM, Pan, Miaoqing wrote:
>>> which chip ? And what's the GPIO number ?
>>
>> lspci -v reports:
>> 09:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
>> Adapter (rev 01)
>> Subsystem: Foxconn International, Inc. Device e052
>> Flags: bus master, fast devsel, latency 0, IRQ 19
>> Memory at c050 (64-bit, non-prefetchable) [size=512K]
>> Expansion ROM at c058 [disabled] [size=64K]
>> Capabilities: [40] Power Management version 2
>> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
>> Capabilities: [70] Express Endpoint, MSI 00
>> Capabilities: [100] Advanced Error Reporting
>> Capabilities: [140] Virtual Channel
>> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
>> Kernel driver in use: ath9k
>>
>> Any easy way to find out the gpio number or i can modify the module to
>> find that out.
>
> Its trying for GPIO 11 with label ath9k-rfkill.
>
> The attached dmesg is with some modification as below.
>
> diff --git a/drivers/net/wireless/ath/ath9k/hw.c
> b/drivers/net/wireless/ath/ath9k/hw.c
> index 8b2895f9..23deea7 100644
> --- a/drivers/net/wireless/ath/ath9k/hw.c
> +++ b/drivers/net/wireless/ath/ath9k/hw.c
> @@ -2729,14 +2729,16 @@ static void ath9k_hw_gpio_cfg_wmac(struct ath_hw
> *ah, u32 gpio, bool out,
> static void ath9k_hw_gpio_request(struct ath_hw *ah, u32 gpio, bool out,
>const char *label, u32 ah_signal_type)
> {
> - WARN_ON(gpio >= ah->caps.num_gpio_pins);
> +// WARN_ON(gpio >= ah->caps.num_gpio_pins);
> +
> + pr_err("sudip: %d %s\n", gpio, label);
>
> if (BIT(gpio) & ah->caps.gpio_mask)
> ath9k_hw_gpio_cfg_wmac(ah, gpio, out, ah_signal_type);
> else if (AR_SREV_SOC(ah))
> ath9k_hw_gpio_cfg_soc(ah, gpio, out, label);
> - else
> - WARN_ON(1);
> +// else
> +// WARN_ON(1);
> }
>
> Regards
> Sudip
> --
> 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
--
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 V2 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
From: Franky Lin
A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
handling events in receive path") which moves eth_type_trans() call
to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but invokes
brcmf_netif_rx() directly. In such case the Ethernet header was not
stripped out resulting in null pointer dereference in the networking
stack.
BUG: unable to handle kernel NULL pointer dereference at 0048
IP: [] enqueue_to_backlog+0x56/0x260
PGD 0
Oops: [#1] PREEMPT SMP
Modules linked in: fuse ipt_MASQUERADE nf_nat_masquerade_ipv4
iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 xt_addrtype
[...]
rtsx_pci scsi_mod usbcore usb_common i8042 serio nvme nvme_core
CPU: 7 PID: 1340 Comm: irq/136-brcmf_p Not tainted 4.7.0-rc1-mainline #1
Hardware name: Dell Inc. XPS 15 9550/0N7TVV, BIOS 01.02.00 04/07/2016
task: 8804a0c5bd00 ti: 88049e124000 task.ti: 88049e124000
RIP: 0010:[] []
enqueue_to_backlog+0x56/0x260
RSP: 0018:88049e127ca0 EFLAGS: 00010046
RAX: RBX: 8804bddd7c40 RCX: 002f
RDX: RSI: 0007 RDI: 8804bddd7d4c
RBP: 88049e127ce8 R08: R09:
R10: 8804bddd12c0 R11: 149e R12: 00017c40
R13: 88049e127d08 R14: 8804a9bd6d00 R15: 8804bddd7d4c
FS: () GS:8804bddc() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0048 CR3: 01806000 CR4: 003406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Stack:
8804bdddad00 8804ad089e00 0282
8804a9bd6d00 8804a1b27e00 8804a9bd6d00
88002ee88000 88049e127d28 814c3f3b 81311fc3
Call Trace:
[] netif_rx_internal+0x4b/0x170
[] ? swiotlb_tbl_unmap_single+0xf3/0x120
[] netif_rx_ni+0x27/0xc0
[] brcmf_netif_rx+0x49/0x70 [brcmfmac]
[] brcmf_msgbuf_process_rx+0x2b4/0x570 [brcmfmac]
[] ? __xen_set_pgd_hyper+0x57/0xd0
[] ? irq_forced_thread_fn+0x70/0x70
[] brcmf_proto_msgbuf_rx_trigger+0x31/0xe0 [brcmfmac]
[] brcmf_pcie_isr_thread+0x7f/0x110 [brcmfmac]
[] irq_thread_fn+0x20/0x50
[] irq_thread+0x12d/0x1c0
[] ? __schedule+0x2f5/0x7a0
[] ? wake_threads_waitq+0x30/0x30
[] ? irq_thread_dtor+0xb0/0xb0
[] kthread+0xd8/0xf0
[] ret_from_fork+0x1f/0x40
[] ? kthread_worker_fn+0x170/0x170
Code: 1c f5 60 9a 8e 81 9c 58 0f 1f 44 00 00 48 89 45 d0 fa 66 0f 1f
44 00 00 4c 8d bb 0c 01 00 00 4c 89 ff e8 5e 08 11 00 49 8b 56 20 <48>
8b 52 48 83 e2 01 74 10 8b 8b 08 01 00 00 8b 15 59 c5 42 00
RIP [] enqueue_to_backlog+0x56/0x260
RSP
CR2: 0048
Fixes: 9c349892ccc9 ("brcmfmac: revise handling events in receive path")
Reported-by: Rafal Milecki
Reported-by: Grey Christoforo
Reviewed-by: Pieter-Paul Giesberts
Reviewed-by: Arend Van Spriel
Reviewed-by: Hante Meuleman
Signed-off-by: Franky Lin
[ar...@broadcom.com: rephrased the commit message]
Signed-off-by: Arend van Spriel
---
drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
index 68f1ce0..2b9a2bc 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c
@@ -1157,6 +1157,8 @@ brcmf_msgbuf_process_rx_complete(struct brcmf_msgbuf
*msgbuf, void *buf)
brcmu_pkt_buf_free_skb(skb);
return;
}
+
+ skb->protocol = eth_type_trans(skb, ifp->ndev);
brcmf_netif_rx(ifp, skb);
}
--
2.1.0
--
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: wireless-testing on 4.7
On Thu, 2016-06-02 at 02:02 -0600, Reinoud Koornstra wrote: > On Wed, Jun 1, 2016 at 10:27 PM, Coelho, Luciano > wrote: > > On Wed, 2016-06-01 at 16:08 -0600, Reinoud Koornstra wrote: > > > On Wed, Jun 1, 2016 at 7:19 AM, Coelho, Luciano > > > wrote: > > > > On Wed, 2016-06-01 at 08:54 -0400, Bob Copeland wrote: > > > > > + Luca, Emmanuel > > > > > > > > Thanks, Bob! > > > > > > > > > > > > > On Tue, May 31, 2016 at 10:06:57PM -0600, Reinoud Koornstra > > > > > wrote: > > > > > > Today I compiled 4.6+ and pulled sources today > > > > > > iwlwifi isn't super smooth. > > > > > > > > > > I assume you mean wireless-testing, based on 4.7-rc1 (as this > > > > > email > > > > > is > > > > > in reply to my announcement of same). > > > > > > > > Yes, we need to know exactly what kernel you're using so we know > > > > what > > > > we're debugging. > > > > > > > > > > Yesterday this is what I did to obtain the latest source: > > > > > > git clone > > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > > > kernel_current > > > > > > This is the latest commit in that tree: > > > > > > commit 367d3fd50566a313946fa9c5b2116a81bf3807e4 > > > Merge: 5eca831 cf0d44d > > > Author: Linus Torvalds > > > Date: Tue May 31 09:43:24 2016 -0700 > > > > > > Merge branch 'for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux > > > > > > Pull s390 fixes from Martin Schwidefsky: > > > "Three bugs fixes and an update for the default configuration" > > > > > > * 'for-linus' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: > > > s390: fix info leak in do_sigsegv > > > s390/config: update default configuration > > > s390/bpf: fix recache skb->data/hlen for skb_vlan_push/pop > > > s390/bpf: reduce maximum program size to 64 KB > > > > Ah, okay. This has nothing to do with the wireless-testing tree. This > > is random commit in Linus' tree. I suggest that you use a release tag > > or such. For instance you could do this in Linus' tree to get the > > current release candidate for 4.7: > > > > git checkout v4.7-rc1 > > > > Or you could use the wireless-testing tree that Bob is maintaining, > > which is always based on an official release candidate (currently the > > above mentioned v4.7-rc1 release) plus the latest and greatest (and > > probably "brokenest" :P) wireless changes: > > > > git clone > > git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git > > > > Ok, i got this tree. > From the start it didn't work. > > [0.00] Linux version 4.7.0-rc1-wt+ > [SNIP] > [2.156875] iwlwifi :04:00.0: Direct firmware load for > iwlwifi-7260-17.ucode failed with error -2 > [2.157681] iwlwifi :04:00.0: Direct firmware load for > iwlwifi-7260-16.ucode failed with error -2 > [2.158438] iwlwifi :04:00.0: no suitable firmware found! This is happening pretty early, did you compile the iwlwifi driver into the kernel (instead of compiling them as modules)? There have been problems when it's in-kernel, so we recommend that you compile them as modules (unless strictly necessary). > I've attached the dmesg in it's entirety. > Booting back to 4.6: > > [ 17.987698] iwlwifi :04:00.0: loaded firmware version > 16.242414.0 op_mode iwlmvm > [ 18.269667] iwlwifi :04:00.0: Detected Intel(R) Dual Band > Wireless AC 7260, REV=0x144 This shows that you have iwlwifi-7260-16.ucode in your file system. But here we are reading it much later. So it's possible that the kernel cannot access the firmware at a very early stage (because the filesystem that contains it is not mounted yet) when you use in-kernel. So, first of all, please make sure they're built as modules. We can continue from there then. -- Cheers, Luca. -- 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: ath9k gpio request
Seems there are something wrong in the datasheet, try
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1122,8 +1122,8 @@ enum {
#define AR9300_NUM_GPIO 16
#define AR9330_NUM_GPIO 16
#define AR9340_NUM_GPIO 23
-#define AR9462_NUM_GPIO 10
-#define AR9485_NUM_GPIO 12
+#define AR9462_NUM_GPIO 14
+#define AR9485_NUM_GPIO 11
#define AR9531_NUM_GPIO 18
#define AR9550_NUM_GPIO 24
#define AR9561_NUM_GPIO 23
@@ -1139,8 +1139,8 @@ enum {
#define AR9300_GPIO_MASK0xF4FF
#define AR9330_GPIO_MASK0xF4FF
#define AR9340_GPIO_MASK0x000F
-#define AR9462_GPIO_MASK0x03FF
-#define AR9485_GPIO_MASK0x0FFF
+#define AR9462_GPIO_MASK0x3FFF
+#define AR9485_GPIO_MASK0x07FF
#define AR9531_GPIO_MASK0x000F
#define AR9550_GPIO_MASK0x000F
#define AR9561_GPIO_MASK0x000F
Thanks,
Miaoqing
From: Sudip Mukherjee
Sent: Wednesday, June 1, 2016 8:18 PM
To: Pan, Miaoqing; Kalle Valo
Cc: Stephen Rothwell; ath9k-devel; linux-n...@vger.kernel.org;
linux-ker...@vger.kernel.org; linux-wireless@vger.kernel.org;
ath9k-de...@lists.ath9k.org; net...@vger.kernel.org; Miaoqing Pan
Subject: Re: ath9k gpio request
On Wednesday 01 June 2016 04:42 PM, Sudip Mukherjee wrote:
> On Wednesday 01 June 2016 12:24 PM, Pan, Miaoqing wrote:
>> which chip ? And what's the GPIO number ?
>
> lspci -v reports:
> 09:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
> Adapter (rev 01)
> Subsystem: Foxconn International, Inc. Device e052
> Flags: bus master, fast devsel, latency 0, IRQ 19
> Memory at c050 (64-bit, non-prefetchable) [size=512K]
> Expansion ROM at c058 [disabled] [size=64K]
> Capabilities: [40] Power Management version 2
> Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
> Capabilities: [70] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting
> Capabilities: [140] Virtual Channel
> Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00
> Kernel driver in use: ath9k
>
> Any easy way to find out the gpio number or i can modify the module to
> find that out.
Its trying for GPIO 11 with label ath9k-rfkill.
The attached dmesg is with some modification as below.
diff --git a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
index 8b2895f9..23deea7 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2729,14 +2729,16 @@ static void ath9k_hw_gpio_cfg_wmac(struct ath_hw
*ah, u32 gpio, bool out,
static void ath9k_hw_gpio_request(struct ath_hw *ah, u32 gpio, bool out,
const char *label, u32 ah_signal_type)
{
- WARN_ON(gpio >= ah->caps.num_gpio_pins);
+// WARN_ON(gpio >= ah->caps.num_gpio_pins);
+
+ pr_err("sudip: %d %s\n", gpio, label);
if (BIT(gpio) & ah->caps.gpio_mask)
ath9k_hw_gpio_cfg_wmac(ah, gpio, out, ah_signal_type);
else if (AR_SREV_SOC(ah))
ath9k_hw_gpio_cfg_soc(ah, gpio, out, label);
- else
- WARN_ON(1);
+// else
+// WARN_ON(1);
}
Regards
Sudip
--
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 v2 2/2] ath10k: fix CCK h/w rates for QCA99X0 and newer chipsets
From: Mohammed Shafi Shajakhan
CCK hardware table mapping from QCA99X0 onwards got revised.
The CCK hardware rate values are in a proper order wrt. to
rate and preamble as below
ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
ATH10K_HW_RATE_REV2_CCK_LP_2M = 2,
ATH10K_HW_RATE_REV2_CCK_LP_5_5M = 3,
ATH10K_HW_RATE_REV2_CCK_LP_11M = 4,
ATH10K_HW_RATE_REV2_CCK_SP_2M = 5,
ATH10K_HW_RATE_REV2_CCK_SP_5_5M = 6,
ATH10K_HW_RATE_REV2_CCK_SP_11M = 7,
This results in reporting of rx frames (with CCK rates)
totally wrong for QCA99X0, QCA4019. Fix this by having
separate CCK rate table for these chipsets with rev2 suffix
and registering the correct rate mapping to mac80211 based on
the new hw_param (introduced) 'cck_rate_map_rev2' which shall
be true for any newchipsets from QCA99X0 onwards
Signed-off-by: Mohammed Shafi Shajakhan
---
[v2: Enabled the fix for QCA9984 - thanks Kalle]
drivers/net/wireless/ath/ath10k/core.c |3 +++
drivers/net/wireless/ath/ath10k/core.h |6 +
drivers/net/wireless/ath/ath10k/hw.h | 10
drivers/net/wireless/ath/ath10k/mac.c | 39 ++--
4 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index a003980..2692243 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -148,6 +148,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -170,6 +171,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.uart_pin = 7,
.otp_exe_param = 0x0700,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 15,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
@@ -227,6 +229,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.has_shifted_cc_wraparound = true,
.otp_exe_param = 0x001,
.continuous_frag_desc = true,
+ .cck_rate_map_rev2 = true,
.channel_counters_freq_hz = 125000,
.max_probe_resp_desc_thres = 24,
.hw_4addr_pad = ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 1852e0e..04cea23 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -716,6 +716,12 @@ struct ath10k {
*/
bool continuous_frag_desc;
+ /* CCK hardware rate table mapping for the newer chipsets
+* like QCA99X0, QCA4019 got revised. The CCK h/w rate values
+* are in a proper order with respect to the rate/preamble
+*/
+ bool cck_rate_map_rev2;
+
u32 channel_counters_freq_hz;
/* Mgmt tx descriptors threshold for limiting probe response
diff --git a/drivers/net/wireless/ath/ath10k/hw.h
b/drivers/net/wireless/ath/ath10k/hw.h
index f41c91c..4ed5be9 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -326,6 +326,16 @@ enum ath10k_hw_rate_cck {
ATH10K_HW_RATE_CCK_SP_2M,
};
+enum ath10k_hw_rate_rev2_cck {
+ ATH10K_HW_RATE_REV2_CCK_LP_1M = 1,
+ ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ ATH10K_HW_RATE_REV2_CCK_LP_11M,
+ ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ ATH10K_HW_RATE_REV2_CCK_SP_11M,
+};
+
enum ath10k_hw_4addr_pad {
ATH10K_HW_4ADDR_PAD_AFTER,
ATH10K_HW_4ADDR_PAD_BEFORE,
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 1dd415d..e7162db 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -62,6 +62,32 @@ static struct ieee80211_rate ath10k_rates[] = {
{ .bitrate = 540, .hw_value = ATH10K_HW_RATE_OFDM_54M },
};
+static struct ieee80211_rate ath10k_rates_rev2[] = {
+ { .bitrate = 10,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_1M },
+ { .bitrate = 20,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_2M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_2M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+ { .bitrate = 55,
+ .hw_value = ATH10K_HW_RATE_REV2_CCK_LP_5_5M,
+ .hw_value_short = ATH10K_HW_RATE_REV2_CCK_SP_5_5M,
+ .flags = IEEE80211_RATE_SHORT_PREAMBLE },
+ { .bitrate = 110,
+ .hw_value = ATH10K_HW_
[PATCH v2 1/2] ath10k: remove duplicate and unused rx rate flags
From: Mohammed Shafi Shajakhan
All these flags are not used and their use is completely
covered by 'ath10k_hw_rate_ofdm', 'ath10k_hw_rate_cck',
and RX_PPDU_START_RATE_FLAG
Signed-off-by: Mohammed Shafi Shajakhan
Patchwork-Id: 9129361
Signed-off-by: Kalle Valo
---
drivers/net/wireless/ath/ath10k/rx_desc.h | 39 -
1 file changed, 39 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/rx_desc.h
b/drivers/net/wireless/ath/ath10k/rx_desc.h
index 9ceebea..034e7a5 100644
--- a/drivers/net/wireless/ath/ath10k/rx_desc.h
+++ b/drivers/net/wireless/ath/ath10k/rx_desc.h
@@ -656,26 +656,6 @@ struct rx_msdu_end {
* Reserved: HW should fill with zero. FW should ignore.
*/
-#define RX_PPDU_START_SIG_RATE_SELECT_OFDM 0
-#define RX_PPDU_START_SIG_RATE_SELECT_CCK 1
-
-#define RX_PPDU_START_SIG_RATE_OFDM_48 0
-#define RX_PPDU_START_SIG_RATE_OFDM_24 1
-#define RX_PPDU_START_SIG_RATE_OFDM_12 2
-#define RX_PPDU_START_SIG_RATE_OFDM_6 3
-#define RX_PPDU_START_SIG_RATE_OFDM_54 4
-#define RX_PPDU_START_SIG_RATE_OFDM_36 5
-#define RX_PPDU_START_SIG_RATE_OFDM_18 6
-#define RX_PPDU_START_SIG_RATE_OFDM_9 7
-
-#define RX_PPDU_START_SIG_RATE_CCK_LP_11 0
-#define RX_PPDU_START_SIG_RATE_CCK_LP_5_5 1
-#define RX_PPDU_START_SIG_RATE_CCK_LP_2 2
-#define RX_PPDU_START_SIG_RATE_CCK_LP_1 3
-#define RX_PPDU_START_SIG_RATE_CCK_SP_11 4
-#define RX_PPDU_START_SIG_RATE_CCK_SP_5_5 5
-#define RX_PPDU_START_SIG_RATE_CCK_SP_2 6
-
#define HTT_RX_PPDU_START_PREAMBLE_LEGACY0x04
#define HTT_RX_PPDU_START_PREAMBLE_HT0x08
#define HTT_RX_PPDU_START_PREAMBLE_HT_WITH_TXBF 0x09
@@ -711,25 +691,6 @@ struct rx_msdu_end {
/* No idea what this flag means. It seems to be always set in rate. */
#define RX_PPDU_START_RATE_FLAG BIT(3)
-enum rx_ppdu_start_rate {
- RX_PPDU_START_RATE_OFDM_48M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_48M,
- RX_PPDU_START_RATE_OFDM_24M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_24M,
- RX_PPDU_START_RATE_OFDM_12M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_12M,
- RX_PPDU_START_RATE_OFDM_6M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_6M,
- RX_PPDU_START_RATE_OFDM_54M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_54M,
- RX_PPDU_START_RATE_OFDM_36M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_36M,
- RX_PPDU_START_RATE_OFDM_18M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_18M,
- RX_PPDU_START_RATE_OFDM_9M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_OFDM_9M,
-
- RX_PPDU_START_RATE_CCK_LP_11M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_11M,
- RX_PPDU_START_RATE_CCK_LP_5_5M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_5_5M,
- RX_PPDU_START_RATE_CCK_LP_2M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_2M,
- RX_PPDU_START_RATE_CCK_LP_1M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_LP_1M,
- RX_PPDU_START_RATE_CCK_SP_11M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_11M,
- RX_PPDU_START_RATE_CCK_SP_5_5M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_5_5M,
- RX_PPDU_START_RATE_CCK_SP_2M = RX_PPDU_START_RATE_FLAG |
ATH10K_HW_RATE_CCK_SP_2M,
-};
-
struct rx_ppdu_start {
struct {
u8 pri20_mhz;
--
1.7.9.5
--
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 for-4.7] brcmfmac: add eth_type_trans back for PCIe full dongle
On 2 June 2016 at 07:20, Arend Van Spriel wrote:
> Op 2 jun. 2016 06:55 schreef "Rafał Miłecki" :
>>
>> On 1 June 2016 at 23:13, Arend van Spriel wrote:
>> > From: Franky Lin
>> >
>> > A regression was introduced in commit 9c349892ccc9 ("brcmfmac: revise
>> > handling events in receive path") which moves eth_type_trans() call
>> > to brcmf_rx_frame(). Msgbuf layer doesn't use brcmf_rx_frame() but
>> > invokes
>> > brcmf_netif_rx() directly. In such case the Ethernet header was not
>> > stripped out resulting in null pointer dereference in the networking
>> > stack.
>> >
>> > (...)
>> >
>> > Reported-by: Grey Christoforo
>>
>> Well, I reported this as well, over a month ago :(
>
> Hi Rafał,
>
> Dived into my emails and shameful to admit you are right. Totally missed it.
> Sorry for unintended disregard.
It happens, thanks for the fix! :)
--
Rafał
--
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 v3] ath10k: Fix 10.4 extended peer stats update
From: Mohammed Shafi Shajakhan
10.4 'extended peer stats' will be not be appended with normal peer stats
data and they shall be coming in separate chunks. Fix this by maintaining
a separate linked list 'extender peer stats' for 10.4 and update
rx_duration for per station statistics. Also parse through beacon filter
(if enabled), to make sure we parse the extended peer stats properly.
This issue was exposed when more than one client is connected and
extended peer stats for 10.4 is enabled
The order for the stats is as below
S - standard peer stats, E- extended peer stats, B - beacon filter stats
{S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for 10.4")
Signed-off-by: Mohammed Shafi Shajakhan
---
[v1: addressed line wrap around comment from Kalle]
[v2: fixed ; in dummy inline function definition - thanks Sven Eckelmann]
[v3: removed wmi-op-version suggested by Kalle, introduced fw specifi hw param
for extd_stats]
drivers/net/wireless/ath/ath10k/core.c|3 ++
drivers/net/wireless/ath/ath10k/core.h|9 +
drivers/net/wireless/ath/ath10k/debug.c | 18 -
drivers/net/wireless/ath/ath10k/debug.h |8 ++--
drivers/net/wireless/ath/ath10k/debugfs_sta.c | 32 ++-
drivers/net/wireless/ath/ath10k/wmi.c | 53 ++---
drivers/net/wireless/ath/ath10k/wmi.h | 14 ++-
7 files changed, 117 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
index 9ccb69c..bfa96ac 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -181,6 +181,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board = QCA99X0_HW_2_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+ .extd_peer_stats = true,
},
},
{
@@ -203,6 +204,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board = QCA9984_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA99X0_BOARD_DATA_SZ,
.board_ext_size = QCA99X0_BOARD_EXT_DATA_SZ,
+ .extd_peer_stats = true,
},
},
{
@@ -261,6 +263,7 @@ static const struct ath10k_hw_params
ath10k_hw_params_list[] = {
.board = QCA4019_HW_1_0_BOARD_DATA_FILE,
.board_size = QCA4019_BOARD_DATA_SZ,
.board_ext_size = QCA4019_BOARD_EXT_DATA_SZ,
+ .extd_peer_stats = true,
},
},
};
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index bbc4e0f..da9b2a9 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -165,6 +165,13 @@ struct ath10k_fw_stats_peer {
u32 rx_duration;
};
+struct ath10k_fw_extd_stats_peer {
+ struct list_head list;
+
+ u8 peer_macaddr[ETH_ALEN];
+ u32 rx_duration;
+};
+
struct ath10k_fw_stats_vdev {
struct list_head list;
@@ -259,6 +266,7 @@ struct ath10k_fw_stats {
struct list_head pdevs;
struct list_head vdevs;
struct list_head peers;
+ struct list_head peers_extd;
};
#define ATH10K_TPC_TABLE_TYPE_FLAG 1
@@ -752,6 +760,7 @@ struct ath10k {
const char *board;
size_t board_size;
size_t board_ext_size;
+ bool extd_peer_stats;
} fw;
} hw_params;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c
b/drivers/net/wireless/ath/ath10k/debug.c
index 8fbb8f2..001c0a1 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -313,6 +313,16 @@ static void ath10k_fw_stats_peers_free(struct list_head
*head)
}
}
+static void ath10k_fw_extd_stats_peers_free(struct list_head *head)
+{
+ struct ath10k_fw_extd_stats_peer *i, *tmp;
+
+ list_for_each_entry_safe(i, tmp, head, list) {
+ list_del(&i->list);
+ kfree(i);
+ }
+}
+
static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
{
spin_lock_bh(&ar->data_lock);
@@ -320,6 +330,7 @@ static void ath10k_debug_fw_stats_reset(struct ath10k *ar)
ath10k_fw_stats_pdevs_free(&ar->debug.fw_stats.pdevs);
ath10k_fw_stats_vdevs_free(&ar->debug.fw_stats.vdevs);
ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
+ ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
spin_unlock_bh(&ar->data_lock);
}
@@ -334,6 +345,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar,
struct sk_buff *skb)
INIT_LIS
