Linux wireless drivers development
 help / color / mirror / Atom feed
* Re: pci-half-mini 7206 ac/bluetooth issues
From: Emmanuel Grumbach @ 2013-10-06  5:02 UTC (permalink / raw)
  To: Tim Nelson; +Cc: linux-wireless
In-Reply-To: <CAOAOC6YT=ek4S=s0YNqejD2iCdPYng6FnJ1ROegwWhmcVZhyOg@mail.gmail.com>

On Sun, Oct 6, 2013 at 4:49 AM, Tim Nelson <tim.l.nelson@gmail.com> wrote:
> If I use both the wifi and the bluetooth at the same time on the
> adapter eventually wifi dies.
>
> Here is a complete log from my syslog, I rmmod'd the iwlmvm and then
> modprobed it to resolve the issue.  This only happens when using
> wifi/bluetooth at the same time.
>

can you please try this:

modprobe bt_coex_active=0

and also (in a different test), can you please disable power save - add:
options iwlmvm power_scheme=1
to /etc/modprobe.d/iwlwifi.conf or something like that?

Thanks

^ permalink raw reply

* [PATCH] net: p54spi: remove deprecated IRQF_DISABLED
From: Michael Opdenacker @ 2013-10-06  5:04 UTC (permalink / raw)
  To: chunkeey, linville
  Cc: linux-wireless, netdev, linux-kernel, Michael Opdenacker

This patch proposes to remove the use of the IRQF_DISABLED flag

It's a NOOP since 2.6.35 and it will be removed one day.

Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
---
 drivers/net/wireless/p54/p54spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index 7fc46f2..de15171 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -636,7 +636,7 @@ static int p54spi_probe(struct spi_device *spi)
 	gpio_direction_input(p54spi_gpio_irq);
 
 	ret = request_irq(gpio_to_irq(p54spi_gpio_irq),
-			  p54spi_interrupt, IRQF_DISABLED, "p54spi",
+			  p54spi_interrupt, 0, "p54spi",
 			  priv->spi);
 	if (ret < 0) {
 		dev_err(&priv->spi->dev, "request_irq() failed");
-- 
1.8.1.2


^ permalink raw reply related

* RE: [Ilw] Re: Kernel panic in 3.10.10-rt7 (iwlwifi)
From: Grumbach, Emmanuel @ 2013-10-06  6:00 UTC (permalink / raw)
  To: Sebastian Andrzej Siewior, Thomas Meyer
  Cc: linux-rt-users@vger.kernel.org, Berg, Johannes,
	linux-wireless@vger.kernel.org, Intel Linux Wireless,
	tglx@linutronix.de
In-Reply-To: <20131004101216.GA17043@linutronix.de>

PiA+TXkgc3lzdGVtIGRpZCBsb2NrdXAgYWZ0ZXIgc2hvcnQgdGltZSBvZiB1c2FnZS4gSSB3YXMg
b25seSBhYmxlIHRvIGNhcHR1cmUNCj4gdGhpcyBzY3JlZW5zaG90Og0KPiA+DQo+ID5BbnkgaWRl
YXM/DQo+IA0KPiB0aGUgcHJvYmxlbSBzZWVtcyB0byBiZSB0aGF0IHRoZXkgdXNlIHNsZWVwaW5n
IGxvY2tzIGluIHRoZSBwcmltYXJ5IGlycQ0KPiBoYW5kbGVyLg0KPiANCj4gaXdsX3BjaWVfcnhf
cmVwbGVuaXNoKCkgdGFrZXMgdGhlIHNhbWUgbG9jayAoLT5pcnFfbG9jaykgYW5kIGFkZGl0aW9u
YWx5DQo+IC0+bG9jayBzbyBJIHRoaW5rIHR1bnJuaW5nIGV2ZXJ5dGhpbmcgaW50byByYXcgbG9j
a3MgaXNuJ3QgdmVyeSB3aXNlIGZvcg0KPiB0aGUgbGF0ZW5jeS4NCj4gDQo+IFRoZSB0aHJlYWRl
ZCBoYW5kbGVyIHRha2VzIGZvciBhIHZlcnkgc2hvcnQgdGltZSBpcnFfbG9jayBsb2NrLiBJdCBh
bHNvIHRha2VzDQo+IHRoZSAtPmxvY2sgdmlhIChpd2xfcGNpZV9yeHFfaW5jX3dyX3B0cigpKSB3
aXRoIGlycXMgb2ZmICh0aGF0IG9uZSBsb29rcyBzaG9ydCwNCj4gdG9vKSBhbmQgb3RoZXJzIGZv
ciBpbnN0YW5jZSB2aWEgaXdsX3BjaWVfcnhfaGFuZGxlKCkuDQo+IElkZWFsbHkgdGhlIGRyaXZl
ciBzaG91bGQgaG9sZCBvbmUgc3BpbmxvY2sgdG8gc3luY2hyb25pemUgdGhlIHByaW1hcnkgYW5k
DQo+IHRocmVhZGVkIGlycSBoYW5kbGVyIHdoaWxlIGRpc2FibGluZyB0aGUgaW50ZXJydXB0IGlu
IHRoZSBpd2wgaGFyZHdhcmUuDQo+IEV2ZXJ5dGhpbmcgZWxzZSB3b3VsZCB0aGVuIGhvbGQgb25l
IG9yIHR3byBtdXRleChlcykgYW5kIGNvdWxkIGV2ZW4NCj4gYWxsb2NhdGUgbWVtb3J5IHdpdGgg
R0ZQX0tFUk5FTC4NCg0KV2UgaGF2ZSBhIHBhdGNoIGludGVybmFsbHkgdGhhdCBnb2VzIGludG8g
dGhhdCBkaXJlY3Rpb24sIGJ1dCBvbmUgdGhpbmcgdGhvdWdoLiBJZiB5b3Ugc3RpbGwgaGF2ZSBh
IHNwaW5sb2NrIGluIHRoZSBwcmltYXJ5IGhhbmRsZXIsIHdvdWxkbid0IHRoYXQgc2xlZXAgaW4g
YSBub24tc2xlZXBhYmxlIGNvbnRleHQ/IEZvcmdpdmUgbXkgLXJ0IGlnbm9yYW5jZSwgYnV0IEkg
dW5kZXJzdG9vZCB0aGF0IGluIC1ydCwgYWxsIHRoZSBzcGlubG9jayBnbyB0byBzbGVlcCB3aGlj
aCBiYXNpY2FsbHkgbWVhbiB0aGF0IHdlIGNhbid0IHRha2UgYW55IHNwaW5sb2NrIGluIHRoZSBw
cmltYXJ5IGlycSBoYW5kbGVyIHNvIEkgYW0gYSBiaXQgY29uZnVzZWQgaGVyZS4NCg0KPiANCj4g
Rm9yIG5vdyBJIHRoaW5rIHRoZSBzaW1wbHkgdGhpbmcgd291bGQgYmUganVzdCB0byBsZXQgYm90
aCBoYW5kbGVycyBydW4gaW4gdGhlDQo+IHRocmVhZC4gRG9lcyB0aGlzIHBhdGNoIHNvbHZlIHlv
dXIgcHJvYmxlbT8NCj4gDQo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL25ldC93aXJlbGVzcy9pd2x3
aWZpL3BjaWUvdHJhbnMuYw0KPiBiL2RyaXZlcnMvbmV0L3dpcmVsZXNzL2l3bHdpZmkvcGNpZS90
cmFucy5jDQo+IGluZGV4IGFlYjcwZTEuLjQyNTY3ZmMgMTAwNjQ0DQo+IC0tLSBhL2RyaXZlcnMv
bmV0L3dpcmVsZXNzL2l3bHdpZmkvcGNpZS90cmFucy5jDQo+ICsrKyBiL2RyaXZlcnMvbmV0L3dp
cmVsZXNzL2l3bHdpZmkvcGNpZS90cmFucy5jDQo+IEBAIC0xNDU2LDYgKzE0NTYsMjAgQEAgc3Rh
dGljIGNvbnN0IHN0cnVjdCBpd2xfdHJhbnNfb3BzIHRyYW5zX29wc19wY2llID0NCj4gew0KPiAg
CS5zZXRfYml0c19tYXNrID0gaXdsX3RyYW5zX3BjaWVfc2V0X2JpdHNfbWFzaywgIH07DQo+IA0K
PiArI2lmZGVmIENPTkZJR19QUkVFTVBUX1JUX0JBU0UNCj4gK3N0YXRpYyBpcnFyZXR1cm5fdCBp
d2xfcnRfaXJxX2hhbmRsZXIoaW50IGlycSwgdm9pZCAqZGV2X2lkKSB7DQo+ICsJaXJxcmV0dXJu
X3QgcmV0Ow0KPiArDQo+ICsJbG9jYWxfYmhfZGlzYWJsZSgpOw0KPiArCXJldCA9IGl3bF9wY2ll
X2lzcl9pY3QoaXJxLCBkZXZfaWQpOw0KPiArCWxvY2FsX2JoX2VuYWJsZSgpOw0KPiArCWlmIChy
ZXQgPT0gSVJRX1dBS0VfVEhSRUFEKQ0KPiArCQlyZXQgPSBpd2xfcGNpZV9pcnFfaGFuZGxlcihp
cnEsIGRldl9pZCk7DQo+ICsJcmV0dXJuIHJldDsNCj4gK30NCj4gKyNlbmRpZg0KPiArDQo+ICBz
dHJ1Y3QgaXdsX3RyYW5zICppd2xfdHJhbnNfcGNpZV9hbGxvYyhzdHJ1Y3QgcGNpX2RldiAqcGRl
diwNCj4gIAkJCQkgICAgICAgY29uc3Qgc3RydWN0IHBjaV9kZXZpY2VfaWQgKmVudCwNCj4gIAkJ
CQkgICAgICAgY29uc3Qgc3RydWN0IGl3bF9jZmcgKmNmZykNCj4gQEAgLTE1NjYsOSArMTU4MCwx
NCBAQCBzdHJ1Y3QgaXdsX3RyYW5zICppd2xfdHJhbnNfcGNpZV9hbGxvYyhzdHJ1Y3QNCj4gcGNp
X2RldiAqcGRldiwNCj4gIAlpZiAoaXdsX3BjaWVfYWxsb2NfaWN0KHRyYW5zKSkNCj4gIAkJZ290
byBvdXRfZnJlZV9jbWRfcG9vbDsNCj4gDQo+ICsjaWZkZWYgQ09ORklHX1BSRUVNUFRfUlRfQkFT
RQ0KPiArCWlmIChyZXF1ZXN0X3RocmVhZGVkX2lycShwZGV2LT5pcnEsIE5VTEwsIGl3bF9ydF9p
cnFfaGFuZGxlciwNCj4gKwkJCQkgSVJRRl9TSEFSRUQgfCBJUlFGX09ORVNIT1QsDQo+IERSVl9O
QU1FLCB0cmFucykpIHsgI2Vsc2UNCj4gIAlpZiAocmVxdWVzdF90aHJlYWRlZF9pcnEocGRldi0+
aXJxLCBpd2xfcGNpZV9pc3JfaWN0LA0KPiAgCQkJCSBpd2xfcGNpZV9pcnFfaGFuZGxlciwNCj4g
IAkJCQkgSVJRRl9TSEFSRUQsIERSVl9OQU1FLCB0cmFucykpIHsNCj4gKyNlbmRpZg0KPiAgCQlJ
V0xfRVJSKHRyYW5zLCAiRXJyb3IgYWxsb2NhdGluZyBJUlEgJWRcbiIsIHBkZXYtPmlycSk7DQo+
ICAJCWdvdG8gb3V0X2ZyZWVfaWN0Ow0KPiAgCX0NCj4gLS0NCj4gMS44LjQucmMzDQo+IA0KPiAN
Cj4gPldpdGgga2luZCByZWdhcmRzDQo+ID5UaG9tYXMNCj4gDQo+IFNlYmFzdGlhbg0KPiANCj4g
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaWx3IG1h
aWxpbmcgbGlzdA0KPiBpbHdAbGludXguaW50ZWwuY29tDQo+IGh0dHA6Ly9saW51eC5pbnRlbC5j
b20vbWFpbG1hbi9saXN0aW5mby9pbHcNCg==

^ permalink raw reply

* RE: [PATCH 3/3] [RFC] cfg80211: Enable GO operation on additional channels
From: Peer, Ilan @ 2013-10-06 11:28 UTC (permalink / raw)
  To: Luis R. Rodriguez, Jeff Johnson
  Cc: Spinadel, David, linux-wireless,
	wireless-regdb@lists.infradead.org, Jouni Malinen, Ginsburg, Noam,
	Perelmooter, Liraz, Shalev, Oz, Michael Green
In-Reply-To: <CAB=NE6WmEQg68BViF9v+2D__p8Gc_5bCFUkBMfTz0A96C1jyDw@mail.gmail.com>

PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBtY2dyb2ZAZ21haWwuY29tIFtt
YWlsdG86bWNncm9mQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIEx1aXMgUi4NCj4gUm9kcmlndWV6
DQo+IFNlbnQ6IEZyaWRheSwgT2N0b2JlciAwNCwgMjAxMyAyMDozOA0KPiBUbzogUGVlciwgSWxh
bjsgSmVmZiBKb2huc29uDQo+IENjOiBTcGluYWRlbCwgRGF2aWQ7IGxpbnV4LXdpcmVsZXNzOyB3
aXJlbGVzcy1yZWdkYkBsaXN0cy5pbmZyYWRlYWQub3JnOyBKb3VuaQ0KPiBNYWxpbmVuOyBHaW5z
YnVyZywgTm9hbTsgUGVyZWxtb290ZXIsIExpcmF6OyBTaGFsZXYsIE96OyBNaWNoYWVsIEdyZWVu
DQo+IFN1YmplY3Q6IFJlOiBbUEFUQ0ggMy8zXSBbUkZDXSBjZmc4MDIxMTogRW5hYmxlIEdPIG9w
ZXJhdGlvbiBvbiBhZGRpdGlvbmFsDQo+IGNoYW5uZWxzDQo+IA0KPiBPbiBUaHUsIEp1bCAxOCwg
MjAxMyBhdCA0OjM0IFBNLCBMdWlzIFIuIFJvZHJpZ3VleiA8bWNncm9mQGRvLW5vdC0NCj4gcGFu
aWMuY29tPiB3cm90ZToNCj4gPiBPbiBXZWQsIEp1bCAxNywgMjAxMyBhdCAxMjoxNSBQTSwgUGVl
ciwgSWxhbiA8aWxhbi5wZWVyQGludGVsLmNvbT4gd3JvdGU6DQo+ID4+PiBJdCB3YXMgdW5jbGVh
ciBmb3Igd2hhdCBleGFjdCBjaGFubmVscyB5b3UgbmVlZGVkIHRvIGRlYWwgd2l0aCBoZXJlLg0K
PiA+Pj4gR2l2ZW4gcmV2aWV3IHNvIGZhciB3b3VsZG4ndCBpdCBqdXN0IGJlIERGUyBmbGFnZ2Vk
IGNoYW5uZWxzIG9uIHNvbWUNCj4gPj4+IFVOSUkgYmFuZHMgPyBUaGVuIGFnYWluIGlmIHRoZSBp
bmRvb3IgZmxhZyBuZWVkcyB0byBiZSBwZWdnZWQgdG8gdG8NCj4gPj4+IGEgc3BlY2lmaWMgVU5J
SSBiYW5kIGFuZCB3ZSBjYW4gZG8gdGhhdCBvbiB3aXJlbGVzcy1yZWdkYiBkbyB3ZSBldmVuDQo+
ID4+PiBuZWVkIHRoZSBVTklJIGJhbmQgY2hlY2sgcm91dGluZSBoZWxwZXI/DQo+ID4+Pg0KPiA+
Pg0KPiA+PiBHZW5lcmFsbHkgaXQgaXMgcG9zc2libGUgdGhhdCB0aGUgaW5kb29yIHByb3BlcnR5
IGlzIG5vdCBwZWdnZWQgdG8NCj4gPj4gdGhlICdvdGhlcl9jaGFubmVsJywgb3IgaXQgaXMgcG9z
c2libGUgdGhhdCBpdCBpcyBwZWdnZWQgYnV0IHRoZXkgYXJlDQo+ID4+IG5vdCBpbiB0aGUgc2Ft
ZSBVTklJIGJhbmQsIHNvIHRoZSB2ZXJpZmljYXRpb24gaXMgc3RpbGwgbmVlZGVkLiBJDQo+ID4+
IGd1ZXNzIHRoYXQgb25jZSBJIGdldCB0aGUgbGlzdCB5b3UgcmVxdWVzdGVkIHRoaW5ncyB3aWxs
IGJlIGNsZWFyZXINCj4gPj4gOikNCj4gPg0KPiA+IE9LIHNvIHRoZXJlIGFyZSBleGNlcHRpb25z
IHRvIHRoZSBpbmRvb3IgZmxhZyBhZmZlY3RpbmcgR08gdW5kZXIgdGhlc2UNCj4gPiBydWxlcyBv
ciBub3QuIExvb2tpbmcgZm9yd2FyZCB0byB0aGUgcmVzcGluLg0KPiANCj4gQW54aW91c2x5IGxv
b2tpbmcgZm9yd2FyZCB0byB0aGUgcmVzcGluIDpEDQo+IA0KDQpNZSB0b28gOykgLi4uIHVuZm9y
dHVuYXRlbHkgSSBkaWQgbm90IGdldCBhIGNoYW5jZSB0byB3b3JrIG9uIHRoaXMgaW4gdGhlIGxh
c3QgY291cGxlIG9mIG1vbnRocy4gSG9wZSBJJ2xsIGdldCB0byBpdCB0aGlzIHdlZWsgb3IgdGhl
IG5leHQuIFNvcnJ5IGZvciBub3QgdXBkYXRpbmcgZWFybGllciAuLi4NCg0KUmVnYXJkcywNCg0K
SWxhbi4NCg0K

^ permalink raw reply

* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: Eugene Krasnikov @ 2013-10-06 19:30 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless, wcn36xx, wcn36xx
In-Reply-To: <20131004234514.GA11128@garbanzo.do-not-panic.com>

Hi Luis,

Thanx for the patch. Although there is a one small comment:

> +static void wcn_reg_notifier(struct wiphy *wiphy,
> +                            struct regulatory_request *request)
> +{

Function should be called wcn36xx_reg_notifier not wcn_reg_notifier.
Could you please change that?

Also are you concerned about this warnings?

> Nice! I test compiled with sparse enabled and got this:
>
> mcgrof@chalten ~/wireless-testing (git::master)$ make C=1
> M=drivers/net/wireless/ath/wcn36xx/
> CHECK   drivers/net/wireless/ath/wcn36xx/main.c
> CC [M]  drivers/net/wireless/ath/wcn36xx/main.o
> CHECK   drivers/net/wireless/ath/wcn36xx/dxe.c
> CC [M]  drivers/net/wireless/ath/wcn36xx/dxe.o
> CHECK   drivers/net/wireless/ath/wcn36xx/txrx.c
> CC [M]  drivers/net/wireless/ath/wcn36xx/txrx.o
> CHECK   drivers/net/wireless/ath/wcn36xx/smd.c
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (4096 8)
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (512 8)
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (128 8)
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (8 8)
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (256 8)
> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (4096 8)

What kind of config are you using to generate this warnings?

^ permalink raw reply

* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: Eugene Krasnikov @ 2013-10-06 20:39 UTC (permalink / raw)
  To: Luis R. Rodriguez; +Cc: John Linville, linux-wireless, wcn36xx, wcn36xx
In-Reply-To: <CAFSJ42YRmwZ-mK5yADsf=sfi7b5rEK9hFdH-waoswrubvyZddA@mail.gmail.com>

Hi Luis,

Warnings are valid! Thanx for pointing them. Will fix and resend the
patch togather with ur regdb patch+warning fix.

2013/10/6 Eugene Krasnikov <k.eugene.e@gmail.com>:
> Hi Luis,
>
> Thanx for the patch. Although there is a one small comment:
>
>> +static void wcn_reg_notifier(struct wiphy *wiphy,
>> +                            struct regulatory_request *request)
>> +{
>
> Function should be called wcn36xx_reg_notifier not wcn_reg_notifier.
> Could you please change that?
>
> Also are you concerned about this warnings?
>
>> Nice! I test compiled with sparse enabled and got this:
>>
>> mcgrof@chalten ~/wireless-testing (git::master)$ make C=1
>> M=drivers/net/wireless/ath/wcn36xx/
>> CHECK   drivers/net/wireless/ath/wcn36xx/main.c
>> CC [M]  drivers/net/wireless/ath/wcn36xx/main.o
>> CHECK   drivers/net/wireless/ath/wcn36xx/dxe.c
>> CC [M]  drivers/net/wireless/ath/wcn36xx/dxe.o
>> CHECK   drivers/net/wireless/ath/wcn36xx/txrx.c
>> CC [M]  drivers/net/wireless/ath/wcn36xx/txrx.o
>> CHECK   drivers/net/wireless/ath/wcn36xx/smd.c
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (4096 8)
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (512 8)
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (128 8)
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (8 8)
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (256 8)
>> /home/mcgrof/wireless-testing/arch/x86/include/asm/bitops.h:329:18: warning: invalid access past the end of 'caps' (4096 8)
>
> What kind of config are you using to generate this warnings?



-- 
Best regards,
Eugene

^ permalink raw reply

* [PATCH V2] memstick: Fix memory leak in memstick_check() error path
From: Larry Finger @ 2013-10-07  3:21 UTC (permalink / raw)
  To: linville, Alex Dubov
  Cc: linux-wireless, Larry Finger, linux-kernel, Kay Sievers,
	Greg Kroah-Hartman

With kernel 3.12-rc3, kmemleak reports the following leak:

> unreferenced object 0xffff8800ae85c190 (size 16):
>   comm "kworker/u4:3", pid 685, jiffies 4294916336 (age 2831.760s)
>   hex dump (first 16 bytes):
>     6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00  memstick0.......
>   backtrace:
>     [<ffffffff8146a0d1>] kmemleak_alloc+0x21/0x50
>     [<ffffffff81160720>] __kmalloc_track_caller+0x160/0x2f0
>     [<ffffffff81237b9b>] kvasprintf+0x5b/0x90
>     [<ffffffff8122c0c1>] kobject_set_name_vargs+0x21/0x60
>     [<ffffffff812e7f5c>] dev_set_name+0x3c/0x40
>     [<ffffffffa02bf918>] memstick_check+0xb8/0x340 [memstick]
>     [<ffffffff81069862>] process_one_work+0x1d2/0x670
>     [<ffffffff8106a88a>] worker_thread+0x11a/0x370
>     [<ffffffff81072ea6>] kthread+0xd6/0xe0
>     [<ffffffff81478bbc>] ret_from_fork+0x7c/0xb0

This problem was introduced by commit 0252c3b "memstick: struct device -
replace bus_id with dev_name(), dev_set_name()" where the name is not freed
in the error path. The name is also leaked in memstick_free_card(). 

Thanks to Catalin Marinas for suggesting the fix.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Alex Dubov <oakad@yahoo.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---

V2 fixes the typos in the commit message, and frees the name in
memstick_free_card() as well as the error path in memstick_check().

Larry
---
 drivers/memstick/core/memstick.c | 2 ++
 1 file changed, 2 insertion(+)

Index: wireless-testing-save/drivers/memstick/core/memstick.c
===================================================================
--- wireless-testing-save.orig/drivers/memstick/core/memstick.c
+++ wireless-testing-save/drivers/memstick/core/memstick.c
@@ -195,6 +195,7 @@ static void memstick_free_card(struct de
 {
 	struct memstick_dev *card = container_of(dev, struct memstick_dev,
 						 dev);
+	kfree(card->dev.kobj.name);
 	kfree(card);
 }
 
@@ -415,6 +416,7 @@ static struct memstick_dev *memstick_all
 	return card;
 err_out:
 	host->card = old_card;
+	kfree(card->dev.kobj.name);
 	kfree(card);
 	return NULL;
 }

^ permalink raw reply

* [PATCH 06/11] bcma: convert bus code to use dev_groups
From: Greg Kroah-Hartman @ 2013-10-07  6:55 UTC (permalink / raw)
  To: linux-kernel; +Cc: Greg Kroah-Hartman, Rafał Miłecki, linux-wireless
In-Reply-To: <1381128950-28125-1-git-send-email-gregkh@linuxfoundation.org>

The dev_attrs field of struct bus_type is going away soon, dev_groups
should be used instead.  This converts the bcma bus code to use the
correct field.

Cc: Rafał Miłecki <zajec5@gmail.com>
Cc: <linux-wireless@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---

Rafał, I can take this through my driver-core tree if you like, just let
me know what would be the easiest for you.

 drivers/bcma/main.c | 23 ++++++++++++++++-------
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index 90ee350..e15430a 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -30,28 +30,37 @@ static ssize_t manuf_show(struct device *dev, struct device_attribute *attr, cha
 	struct bcma_device *core = container_of(dev, struct bcma_device, dev);
 	return sprintf(buf, "0x%03X\n", core->id.manuf);
 }
+static DEVICE_ATTR_RO(manuf);
+
 static ssize_t id_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct bcma_device *core = container_of(dev, struct bcma_device, dev);
 	return sprintf(buf, "0x%03X\n", core->id.id);
 }
+static DEVICE_ATTR_RO(id);
+
 static ssize_t rev_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct bcma_device *core = container_of(dev, struct bcma_device, dev);
 	return sprintf(buf, "0x%02X\n", core->id.rev);
 }
+static DEVICE_ATTR_RO(rev);
+
 static ssize_t class_show(struct device *dev, struct device_attribute *attr, char *buf)
 {
 	struct bcma_device *core = container_of(dev, struct bcma_device, dev);
 	return sprintf(buf, "0x%X\n", core->id.class);
 }
-static struct device_attribute bcma_device_attrs[] = {
-	__ATTR_RO(manuf),
-	__ATTR_RO(id),
-	__ATTR_RO(rev),
-	__ATTR_RO(class),
-	__ATTR_NULL,
+static DEVICE_ATTR_RO(class);
+
+static struct attribute *bcma_device_attrs[] = {
+	&dev_attr_manuf.attr,
+	&dev_attr_id.attr,
+	&dev_attr_rev.attr,
+	&dev_attr_class.attr,
+	NULL,
 };
+ATTRIBUTE_GROUPS(bcma_device);
 
 static struct bus_type bcma_bus_type = {
 	.name		= "bcma",
@@ -59,7 +68,7 @@ static struct bus_type bcma_bus_type = {
 	.probe		= bcma_device_probe,
 	.remove		= bcma_device_remove,
 	.uevent		= bcma_device_uevent,
-	.dev_attrs	= bcma_device_attrs,
+	.dev_groups	= bcma_device_groups,
 };
 
 static u16 bcma_cc_core_id(struct bcma_bus *bus)
-- 
1.8.4.6.g82e253f.dirty


^ permalink raw reply related

* Re: [Ilw] Re: Kernel panic in 3.10.10-rt7 (iwlwifi)
From: Sebastian Andrzej Siewior @ 2013-10-07  7:33 UTC (permalink / raw)
  To: Grumbach, Emmanuel
  Cc: Thomas Meyer, linux-rt-users@vger.kernel.org, Berg, Johannes,
	linux-wireless@vger.kernel.org, Intel Linux Wireless,
	tglx@linutronix.de
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301DBC098@HASMSX103.ger.corp.intel.com>

On 10/06/2013 08:00 AM, Grumbach, Emmanuel wrote:
> 
> We have a patch internally that goes into that direction, but one thing though.

Sounds great.

> If you still have a spinlock in the primary handler, wouldn't that sleep in a non-sleepable context? Forgive my -rt ignorance, but I understood that in -rt, all the spinlock go to sleep which basically mean that we can't take any spinlock in the primary irq handler so I am a bit confused here.

After my change there is no primary handler anymore, just the threaded
where you can take the (sleeping) spinlock.
Everything what you wrote is correct:
- you can't take a spinlock in the primary handler
- all spinlocks may sleep

Sebastian

^ permalink raw reply

* Re: NetworkManager not listing access points
From: Johannes Berg @ 2013-10-07  7:40 UTC (permalink / raw)
  To: Detlev Casanova; +Cc: Dan Williams, linux-wireless, laurent.pinchart
In-Reply-To: <2916718.7t7kLXuBQV@naboo>

On Mon, 2013-10-07 at 08:48 +0200, Detlev Casanova wrote:

> > > Yes and the problem is most likely to be in the driver because it
> doesn't
> > > occur before commit 0172bb75073e11a5aa9d8a953bdaefb8709f00c8
> ("cfg80211:
> > > use DS or HT operation IEs to determine BSS channel")

[...]

> I looked into wpa_supplicant and after an upgrade from 0.7.3 to 2.0,
> the problem seems to be fixed.

Huh, that's odd. Did 0.7.3 use wext driver?

johannes


^ permalink raw reply

* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: Johannes Berg @ 2013-10-07  7:49 UTC (permalink / raw)
  To: Luis R. Rodriguez
  Cc: Eugene Krasnikov, linville, linux-wireless, wcn36xx, wcn36xx
In-Reply-To: <20131004234514.GA11128@garbanzo.do-not-panic.com>

On Fri, 2013-10-04 at 16:45 -0700, Luis R. Rodriguez wrote:

> Nice! I test compiled with sparse enabled and got this:

Could also consider running smatch.

johannes


^ permalink raw reply

* Re: [PATCH] wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware
From: Eugene Krasnikov @ 2013-10-07  7:57 UTC (permalink / raw)
  To: Johannes Berg
  Cc: Luis R. Rodriguez, John Linville, linux-wireless, wcn36xx,
	wcn36xx
In-Reply-To: <1381132198.13586.1.camel@jlt4.sipsolutions.net>

Thanx Johannes for advice. Will try it as well.

2013/10/7 Johannes Berg <johannes@sipsolutions.net>:
> On Fri, 2013-10-04 at 16:45 -0700, Luis R. Rodriguez wrote:
>
>> Nice! I test compiled with sparse enabled and got this:
>
> Could also consider running smatch.
>
> johannes
>



-- 
Best regards,
Eugene

^ permalink raw reply

* [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Kevin Lo @ 2013-10-07  7:59 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users

In rt2800_config_channel_rf3xxx(), there's no need to toggle
RF R30 bit 7 twice.

Signed-off-by: Kevin Lo <kevlo@kevlo.org>
---
Changes since v1:
   - the previous patch was malformed
---

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c 
b/drivers/net/wireless/rt2x00/rt2800lib.c
index 25aaa5e..65b4416 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2029,13 +2029,6 @@ static void rt2800_config_channel_rf3xxx(struct 
rt2x00_dev *rt2x00dev,
                           rt2x00dev->default_ant.tx_chain_num <= 2);
         rt2800_rfcsr_write(rt2x00dev, 1, rfcsr);

-       rt2800_rfcsr_read(rt2x00dev, 30, &rfcsr);
-       rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 1);
-       rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
-       msleep(1);
-       rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
-       rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
-
         rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
         rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET, 
rt2x00dev->freq_offset);
         rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);


^ permalink raw reply related

* [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Kevin Lo @ 2013-10-07  8:02 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless, users

In rt2800_config_channel_rf3xxx(), there's no need to toggle
RF R30 bit 7 twice. 

Signed-off-by: Kevin Lo <kevlo@kevlo.org>
---
Changes since v1:
  - the previous patch was malformed
--- 

diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 25aaa5e..65b4416 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2029,13 +2029,6 @@ static void rt2800_config_channel_rf3xxx(struct rt2x00_dev *rt2x00dev,
 			  rt2x00dev->default_ant.tx_chain_num <= 2);
 	rt2800_rfcsr_write(rt2x00dev, 1, rfcsr);
 
-	rt2800_rfcsr_read(rt2x00dev, 30, &rfcsr);
-	rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 1);
-	rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
-	msleep(1);
-	rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
-	rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
-
 	rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
 	rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET, rt2x00dev->freq_offset);
 	rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);

^ permalink raw reply related

* Re: [regression] [bisected] rt2800pci doesn't work after 9483f40d8d01918b399b4e24d0c1111db0afffeb
From: Stanislaw Gruszka @ 2013-10-07  8:24 UTC (permalink / raw)
  To: Kirill Tkhai; +Cc: linux-wireless, linville, ivdoorn, gwingerde, helmut.schaa
In-Reply-To: <39871380943748@web17j.yandex.ru>

On Sat, Oct 05, 2013 at 07:29:08AM +0400, Kirill Tkhai wrote:
> GIt bisect says the first bad commit is 9483f40d8d01918b399b4e24d0c1111db0afffeb:
> 
>         Author: Jakub Kicinski <kubakici@wp.pl>
>         Date:   Tue May 7 00:28:50 2013 +0200
> 
>             rt2x00pci: Use PCI MSIs whenever possible
> 
>             All PCIe devices must support MSIs, make use of them.

I posted revert of that patch some time ago, it's on the way
upstream/stable ...

Stanislaw

^ permalink raw reply

* Re: [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Johannes Berg @ 2013-10-07  8:29 UTC (permalink / raw)
  To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <524FF599.5040706@openwrt.org>

On Sat, 2013-10-05 at 13:18 +0200, Felix Fietkau wrote:

> > I understand. I don't understand the pieces about "max_antenna_gain".

> Right now ath9k has an antenna gain value in the EEPROM, and it compares
> it against the channel max_antenna_gain value.

I just don't understand what the max means. If I connect a 5dBi gain
antenna, but the "max antenna gain" is 3dBi, what should happen?

> Let's assume we have configured the tx power to the maximum value, the
> regdb allows 3 dB antenna gain, and the ath9k EEPROM contains an antenna
> gain of 3 dB as well.
> If we now add another 3 dB of user-configured antenna gain, it first
> starts tapping into the regulatory-allowed antenna gain before reducing
> tx power in mac80211. The driver needs to know about this, so I put the
> calculated maximum antenna gain into the hw conf as well.

I don't think it really works this way, does it? I don't believe the
"regulatory-allowed antenna gain" is really something that's allowed on
top of the EIRP?

johannes


^ permalink raw reply

* Re: [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Johannes Berg @ 2013-10-07  8:30 UTC (permalink / raw)
  To: Felix Fietkau; +Cc: linux-wireless, wireless-regdb
In-Reply-To: <1381134567.13586.3.camel@jlt4.sipsolutions.net>

+ wireless-regdb

On Mon, 2013-10-07 at 10:29 +0200, Johannes Berg wrote:
> On Sat, 2013-10-05 at 13:18 +0200, Felix Fietkau wrote:
> 
> > > I understand. I don't understand the pieces about "max_antenna_gain".
> 
> > Right now ath9k has an antenna gain value in the EEPROM, and it compares
> > it against the channel max_antenna_gain value.
> 
> I just don't understand what the max means. If I connect a 5dBi gain
> antenna, but the "max antenna gain" is 3dBi, what should happen?
> 
> > Let's assume we have configured the tx power to the maximum value, the
> > regdb allows 3 dB antenna gain, and the ath9k EEPROM contains an antenna
> > gain of 3 dB as well.
> > If we now add another 3 dB of user-configured antenna gain, it first
> > starts tapping into the regulatory-allowed antenna gain before reducing
> > tx power in mac80211. The driver needs to know about this, so I put the
> > calculated maximum antenna gain into the hw conf as well.
> 
> I don't think it really works this way, does it? I don't believe the
> "regulatory-allowed antenna gain" is really something that's allowed on
> top of the EIRP?
> 
> johannes
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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

* Re: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel
From: Johannes Berg @ 2013-10-07  8:37 UTC (permalink / raw)
  To: Undekari, Sunil Dutt; +Cc: linux-wireless@vger.kernel.org, j@w1.fi
In-Reply-To: <26F3B0343EE4744AA14EEEF9E1E534511F71B55F@aphydexd01a>

On Thu, 2013-10-03 at 07:20 +0000, Undekari, Sunil Dutt wrote:
> Thanks Johannes for the review.
> 
> >It seems you should validate that the length is even, and at least 2?
> Can I know why the check for even/ atleast 2 is? Though I would
> validate for a non zero length and return failure in the else,
> considering a case where the TDLS peer advertises a single channel.
> Shouldn't it suffice?

Yes, if you look at the 802.11 spec you can know why. Hint: a single
channel is advertised using 2 bytes.

johannes


^ permalink raw reply

* WIFI USB-Stick for P2P
From: Alexander Müller @ 2013-10-07  9:08 UTC (permalink / raw)
  To: linux-wireless@vger.kernel.org

Hello linux-wireless,

I'm wondering if there is a list of usb wifi devices having a good and stable p2p support for wifi direct. We are currently using an AVM Fritz wifi stick that is supported by the carl9170 driver, but it is experiencing random failures and stalls which require a hardware reset. The p2p howto page at http://wireless.kernel.org/en/developers/p2p/howto suggests that there may be other devices and drivers supporting p2p, but I haven't figured out exactly which devices work best.

Can you give me a hint?

Regards,
Alex

________________________________

Dipl.-Inf. (Univ.) Alexander Müller, Software Architect
Phone: +49 89 45 23 47 - 224


jambit GmbH
Erika-Mann-Str. 63, 80636 München
Phone: +49 89 45 23 47 - 0 Fax: +49 89 45 23 47 - 70

http://www.jambit.com where innovation works

Geschäftsführer: Peter F. Fellinger, Markus Hartinger
Sitz: München; Registergericht: München, HRB 129139

^ permalink raw reply

* pull-request: mac80211-next 2013-10-07
From: Johannes Berg @ 2013-10-07  9:51 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless

[-- Attachment #1: Type: text/plain, Size: 3818 bytes --]

John,

First pull request for new features - sorry it's so late.

We have an assortment of cleanups and new features, of which the biggest
one is probably the channel-switch support in IBSS. Nothing else really
stands out much.

Let me know if there's any problem.

johannes


The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git for-john

for you to fetch changes up to 7578d57520f51093f590d68e16965e2714e69747:

  mac80211: implement STA CSA for drivers using channel contexts (2013-10-02 18:18:23 +0200)

----------------------------------------------------------------
Arik Nemtsov (1):
      mac80211: implement STA CSA for drivers using channel contexts

Eliad Peller (2):
      mac80211: fix some snprintf misuses
      ieee80211: fix vht cap definitions

Fred Zhou (2):
      mac80211: use exact-size allocation for authentication frame
      mac80211: improve default WMM parameter setting

Janusz Dziedzic (1):
      cfg80211: parse dfs region for internal regdb option

Johannes Berg (4):
      mac80211: add ieee80211_iterate_active_interfaces_rtnl()
      mac80211: use ERR_CAST()
      mac80211: add explicit IBSS driver operations
      regulatory: enable channels 52-64 and 100-144 for world roaming

Lorenzo Bianconi (2):
      mac80211: add fixed_rate management to minstrel rc
      mac80211: do not override fixed_rate_idx in minstrel_ht_update_stats

Michal Kazior (1):
      mac80211: support reporting A-MSDU subframes individually

Sergey Ryazanov (1):
      mac80211: Remove superfluous is_multicast_ether_addr() call

Simon Wunderlich (7):
      cfg80211: export cfg80211_chandef_dfs_required
      mac80211: split off channel switch parsing function
      mac80211: split off ibss disconnect
      mac80211: add support for CSA in IBSS mode
      mac80211: send a CSA action frame when changing channel
      nl80211: enable IBSS support for channel switch announcements
      nl80211: allow CAC only if no operation is going on

Stanislaw Gruszka (1):
      mac80211: change beacon/connection polling

cedric Voncken (1):
      cfg80211: vlan priority handling in WMM

 include/linux/ieee80211.h          |   4 +-
 include/net/cfg80211.h             |   9 +
 include/net/mac80211.h             |  42 +++
 net/mac80211/cfg.c                 |  92 ++++--
 net/mac80211/chan.c                |   5 -
 net/mac80211/debugfs.c             |  55 ++--
 net/mac80211/driver-ops.h          |  27 ++
 net/mac80211/ibss.c                | 608 +++++++++++++++++++++++++++++++------
 net/mac80211/ieee80211_i.h         |  30 +-
 net/mac80211/iface.c               |   4 +
 net/mac80211/key.c                 |   2 +-
 net/mac80211/mlme.c                | 334 +++++---------------
 net/mac80211/rc80211_minstrel.c    |  14 +
 net/mac80211/rc80211_minstrel_ht.c |  23 +-
 net/mac80211/rc80211_pid_debugfs.c |  26 +-
 net/mac80211/rx.c                  |  39 ++-
 net/mac80211/scan.c                |   3 +-
 net/mac80211/spectmgmt.c           | 162 ++++++++++
 net/mac80211/trace.h               |  35 +++
 net/mac80211/tx.c                  |  39 ++-
 net/mac80211/util.c                | 162 ++++++----
 net/mac80211/vht.c                 |   4 +-
 net/wireless/chan.c                |   1 +
 net/wireless/core.h                |   9 -
 net/wireless/debugfs.c             |  24 +-
 net/wireless/genregdb.awk          |   6 +
 net/wireless/nl80211.c             |  52 +++-
 net/wireless/reg.c                 |  14 +-
 net/wireless/util.c                |   9 +
 29 files changed, 1290 insertions(+), 544 deletions(-)


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* pull-request: iwlwifi-next 2013-10-07
From: Johannes Berg @ 2013-10-07  9:56 UTC (permalink / raw)
  To: John Linville; +Cc: linux-wireless

[-- Attachment #1: Type: text/plain, Size: 5557 bytes --]

John,

Also the first pull request for iwlwifi-next, also quite late, sorry.

We have a collection of things all over, with two bigger things standing
out: a rather big Bluetooth coexistence update and VHT support in rate
scaling.

Let me know if there's any problem.

johannes


The following changes since commit 272b98c6455f00884f0350f775c5342358ebb73f:

  Linux 3.12-rc1 (2013-09-16 16:17:51 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git for-john

for you to fetch changes up to 07ad72f761482a0b59a946efe0c6290e0858057f:

  iwlwifi: mvm: add support for NICs which have only 16 Tx queues. (2013-10-02 18:00:49 +0200)

----------------------------------------------------------------
Alexander Bondar (2):
      iwlwifi: mvm: Adjust some power management constants
      iwlwifi: mvm: Add device wide power command

Andrei Otcheretianski (1):
      iwlwifi: mvm: Implement BT coex notifications

David Spinadel (3):
      iwlwifi: mvm: implement NoA testing using testmode cmd
      iwlwifi: mvm: add no_basic_ssid option
      iwlwifi: mvm: support sched scan if supported by the fw

Djalal Harouni (1):
      iwlwifi: mvm: make debugfs write() operations write up to count bytes

Emmanuel Grumbach (13):
      iwlwifi: mvm: use CTS to Self if firmware allows it
      iwlwifi: pcie: clean RFKILL interrupt in AMPG
      iwlwifi: mvm: don't sleep while allocating in atomic context
      iwlwifi: mvm: new BT Coex API
      iwlwifi: mvm: BT Coex - no need to send envelopes
      iwlwifi: mvm: BT Coex - use data from firmware
      iwlwifi: mvm: don't use reduced Tx power when not applicable
      iwlwifi: mvm: BT Coex - adapt debugfs to new API
      iwlwifi: mvm: BT Coex - Correctly enable and treat rssi events
      iwlwifi: pcie: dump_stack upon timeout of SYNC cmd
      iwlwifi: mvm: BT Coex - don't limit agg size in loose scheme
      iwlwifi: mvm: BT Coex - set the proper LUT for single ant devices
      iwlwifi: pcie: restart the driver when a command times out

Eyal Shapira (5):
      iwlwifi: mvm: remove rs FSM actions relevant only for 3 antennas
      iwlwifi: mvm: fix switch from shared antenna in case of BT load
      iwlwifi: mvm: update expected tpt tables for VHT
      iwlwifi: mvm: support VHT in rs
      iwlwifi: mvm: remove GF support in rs

Eytan Lifshitz (3):
      iwlwifi: mvm: change the name of init_ucode_run flag
      iwlwifi: mvm: prevent the NIC to be powered at driver load time.
      iwlwifi: mvm: add support for NICs which have only 16 Tx queues.

Jingoo Han (1):
      wireless: iwlwifi: remove unnecessary pci_set_drvdata()

Johannes Berg (5):
      iwlwifi: mvm: implement beacon filtering testmode command
      iwlwifi: mvm: query firmware for non-QoS seqno
      iwlwifi: mvm: give client MACs time to synchronise during restart
      iwlwifi: mvm: fix locking in iwl_mvm_bt_rssi_event()
      iwlwifi: mvm: implement new IPv6 offload API

Max Stepanov (1):
      iwlwifi: mvm: split ADD_STA and ADD_STA_KEY in firmware API

Oren Givon (1):
      iwlwifi: mvm: debugfs: add an option to set antennas for scan command

 drivers/net/wireless/iwlwifi/iwl-fw.h             |  18 +
 drivers/net/wireless/iwlwifi/iwl-prph.h           |   2 +
 drivers/net/wireless/iwlwifi/mvm/bt-coex.c        | 598 ++++++++++++-----
 drivers/net/wireless/iwlwifi/mvm/constants.h      |   4 +-
 drivers/net/wireless/iwlwifi/mvm/d3.c             | 138 +++-
 drivers/net/wireless/iwlwifi/mvm/debugfs.c        | 197 ++++--
 drivers/net/wireless/iwlwifi/mvm/fw-api-bt-coex.h | 145 +++--
 drivers/net/wireless/iwlwifi/mvm/fw-api-d3.h      |  44 +-
 drivers/net/wireless/iwlwifi/mvm/fw-api-power.h   |  29 +-
 drivers/net/wireless/iwlwifi/mvm/fw-api-rs.h      |  21 +-
 drivers/net/wireless/iwlwifi/mvm/fw-api-scan.h    |  34 +-
 drivers/net/wireless/iwlwifi/mvm/fw-api-sta.h     |  55 +-
 drivers/net/wireless/iwlwifi/mvm/fw-api.h         |  16 +-
 drivers/net/wireless/iwlwifi/mvm/fw.c             |  23 +-
 drivers/net/wireless/iwlwifi/mvm/mac-ctxt.c       |  18 +-
 drivers/net/wireless/iwlwifi/mvm/mac80211.c       | 177 ++++-
 drivers/net/wireless/iwlwifi/mvm/mvm.h            |  67 +-
 drivers/net/wireless/iwlwifi/mvm/nvm.c            |  99 ++-
 drivers/net/wireless/iwlwifi/mvm/ops.c            |  60 +-
 drivers/net/wireless/iwlwifi/mvm/power.c          |  70 +-
 drivers/net/wireless/iwlwifi/mvm/quota.c          |  34 +
 drivers/net/wireless/iwlwifi/mvm/rs.c             | 758 ++++++++++++----------
 drivers/net/wireless/iwlwifi/mvm/rs.h             | 154 +++--
 drivers/net/wireless/iwlwifi/mvm/rx.c             |  21 +
 drivers/net/wireless/iwlwifi/mvm/scan.c           | 456 ++++++++++++-
 drivers/net/wireless/iwlwifi/mvm/sta.c            | 192 ++++--
 drivers/net/wireless/iwlwifi/mvm/sta.h            |   4 -
 drivers/net/wireless/iwlwifi/mvm/testmode.h       |  95 +++
 drivers/net/wireless/iwlwifi/mvm/time-event.c     |   5 +-
 drivers/net/wireless/iwlwifi/mvm/time-event.h     |   4 +-
 drivers/net/wireless/iwlwifi/mvm/tx.c             |  49 +-
 drivers/net/wireless/iwlwifi/mvm/utils.c          |   2 +-
 drivers/net/wireless/iwlwifi/pcie/drv.c           |   3 -
 drivers/net/wireless/iwlwifi/pcie/trans.c         |   3 +
 drivers/net/wireless/iwlwifi/pcie/tx.c            |   3 +
 35 files changed, 2716 insertions(+), 882 deletions(-)
 create mode 100644 drivers/net/wireless/iwlwifi/mvm/testmode.h


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

^ permalink raw reply

* Re: [PATCH] iwlwifi: pcie: fix merge damage
From: Johannes Berg @ 2013-10-07 11:47 UTC (permalink / raw)
  To: sedat.dilek; +Cc: John W. Linville, wireless
In-Reply-To: <CA+icZUVf1A2+-LPEARpOnRShm2BXagtHtw7+SidTs2b_ifV97A@mail.gmail.com>

On Thu, 2013-10-03 at 12:07 +0200, Sedat Dilek wrote:

> > I believe the merge damage only occurred during merging wireless.git (or
> > one of its upstreams) into wireless-next.git.
> >
> 
> Hmm, this patch applies also for Linux v3.12-rc3+, so you are sure it
> is not for iwlwifi-3.12-fixes?

Ahrg, yes, so it happened in wireless-next *before* wireless-next went
into 3.12-rc1.

John, any idea what to do now? Cherry-pick the patch over to
wireless.git?

johannes


^ permalink raw reply

* Re: [regression] [bisected] rt2800pci doesn't work after 9483f40d8d01918b399b4e24d0c1111db0afffeb
From: Kirill Tkhai @ 2013-10-07 12:04 UTC (permalink / raw)
  To: Stanislaw Gruszka
  Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
	ivdoorn@gmail.com, gwingerde@gmail.com,
	helmut.schaa@googlemail.com
In-Reply-To: <20131007082457.GB2418@redhat.com>

07.10.2013, 12:28, "Stanislaw Gruszka" <sgruszka@redhat.com>:

>  On Sat, Oct 05, 2013 at 07:29:08AM +0400, Kirill Tkhai wrote:
>>   GIt bisect says the first bad commit is 9483f40d8d01918b399b4e24d0c1111db0afffeb:
>>
>>           Author: Jakub Kicinski <kubakici@wp.pl>
>>           Date:   Tue May 7 00:28:50 2013 +0200
>>
>>               rt2x00pci: Use PCI MSIs whenever possible
>>
>>               All PCIe devices must support MSIs, make use of them.
>  I posted revert of that patch some time ago, it's on the way
>  upstream/stable ...
>

I bought this device one or two weeks ago, so I had not watched linux-wireless.git ;)
This fix was not in linux-next.git when I wrote the message.

If sometimes you need testing the driver on device with IDs like I wrote I'm ready
to help with this.

Kirill

^ permalink raw reply

* Re: [PATCH 1/2] ath10k: advestise 10.X fw support on wmi_attach
From: Kalle Valo @ 2013-10-07 12:26 UTC (permalink / raw)
  To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1380696532-4147-1-git-send-email-bartosz.markowski@tieto.com>

Bartosz Markowski <bartosz.markowski@tieto.com> writes:

> Since the WMI API has been added and we can detect from the
> FW IEs what firmware variant we deal with, turn on 10.X support.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>

Thanks, both patches applied. For patch 1 I changed the commit log a bit
as we don't really advertise anything to user space:

commit 8acd3c97ff9ea803513c55f89d3f1832481b5b76
Author: Bartosz Markowski <bartosz.markowski@tieto.com>
Date:   Wed Oct 2 08:48:51 2013 +0200

    ath10k: enable 10.x firmware branch support
    
    Since the WMI API has been added and we can detect from the
    FW IEs what firmware variant we deal with, turn on support
    for 10.x firmware branch in ath10k_wmi_attach().
    
    kvalo: improve the commit log
    
    Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
    Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>

-- 
Kalle Valo

^ permalink raw reply

* [PATCH] bluetooth: fix variable shadow warnings
From: Johannes Berg @ 2013-10-07 14:56 UTC (permalink / raw)
  To: linux-wireless, linux-bluetooth; +Cc: Johannes Berg

From: Johannes Berg <johannes.berg@intel.com>

Sparse points out three places where variables are shadowed,
rename two of the variables and remove the duplicate third.

Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
 net/bluetooth/hci_event.c  | 12 +++++++-----
 net/bluetooth/l2cap_sock.c |  2 +-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 94aab73..b5a3736 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1291,9 +1291,11 @@ static void hci_cs_remote_name_req(struct hci_dev *hdev, __u8 status)
 		goto unlock;
 
 	if (!test_and_set_bit(HCI_CONN_AUTH_PEND, &conn->flags)) {
-		struct hci_cp_auth_requested cp;
-		cp.handle = __cpu_to_le16(conn->handle);
-		hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+		struct hci_cp_auth_requested auth_req;
+
+		auth_req.handle = __cpu_to_le16(conn->handle);
+		hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
+			     sizeof(auth_req), &auth_req);
 	}
 
 unlock:
@@ -3636,8 +3638,8 @@ void hci_event_packet(struct hci_dev *hdev, struct sk_buff *skb)
 	skb_pull(skb, HCI_EVENT_HDR_SIZE);
 
 	if (hdev->sent_cmd && bt_cb(hdev->sent_cmd)->req.event == event) {
-		struct hci_command_hdr *hdr = (void *) hdev->sent_cmd->data;
-		u16 opcode = __le16_to_cpu(hdr->opcode);
+		struct hci_command_hdr *cmd_hdr = (void *) hdev->sent_cmd->data;
+		u16 opcode = __le16_to_cpu(cmd_hdr->opcode);
 
 		hci_req_cmd_complete(hdev, opcode, 0);
 	}
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index 0098af8..f07e25d 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -683,7 +683,7 @@ static int l2cap_sock_setsockopt(struct socket *sock, int level, int optname,
 		}
 
 		if (opt == BT_FLUSHABLE_OFF) {
-			struct l2cap_conn *conn = chan->conn;
+			conn = chan->conn;
 			/* proceed further only when we have l2cap_conn and
 			   No Flush support in the LM */
 			if (!conn || !lmp_no_flush_capable(conn->hcon->hdev)) {
-- 
1.8.4.rc3


^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox