* RE: [PATCH 2/2] cfg80211/nl80211: Add coalesce support
From: Bing Zhao @ 2013-05-22 18:46 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, linux-wireless@vger.kernel.org, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369246994.8207.24.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gPiA+IEJlZm9yZSB5b3UgbWFrZSBhbnkgY2hhbmdlcyAoSSBkaWRu
J3QgZ2V0IGFyb3VuZCB0byBjb21tZW50aW5nIG9uIHlvdXINCj4gPiA+IHBhdGNoZXMgeWVzdGVy
ZGF5KSwgSSB0aGluayB5b3UgaGF2ZSB0byBiZSBtb3JlIGNhcmVmdWwgd2l0aCB0aGUgcmVuYW1l
cw0KPiA+ID4gdG8gbm90IGJyZWFrIHRoZSBBUEkuIFBsZWFzZSBwcm92aWRlIGRlZmluZXMgb3Ig
c28gdG8gbm90IGJyZWFrDQo+ID4gPiBjb21waWxhdGlvbiBpbiB0aGUgcmVuYW1lLg0KPiA+DQo+
ID4gIltQQVRDSCAxLzJdIGNmZzgwMjExL25sODAyMTE6IHJlbmFtZSBwYWNrZXQgcGF0dGVybiBy
ZWxhdGVkDQo+ID4gc3RydWN0dXJlcyBhbmQgZW51bXMiIHNob3VsZCBoYXZlIHRha2VuIGNhcmUg
b2YgdGhlIHJlbmFtZXMuIFBsZWFzZQ0KPiA+IGxldCBtZSBrbm93IGlmIEkgbWlzc2VkIGFueXRo
aW5nIGhlcmUuDQo+IA0KPiBJdCBkaWQgaW4gdGhlIGtlcm5lbCwgSSB3YXMgcmVmZXJyaW5nIHRv
IHRoZSBjaGFuZ2VzIGluIG5sODAyMTEuaCwgYXMNCj4gZmFyIGFzIEkgY2FuIHRlbGwgdGhvc2Ug
YnJlYWsgZXhpc3RpbmcgdXNlcnNwYWNlIHRvb2xzLiBZb3Ugc2hvdWxkIGJlDQo+IGFibGUgdG8g
Y29tcGlsZSB0b29scyBsaWtlIGl3IGFuZCB3cGFfc3VwcGxpY2FudCB3aXRoIHRoZSBuZXcgbmw4
MDIxMS5oDQo+IHdpdGhvdXQgY2hhbmdpbmcgYW55dGhpbmcgaW4gdGhlbS4NCg0KSSBzZWUuIFRo
YW5rcyBmb3IgeW91ciBoZWxwLg0KDQpSZWdhcmRzLA0KQmluZw0KDQo=
^ permalink raw reply
* Re: [PATCH 7/7] rt2x00: rt2x00dev: use rt2x00dev->bcn->limit
From: John W. Linville @ 2013-05-22 18:53 UTC (permalink / raw)
To: Gabor Juhos
Cc: Gertjan van Wingerde, linux-wireless@vger.kernel.org,
rt2x00 Users List
In-Reply-To: <5182176B.20707@openwrt.org>
On Thu, May 02, 2013 at 09:36:11AM +0200, Gabor Juhos wrote:
> 2013.05.01. 22:08 keltezéssel, Gertjan van Wingerde írta:
> > On Wed, May 1, 2013 at 5:17 PM, Gabor Juhos <juhosg@openwrt.org> wrote:
> >> The beacon data queue is initialized already,
> >> so fetch the number of the queue entries from
> >> that instead of using the entry_num field of
> >> the data queue descriptor.
> >>
> >> The two values are the same, and the use of the
> >> rt2x00dev->bcn->limit value allows us to get rid
> >> of a superfluous pointer dereference.
> >>
> >> Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
> >
> > Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
>
> John, please ignore the last patch. This depends on other patches which were not
> included in the series. Without those it causes the following warning:
OK, dropped...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 00/32] BBP initialization split
From: John W. Linville @ 2013-05-22 19:01 UTC (permalink / raw)
To: stf_xl; +Cc: linux-wireless, users, gwingerde, ivdoorn, Helmut Schaa
In-Reply-To: <1368878635-4455-1-git-send-email-stf_xl@wp.pl>
On Sat, May 18, 2013 at 02:03:23PM +0200, stf_xl@wp.pl wrote:
> This series spits big and messy rt2800_init_bbp() procedure into small
> per chip (or few similar chips) subroutines.
Lots of refactoring here -- I trust Stanislaw, but it might be nice
to see an ACK from Gertjan, Helmut, and/or Ivo?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 1/3] mac80211: add STBC flag for radiotap
From: Johannes Berg @ 2013-05-22 19:24 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1368949136-6079-2-git-send-email-linux@rempel-privat.de>
On Sun, 2013-05-19 at 09:38 +0200, Oleksij Rempel wrote:
> + * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
> + RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
> @@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
> pos += 2;
>
> if (status->flag & RX_FLAG_HT) {
> + unsigned int stbc = status->flag & RX_FLAG_STBC_MASK;
> rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
> *pos++ = local->hw.radiotap_mcs_details;
> *pos = 0;
> @@ -267,6 +268,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
> *pos |= IEEE80211_RADIOTAP_MCS_BW_40;
> if (status->flag & RX_FLAG_HT_GF)
> *pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
> + if (stbc)
> + *pos |= (stbc >> RX_FLAG_STBC_SHIFT)
> + << IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
> pos++;
> *pos++ = status->rate_idx;
Here you forgot the "HAVE" bit.
> - IEEE80211_RADIOTAP_MCS_HAVE_BW;
> + IEEE80211_RADIOTAP_MCS_HAVE_BW |
> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
And here it's completely bogus.
johannes
^ permalink raw reply
* Re: [PATCH 00/32] BBP initialization split
From: Gertjan van Wingerde @ 2013-05-22 19:42 UTC (permalink / raw)
To: John W. Linville
Cc: stf_xl@wp.pl, linux-wireless@vger.kernel.org,
users@rt2x00.serialmonkey.com, ivdoorn@gmail.com, Helmut Schaa
In-Reply-To: <20130522190145.GJ2113@tuxdriver.com>
John,
Sent from my iPad
On 22 mei 2013, at 21:01, "John W. Linville" <linville@tuxdriver.com> wrote:
> On Sat, May 18, 2013 at 02:03:23PM +0200, stf_xl@wp.pl wrote:
>> This series spits big and messy rt2800_init_bbp() procedure into small
>> per chip (or few similar chips) subroutines.
>
> Lots of refactoring here -- I trust Stanislaw, but it might be nice
> to see an ACK from Gertjan, Helmut, and/or Ivo?
I believe Helmut already acked it, but I don't have issues with the patch set. So, you can add my
Acked-by: Gertjan van Wingerde <gwingerde@gmail.com>
to the whole series.
---
Gertjan
^ permalink raw reply
* Re: Ralink RT3290 proprietary drivers causing kernel panic
From: Gertjan van Wingerde @ 2013-05-22 19:55 UTC (permalink / raw)
To: Mohit; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <519D0D44.1040901@pdm.ac.in>
Hi Mohit,
Sent from my iPad
On 22 mei 2013, at 20:24, Mohit <mt1037ag11@pdm.ac.in> wrote:
> Hello,
>
> I am on openSUSE 12.3 with kernel 3.7.10-1.4-desktop, i wanted to try out the proprietary drivers for Ralink RT3290 so i downloaded the drivers from http://www.mediatek.com/_en/07_downloads/01_windows.php?sn=501 and compiled the drivers as mentioned on my thread here : https://forums.opensuse.org/english/get-technical-help-here/wireless/486975-rt3290-wireless-proprietary-drivers-not-working.html#post2557514. Everything compiled fine, openSUSE was able to scan and connect to access points after installation, but when i access the internet a kernel panic occurs after ~5sec (time varies based on the data usage). So i humbly request you to please provide the solution for the same, you can reach me through email or reply to my thread (probably faster as i don't check my email everyday).
>
You'll have to contact Mediatek about the drivers that you downloaded from their web site.
None of us on this mailing list have created this driver, nor are we supporting it.
Note that the standard kernel does contain support for the RT3290 chipset in its rt2x00 driver since kernel version 3.6 or 3.7, so you might give that a try.
---
Gertjan
^ permalink raw reply
* iwlwifi: problems with Intel 6235
From: Matt Taggart @ 2013-05-22 20:01 UTC (permalink / raw)
To: linux-wireless; +Cc: 709364
I am seeing problems with the "Intel Corporation Centrino Advanced-N
6235 [8086:088e]" card in my laptop.
When connected to a particular access point using 802.11n I get
frequent disconnects, dropped packets, erratic latency, and slow
data rates. Some access points don't have the problem.
I have tested both the Debian wheezy (3.2.41 based) and sid (3.8.13
based) kernels and both have the problems.
I reported the problem and details to the Debian BTS here
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709364
(cc'd) and I think it's the same problem as this ubuntu bug
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/836250
Let me know if you want me to try anything or need me to send more
info.
Thanks,
--
Matt Taggart
taggart@debian.org
^ permalink raw reply
* Re: Problem with iwlwifi kernel 3.9.0 and 3.9.2
From: Flavio @ 2013-05-22 20:20 UTC (permalink / raw)
To: Emmanuel Grumbach; +Cc: linux-wireless
In-Reply-To: <CANUX_P1zU-ntkdb33taPz=0qw2Xy-bp3jdA-C7eqXX-wbebMGA@mail.gmail.com>
On 22 May 2013 10:17, Emmanuel Grumbach <egrumbach@gmail.com> wrote:
>
> Please try the patch attached in
> https://bugzilla.kernel.org/show_bug.cgi?id=58341
Thank you.
I applied the patch and now the connection was immediate.
It's strange because the problem I've reported didn't happen the first
time I booted the OS,
even before applying the patch. So I will test this patch starting
from now and I will report
any issue if appropriate.
Thanks!
--
Flavio
^ permalink raw reply
* Re: Ralink RT3290 proprietary drivers causing kernel panic
From: Jakub Kiciński @ 2013-05-22 20:22 UTC (permalink / raw)
To: Mohit; +Cc: linux-wireless
In-Reply-To: <519D0D44.1040901@pdm.ac.in>
On Wed, 22 May 2013 23:54:04 +0530, Mohit wrote:
> Hello,
>
> I am on openSUSE 12.3 with kernel 3.7.10-1.4-desktop, i
> wanted to try out the proprietary drivers for Ralink RT3290 so i
> downloaded the drivers from
> http://www.mediatek.com/_en/07_downloads/01_windows.php?sn=501 and
> compiled the drivers as mentioned on my thread here :
> https://forums.opensuse.org/english/get-technical-help-here/wireless/486975-rt3290-wireless-proprietary-drivers-not-working.html#post2557514.
> Everything compiled fine, openSUSE was able to scan and connect to
> access points after installation, but when i access the internet a
> kernel panic occurs after ~5sec (time varies based on the data usage).
> So i humbly request you to please provide the solution for the same, you
> can reach me through email or reply to my thread (probably faster as i
> don't check my email everyday).
I think vendor drivers crash on 64bit kernel because they
have faulty skb offsets handling. It's usually enough to fix
GCC warnings to make them work.
Having said that - I agree with Gertjan, you should really try
rt2800 from your kernel (or preferably from compat-wireless)
and if that doesn't work ask the vendor for help.
-- Kuba
^ permalink raw reply
* skb_under_panic in ath9k
From: Marc Kleine-Budde @ 2013-05-22 22:02 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 5834 bytes --]
Hello,
I'm on a kirkwood based armv5 system with an USB attached TP-Link
TL-WN821N - Atheros AR7010+AR9287, [1]. the wlan is running in AP mode
with hostapd-1.0. The kernel is v3.8.12 from debian (3.8-1-kirkwood #1
Debian 3.8.12-1).
The system crashes repeatedly after about one week with the following
oops:
[633625.401875] skbuff: skb_under_panic: text:bf501028 len:128 put:8 head:d2788800 data:d27887fe tail:0xd278887e end:0xd2788f40 dev:wlan1
[633625.414180] ------------[ cut here ]------------
[633625.418909] kernel BUG at /build/buildd-linux_3.8.12-1-armel-7F6kBx/linux-3.8.12/net/core/skbuff.c:145!
[633625.428430] Internal error: Oops - BUG: 0 [#1] ARM
[633625.433322] Modules linked in:
[...]
[633625.583170] CPU: 0 Not tainted (3.8-1-kirkwood #1 Debian 3.8.12-1)
[633625.589821] PC is at skb_push+0x6c/0x84
[633625.593763] LR is at skb_push+0x6c/0x84
[633625.597707] pc : [<c0282990>] lr : [<c0282990>] psr: 20000013
[633625.597707] sp : c04c1d50 ip : 000008f8 fp : df04ea54
[633625.609404] r10: 00000002 r9 : 00000008 r8 : df00dca8
[633625.614734] r7 : 00000006 r6 : c04410a0 r5 : d278887e r4 : d2788800
[633625.621378] r3 : c04d328c r2 : 20000093 r1 : 00000001 r0 : 00000079
[633625.628015] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[633625.635443] Control: 0005317f Table: 1f224000 DAC: 00000017
[633625.641295] Process swapper (pid: 0, stack limit = 0xc04c01b8)
[633625.647241] Stack: (0xc04c1d50 to 0xc04c2000)
[633625.657414] 1d40: 00000008 d2788800 d27887fe d278887e
[633625.666101] 1d60: d2788f40 df04e000 df00dc00 df2e0c00 00000078 bf501028 df2e0c00 dfba3120
[633625.675025] 1d80: d278882a df04e9a0 00000000 bf504110 dfb3ce20 00000201 00000000 00084502
[633625.683954] 1da0: 00000001 df2e0c00 dfba3120 00000008 00000002 c04c1df4 00000000 00000001
[633625.693553] 1dc0: 0000006a bf5058b0 00000000 c04c1df4 c04c1e30 dfba2300 c151ff18 df04e9a0
[633625.702041] 1de0: c04c1e30 bf37560c 0000000c 00004288 c04c1e2c c151ff18 0000006a df2e0c00
[633625.710540] 1e00: dfba2300 00000000 0000006a df04e462 00000000 00000001 60000013 bf375760
[633625.718904] 1e20: 00000001 c14c19a0 c14c0460 00000000 c04c1e30 c04c1e30 00000000 dfba2300
[633625.727374] 1e40: df04e460 c151fc00 de5af200 00000002 00000002 dfba2300 dfba2308 dfba28a8
[633625.787263] 1e60: c04c1e7c dfba28ac df2e0c00 bf376d58 c0508ae0 00000000 0000012c 00000080
[633625.798914] 1e80: 03c66eab c0508ae8 c04d4c68 c04d3494 00000000 00000000 00000006 00000100
[633625.810249] 1ea0: c052b3a0 00000009 c052b3c0 c0026e2c 00000001 00000018 c04c0000 c0026644
[633625.818620] 1ec0: c04d8f74 c1484260 1144b25a c04d8f74 00000000 00200000 c04c1f4c 00000013
[633625.831230] 1ee0: 00000000 fed20200 c04c1f4c 00000000 56251311 c04d0420 00000000 c0026a2c
[633625.842695] 1f00: 00002000 c000f28c c004e27c c0271318 20000013 c000df94 c04c1f60 60000013
[633625.853824] 1f20: 000e32dc 0002404f b5def004 0002404f c04d0698 00000000 00000000 56251311
[633625.864745] 1f40: c04d0420 00000000 00000003 c04c1f60 c004e27c c0271318 20000013 ffffffff
[633625.875714] 1f60: b5ed22e0 0002404f 0084d405 00000000 00000000 c04d0698 00000000 c04d0698
[633625.886646] 1f80: 00000000 c04d0420 004b8074 c0270e88 c04d0698 00000000 c050918c c0271014
[633625.898317] 1fa0: c04c0000 c0509b28 c04cc1cc c096f0e0 00004000 c000f484 c04c8c20 00000000
[633625.909787] 1fc0: c04b9650 c0498764 ffffffff ffffffff c0498284 00000000 00000000 c04b9650
[633625.918159] 1fe0: 00000000 00053175 c04c8048 c04b964c c04cc1c4 00008040 00000000 00000000
[633625.926557] [<c0282990>] (skb_push+0x6c/0x84) from [<bf501028>] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc])
[633625.937158] [<bf501028>] (htc_issue_send.constprop.0+0x28/0x68 [ath9k_htc]) from [<bf504110>] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc])
[633625.949877] [<bf504110>] (ath9k_htc_tx_start+0x290/0x2a4 [ath9k_htc]) from [<bf5058b0>] (ath9k_htc_tx+0x98/0xcc [ath9k_htc])
[633625.961458] [<bf5058b0>] (ath9k_htc_tx+0x98/0xcc [ath9k_htc]) from [<bf37560c>] (__ieee80211_tx+0x210/0x2a8 [mac80211])
[633625.972695] [<bf37560c>] (__ieee80211_tx+0x210/0x2a8 [mac80211]) from [<bf375760>] (ieee80211_tx+0xbc/0xc4 [mac80211])
[633625.983816] [<bf375760>] (ieee80211_tx+0xbc/0xc4 [mac80211]) from [<bf376d58>] (ieee80211_tx_pending+0xf0/0x194 [mac80211])
[633625.995326] [<bf376d58>] (ieee80211_tx_pending+0xf0/0x194 [mac80211]) from [<c0026e2c>] (tasklet_action+0x84/0xcc)
[633626.005905] [<c0026e2c>] (tasklet_action+0x84/0xcc) from [<c0026644>] (__do_softirq+0xdc/0x204)
[633626.014750] [<c0026644>] (__do_softirq+0xdc/0x204) from [<c0026a2c>] (irq_exit+0x40/0x8c)
[633626.023103] [<c0026a2c>] (irq_exit+0x40/0x8c) from [<c000f28c>] (handle_IRQ+0x64/0x84)
[633626.031193] [<c000f28c>] (handle_IRQ+0x64/0x84) from [<c000df94>] (__irq_svc+0x34/0x78)
[633626.039412] [<c000df94>] (__irq_svc+0x34/0x78) from [<c0271318>] (cpuidle_wrap_enter+0x54/0x9c)
[633626.048331] [<c0271318>] (cpuidle_wrap_enter+0x54/0x9c) from [<c0270e88>] (cpuidle_enter_state+0x14/0x68)
[633626.058162] [<c0270e88>] (cpuidle_enter_state+0x14/0x68) from [<c0271014>] (cpuidle_idle_call+0x138/0x25c)
[633626.067998] [<c0271014>] (cpuidle_idle_call+0x138/0x25c) from [<c000f484>] (cpu_idle+0x68/0xc8)
[633626.076852] [<c000f484>] (cpu_idle+0x68/0xc8) from [<c0498764>] (start_kernel+0x2b4/0x30c)
[633626.146230] Code: e58dc014 e59f1014 e59f0014 eb0308b0 (e7f001f2)
[633626.152520] ---[ end trace ee5dbceea3381e46 ]---
[633626.157249] Kernel panic - not syncing: Fatal exception in interrupt
Has the problem been fixed already? I can update the kernel to a recent
version if needed.
regards,
Marc
[1] lsusb:
Bus 001 Device 004: ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [RFC v4] cfg80211: Android P2P-Device workaround
From: YanBo @ 2013-05-23 3:18 UTC (permalink / raw)
To: Johannes Berg; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <1367922058.8328.2.camel@jlt4.sipsolutions.net>
After create the p2p0 wireless device. When call the
cfg80211_conn_work, it will crash cause this function will use
wdev->netdev which is invalid, below patch will skip the further
operation when get the info if the wireless
device is P2P device. please review, thanks.
BR /Yanbo
From: Yanbo Li <dreamfly281@gmail.com>
Date: Thu, 23 May 2013 11:05:20 +0800
Subject: [PATCH] Add the P2P device condition at cfg80211_conn_work to avoid
crash
Signed-off-by: Yanbo Li <dreamfly281@gmail.com>
---
net/wireless/sme.c | 6 ++++++
1 files changed, 6 insertions(+)
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index 8019b39..232194c 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -232,6 +232,12 @@ void cfg80211_conn_work(struct work_struct *work)
list_for_each_entry(wdev, &rdev->wdev_list, list) {
wdev_lock(wdev);
+#ifdef CONFIG_CFG80211_ANDROID_P2P_HACK
+ if (wdev->iftype == NL80211_IFTYPE_P2P_DEVICE) {
+ wdev_unlock(wdev);
+ continue;
+ }
+#endif
if (!netif_running(wdev->netdev)) {
wdev_unlock(wdev);
continue;
--
1.7.9.5
^ permalink raw reply related
* ath9k_htc p2p finding issue
From: Zhou, Robie @ 2013-05-23 5:58 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Deng, Flavian
Hi all,
We meet some problem when try P2P by using ath9k_htc compat-wireless-v3.6.8-1.
When using the compat-wireless-v3.6.8-1, AR9271 could find other P2P devices, but other P2P devices couldn't find AR9271 (runs ath9k_htc) because driver couldn't report Probe Request to wpa_supplicant.
And this issue could not be observed when using compat-wireless-v3.0.9-1, by compare with compat-wireless-v3.0.9-1, ATH9K RX filter is set correctly after got "Report Probe Request" command from wpa_supplicant, but ATH9K driver couldn't get "Probe Request" frame(I add debug msg in ieee80211_rx_handlers() function).
<7>[ 205.784118] [DF_DBG] [ieee80211_mgmt_frame_register] : local->probe_req_reg = 1;
<7>[ 205.830232] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
<7>[ 205.832858] [DF_DBG] [ieee80211_configure_filter] : new_flags |= FIF_PROBE_REQ;
<7>[ 205.833101] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x287; -> ath9k_hw_setrxfilter
<7>[ 205.878230] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x287; -> ath9k_hw_setrxfilter
<7>[ 205.882556] [DF_DBG] [ieee80211_configure_filter] : new_flags |= FIF_PROBE_REQ;
<7>[ 205.883606] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x287; -> ath9k_hw_setrxfilter
<7>[ 206.010886] [DF_DBG] [ieee80211_mgmt_frame_register] : local->probe_req_reg = 0;
<7>[ 206.036237] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x287; -> ath9k_hw_setrxfilter
<7>[ 206.043357] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x17; -> ath9k_hw_setrxfilter
<7>[ 206.044107] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x17; -> ath9k_hw_setrxfilter
<7>[ 206.090106] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
<7>[ 206.160734] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
<7>[ 206.230740] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
Did anyone ever meet this issue? Any suggestion for further debugging this issue?
Thanks
Robie
^ permalink raw reply
* [PATCH v2 1/3] mac80211: add STBC flag for radiotap
From: Oleksij Rempel @ 2013-05-23 7:17 UTC (permalink / raw)
To: ath9k-devel, linux-wireless, johannes; +Cc: Oleksij Rempel
In-Reply-To: <1369250674.8207.26.camel@jlt4.sipsolutions.net>
revision:
- v2. set HAVE_STBC only if it is present.
do not set STBC flag on TX packets.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
include/net/ieee80211_radiotap.h | 7 +++++++
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 13 ++++++++++++-
3 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index c399963..c6d07cb 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -269,6 +269,7 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_HAVE_GI 0x04
#define IEEE80211_RADIOTAP_MCS_HAVE_FMT 0x08
#define IEEE80211_RADIOTAP_MCS_HAVE_FEC 0x10
+#define IEEE80211_RADIOTAP_MCS_HAVE_STBC 0x20
#define IEEE80211_RADIOTAP_MCS_BW_MASK 0x03
#define IEEE80211_RADIOTAP_MCS_BW_20 0
@@ -278,6 +279,12 @@ enum ieee80211_radiotap_type {
#define IEEE80211_RADIOTAP_MCS_SGI 0x04
#define IEEE80211_RADIOTAP_MCS_FMT_GF 0x08
#define IEEE80211_RADIOTAP_MCS_FEC_LDPC 0x10
+#define IEEE80211_RADIOTAP_MCS_STBC_MASK 0x60
+#define IEEE80211_RADIOTAP_MCS_STBC_1 1
+#define IEEE80211_RADIOTAP_MCS_STBC_2 2
+#define IEEE80211_RADIOTAP_MCS_STBC_3 3
+
+#define IEEE80211_RADIOTAP_MCS_STBC_SHIFT 5
/* For IEEE80211_RADIOTAP_AMPDU_STATUS */
#define IEEE80211_RADIOTAP_AMPDU_REPORT_ZEROLEN 0x0001
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 885898a..16705a9 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -805,6 +805,7 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info *info)
* on this subframe
* @RX_FLAG_AMPDU_DELIM_CRC_KNOWN: The delimiter CRC field is known (the CRC
* is stored in the @ampdu_delimiter_crc field)
+ * @RX_FLAG_STBC_MASK: STBC 2 bit bitmask. 1 - Nss=1, 2 - Nss=2, 3 - Nss=3
*/
enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR = BIT(0),
@@ -832,8 +833,11 @@ enum mac80211_rx_flags {
RX_FLAG_80MHZ = BIT(23),
RX_FLAG_80P80MHZ = BIT(24),
RX_FLAG_160MHZ = BIT(25),
+ RX_FLAG_STBC_MASK = BIT(26) | BIT(27),
};
+#define RX_FLAG_STBC_SHIFT 26
+
/**
* struct ieee80211_rx_status - receive status
*
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 8e29526..db7c68a 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,8 +258,16 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
pos += 2;
if (status->flag & RX_FLAG_HT) {
+ unsigned int stbc = status->flag & RX_FLAG_STBC_MASK;
rthdr->it_present |= cpu_to_le32(1 << IEEE80211_RADIOTAP_MCS);
- *pos++ = local->hw.radiotap_mcs_details;
+
+ /* MCS known field */
+ *pos = local->hw.radiotap_mcs_details;
+ if (stbc)
+ *pos |= IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ *pos++;
+
+ /* MCS flags field */
*pos = 0;
if (status->flag & RX_FLAG_SHORT_GI)
*pos |= IEEE80211_RADIOTAP_MCS_SGI;
@@ -267,6 +275,9 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
*pos |= IEEE80211_RADIOTAP_MCS_BW_40;
if (status->flag & RX_FLAG_HT_GF)
*pos |= IEEE80211_RADIOTAP_MCS_FMT_GF;
+ if (stbc)
+ *pos |= (stbc >> RX_FLAG_STBC_SHIFT)
+ << IEEE80211_RADIOTAP_MCS_STBC_SHIFT;
pos++;
*pos++ = status->rate_idx;
}
--
1.8.1.2
^ permalink raw reply related
* Re: ath9k_htc p2p finding issue
From: Arend van Spriel @ 2013-05-23 8:12 UTC (permalink / raw)
To: Zhou, Robie; +Cc: linux-wireless@vger.kernel.org, Deng, Flavian
In-Reply-To: <A75A50687AD91044B3B81AB78993F668447D2F7F@NASANEXD02E.na.qualcomm.com>
On 05/23/2013 07:58 AM, Zhou, Robie wrote:
> Hi all,
>
> We meet some problem when try P2P by using ath9k_htc compat-wireless-v3.6.8-1.
>
> When using the compat-wireless-v3.6.8-1, AR9271 could find other P2P devices, but other P2P devices couldn't find AR9271 (runs ath9k_htc) because driver couldn't report Probe Request to wpa_supplicant.
>
> And this issue could not be observed when using compat-wireless-v3.0.9-1, by compare with compat-wireless-v3.0.9-1, ATH9K RX filter is set correctly after got "Report Probe Request" command from wpa_supplicant, but ATH9K driver couldn't get "Probe Request" frame(I add debug msg in ieee80211_rx_handlers() function).
>
> <7>[ 205.784118] [DF_DBG] [ieee80211_mgmt_frame_register] : local->probe_req_reg = 1;
> <7>[ 205.830232] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
> <7>[ 205.832858] [DF_DBG] [ieee80211_configure_filter] : new_flags |= FIF_PROBE_REQ;
> <7>[ 205.833101] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x287; -> ath9k_hw_setrxfilter
> <7>[ 205.878230] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x287; -> ath9k_hw_setrxfilter
> <7>[ 205.882556] [DF_DBG] [ieee80211_configure_filter] : new_flags |= FIF_PROBE_REQ;
> <7>[ 205.883606] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x287; -> ath9k_hw_setrxfilter
>
> <7>[ 206.010886] [DF_DBG] [ieee80211_mgmt_frame_register] : local->probe_req_reg = 0;
> <7>[ 206.036237] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x287; -> ath9k_hw_setrxfilter
> <7>[ 206.043357] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x17; -> ath9k_hw_setrxfilter
> <7>[ 206.044107] [DF_DBG] [ath9k_htc_configure_filter] rfilt = 0x17; -> ath9k_hw_setrxfilter
> <7>[ 206.090106] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
> <7>[ 206.160734] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
> <7>[ 206.230740] [DF_DBG] [ath9k_htc_opmode_init] rfilt = 0x17; -> ath9k_hw_setrxfilter
>
>
> Did anyone ever meet this issue? Any suggestion for further debugging this issue?
Did you confirm ath9k_htc is handing over probe requests to mac80211?
Might be useful to add debugging in prepare_for_handlers() instead.
Regards,
Arend
^ permalink raw reply
* [PATCH -next] wil6210: use kfree_skb() instead of kfree()
From: Wei Yongjun @ 2013-05-23 9:10 UTC (permalink / raw)
To: qca_vkondrat, linville; +Cc: yongjun_wei, linux-wireless, wil6210
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Use kfree_skb() instead of kfree() to free sk_buff.
Introduced by commit e270045b569cc7030abd29857f3a4e7906524ec0
(wil6210: Sanity check for reported DMA length)
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
drivers/net/wireless/ath/wil6210/txrx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/txrx.c b/drivers/net/wireless/ath/wil6210/txrx.c
index 082f76b..00dffed 100644
--- a/drivers/net/wireless/ath/wil6210/txrx.c
+++ b/drivers/net/wireless/ath/wil6210/txrx.c
@@ -369,7 +369,7 @@ static struct sk_buff *wil_vring_reap_rx(struct wil6210_priv *wil,
if (dmalen > sz) {
wil_err(wil, "Rx size too large: %d bytes!\n", dmalen);
- kfree(skb);
+ kfree_skb(skb);
return NULL;
}
skb_trim(skb, dmalen);
^ permalink raw reply related
* Re: [RFC v4] cfg80211: Android P2P-Device workaround
From: Johannes Berg @ 2013-05-23 9:40 UTC (permalink / raw)
To: YanBo; +Cc: Arend van Spriel, linux-wireless
In-Reply-To: <CAFuUQkgTbf0959=xCUCA1AR-Vxv7Cj90GC4Ae7+BQUqme70ksQ@mail.gmail.com>
On Thu, 2013-05-23 at 11:18 +0800, YanBo wrote:
> After create the p2p0 wireless device. When call the
> cfg80211_conn_work
How is that getting called in the first place? I'm not saying there's no
bug, but your suggested fix is completely pointless, we shouldn't get
there.
johannes
^ permalink raw reply
* [PATCH 3.10 1/3] ath9k_hw: fix spur mitigation issues on AR934x
From: Felix Fietkau @ 2013-05-23 10:20 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
Do not subtract spur power from noise floor on this chip, as it can lead
to packet loss and other connectivity issues.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_phy.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_phy.c b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
index 2bf6548..e1714d7 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
@@ -334,7 +334,8 @@ static void ar9003_hw_spur_ofdm(struct ath_hw *ah,
REG_RMW_FIELD(ah, AR_PHY_SPUR_REG,
AR_PHY_SPUR_REG_EN_VIT_SPUR_RSSI, 1);
- if (REG_READ_FIELD(ah, AR_PHY_MODE,
+ if (!AR_SREV_9340(ah) &&
+ REG_READ_FIELD(ah, AR_PHY_MODE,
AR_PHY_MODE_DYNAMIC) == 0x1)
REG_RMW_FIELD(ah, AR_PHY_SPUR_REG,
AR_PHY_SPUR_REG_ENABLE_NF_RSSI_SPUR_MIT, 1);
--
1.8.0.2
^ permalink raw reply related
* [PATCH 3.10 3/3] ath9k_hw: improve performance for AR934x v1.3+
From: Felix Fietkau @ 2013-05-23 10:20 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
In-Reply-To: <1369304456-74526-1-git-send-email-nbd@openwrt.org>
AR934x v1.3 no longer needs the DCU backoff reduction workaround for
preventing rx overruns, but in turn needs the number of usable Tx
buffers to be reduced slightly.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/hw.c | 15 ++++++++++-----
drivers/net/wireless/ath/ath9k/mac.c | 2 +-
drivers/net/wireless/ath/ath9k/reg.h | 9 +++++++++
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 40331f4..2caf7de 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1172,6 +1172,7 @@ u32 ath9k_regd_get_ctl(struct ath_regulatory *reg, struct ath9k_channel *chan)
static inline void ath9k_hw_set_dma(struct ath_hw *ah)
{
struct ath_common *common = ath9k_hw_common(ah);
+ int txbuf_size;
ENABLE_REGWRITE_BUFFER(ah);
@@ -1225,13 +1226,17 @@ static inline void ath9k_hw_set_dma(struct ath_hw *ah)
* So set the usable tx buf size also to half to
* avoid data/delimiter underruns
*/
- REG_WRITE(ah, AR_PCU_TXBUF_CTRL,
- AR_9285_PCU_TXBUF_CTRL_USABLE_SIZE);
- } else if (!AR_SREV_9271(ah)) {
- REG_WRITE(ah, AR_PCU_TXBUF_CTRL,
- AR_PCU_TXBUF_CTRL_USABLE_SIZE);
+ txbuf_size = AR_9285_PCU_TXBUF_CTRL_USABLE_SIZE;
+ } else if (AR_SREV_9340_13_OR_LATER(ah)) {
+ /* Uses fewer entries for AR934x v1.3+ to prevent rx overruns */
+ txbuf_size = AR_9340_PCU_TXBUF_CTRL_USABLE_SIZE;
+ } else {
+ txbuf_size = AR_PCU_TXBUF_CTRL_USABLE_SIZE;
}
+ if (!AR_SREV_9271(ah))
+ REG_WRITE(ah, AR_PCU_TXBUF_CTRL, txbuf_size);
+
REGWRITE_BUFFER_FLUSH(ah);
if (AR_SREV_9300_20_OR_LATER(ah))
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..566109a 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -410,7 +410,7 @@ bool ath9k_hw_resettxqueue(struct ath_hw *ah, u32 q)
REG_WRITE(ah, AR_QMISC(q), AR_Q_MISC_DCU_EARLY_TERM_REQ);
- if (AR_SREV_9340(ah))
+ if (AR_SREV_9340(ah) && !AR_SREV_9340_13_OR_LATER(ah))
REG_WRITE(ah, AR_DMISC(q),
AR_D_MISC_CW_BKOFF_EN | AR_D_MISC_FRAG_WAIT_EN | 0x1);
else
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 9c056a8..f7c90cc 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -798,6 +798,10 @@
#define AR_SREV_REVISION_9485_10 0
#define AR_SREV_REVISION_9485_11 1
#define AR_SREV_VERSION_9340 0x300
+#define AR_SREV_REVISION_9340_10 0
+#define AR_SREV_REVISION_9340_11 1
+#define AR_SREV_REVISION_9340_12 2
+#define AR_SREV_REVISION_9340_13 3
#define AR_SREV_VERSION_9580 0x1C0
#define AR_SREV_REVISION_9580_10 4 /* AR9580 1.0 */
#define AR_SREV_VERSION_9462 0x280
@@ -897,6 +901,10 @@
#define AR_SREV_9340(_ah) \
(((_ah)->hw_version.macVersion == AR_SREV_VERSION_9340))
+#define AR_SREV_9340_13_OR_LATER(_ah) \
+ (AR_SREV_9340((_ah)) && \
+ ((_ah)->hw_version.macRev >= AR_SREV_REVISION_9340_13))
+
#define AR_SREV_9285E_20(_ah) \
(AR_SREV_9285_12_OR_LATER(_ah) && \
((REG_READ(_ah, AR_AN_SYNTH9) & 0x7) == 0x1))
@@ -1883,6 +1891,7 @@ enum {
#define AR_PCU_TXBUF_CTRL_SIZE_MASK 0x7FF
#define AR_PCU_TXBUF_CTRL_USABLE_SIZE 0x700
#define AR_9285_PCU_TXBUF_CTRL_USABLE_SIZE 0x380
+#define AR_9340_PCU_TXBUF_CTRL_USABLE_SIZE 0x500
#define AR_PCU_MISC_MODE2 0x8344
#define AR_PCU_MISC_MODE2_MGMT_CRYPTO_ENABLE 0x00000002
--
1.8.0.2
^ permalink raw reply related
* [PATCH 3.10 2/3] ath9k_hw: fix host interface reset on AR934x
From: Felix Fietkau @ 2013-05-23 10:20 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof
In-Reply-To: <1369304456-74526-1-git-send-email-nbd@openwrt.org>
If a local bus timeout has been detected, the host interface needs to be
reset to clear the errors. AR934x uses a different synchronous interrupt
bit to indicate this, so the check needs to be fixed.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/hw.c | 10 +++++++---
drivers/net/wireless/ath/ath9k/reg.h | 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index a263ccc..40331f4 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1306,9 +1306,13 @@ static bool ath9k_hw_set_reset(struct ath_hw *ah, int type)
AR_RTC_RC_COLD_RESET | AR_RTC_RC_WARM_RESET;
} else {
tmpReg = REG_READ(ah, AR_INTR_SYNC_CAUSE);
- if (tmpReg &
- (AR_INTR_SYNC_LOCAL_TIMEOUT |
- AR_INTR_SYNC_RADM_CPL_TIMEOUT)) {
+ if (AR_SREV_9340(ah))
+ tmpReg &= AR9340_INTR_SYNC_LOCAL_TIMEOUT;
+ else
+ tmpReg &= AR_INTR_SYNC_LOCAL_TIMEOUT |
+ AR_INTR_SYNC_RADM_CPL_TIMEOUT;
+
+ if (tmpReg) {
u32 val;
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, 0);
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 5c4ab50..9c056a8 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -1007,6 +1007,8 @@ enum {
AR_INTR_SYNC_LOCAL_TIMEOUT |
AR_INTR_SYNC_MAC_SLEEP_ACCESS),
+ AR9340_INTR_SYNC_LOCAL_TIMEOUT = 0x00000010,
+
AR_INTR_SYNC_SPURIOUS = 0xFFFFFFFF,
};
--
1.8.0.2
^ permalink raw reply related
* [RFT/RFC 0/4] iwlegacy: workaround for firmware frame tx rejection
From: Stanislaw Gruszka @ 2013-05-23 12:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Jake Edge, Johannes Berg, Stanislaw Gruszka
Jake, please test this set and check if it not cause association
problems you reported earlier this month.
Please apply it together with this mac80211 patch:
http://marc.info/?l=linux-wireless&m=136879090123023&w=2
which I already posted and is queued to upstream. Not having
it may cause troubles and influence negatively this set test.
Johannes, is need to check beacon bssid or even if rx frame
is a beacon to unblock queues? I think if we receive any frame
(not necessary beacon or our bssid beacon) on passive channel,
that mean we can use that channel. But that depend how firmware
is implemented, if firmware require our bssid beacon to unblock
channel, driver of course need that too.
Stanislaw Gruszka (4):
iwlegacy: small refactoring of il_{stop,wake}_queue
iwlegacy: add il_{stop,wake}_queues_by_reason functions
iwlegacy: workaround for firmware frame tx rejection
Revert "iwl4965: workaround connection regression on passive channel"
drivers/net/wireless/iwlegacy/4965-mac.c | 22 ++++++++++++++++-
drivers/net/wireless/iwlegacy/common.c | 10 ++++++++
drivers/net/wireless/iwlegacy/common.h | 41 ++++++++++++++++++++++++++++----
3 files changed, 68 insertions(+), 5 deletions(-)
--
1.7.11.7
^ permalink raw reply
* [RFT/RFC 1/4] iwlegacy: small refactoring of il_{stop,wake}_queue
From: Stanislaw Gruszka @ 2013-05-23 12:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Jake Edge, Johannes Berg, Stanislaw Gruszka
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/common.h | 19 +++++++++++++++----
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index f8246f2..c6956ea 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -2257,6 +2257,19 @@ il_set_swq_id(struct il_tx_queue *txq, u8 ac, u8 hwq)
}
static inline void
+_il_wake_queue(struct il_priv *il, u8 ac)
+{
+ if (atomic_dec_return(&il->queue_stop_count[ac]) <= 0)
+ ieee80211_wake_queue(il->hw, ac);
+}
+
+static inline void
+_il_stop_queue(struct il_priv *il, u8 ac)
+{
+ if (atomic_inc_return(&il->queue_stop_count[ac]) > 0)
+ ieee80211_stop_queue(il->hw, ac);
+}
+static inline void
il_wake_queue(struct il_priv *il, struct il_tx_queue *txq)
{
u8 queue = txq->swq_id;
@@ -2264,8 +2277,7 @@ il_wake_queue(struct il_priv *il, struct il_tx_queue *txq)
u8 hwq = (queue >> 2) & 0x1f;
if (test_and_clear_bit(hwq, il->queue_stopped))
- if (atomic_dec_return(&il->queue_stop_count[ac]) <= 0)
- ieee80211_wake_queue(il->hw, ac);
+ _il_wake_queue(il, ac);
}
static inline void
@@ -2276,8 +2288,7 @@ il_stop_queue(struct il_priv *il, struct il_tx_queue *txq)
u8 hwq = (queue >> 2) & 0x1f;
if (!test_and_set_bit(hwq, il->queue_stopped))
- if (atomic_inc_return(&il->queue_stop_count[ac]) > 0)
- ieee80211_stop_queue(il->hw, ac);
+ _il_stop_queue(il, ac);
}
#ifdef ieee80211_stop_queue
--
1.7.11.7
^ permalink raw reply related
* [RFT/RFC 2/4] iwlegacy: add il_{stop,wake}_queues_by_reason functions
From: Stanislaw Gruszka @ 2013-05-23 12:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Jake Edge, Johannes Berg, Stanislaw Gruszka
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
Add functions that will stop/wake all queues. Make them safe
regarding multiple calls and when some ac are stopped/woke
independently.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/common.h | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/wireless/iwlegacy/common.h b/drivers/net/wireless/iwlegacy/common.h
index c6956ea..3c9143e 100644
--- a/drivers/net/wireless/iwlegacy/common.h
+++ b/drivers/net/wireless/iwlegacy/common.h
@@ -1299,6 +1299,8 @@ struct il_priv {
/* queue refcounts */
#define IL_MAX_HW_QUEUES 32
unsigned long queue_stopped[BITS_TO_LONGS(IL_MAX_HW_QUEUES)];
+#define IL_STOP_REASON_PASSIVE 0
+ unsigned long stop_reason;
/* for each AC */
atomic_t queue_stop_count[4];
@@ -2291,6 +2293,26 @@ il_stop_queue(struct il_priv *il, struct il_tx_queue *txq)
_il_stop_queue(il, ac);
}
+static inline void
+il_wake_queues_by_reason(struct il_priv *il, int reason)
+{
+ u8 ac;
+
+ if (test_and_clear_bit(reason, &il->stop_reason))
+ for (ac = 0; ac < 4; ac++)
+ _il_wake_queue(il, ac);
+}
+
+static inline void
+il_stop_queues_by_reason(struct il_priv *il, int reason)
+{
+ u8 ac;
+
+ if (!test_and_set_bit(reason, &il->stop_reason))
+ for (ac = 0; ac < 4; ac++)
+ _il_stop_queue(il, ac);
+}
+
#ifdef ieee80211_stop_queue
#undef ieee80211_stop_queue
#endif
--
1.7.11.7
^ permalink raw reply related
* [RFT/RFC 3/4] iwlegacy: workaround for firmware frame tx rejection
From: Stanislaw Gruszka @ 2013-05-23 12:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Jake Edge, Johannes Berg, Stanislaw Gruszka
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
Firmware can reject to transmit frame on passive channel, when it
did not yet received any beacon on that channel. Workaround this
problem in the driver.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/iwlegacy/4965-mac.c | 19 +++++++++++++++++++
drivers/net/wireless/iwlegacy/common.c | 10 ++++++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index 9a95045..72b8c4e 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -588,6 +588,13 @@ il4965_pass_packet_to_mac80211(struct il_priv *il, struct ieee80211_hdr *hdr,
return;
}
+ if (unlikely(test_bit(IL_STOP_REASON_PASSIVE, &il->stop_reason)) &&
+ ieee80211_is_beacon(fc) &&
+ ether_addr_equal(hdr->addr3, il->active.bssid_addr)) {
+ il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+ D_INFO("Woke queues - beacon received on passive channel\n");
+ }
+
/* In case of HW accelerated crypto and bad decryption, drop */
if (!il->cfg->mod_params->sw_crypto &&
il_set_decrypted_flag(il, hdr, ampdu_status, stats))
@@ -2806,6 +2813,18 @@ il4965_hdl_tx(struct il_priv *il, struct il_rx_buf *rxb)
return;
}
+ /*
+ * Firmware will not transmit frame on passive channel, if it not yet
+ * received beacon frame on that channel. When this error happen, we
+ * have to wait until firmware will unblock itself i.e. when we note
+ * received beacon (see il4965_pass_packet_to_mac80211).
+ */
+ if (unlikely(status == TX_STATUS_FAIL_PASSIVE_NO_RX) &&
+ il->iw_mode == NL80211_IFTYPE_STATION) {
+ il_stop_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+ D_INFO("Stopped queues - RX waiting on passive channel\n");
+ }
+
spin_lock_irqsave(&il->sta_lock, flags);
if (txq->sched_retry) {
const u32 scd_ssn = il4965_get_scd_ssn(tx_resp);
diff --git a/drivers/net/wireless/iwlegacy/common.c b/drivers/net/wireless/iwlegacy/common.c
index e9a3cbc..9360d1f 100644
--- a/drivers/net/wireless/iwlegacy/common.c
+++ b/drivers/net/wireless/iwlegacy/common.c
@@ -5307,6 +5307,16 @@ il_mac_bss_info_changed(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
D_MAC80211("BSSID %pM\n", bss_conf->bssid);
/*
+ * On passive channel we wait with blocked queues for a beacon.
+ * If beacon will not be received (what is very unlikely, but
+ * theoretically possible), mac80211 associate procedure will
+ * time out and mac80211 will call us with NULL bssid. We have
+ * to unblock queues on such condition.
+ */
+ if (is_zero_ether_addr(bss_conf->bssid))
+ il_wake_queues_by_reason(il, IL_STOP_REASON_PASSIVE);
+
+ /*
* If there is currently a HW scan going on in the background,
* then we need to cancel it, otherwise sometimes we are not
* able to authenticate (FIXME: why ?)
--
1.7.11.7
^ permalink raw reply related
* [RFT/RFC 4/4] Revert "iwl4965: workaround connection regression on passive channel"
From: Stanislaw Gruszka @ 2013-05-23 12:21 UTC (permalink / raw)
To: linux-wireless; +Cc: Jake Edge, Johannes Berg, Stanislaw Gruszka
In-Reply-To: <1369311660-15378-1-git-send-email-sgruszka@redhat.com>
This reverts commit dd9c46408fdc07098333655ff27edf8cac8d9fcf.
---
drivers/net/wireless/iwlegacy/4965-mac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/iwlegacy/4965-mac.c b/drivers/net/wireless/iwlegacy/4965-mac.c
index 72b8c4e..b083502 100644
--- a/drivers/net/wireless/iwlegacy/4965-mac.c
+++ b/drivers/net/wireless/iwlegacy/4965-mac.c
@@ -5760,7 +5760,8 @@ il4965_mac_setup_register(struct il_priv *il, u32 max_probe_length)
hw->flags =
IEEE80211_HW_SIGNAL_DBM | IEEE80211_HW_AMPDU_AGGREGATION |
IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC | IEEE80211_HW_SPECTRUM_MGMT |
- IEEE80211_HW_SUPPORTS_PS | IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
+ IEEE80211_HW_REPORTS_TX_ACK_STATUS | IEEE80211_HW_SUPPORTS_PS |
+ IEEE80211_HW_SUPPORTS_DYNAMIC_PS;
if (il->cfg->sku & IL_SKU_N)
hw->flags |=
IEEE80211_HW_SUPPORTS_DYNAMIC_SMPS |
--
1.7.11.7
^ permalink raw reply related
* Re: Ralink RT3290 proprietary drivers causing kernel panic
From: Mohit @ 2013-05-23 12:21 UTC (permalink / raw)
To: Gertjan van Wingerde, linux-wireless
In-Reply-To: <14ECE0C4-AE53-4CC5-B6B6-42930C2C26FB@gmail.com>
On Thursday 23 May 2013 01:25 AM, Gertjan van Wingerde wrote:
> Hi Mohit,
>
> Sent from my iPad
>
> On 22 mei 2013, at 20:24, Mohit <mt1037ag11@pdm.ac.in> wrote:
>
>> Hello,
>>
>> I am on openSUSE 12.3 with kernel 3.7.10-1.4-desktop, i wanted to try out the proprietary drivers for Ralink RT3290 so i downloaded the drivers from http://www.mediatek.com/_en/07_downloads/01_windows.php?sn=501 and compiled the drivers as mentioned on my thread here : https://forums.opensuse.org/english/get-technical-help-here/wireless/486975-rt3290-wireless-proprietary-drivers-not-working.html#post2557514. Everything compiled fine, openSUSE was able to scan and connect to access points after installation, but when i access the internet a kernel panic occurs after ~5sec (time varies based on the data usage). So i humbly request you to please provide the solution for the same, you can reach me through email or reply to my thread (probably faster as i don't check my email everyday).
>>
> You'll have to contact Mediatek about the drivers that you downloaded from their web site.
> None of us on this mailing list have created this driver, nor are we supporting it.
>
> Note that the standard kernel does contain support for the RT3290 chipset in its rt2x00 driver since kernel version 3.6 or 3.7, so you might give that a try.
>
> ---
> Gertjan
The drivers work in kernel 3.2 but stop working from either kernel ver.
3.3, 3.4 or 3.5.
The drivers included in the kernel work, but they are a buggy, have low
range, connection drops etc.
I switched from Linux mint 13 kernel 3.2, installed the proprietary
driver and it is way better than rt2800pci drivers interms of signal
strength, latency, speed etc. I think the proprietary drivers use
rt2860pci driver instead of a dedicated rt3290sta driver.
Can the drivers included in the kernel be tweaked to match the
proprietary driver?
Can the future kernels support the drivers?
--
--
******************************************************************************************************************************************************************
"This e-Mail may contain proprietary and confidential information and is
sent for the intended recipient(s) only. If, by an addressing or
transmission error, this mail has been misdirected to you, you are
requested to delete this mail immediately.You are also hereby notified that
any use, any form of reproduction, dissemination, copying, disclosure,
modification, distribution and/or publication of this e-mail
message,contents or its attachment(s) other than by its intended
recipient(s) is strictly prohibited.Any opinions expressed in this email
are those of the individual and not necessarily of the organization.Before
opening attachment(s), please scan for viruses."
**********************************************************************************************************************************************************************
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox