* Re: [PATCH v2 1/2] iw: use updated structures and enums for packet pattern
From: Johannes Berg @ 2013-05-23 21:39 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369344941-11217-1-git-send-email-bzhao@marvell.com>
On Thu, 2013-05-23 at 14:35 -0700, Bing Zhao wrote:
> From: Amitkumar Karwar <akarwar@marvell.com>
>
> They are renamed so that they can be used for new feature.
This isn't really necessary, right? I mean, it should compile w/o this
even after the kernel patches, but this is just for making it look
nicer?
johannes
^ permalink raw reply
* RE: [PATCH v2 1/2] iw: use updated structures and enums for packet pattern
From: Bing Zhao @ 2013-05-23 22:23 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369345157.12002.87.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gT24gVGh1LCAyMDEzLTA1LTIzIGF0IDE0OjM1IC0wNzAwLCBCaW5n
IFpoYW8gd3JvdGU6DQo+ID4gRnJvbTogQW1pdGt1bWFyIEthcndhciA8YWthcndhckBtYXJ2ZWxs
LmNvbT4NCj4gPg0KPiA+IFRoZXkgYXJlIHJlbmFtZWQgc28gdGhhdCB0aGV5IGNhbiBiZSB1c2Vk
IGZvciBuZXcgZmVhdHVyZS4NCj4gDQo+IFRoaXMgaXNuJ3QgcmVhbGx5IG5lY2Vzc2FyeSwgcmln
aHQ/IEkgbWVhbiwgaXQgc2hvdWxkIGNvbXBpbGUgdy9vIHRoaXMNCj4gZXZlbiBhZnRlciB0aGUg
a2VybmVsIHBhdGNoZXMsIGJ1dCB0aGlzIGlzIGp1c3QgZm9yIG1ha2luZyBpdCBsb29rDQo+IG5p
Y2VyPw0KDQpZZXMsIGl0IGNvbXBpbGVzIHcvbyB0aGlzIHBhdGNoLiBJdCBkb2VzIG1ha2UgaXQg
bG9vayBuaWNlciwgSSB0aGluay4NCkhvd2V2ZXIsIHRoZSBjb21taXQgbWVzc2FnZSBzaG91bGQg
YmUgc29tZXRoaW5nIGxpa2U6DQoNCiJUaGV5IGFyZSByZW5hbWVkIHRvIG1hdGNoIG5ldyBubDgw
MjExLmggYW5kIG1ha2UgdGhlIGNvZGUgbG9vayBuaWNlci4iDQoNClBsZWFzZSBsZXQgbWUga25v
dyBpZiB5b3Ugd2FudCBtZSB0byByZXNlbmQgMS8yIHdpdGggcmV2aXNlZCBjb21taXQgbG9nLg0K
T3RoZXJ3aXNlLCBwbGVhc2Ugc2ltcGx5IGRyb3AgMS8yIGFuZCBhcHBseSAyLzIgYWxvbmUuDQoN
ClRoYW5rcywNCkJpbmcNCg0K
^ permalink raw reply
* Re: [PATCH v2 1/2] iw: use updated structures and enums for packet pattern
From: Johannes Berg @ 2013-05-23 22:28 UTC (permalink / raw)
To: Bing Zhao
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <477F20668A386D41ADCC57781B1F70430E801DC656@SC-VEXCH1.marvell.com>
On Thu, 2013-05-23 at 15:23 -0700, Bing Zhao wrote:
> Hi Johannes,
>
> > On Thu, 2013-05-23 at 14:35 -0700, Bing Zhao wrote:
> > > From: Amitkumar Karwar <akarwar@marvell.com>
> > >
> > > They are renamed so that they can be used for new feature.
> >
> > This isn't really necessary, right? I mean, it should compile w/o this
> > even after the kernel patches, but this is just for making it look
> > nicer?
>
> Yes, it compiles w/o this patch. It does make it look nicer, I think.
> However, the commit message should be something like:
>
> "They are renamed to match new nl80211.h and make the code look nicer."
>
> Please let me know if you want me to resend 1/2 with revised commit log.
> Otherwise, please simply drop 1/2 and apply 2/2 alone.
No, no need. Just wanted to double-check. I started going through the
kernel side patches and had some comments, but I'm too tired to finish
now.
johannes
^ permalink raw reply
* RE: [PATCH v2 1/2] iw: use updated structures and enums for packet pattern
From: Bing Zhao @ 2013-05-23 22:36 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho, Amitkumar Karwar
In-Reply-To: <1369348092.17244.0.camel@jlt4.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNCj4gPiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgeW91IHdhbnQgbWUgdG8g
cmVzZW5kIDEvMiB3aXRoIHJldmlzZWQgY29tbWl0IGxvZy4NCj4gPiBPdGhlcndpc2UsIHBsZWFz
ZSBzaW1wbHkgZHJvcCAxLzIgYW5kIGFwcGx5IDIvMiBhbG9uZS4NCj4gDQo+IE5vLCBubyBuZWVk
LiBKdXN0IHdhbnRlZCB0byBkb3VibGUtY2hlY2suIEkgc3RhcnRlZCBnb2luZyB0aHJvdWdoIHRo
ZQ0KPiBrZXJuZWwgc2lkZSBwYXRjaGVzIGFuZCBoYWQgc29tZSBjb21tZW50cywgYnV0IEknbSB0
b28gdGlyZWQgdG8gZmluaXNoDQo+IG5vdy4NCg0KT0ssIE5vIGh1cnJ5Lg0KDQpUaGFua3MsDQpC
aW5nDQo=
^ permalink raw reply
* [PATCH 3.10] mac80211: close AP_VLAN interfaces before unregistering all
From: Johannes Berg @ 2013-05-23 23:10 UTC (permalink / raw)
To: linux-wireless; +Cc: Eric Dumazet, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Since Eric's commit efe117ab8 ("Speedup ieee80211_remove_interfaces")
there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
up. If the AP_VLAN interface was registered after the AP it belongs
to (which is the typical case) and then we get into this code path,
unregister_netdevice_many() will crash because it isn't prepared to
deal with interfaces being closed in the middle of it. Exactly this
happens though, because we iterate the list, find the AP master this
AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
unregister_netdevice_many() won't pick up the fact that the AP_VLAN
is already down and will do it again, causing a crash.
Cc: stable@vger.kernel.org [2.6.33+]
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/iface.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 00e2238..ceef644 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1703,6 +1703,15 @@ void ieee80211_remove_interfaces(struct ieee80211_local *local)
ASSERT_RTNL();
+ /*
+ * Close all AP_VLAN interfaces first, as otherwise they
+ * might be closed while the AP interface they belong to
+ * is closed, causing unregister_netdevice_many() to crash.
+ */
+ list_for_each_entry(sdata, &local->interfaces, list)
+ if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
+ dev_close(sdata->dev);
+
mutex_lock(&local->iflist_mtx);
list_for_each_entry_safe(sdata, tmp, &local->interfaces, list) {
list_del(&sdata->list);
--
1.8.0
^ permalink raw reply related
* RE: ath9k_htc p2p finding issue
From: Deng, Flavian @ 2013-05-24 1:46 UTC (permalink / raw)
To: Arend van Spriel, Zhou, Robie; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <519DCF76.8050704@broadcom.com>
SGkgQXJlbmQsDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbiwgYnV0IGl0IGxvb2tzIHRoZSBh
dGg5a19odGMgZGlkbid0IGdldCBwcm9iZSByZXF1ZXN0IGZyYW1lLiBJIGFkZGVkIGRlYnVnIG1l
c3NhZ2UgaW4gImF0aDlrX3J4X3Rhc2tsZXQoKSIoaHRjX2Rydl90eHJ4LmMpLCBidXQgbm8gcHJv
YmUgcmVxdWVzdCBmcmFtZSBhcnJpdmVkIHRoZXJlLg0KQWZ0ZXIgbW9yZSB0ZXN0LCBpdCBsb29r
cyB0aGlzIGlzc3VlIG9jY3VycmVkIGFmdGVyICJjb21wYXQtd2lyZWxlc3MtMy42LjItMSIsIGFu
ZCB0aGlzIGlzc3VlIGNvdWxkbid0IGJlIG9ic2VydmVkIGluICJjb21wYXQtd2lyZWxlc3MtMy41
LjQtMSIuDQoNCkRvIHlvdSBoYXZlIG90aGVyIHN1Z2dlc3Rpb24gZm9yIHRoaXMgaXNzdWU/DQoN
ClRoYW5rcw0KRmxhdmlhbiBEZW5nDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IEFyZW5kIHZhbiBTcHJpZWwgW21haWx0bzphcmVuZEBicm9hZGNvbS5jb21dIA0KU2VudDog
MjAxM8TqNdTCMjPI1SAxNjoxMw0KVG86IFpob3UsIFJvYmllDQpDYzogbGludXgtd2lyZWxlc3NA
dmdlci5rZXJuZWwub3JnOyBEZW5nLCBGbGF2aWFuDQpTdWJqZWN0OiBSZTogYXRoOWtfaHRjIHAy
cCBmaW5kaW5nIGlzc3VlDQoNCk9uIDA1LzIzLzIwMTMgMDc6NTggQU0sIFpob3UsIFJvYmllIHdy
b3RlOg0KPiBIaSBhbGwsDQo+DQo+IFdlIG1lZXQgc29tZSBwcm9ibGVtIHdoZW4gdHJ5IFAyUCBi
eSB1c2luZyBhdGg5a19odGMgY29tcGF0LXdpcmVsZXNzLXYzLjYuOC0xLg0KPg0KPiBXaGVuIHVz
aW5nIHRoZSBjb21wYXQtd2lyZWxlc3MtdjMuNi44LTEsIEFSOTI3MSBjb3VsZCBmaW5kIG90aGVy
IFAyUCBkZXZpY2VzLCBidXQgb3RoZXIgUDJQIGRldmljZXMgY291bGRuJ3QgZmluZCBBUjkyNzEg
KHJ1bnMgYXRoOWtfaHRjKSBiZWNhdXNlIGRyaXZlciBjb3VsZG4ndCByZXBvcnQgUHJvYmUgUmVx
dWVzdCB0byB3cGFfc3VwcGxpY2FudC4NCj4NCj4gQW5kIHRoaXMgaXNzdWUgY291bGQgbm90IGJl
IG9ic2VydmVkIHdoZW4gdXNpbmcgY29tcGF0LXdpcmVsZXNzLXYzLjAuOS0xLCBieSBjb21wYXJl
IHdpdGggY29tcGF0LXdpcmVsZXNzLXYzLjAuOS0xLCBBVEg5SyBSWCBmaWx0ZXIgaXMgIHNldCBj
b3JyZWN0bHkgYWZ0ZXIgZ290ICJSZXBvcnQgUHJvYmUgUmVxdWVzdCIgY29tbWFuZCBmcm9tIHdw
YV9zdXBwbGljYW50LCBidXQgQVRIOUsgZHJpdmVyIGNvdWxkbid0IGdldCAiUHJvYmUgUmVxdWVz
dCIgZnJhbWUoSSBhZGQgZGVidWcgbXNnIGluIGllZWU4MDIxMV9yeF9oYW5kbGVycygpIGZ1bmN0
aW9uKS4NCj4NCj4gPDc+WyAgMjA1Ljc4NDExOF0gW0RGX0RCR10gICAgW2llZWU4MDIxMV9tZ210
X2ZyYW1lX3JlZ2lzdGVyXSA6IGxvY2FsLT5wcm9iZV9yZXFfcmVnID0gMTsNCj4gPDc+WyAgMjA1
LjgzMDIzMl0gW0RGX0RCR10gICAgW2F0aDlrX2h0Y19vcG1vZGVfaW5pdF0gICAgcmZpbHQgPSAw
eDE3OyAgIC0+ICAgYXRoOWtfaHdfc2V0cnhmaWx0ZXINCj4gPDc+WyAgMjA1LjgzMjg1OF0gW0RG
X0RCR10gICAgW2llZWU4MDIxMV9jb25maWd1cmVfZmlsdGVyXSA6IG5ld19mbGFncyB8PSBGSUZf
UFJPQkVfUkVROw0KPiA8Nz5bICAyMDUuODMzMTAxXSBbREZfREJHXSAgICBbYXRoOWtfaHRjX2Nv
bmZpZ3VyZV9maWx0ZXJdICAgIHJmaWx0ID0gMHgyODc7ICAgLT4gICBhdGg5a19od19zZXRyeGZp
bHRlcg0KPiA8Nz5bICAyMDUuODc4MjMwXSBbREZfREJHXSAgICBbYXRoOWtfaHRjX29wbW9kZV9p
bml0XSAgICByZmlsdCA9IDB4Mjg3OyAgIC0+ICAgYXRoOWtfaHdfc2V0cnhmaWx0ZXINCj4gPDc+
WyAgMjA1Ljg4MjU1Nl0gW0RGX0RCR10gICAgW2llZWU4MDIxMV9jb25maWd1cmVfZmlsdGVyXSA6
IG5ld19mbGFncyB8PSBGSUZfUFJPQkVfUkVROw0KPiA8Nz5bICAyMDUuODgzNjA2XSBbREZfREJH
XSAgICBbYXRoOWtfaHRjX2NvbmZpZ3VyZV9maWx0ZXJdICAgIHJmaWx0ID0gMHgyODc7ICAgLT4g
ICBhdGg5a19od19zZXRyeGZpbHRlcg0KPg0KPiA8Nz5bICAyMDYuMDEwODg2XSBbREZfREJHXSAg
ICBbaWVlZTgwMjExX21nbXRfZnJhbWVfcmVnaXN0ZXJdIDogbG9jYWwtPnByb2JlX3JlcV9yZWcg
PSAwOw0KPiA8Nz5bICAyMDYuMDM2MjM3XSBbREZfREJHXSAgICBbYXRoOWtfaHRjX29wbW9kZV9p
bml0XSAgICByZmlsdCA9IDB4Mjg3OyAgIC0+ICAgYXRoOWtfaHdfc2V0cnhmaWx0ZXINCj4gPDc+
WyAgMjA2LjA0MzM1N10gW0RGX0RCR10gICAgW2F0aDlrX2h0Y19jb25maWd1cmVfZmlsdGVyXSAg
ICByZmlsdCA9IDB4MTc7ICAgLT4gICBhdGg5a19od19zZXRyeGZpbHRlcg0KPiA8Nz5bICAyMDYu
MDQ0MTA3XSBbREZfREJHXSAgICBbYXRoOWtfaHRjX2NvbmZpZ3VyZV9maWx0ZXJdICAgIHJmaWx0
ID0gMHgxNzsgICAtPiAgIGF0aDlrX2h3X3NldHJ4ZmlsdGVyDQo+IDw3PlsgIDIwNi4wOTAxMDZd
IFtERl9EQkddICAgIFthdGg5a19odGNfb3Btb2RlX2luaXRdICAgIHJmaWx0ID0gMHgxNzsgICAt
PiAgIGF0aDlrX2h3X3NldHJ4ZmlsdGVyDQo+IDw3PlsgIDIwNi4xNjA3MzRdIFtERl9EQkddICAg
IFthdGg5a19odGNfb3Btb2RlX2luaXRdICAgIHJmaWx0ID0gMHgxNzsgICAtPiAgIGF0aDlrX2h3
X3NldHJ4ZmlsdGVyDQo+IDw3PlsgIDIwNi4yMzA3NDBdIFtERl9EQkddICAgIFthdGg5a19odGNf
b3Btb2RlX2luaXRdICAgIHJmaWx0ID0gMHgxNzsgICAtPiAgIGF0aDlrX2h3X3NldHJ4ZmlsdGVy
DQo+DQo+DQo+IERpZCBhbnlvbmUgZXZlciBtZWV0IHRoaXMgaXNzdWU/IEFueSBzdWdnZXN0aW9u
IGZvciBmdXJ0aGVyIGRlYnVnZ2luZyB0aGlzIGlzc3VlPw0KDQpEaWQgeW91IGNvbmZpcm0gYXRo
OWtfaHRjIGlzIGhhbmRpbmcgb3ZlciBwcm9iZSByZXF1ZXN0cyB0byBtYWM4MDIxMT8gDQpNaWdo
dCBiZSB1c2VmdWwgdG8gYWRkIGRlYnVnZ2luZyBpbiBwcmVwYXJlX2Zvcl9oYW5kbGVycygpIGlu
c3RlYWQuDQoNClJlZ2FyZHMsDQpBcmVuZA0KDQoNCg==
^ permalink raw reply
* Cross compilation compat-wireless in kernel-2.6.35 for powerpc
From: Suman Pandit @ 2013-05-24 6:24 UTC (permalink / raw)
To: linux-wireless
"WARNING: CONFIG_CFG80211_WEXT will be deactivated or not working because
kernel was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface
like iwconfig will not work. To activate it build your kernel e.g. with
CONFIG_LIBIPW=m."
./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
^ permalink raw reply
* Re: skb_under_panic in ath9k
From: Marc Kleine-Budde @ 2013-05-24 8:47 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath9k-devel
In-Reply-To: <519D405B.2080806@blackshift.org>
[-- Attachment #1: Type: text/plain, Size: 6067 bytes --]
added ath9k-devel to Cc
On 05/23/2013 12:02 AM, Marc Kleine-Budde wrote:
> 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
* [PATCH] mwl8k: Fix the firmware hang issue for 8764
From: Nishant Sarmukadam @ 2013-05-24 9:12 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, Lennert Buytenhek, Nishant Sarmukadam,
Yogesh Ashok Powar
The firmware hang issue is not seen very often,
though it is still seen sometimes (once in 12
hours in local tests). The changes in the driver
,to interrupt the firmware, are needed when we
detect that firmware is stuck and when the host
queues are full and we begin to drop packets.
This is to ensure that the firmware does not
miss any PPA_RDY interrupts to cause the firmware
restart dont miss PPA_READY interrupt for SC2
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
Signed-off-by: Yogesh Ashok Powar <yogeshp@marvell.com>
---
drivers/net/wireless/mwl8k.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwl8k.c b/drivers/net/wireless/mwl8k.c
index 6820fce..a3707fd 100644
--- a/drivers/net/wireless/mwl8k.c
+++ b/drivers/net/wireless/mwl8k.c
@@ -1548,7 +1548,7 @@ static int mwl8k_tx_wait_empty(struct ieee80211_hw *hw)
if (!priv->pending_tx_pkts)
return 0;
- retry = 0;
+ retry = 1;
rc = 0;
spin_lock_bh(&priv->tx_lock);
@@ -1572,13 +1572,19 @@ static int mwl8k_tx_wait_empty(struct ieee80211_hw *hw)
spin_lock_bh(&priv->tx_lock);
- if (timeout) {
+ if (timeout || !priv->pending_tx_pkts) {
WARN_ON(priv->pending_tx_pkts);
if (retry)
wiphy_notice(hw->wiphy, "tx rings drained\n");
break;
}
+ if (retry) {
+ mwl8k_tx_start(priv);
+ retry = 0;
+ continue;
+ }
+
if (priv->pending_tx_pkts < oldcount) {
wiphy_notice(hw->wiphy,
"waiting for tx rings to drain (%d -> %d pkts)\n",
@@ -2055,6 +2061,7 @@ mwl8k_txq_xmit(struct ieee80211_hw *hw,
mwl8k_remove_stream(hw, stream);
spin_unlock(&priv->stream_lock);
}
+ mwl8k_tx_start(priv);
spin_unlock_bh(&priv->tx_lock);
pci_unmap_single(priv->pdev, dma, skb->len,
PCI_DMA_TODEVICE);
--
1.8.0.3
^ permalink raw reply related
* [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Oleksij Rempel @ 2013-05-24 10:05 UTC (permalink / raw)
To: ath9k-devel, linux-wireless, johannes; +Cc: Oleksij Rempel
In-Reply-To: <1369250674.8207.26.camel@jlt4.sipsolutions.net>
Some chips can tell us if received frame was
encoded with STBC or not. To make this information available
in user space we can use updated radiotap specification:
http://www.radiotap.org/defined-fields/MCS
This patch will set number of STBC encoded spatial streams (Nss).
The HAVE_STBC flag should be provided by driver.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
include/net/ieee80211_radiotap.h | 7 +++++++
include/net/mac80211.h | 4 ++++
net/mac80211/rx.c | 4 ++++
3 files changed, 15 insertions(+)
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..811dd64 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -258,6 +258,7 @@ ieee80211_add_rx_radiotap_header(struct ieee80211_local *local,
pos += 2;
if (status->flag & RX_FLAG_HT) {
+ unsigned int stbc;
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;
+ stbc = status->flag & RX_FLAG_STBC_MASK;
+ *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: [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Johannes Berg @ 2013-05-24 10:08 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369389945-805-1-git-send-email-linux@rempel-privat.de>
On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote:
> Some chips can tell us if received frame was
> encoded with STBC or not. To make this information available
> in user space we can use updated radiotap specification:
> http://www.radiotap.org/defined-fields/MCS
>
> This patch will set number of STBC encoded spatial streams (Nss).
> The HAVE_STBC flag should be provided by driver.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [PATCH v4 1/3] mac80211: add STBC flag for radiotap
From: Oleksij Rempel @ 2013-05-24 10:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390088.8290.5.camel@jlt4.sipsolutions.net>
Am 24.05.2013 12:08, schrieb Johannes Berg:
> On Fri, 2013-05-24 at 12:05 +0200, Oleksij Rempel wrote:
>> Some chips can tell us if received frame was
>> encoded with STBC or not. To make this information available
>> in user space we can use updated radiotap specification:
>> http://www.radiotap.org/defined-fields/MCS
>>
>> This patch will set number of STBC encoded spatial streams (Nss).
>> The HAVE_STBC flag should be provided by driver.
>
> Applied, thanks.
>
thank you.
--
Regards,
Oleksij
^ permalink raw reply
* [PATCH 1/2] ath9k: remove useless flag conversation.
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1369390711-992-1-git-send-email-linux@rempel-privat.de>
some flags used only outside of ath9k - In this case we can use
"enum mac80211_rx_flags" and pass it upstream without extra
conversation.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/mac.c | 11 +++++++----
drivers/net/wireless/ath/ath9k/mac.h | 1 +
drivers/net/wireless/ath/ath9k/recv.c | 5 +----
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_mac.c b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
index 301bf72..5163abd 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_mac.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_mac.c
@@ -469,6 +469,7 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_status = 0;
rxs->rs_flags = 0;
+ rxs->flag = 0;
rxs->rs_datalen = rxsp->status2 & AR_DataLen;
rxs->rs_tstamp = rxsp->status3;
@@ -493,8 +494,8 @@ int ath9k_hw_process_rxdesc_edma(struct ath_hw *ah, struct ath_rx_status *rxs,
rxs->rs_isaggr = (rxsp->status11 & AR_RxAggr) ? 1 : 0;
rxs->rs_moreaggr = (rxsp->status11 & AR_RxMoreAggr) ? 1 : 0;
rxs->rs_antenna = (MS(rxsp->status4, AR_RxAntenna) & 0x7);
- rxs->rs_flags = (rxsp->status4 & AR_GI) ? ATH9K_RX_GI : 0;
- rxs->rs_flags |= (rxsp->status4 & AR_2040) ? ATH9K_RX_2040 : 0;
+ rxs->flag |= (rxsp->status4 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rxs->flag |= (rxsp->status4 & AR_2040) ? RX_FLAG_40MHZ : 0;
rxs->evm0 = rxsp->status6;
rxs->evm1 = rxsp->status7;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 498fee0..a52081d 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -547,6 +547,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_status = 0;
rs->rs_flags = 0;
+ rs->flag = 0;
rs->rs_datalen = ads.ds_rxstatus1 & AR_DataLen;
rs->rs_tstamp = ads.AR_RcvTimestamp;
@@ -586,10 +587,12 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_moreaggr =
(ads.ds_rxstatus8 & AR_RxMoreAggr) ? 1 : 0;
rs->rs_antenna = MS(ads.ds_rxstatus3, AR_RxAntenna);
- rs->rs_flags =
- (ads.ds_rxstatus3 & AR_GI) ? ATH9K_RX_GI : 0;
- rs->rs_flags |=
- (ads.ds_rxstatus3 & AR_2040) ? ATH9K_RX_2040 : 0;
+
+ /* directly mapped flags for ieee80211_rx_status */
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 5865f92..3f1e775 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -149,6 +149,7 @@ struct ath_rx_status {
u32 evm2;
u32 evm3;
u32 evm4;
+ u32 flag; /* see enum mac80211_rx_flags */
};
struct ath_htc_rx_status {
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 8be2b5d..b4b758d 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -868,10 +868,7 @@ static int ath9k_process_rate(struct ath_common *common,
if (rx_stats->rs_rate & 0x80) {
/* HT rate */
rxs->flag |= RX_FLAG_HT;
- if (rx_stats->rs_flags & ATH9K_RX_2040)
- rxs->flag |= RX_FLAG_40MHZ;
- if (rx_stats->rs_flags & ATH9K_RX_GI)
- rxs->flag |= RX_FLAG_SHORT_GI;
+ rxs->flag |= rx_stats->flag;
rxs->rate_idx = rx_stats->rs_rate & 0x7f;
return 0;
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/2] ath9k: STBC Rx monitoring
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1368949136-6079-1-git-send-email-linux@rempel-privat.de>
this are two remaining patches to allow STBC Rx monitoring
on ath9k devices.
This patches depend on currently applied:
[PATCH v4 1/3] mac80211: add STBC flag for radiotap
Oleksij Rempel (2):
ath9k: remove useless flag conversation.
ath9k: check for Rx-STBC flag and pass it to ieee80211
drivers/net/wireless/ath/ath9k/ar9003_mac.c | 5 +++--
drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
drivers/net/wireless/ath/ath9k/mac.c | 16 ++++++++++++----
drivers/net/wireless/ath/ath9k/mac.h | 4 +++-
drivers/net/wireless/ath/ath9k/recv.c | 5 +----
5 files changed, 26 insertions(+), 13 deletions(-)
--
1.8.1.2
^ permalink raw reply
* [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 10:18 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1369390711-992-1-git-send-email-linux@rempel-privat.de>
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..7739b05 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
- hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
+ hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw->radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs->flag |=
(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 << RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x00000002
#define AR_Parallel40 0x00000004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x000000f8
+#define AR_STBC 0x00000008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x000000f0
#define AR_RxAntenna 0xffffff00
#define AR_RxAntenna_S 8
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Johannes Berg @ 2013-05-24 10:29 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390711-992-3-git-send-email-linux@rempel-privat.de>
On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index aba4151..7739b05 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> IEEE80211_HW_SUPPORTS_RC_TABLE;
>
> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> +
> + if (AR_SREV_9280_20_OR_LATER(ah))
> + hw->radiotap_mcs_details |=
> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
> + }
Are you sure this is right? It seems that if other devices don't support
STBC they can report all frames to be w/o STBC. Or do they support STBC
but don't report it?
johannes
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 10:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369391399.8290.6.camel@jlt4.sipsolutions.net>
Am 24.05.2013 12:29, schrieb Johannes Berg:
> On Fri, 2013-05-24 at 12:18 +0200, Oleksij Rempel wrote:
>> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
>> ---
>> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
>> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
>> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
>> 3 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
>> index aba4151..7739b05 100644
>> --- a/drivers/net/wireless/ath/ath9k/init.c
>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
>> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
>> IEEE80211_HW_SUPPORTS_RC_TABLE;
>>
>> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
>> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
>> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
>> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
>> +
>> + if (AR_SREV_9280_20_OR_LATER(ah))
>> + hw->radiotap_mcs_details |=
>> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
>> + }
>
> Are you sure this is right? It seems that if other devices don't support
> STBC they can report all frames to be w/o STBC. Or do they support STBC
> but don't report it?
They support STBC but don't report it. First device whhic can report it
is ar9280.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 11:35 UTC (permalink / raw)
To: Oleksij Rempel; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <1369390711-992-3-git-send-email-linux@rempel-privat.de>
Am 24.05.2013 12:18, schrieb Oleksij Rempel:
> Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
> ---
> drivers/net/wireless/ath/ath9k/init.c | 9 +++++++--
> drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
> drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
> index aba4151..7739b05 100644
> --- a/drivers/net/wireless/ath/ath9k/init.c
> +++ b/drivers/net/wireless/ath/ath9k/init.c
> @@ -769,8 +769,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
> IEEE80211_HW_REPORTS_TX_ACK_STATUS |
> IEEE80211_HW_SUPPORTS_RC_TABLE;
>
> - if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
> - hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> + if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
> + hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
> +
> + if (AR_SREV_9280_20_OR_LATER(ah))
> + hw->radiotap_mcs_details |=
> + IEEE80211_RADIOTAP_MCS_HAVE_STBC;
comment for my self. i forgot to include <net/ieee80211_radiotap.h>
for IEEE80211_RADIOTAP_MCS_HAVE_STBC. This patch is broken.
--
Regards,
Oleksij
^ permalink raw reply
* Re: [PATCH] B43: Handle DMA RX descriptor underrun
From: John W. Linville @ 2013-05-24 16:49 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless, b43-dev, m, piotras, Larry.Finger,
Thommy Jakobsson
In-Reply-To: <alpine.DEB.2.02.1305132025560.1278@kelly.ryd.net>
On Mon, May 13, 2013 at 08:27:08PM +0200, Thommy Jakobsson wrote:
>
>
> On Sun, 5 May 2013, Rafa? Mi?ecki wrote:
>
> > I think we may want turning this interrupt anyway, but I wonder if
> > there is another issue we just hide a bit better.
> >
> Any news on the testing Rafael? Did you have any more questions about the
> solution? Just let me know if I can help
>
> //Thommy
Ping? Should I drop this one?
--
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 V7 1/3] cfg80211: introduce critical protocol indication from user-space
From: Arend van Spriel @ 2013-05-24 16:43 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <1369333809.25066.6.camel@dcbw.foobar.com>
On 05/23/2013 08:30 PM, Dan Williams wrote:
> On Thu, 2013-04-18 at 15:49 +0200, Arend van Spriel wrote:
>> Some protocols need a more reliable connection to complete
>> successful in reasonable time. This patch adds a user-space
>> API to indicate the wireless driver that a critical protocol
>> is about to commence and when it is done, using nl80211 primitives
>> NL80211_CMD_CRIT_PROTOCOL_START and NL80211_CRIT_PROTOCOL_STOP.
>>
>> There can be only on critical protocol session started per
>> registered cfg80211 device.
>
> Ok, so while implementing support for this in NetworkManager, I ran into
> a few questions some issues.
Hi Dan,
Thanks for your feedback.
> 1) Why have a new attribute? Why not just use NL80211_ATTR_DURATION
> like all the other commands do?
I guess it was overlooked. The only difference is that this attribute is
u32. I have not problem changing it.
> 2) Why have a restriction on a single critical protocol at a time? Even
> if this is the case *now*, just for sake of time, we should pass the
> protocol to the _STOP command to allow for multiples in the future.
>
> Yeah, you won't have EAPOL running at the same time as DHCP, but think
> about it from userspace's perspective:
>
> a) process A starts critical protocol like EAPOL
> b) process A forgets to stop critical protocol
> c) process B starts critical protocol DHCP, oops, error!
> d) process B has to clear old critical protocol
> e) process B starts critical protocol DHCP
> f) process A realizes it forgot (b) and stops protocol
>
> I think there's a lot of opportunity for races here. This would at
> least be reduced if the START/STOP commands were paired for a specific
> protocol, and if something requested a STOP for a protocol that's
> currently not started, it was rejected.
I guess you are right if the processes mentioned above share the same
netlink socket. That is why the netlink portid is used as a flag that a
critical protocol has been started. Just scrolled down and found we are
not checking the portid in nl80211_crit_proto_stop(). That needs to be
fixed or .... we should reconsider based on your feedback. I am not
fully convinced there will be a need for multiple protocols.
> Better yet, why not just have an internal array of all the protocols
> with their max duration and start time, and the stack manages when each
> protocol gets stopped? (unless you think drivers will have different
> behavior on a per-protocol basis, eg they'd do something different with
> DHCP than with EAPOL...?)
Not sure if I understand. Does 'start time' mean a fixed time after link
being established. The whole idea was that user-space tools would know
when a protocol would complete. I do not see how putting static numbers
into an array would be 'better yet'.
Regards,
Arend
>> The driver can support this by implementing the cfg80211 callbacks
>> .crit_proto_start() and .crit_proto_stop(). Examples of protocols
>> that can benefit from this are DHCP, EAPOL, APIPA. Exactly how the
>> link can/should be made more reliable is up to the driver. Things
>> to consider are avoid scanning, no multi-channel operations, and
>> alter coexistence schemes.
>>
>> Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
>> Reviewed-by: Franky (Zhenhui) Lin <frankyl@broadcom.com>
>> Signed-off-by: Arend van Spriel <arend@broadcom.com>
>> ---
>> Hi Johannes,
>>
>> Not sure whether you made the minor fixes already as you offered
>> to do so. I saw the change pop-up in your repo a couple of nights
>> ago, but it disappeared the next morning after another fetch.
>>
>> I also made related changes in our brcmfmac driver. Can you take
>> them through your tree as well.
>>
>> Regards,
>> Arend
>>
>> Changelog:
>> ----------
>> V7:
>> - remove crit_proto_started field from wireless_dev.
>> - remove CRIT_PROTO_STOPPED_EVENT definition.
>> - allow always calling cfg80211_crit_proto_stopped().
>> V6:
>> - added crit_proto_stopped event message.
>> - use nlportid as flag for critical protocol being active.
>> - return error when duration is over specified limit.
>> - remove logic from rdev_* inline wrappers.
>> - added more documentation.
>> - some renaming of identifiers.
>> V5:
>> - change return type for .crit_prot_stop() to void.
>> - correct limiting the duration.
>> V4:
>> - added cfg80211_crit_proto_stopped() for drivers to use.
>> - added back protocol identifier for drivers to use.
>> - reject starting critical protocol session when already started.
>> - critical protocol session tracked per registered device.
>> V3:
>> - remove protocol identifier.
>> - remove delayed work from cfg80211.
>> - guard maximum limit for duration.
>> - do .crit_proto_stop() upon netlink socket release.
>> V2:
>> - subject changed. Below previous subject is given for reference:
>> [RFC] cfg80211: configuration of Bluetooth coexistence mode
>> - introduced dedicated nl80211 API.
>> V1:
>> - initial proposal.
>> ---
>> include/net/cfg80211.h | 23 +++++++++
>> include/uapi/linux/nl80211.h | 39 ++++++++++++++
>> net/wireless/core.h | 3 ++
>> net/wireless/mlme.c | 5 ++
>> net/wireless/nl80211.c | 117 ++++++++++++++++++++++++++++++++++++++++++
>> net/wireless/rdev-ops.h | 24 ++++++++-
>> net/wireless/trace.h | 35 +++++++++++++
>> 7 files changed, 245 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
>> index dff96d8..26b5b69 100644
>> --- a/include/net/cfg80211.h
>> +++ b/include/net/cfg80211.h
>> @@ -2002,6 +2002,12 @@ struct cfg80211_update_ft_ies_params {
>> * @update_ft_ies: Provide updated Fast BSS Transition information to the
>> * driver. If the SME is in the driver/firmware, this information can be
>> * used in building Authentication and Reassociation Request frames.
>> + *
>> + * @crit_proto_start: Indicates a critical protocol needs more link reliability
>> + * for a given duration (milliseconds). The protocol is provided so the
>> + * driver can take the most appropriate actions.
>> + * @crit_proto_stop: Indicates critical protocol no longer needs increased link
>> + * reliability. This operation can not fail.
>> */
>> struct cfg80211_ops {
>> int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
>> @@ -2231,6 +2237,12 @@ struct cfg80211_ops {
>> struct cfg80211_chan_def *chandef);
>> int (*update_ft_ies)(struct wiphy *wiphy, struct net_device *dev,
>> struct cfg80211_update_ft_ies_params *ftie);
>> + int (*crit_proto_start)(struct wiphy *wiphy,
>> + struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol,
>> + u16 duration);
>> + void (*crit_proto_stop)(struct wiphy *wiphy,
>> + struct wireless_dev *wdev);
>> };
>>
>> /*
>> @@ -4137,6 +4149,17 @@ void cfg80211_report_wowlan_wakeup(struct wireless_dev *wdev,
>> struct cfg80211_wowlan_wakeup *wakeup,
>> gfp_t gfp);
>>
>> +/**
>> + * cfg80211_crit_proto_stopped() - indicate critical protocol stopped by driver.
>> + *
>> + * @wdev: the wireless device for which critical protocol is stopped.
>> + *
>> + * This function can be called by the driver to indicate it has reverted
>> + * operation back to normal. One reason could be that the duration given
>> + * by .crit_proto_start() has expired.
>> + */
>> +void cfg80211_crit_proto_stopped(struct wireless_dev *wdev, gfp_t gfp);
>> +
>> /* Logging, debugging and troubleshooting/diagnostic helpers. */
>>
>> /* wiphy_printk helpers, similar to dev_printk */
>> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
>> index 79da871..d1e48b5 100644
>> --- a/include/uapi/linux/nl80211.h
>> +++ b/include/uapi/linux/nl80211.h
>> @@ -639,6 +639,13 @@
>> * with the relevant Information Elements. This event is used to report
>> * received FT IEs (MDIE, FTIE, RSN IE, TIE, RICIE).
>> *
>> + * @NL80211_CMD_CRIT_PROTOCOL_START: Indicates user-space will start running
>> + * a critical protocol that needs more reliability in the connection to
>> + * complete.
>> + *
>> + * @NL80211_CMD_CRIT_PROTOCOL_STOP: Indicates the connection reliability can
>> + * return back to normal.
>> + *
>> * @NL80211_CMD_MAX: highest used command number
>> * @__NL80211_CMD_AFTER_LAST: internal use
>> */
>> @@ -798,6 +805,9 @@ enum nl80211_commands {
>> NL80211_CMD_UPDATE_FT_IES,
>> NL80211_CMD_FT_EVENT,
>>
>> + NL80211_CMD_CRIT_PROTOCOL_START,
>> + NL80211_CMD_CRIT_PROTOCOL_STOP,
>> +
>> /* add new commands above here */
>>
>> /* used to define NL80211_CMD_MAX below */
>> @@ -1414,6 +1424,11 @@ enum nl80211_commands {
>> * @NL80211_ATTR_IE_RIC: Resource Information Container Information
>> * Element
>> *
>> + * @NL80211_ATTR_CRIT_PROT_ID: critical protocol identifier requiring increased
>> + * reliability, see &enum nl80211_crit_proto_id (u16).
>> + * @NL80211_ATTR_MAX_CRIT_PROT_DURATION: duration in milliseconds in which
>> + * the connection should have increased reliability (u16).
>> + *
>> * @NL80211_ATTR_MAX: highest attribute number currently defined
>> * @__NL80211_ATTR_AFTER_LAST: internal use
>> */
>> @@ -1709,6 +1724,9 @@ enum nl80211_attrs {
>> NL80211_ATTR_MDID,
>> NL80211_ATTR_IE_RIC,
>>
>> + NL80211_ATTR_CRIT_PROT_ID,
>> + NL80211_ATTR_MAX_CRIT_PROT_DURATION,
>> +
>> /* add attributes here, update the policy in nl80211.c */
>>
>> __NL80211_ATTR_AFTER_LAST,
>> @@ -3682,4 +3700,25 @@ enum nl80211_protocol_features {
>> NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP = 1 << 0,
>> };
>>
>> +/**
>> + * enum nl80211_crit_proto_id - nl80211 critical protocol identifiers
>> + *
>> + * @NL80211_CRIT_PROTO_UNSPEC: protocol unspecified.
>> + * @NL80211_CRIT_PROTO_DHCP: BOOTP or DHCPv6 protocol.
>> + * @NL80211_CRIT_PROTO_EAPOL: EAPOL protocol.
>> + * @NL80211_CRIT_PROTO_APIPA: APIPA protocol.
>> + * @NUM_NL80211_CRIT_PROTO: must be kept last.
>> + */
>> +enum nl80211_crit_proto_id {
>> + NL80211_CRIT_PROTO_UNSPEC,
>> + NL80211_CRIT_PROTO_DHCP,
>> + NL80211_CRIT_PROTO_EAPOL,
>> + NL80211_CRIT_PROTO_APIPA,
>> + /* add other protocols before this one */
>> + NUM_NL80211_CRIT_PROTO
>> +};
>> +
>> +/* maximum duration for critical protocol measures */
>> +#define NL80211_CRIT_PROTO_MAX_DURATION 5000 /* msec */
>> +
>> #endif /* __LINUX_NL80211_H */
>> diff --git a/net/wireless/core.h b/net/wireless/core.h
>> index d5d06fd..eac5308 100644
>> --- a/net/wireless/core.h
>> +++ b/net/wireless/core.h
>> @@ -88,6 +88,9 @@ struct cfg80211_registered_device {
>>
>> struct delayed_work dfs_update_channels_wk;
>>
>> + /* netlink port which started critical protocol (0 means not started) */
>> + u32 crit_proto_nlportid;
>> +
>> /* must be last because of the way we do wiphy_priv(),
>> * and it should at least be aligned to NETDEV_ALIGN */
>> struct wiphy wiphy __aligned(NETDEV_ALIGN);
>> diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
>> index 390198b..0c7b7dd 100644
>> --- a/net/wireless/mlme.c
>> +++ b/net/wireless/mlme.c
>> @@ -648,6 +648,11 @@ void cfg80211_mlme_unregister_socket(struct wireless_dev *wdev, u32 nlportid)
>>
>> spin_unlock_bh(&wdev->mgmt_registrations_lock);
>>
>> + if (nlportid && rdev->crit_proto_nlportid == nlportid) {
>> + rdev->crit_proto_nlportid = 0;
>> + rdev_crit_proto_stop(rdev, wdev);
>> + }
>> +
>> if (nlportid == wdev->ap_unexpected_nlportid)
>> wdev->ap_unexpected_nlportid = 0;
>> }
>> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
>> index f924d45..96ba1eb 100644
>> --- a/net/wireless/nl80211.c
>> +++ b/net/wireless/nl80211.c
>> @@ -1417,6 +1417,10 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *dev,
>> }
>> CMD(start_p2p_device, START_P2P_DEVICE);
>> CMD(set_mcast_rate, SET_MCAST_RATE);
>> + if (split) {
>> + CMD(crit_proto_start, CRIT_PROTOCOL_START);
>> + CMD(crit_proto_stop, CRIT_PROTOCOL_STOP);
>> + }
>>
>> #ifdef CONFIG_NL80211_TESTMODE
>> CMD(testmode_cmd, TESTMODE);
>> @@ -8196,6 +8200,64 @@ static int nl80211_update_ft_ies(struct sk_buff *skb, struct genl_info *info)
>> return rdev_update_ft_ies(rdev, dev, &ft_params);
>> }
>>
>> +static int nl80211_crit_protocol_start(struct sk_buff *skb,
>> + struct genl_info *info)
>> +{
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + struct wireless_dev *wdev = info->user_ptr[1];
>> + enum nl80211_crit_proto_id proto = NL80211_CRIT_PROTO_UNSPEC;
>> + u16 duration;
>> + int ret;
>> +
>> + if (!rdev->ops->crit_proto_start)
>> + return -EOPNOTSUPP;
>> +
>> + if (WARN_ON(!rdev->ops->crit_proto_stop))
>> + return -EINVAL;
>> +
>> + if (rdev->crit_proto_nlportid)
>> + return -EBUSY;
>> +
>> + /* determine protocol if provided */
>> + if (info->attrs[NL80211_ATTR_CRIT_PROT_ID])
>> + proto = nla_get_u16(info->attrs[NL80211_ATTR_CRIT_PROT_ID]);
>> +
>> + if (proto >= NUM_NL80211_CRIT_PROTO)
>> + return -EINVAL;
>> +
>> + /* timeout must be provided */
>> + if (!info->attrs[NL80211_ATTR_MAX_CRIT_PROT_DURATION])
>> + return -EINVAL;
>> +
>> + duration =
>> + nla_get_u16(info->attrs[NL80211_ATTR_MAX_CRIT_PROT_DURATION]);
>> +
>> + if (duration > NL80211_CRIT_PROTO_MAX_DURATION)
>> + return -ERANGE;
>> +
>> + ret = rdev_crit_proto_start(rdev, wdev, proto, duration);
>> + if (!ret)
>> + rdev->crit_proto_nlportid = info->snd_portid;
>> +
>> + return ret;
>> +}
>> +
>> +static int nl80211_crit_protocol_stop(struct sk_buff *skb,
>> + struct genl_info *info)
>> +{
>> + struct cfg80211_registered_device *rdev = info->user_ptr[0];
>> + struct wireless_dev *wdev = info->user_ptr[1];
>> +
>> + if (!rdev->ops->crit_proto_stop)
>> + return -EOPNOTSUPP;
>> +
>> + if (rdev->crit_proto_nlportid) {
>> + rdev->crit_proto_nlportid = 0;
>> + rdev_crit_proto_stop(rdev, wdev);
>> + }
>> + return 0;
>> +}
>> +
>> #define NL80211_FLAG_NEED_WIPHY 0x01
>> #define NL80211_FLAG_NEED_NETDEV 0x02
>> #define NL80211_FLAG_NEED_RTNL 0x04
>> @@ -8885,6 +8947,22 @@ static struct genl_ops nl80211_ops[] = {
>> .internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
>> NL80211_FLAG_NEED_RTNL,
>> },
>> + {
>> + .cmd = NL80211_CMD_CRIT_PROTOCOL_START,
>> + .doit = nl80211_crit_protocol_start,
>> + .policy = nl80211_policy,
>> + .flags = GENL_ADMIN_PERM,
>> + .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
>> + NL80211_FLAG_NEED_RTNL,
>> + },
>> + {
>> + .cmd = NL80211_CMD_CRIT_PROTOCOL_STOP,
>> + .doit = nl80211_crit_protocol_stop,
>> + .policy = nl80211_policy,
>> + .flags = GENL_ADMIN_PERM,
>> + .internal_flags = NL80211_FLAG_NEED_WDEV_UP |
>> + NL80211_FLAG_NEED_RTNL,
>> + }
>> };
>>
>> static struct genl_multicast_group nl80211_mlme_mcgrp = {
>> @@ -10630,6 +10708,45 @@ void cfg80211_ft_event(struct net_device *netdev,
>> }
>> EXPORT_SYMBOL(cfg80211_ft_event);
>>
>> +void cfg80211_crit_proto_stopped(struct wireless_dev *wdev, gfp_t gfp)
>> +{
>> + struct cfg80211_registered_device *rdev;
>> + struct sk_buff *msg;
>> + void *hdr;
>> + u32 nlportid;
>> +
>> + rdev = wiphy_to_dev(wdev->wiphy);
>> + if (!rdev->crit_proto_nlportid)
>> + return;
>> +
>> + nlportid = rdev->crit_proto_nlportid;
>> + rdev->crit_proto_nlportid = 0;
>> +
>> + msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
>> + if (!msg)
>> + return;
>> +
>> + hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_CRIT_PROTOCOL_STOP);
>> + if (!hdr)
>> + goto nla_put_failure;
>> +
>> + if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx) ||
>> + nla_put_u64(msg, NL80211_ATTR_WDEV, wdev_id(wdev)))
>> + goto nla_put_failure;
>> +
>> + genlmsg_end(msg, hdr);
>> +
>> + genlmsg_unicast(wiphy_net(&rdev->wiphy), msg, nlportid);
>> + return;
>> +
>> + nla_put_failure:
>> + if (hdr)
>> + genlmsg_cancel(msg, hdr);
>> + nlmsg_free(msg);
>> +
>> +}
>> +EXPORT_SYMBOL(cfg80211_crit_proto_stopped);
>> +
>> /* initialisation/exit functions */
>>
>> int nl80211_init(void)
>> diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h
>> index d77e1c1..9f15f0a 100644
>> --- a/net/wireless/rdev-ops.h
>> +++ b/net/wireless/rdev-ops.h
>> @@ -875,7 +875,7 @@ static inline void rdev_stop_p2p_device(struct cfg80211_registered_device *rdev,
>> trace_rdev_stop_p2p_device(&rdev->wiphy, wdev);
>> rdev->ops->stop_p2p_device(&rdev->wiphy, wdev);
>> trace_rdev_return_void(&rdev->wiphy);
>> -}
>> +}
>>
>> static inline int rdev_set_mac_acl(struct cfg80211_registered_device *rdev,
>> struct net_device *dev,
>> @@ -901,4 +901,26 @@ static inline int rdev_update_ft_ies(struct cfg80211_registered_device *rdev,
>> return ret;
>> }
>>
>> +static inline int rdev_crit_proto_start(struct cfg80211_registered_device *rdev,
>> + struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol,
>> + u16 duration)
>> +{
>> + int ret;
>> +
>> + trace_rdev_crit_proto_start(&rdev->wiphy, wdev, protocol, duration);
>> + ret = rdev->ops->crit_proto_start(&rdev->wiphy, wdev,
>> + protocol, duration);
>> + trace_rdev_return_int(&rdev->wiphy, ret);
>> + return ret;
>> +}
>> +
>> +static inline void rdev_crit_proto_stop(struct cfg80211_registered_device *rdev,
>> + struct wireless_dev *wdev)
>> +{
>> + trace_rdev_crit_proto_stop(&rdev->wiphy, wdev);
>> + rdev->ops->crit_proto_stop(&rdev->wiphy, wdev);
>> + trace_rdev_return_void(&rdev->wiphy);
>> +}
>> +
>> #endif /* __CFG80211_RDEV_OPS */
>> diff --git a/net/wireless/trace.h b/net/wireless/trace.h
>> index ccadef2..499c982 100644
>> --- a/net/wireless/trace.h
>> +++ b/net/wireless/trace.h
>> @@ -1805,6 +1805,41 @@ TRACE_EVENT(rdev_update_ft_ies,
>> WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->md)
>> );
>>
>> +TRACE_EVENT(rdev_crit_proto_start,
>> + TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev,
>> + enum nl80211_crit_proto_id protocol, u16 duration),
>> + TP_ARGS(wiphy, wdev, protocol, duration),
>> + TP_STRUCT__entry(
>> + WIPHY_ENTRY
>> + WDEV_ENTRY
>> + __field(u16, proto)
>> + __field(u16, duration)
>> + ),
>> + TP_fast_assign(
>> + WIPHY_ASSIGN;
>> + WDEV_ASSIGN;
>> + __entry->proto = protocol;
>> + __entry->duration = duration;
>> + ),
>> + TP_printk(WIPHY_PR_FMT ", " WDEV_PR_FMT ", proto=%x, duration=%u",
>> + WIPHY_PR_ARG, WDEV_PR_ARG, __entry->proto, __entry->duration)
>> +);
>> +
>> +TRACE_EVENT(rdev_crit_proto_stop,
>> + TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev),
>> + TP_ARGS(wiphy, wdev),
>> + TP_STRUCT__entry(
>> + WIPHY_ENTRY
>> + WDEV_ENTRY
>> + ),
>> + TP_fast_assign(
>> + WIPHY_ASSIGN;
>> + WDEV_ASSIGN;
>> + ),
>> + TP_printk(WIPHY_PR_FMT ", " WDEV_PR_FMT,
>> + WIPHY_PR_ARG, WDEV_PR_ARG)
>> +);
>> +
>> /*************************************************************
>> * cfg80211 exported functions traces *
>> *************************************************************/
>
>
>
^ permalink raw reply
* Mobile Broadband Interface Model (MBIM) support?
From: Sarah Sharp @ 2013-05-24 17:09 UTC (permalink / raw)
To: linux-wireless, netdev, linux-usb; +Cc: Ismail, Rahman, Wallick, Stephanie S
Do we have support for the new extensions for USB communication devices
that use the Mobile Broadband Interface Model (MBIM) spec?
http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
The spec was released pretty recently, which is why I'm asking on the
mailing lists, rather than digging around the kernel tree for a driver.
Sarah Sharp
^ permalink raw reply
* Re: [PATCH] ST-E CW1200 driver (v6)
From: John W. Linville @ 2013-05-24 17:50 UTC (permalink / raw)
To: Solomon Peachy; +Cc: linux-wireless
In-Reply-To: <1367090847-11937-1-git-send-email-pizza@shaftnet.org>
On Sat, Apr 27, 2013 at 03:27:13PM -0400, Solomon Peachy wrote:
> I'd love to see this finally committed upstream. There are no known
> bugs in the code, and it handles everything I (and other testers I've
> been working with) have thrown at it.
>
> Changes from the last patch series (v5):
> * Updated contact info for original author (Dmitry Tarnyagin)
> * Better documented the DPLL constants
> * Fixed more checkpatch warnings
> * Better logging in scan and bss loss state machines
> * BSS loss mitigation reimplemented (differently) due to FW bugginess
> * Reworked locking in the join code to handle rare corner cases
I'm sorry, but this just doesn't build on the current wireless-next
and I don't have enough time ATM to chase-down all the fix-ups.
Could you work that out and repost? Please also check the Kconfig
stuff, as that still seemed to be broken...
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: Mobile Broadband Interface Model (MBIM) support?
From: Sarah Sharp @ 2013-05-24 18:10 UTC (permalink / raw)
To: linux-wireless, netdev, linux-usb, dcbw
Cc: Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <20130524170915.GA15788@xanatos>
Ccing Dan Williams, since Johannes Berg mentioned on IRC that Dan might
know the status of MBIM support.
On Fri, May 24, 2013 at 10:09:15AM -0700, Sarah Sharp wrote:
> Do we have support for the new extensions for USB communication devices
> that use the Mobile Broadband Interface Model (MBIM) spec?
>
> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
>
> The spec was released pretty recently, which is why I'm asking on the
> mailing lists, rather than digging around the kernel tree for a driver.
>
> Sarah Sharp
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 2/2] ath9k: check for Rx-STBC flag and pass it to ieee80211
From: Oleksij Rempel @ 2013-05-24 18:30 UTC (permalink / raw)
To: ath9k-devel, linux-wireless; +Cc: Oleksij Rempel
In-Reply-To: <1368949136-6079-1-git-send-email-linux@rempel-privat.de>
This patch make use of STBC flag in DMA RX descriptor.
Only devices after ar9280 can provide this information.
If card support it we will set HAVE_STBC flag, to show
clint programm thet STBC is supported but not received.
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
---
drivers/net/wireless/ath/ath9k/init.c | 10 ++++++++--
drivers/net/wireless/ath/ath9k/mac.c | 5 +++++
drivers/net/wireless/ath/ath9k/mac.h | 3 ++-
3 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index aba4151..b9c97d4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -21,6 +21,7 @@
#include <linux/ath9k_platform.h>
#include <linux/module.h>
#include <linux/relay.h>
+#include <net/ieee80211_radiotap.h>
#include "ath9k.h"
@@ -769,8 +770,13 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
IEEE80211_HW_SUPPORTS_RC_TABLE;
- if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT)
- hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+ if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
+ hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
+
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ hw->radiotap_mcs_details |=
+ IEEE80211_RADIOTAP_MCS_HAVE_STBC;
+ }
if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index a52081d..d055e38 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -593,6 +593,11 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
(ads.ds_rxstatus3 & AR_GI) ? RX_FLAG_SHORT_GI : 0;
rs->flag |=
(ads.ds_rxstatus3 & AR_2040) ? RX_FLAG_40MHZ : 0;
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ rs->flag |=
+ (ads.ds_rxstatus3 & AR_STBC) ?
+ /* we can only Nss=1 STBC */
+ (1 << RX_FLAG_STBC_SHIFT) : 0;
if (ads.ds_rxstatus8 & AR_PreDelimCRCErr)
rs->rs_flags |= ATH9K_RX_DELIM_CRC_PRE;
diff --git a/drivers/net/wireless/ath/ath9k/mac.h b/drivers/net/wireless/ath/ath9k/mac.h
index 3f1e775..b02dfce 100644
--- a/drivers/net/wireless/ath/ath9k/mac.h
+++ b/drivers/net/wireless/ath/ath9k/mac.h
@@ -534,7 +534,8 @@ struct ar5416_desc {
#define AR_2040 0x00000002
#define AR_Parallel40 0x00000004
#define AR_Parallel40_S 2
-#define AR_RxStatusRsvd30 0x000000f8
+#define AR_STBC 0x00000008 /* on ar9280 and later */
+#define AR_RxStatusRsvd30 0x000000f0
#define AR_RxAntenna 0xffffff00
#define AR_RxAntenna_S 8
--
1.8.1.2
^ permalink raw reply related
* Re: Mobile Broadband Interface Model (MBIM) support?
From: Bjørn Mork @ 2013-05-24 19:08 UTC (permalink / raw)
To: Sarah Sharp
Cc: linux-wireless, linux-usb, Ismail, Rahman, Wallick, Stephanie S
In-Reply-To: <20130524170915.GA15788@xanatos>
[resending due to an unreliable smtp smarthost - apologies if you
receive any duplicates]
Sarah Sharp <sarah.a.sharp@linux.intel.com> writes:
> Do we have support for the new extensions for USB communication devices
> that use the Mobile Broadband Interface Model (MBIM) spec?
We do. See drivers/net/usb/cdc_mbim.c. It's a usbnet minidriver based on
reusing parts of cdc_ncm. It should be fairly complete, but the IP
session multiplexing and Device Service Streams features are not tested
on actual devices. I just haven't found any device with those features
yet. Any hints are appreciated...
The management protocol implementation is completely delegated to
userspace. The driver isn't involved at all. One implementation is
libmbim, which just had its 1.0.0 release:
http://www.freedesktop.org/software/libmbim/
The next ModemManager release will support MBIM devices using this
library.
> http://www.usb.org/developers/devclass_docs/MBIM10Errata1.zip
Thanks for that pointer. I haven't seen the errata before. Will study
it, but fortunately we are protected against anything involving
management protocol updates.
> The spec was released pretty recently, which is why I'm asking on the
> mailing lists, rather than digging around the kernel tree for a driver.
Well, a "git grep MBIM drivers/" would be enough. But I'm happy to
answer your questions :)
Bjørn
^ 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