* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-19 6:46 UTC (permalink / raw)
To: Guy, Wey-Yi
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1319003304.31823.46.camel@wwguy-huron>
On Di, 18 Okt 2011, Guy, Wey-Yi wrote:
> it is very interesting, for sure there is a bug here which cause NIC
> stop working, if you look at the tx queue, hwq 0 is stop, which mean
> nothing go out. I am not sure how we get into this? yes, most likely
Yes, that is my obervation, too. Nothing goes out, so reassociation
does not succeed.
> Could you help me how to repro this problem?
Not really, besides you come here to my university ;-)
I have this problem currently only with the routers here at
the university, not with other routers.
Any other way I can provide you help?
Best wishes
Norbert
------------------------------------------------------------------------
Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
------------------------------------------------------------------------
SKENFRITH (n.)
The flakes of athlete's foot found inside socks.
--- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Guy, Wey-Yi @ 2011-10-19 5:55 UTC (permalink / raw)
To: Pekka Enberg
Cc: David Rientjes, Norbert Preining, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <CAOJsxLFXBQXDtjGkuHV8fpxSy4U0dOdzBm6=4xfy2dMQo7NvOg@mail.gmail.com>
hi,
On Tue, 2011-10-18 at 23:11 -0700, Pekka Enberg wrote:
> On Wed, Oct 19, 2011 at 9:09 AM, David Rientjes <rientjes@google.com> wrote:
> > On Wed, 19 Oct 2011, Norbert Preining wrote:
> >
> >> Hi everyone
> >>
> >> (please Cc),
> >>
> >> I am currently running 3.1.0-rc10, and I am having a hard time with
> >> the wlan network here at the university.
> >>
> >> For quite some time, like 10min, it is fine, then suddently the
> >> iwlagn driver gives up on me and connection is dropped.
> >>
> >> In the log file I see:
> >> [ 172.137011] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 0
> >> [ 821.841016] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 6
> >> [ 1095.580735] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> >> [ 1095.780076] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> >> [ 1095.980101] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> >> [ 1096.180117] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> >> [ 1105.255464] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> >> [ 1105.255519] iwlagn 0000:06:00.0: Stopping AGG while state not ON or starting
> >> [ 1105.265581] cfg80211: Calling CRDA for country: JP
> >> [ 1105.271476] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 1)
> >> [ 1105.468105] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 2)
> >> [ 1105.668110] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3)
> >> [ 1105.868090] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out
> >> [ 1113.667890] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> >> [ 1113.864116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> >> [ 1114.064095] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> >> [ 1114.264109] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> >>
> >> Somewhere around 1100 the connection is gone and never comes back again.
> >>
> >> I tried removing the driver module from the kernel and reinserting it,
> >> tried to turn on and off the hardware swithc (rfkill), all without
> >> no success, the wlan connection remains dead until I reboot.
> >>
> >> I am not sure exactely when it started, I guess somewhere in the
> >> 3.1 cycle, before I was permanently working wiht wlan, now I always
> >> plug in the cable.
> >>
> >> If there is any way to track down this, or any suggestions how I can
> >> debug it, please let me know.
> >>
> >> Hardware: Sony VGN-Z11, Intel(R) WiFi Link 5100 AGN, REV=0x54
> >> L1 Enabled; Disabling L0S
> >> device EEPROM VER=0x11e, CALIB=0x4
> >> Device SKU: 0Xf0
> >> Tunable channels: 13 802.11bg, 24 802.11a channels
> >> loaded firmware version 8.83.5.1 build 33692 (EXP)
> >>
looks like you are using experimental version of uCode, but by saying
that, I don't think i will make much differences
so could you dump the tx queue to see if it is the similar problem what
Norbert point out
thanks
Wey
> >>
> >> On the other hand, the same laptop with the very same configuration
> >> works very nicely in my flat's wlan, which is some dirt cheap Japanese
> >> only wlan router.
> >>
> >
> > There have been recent issues in 3.1-rc9 reported with iwlagn, see the
> > thread at https://lkml.org/lkml/2011/10/15/107 even though you have
> > different hardware. Adding Wey-Yi Guy from Intel and the linux-wireless
> > mailing list to the cc.
>
> I'm seeing very similar problems with 3.1-rc9 when my laptop is
> connected to an iPhone WiFi hotspot. Works just fine at home where I
> use Airport Express.
>
> Pekka
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Guy, Wey-Yi @ 2011-10-19 5:48 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org
In-Reply-To: <20111019062517.GC11588@gamma.logic.tuwien.ac.at>
hi all,
On Tue, 2011-10-18 at 23:25 -0700, Norbert Preining wrote:
> Hi David, hi all
>
> On Di, 18 Okt 2011, David Rientjes wrote:
> > There have been recent issues in 3.1-rc9 reported with iwlagn, see the
> > thread at https://lkml.org/lkml/2011/10/15/107 even though you have
>
> Interesting. I read through the thread and activated the debugfs
> option.
>
> I could get my hardware back by
> echo 1 > /sys/kernel/debug/ieee80211/phy0/iwlagn/debug/force_reset
>
> [ 2761.352629] ieee80211 phy0: Hardware restart was requested
> [ 2761.352714] iwlagn 0000:06:00.0: L1 Enabled; Disabling L0S
> [ 2761.355763] iwlagn 0000:06:00.0: Radio type=0x1-0x2-0x0
> [ 2779.484308] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 2779.684128] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 2779.884087] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 2780.084079] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 2788.051381] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 2788.248079] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 2788.448083] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 2788.648140] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 2796.614710] wlan0: authenticate with 00:24:c4:ab:bd:ef (try 1)
> [ 2796.615623] wlan0: authenticated
> [ 2796.618046] wlan0: associate with 00:24:c4:ab:bd:ef (try 1)
> [ 2796.622748] wlan0: RX AssocResp from 00:24:c4:ab:bd:ef (capab=0x1 status=0 aid=1)
> [ 2796.622751] wlan0: associated
> [ 2871.224192] e1000e: eth0 NIC Link is Down
>
> I unplugged the cable and could ping the world still, nice....
>
> After a short time I got:
> [ 2895.575964] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 2895.772067] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 2895.972101] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 2896.172054] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 2905.316968] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> [ 2905.356316] cfg80211: Calling CRDA to update world regulatory domain
> [ 2905.361965] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 1)
> [ 2905.560063] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 2)
> [ 2905.760091] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3)
> [ 2905.960077] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out
> [ 2913.908984] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 2914.108116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 2914.308116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 2914.508103] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 2922.473062] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 2922.672109] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 2922.872106] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 2923.072103] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>
> And at this time the tx_queue showed me:
> -----------------------------------------------------------
> hwq 00: read=91 write=91 stop=1 swq_id=0x00 (ac 0/hwq 0)s.
> stop-count: 1
it is very interesting, for sure there is a bug here which cause NIC
stop working, if you look at the tx queue, hwq 0 is stop, which mean
nothing go out. I am not sure how we get into this? yes, most likely
force_reset will fix it by reload the firmware and reset all the queues
Could you help me how to repro this problem?
Thanks
Wey
> hwq 01: read=0 write=0 stop=0 swq_id=0x05 (ac 1/hwq 1)
> stop-count: 0
> hwq 02: read=127 write=127 stop=0 swq_id=0x0a (ac 2/hwq 2)
> stop-count: 0
> hwq 03: read=0 write=0 stop=0 swq_id=0x0f (ac 3/hwq 3)
> stop-count: 0
> hwq 04: read=13 write=13 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 05: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 06: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 07: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 08: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 09: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 10: read=0 write=0 stop=0 swq_id=0x2a (ac 2/hwq 10)
> hwq 11: read=0 write=0 stop=0 swq_id=0x2c (ac 0/hwq 11)
> hwq 12: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 13: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 14: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 15: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 16: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 17: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 18: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> hwq 19: read=0 write=0 stop=0 swq_id=0x00 (ac 0/hwq 0)
> -------------------------------------------------
>
> Hope that helps. Anyone let me know if you need more testing.
>
> Once more, be reminded the the firmware of the iwlagn is from
> an experimental build that should solve the AGN stopped working
> problem.
>
> Best wishes
>
> Norbert
> ------------------------------------------------------------------------
> Norbert Preining preining@{jaist.ac.jp, logic.at, debian.org}
> JAIST, Japan TeX Live & Debian Developer
> DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
> ------------------------------------------------------------------------
> SCRAMOGE (vb.)
> To cut oneself whilst licking envelopes.
> --- Douglas Adams, The Meaning of Liff
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Pekka Enberg @ 2011-10-19 6:11 UTC (permalink / raw)
To: David Rientjes
Cc: Norbert Preining, linux-kernel, ipw3945-devel, Wey-Yi Guy, ilw,
linux-wireless
In-Reply-To: <alpine.DEB.2.00.1110182305110.7719@chino.kir.corp.google.com>
On Wed, Oct 19, 2011 at 9:09 AM, David Rientjes <rientjes@google.com> wrote:
> On Wed, 19 Oct 2011, Norbert Preining wrote:
>
>> Hi everyone
>>
>> (please Cc),
>>
>> I am currently running 3.1.0-rc10, and I am having a hard time with
>> the wlan network here at the university.
>>
>> For quite some time, like 10min, it is fine, then suddently the
>> iwlagn driver gives up on me and connection is dropped.
>>
>> In the log file I see:
>> [ 172.137011] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 0
>> [ 821.841016] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 6
>> [ 1095.580735] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
>> [ 1095.780076] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
>> [ 1095.980101] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
>> [ 1096.180117] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>> [ 1105.255464] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
>> [ 1105.255519] iwlagn 0000:06:00.0: Stopping AGG while state not ON or starting
>> [ 1105.265581] cfg80211: Calling CRDA for country: JP
>> [ 1105.271476] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 1)
>> [ 1105.468105] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 2)
>> [ 1105.668110] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3)
>> [ 1105.868090] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out
>> [ 1113.667890] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
>> [ 1113.864116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
>> [ 1114.064095] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
>> [ 1114.264109] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>>
>> Somewhere around 1100 the connection is gone and never comes back again.
>>
>> I tried removing the driver module from the kernel and reinserting it,
>> tried to turn on and off the hardware swithc (rfkill), all without
>> no success, the wlan connection remains dead until I reboot.
>>
>> I am not sure exactely when it started, I guess somewhere in the
>> 3.1 cycle, before I was permanently working wiht wlan, now I always
>> plug in the cable.
>>
>> If there is any way to track down this, or any suggestions how I can
>> debug it, please let me know.
>>
>> Hardware: Sony VGN-Z11, Intel(R) WiFi Link 5100 AGN, REV=0x54
>> L1 Enabled; Disabling L0S
>> device EEPROM VER=0x11e, CALIB=0x4
>> Device SKU: 0Xf0
>> Tunable channels: 13 802.11bg, 24 802.11a channels
>> loaded firmware version 8.83.5.1 build 33692 (EXP)
>>
>>
>> On the other hand, the same laptop with the very same configuration
>> works very nicely in my flat's wlan, which is some dirt cheap Japanese
>> only wlan router.
>>
>
> There have been recent issues in 3.1-rc9 reported with iwlagn, see the
> thread at https://lkml.org/lkml/2011/10/15/107 even though you have
> different hardware. Adding Wey-Yi Guy from Intel and the linux-wireless
> mailing list to the cc.
I'm seeing very similar problems with 3.1-rc9 when my laptop is
connected to an iPhone WiFi hotspot. Works just fine at home where I
use Airport Express.
Pekka
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: David Rientjes @ 2011-10-19 6:09 UTC (permalink / raw)
To: Norbert Preining
Cc: linux-kernel, ipw3945-devel, Wey-Yi Guy, ilw, linux-wireless
In-Reply-To: <20111019060108.GA11588@gamma.logic.tuwien.ac.at>
On Wed, 19 Oct 2011, Norbert Preining wrote:
> Hi everyone
>
> (please Cc),
>
> I am currently running 3.1.0-rc10, and I am having a hard time with
> the wlan network here at the university.
>
> For quite some time, like 10min, it is fine, then suddently the
> iwlagn driver gives up on me and connection is dropped.
>
> In the log file I see:
> [ 172.137011] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 0
> [ 821.841016] iwlagn 0000:06:00.0: Tx aggregation enabled on ra = 00:24:c4:ab:bd:ef tid = 6
> [ 1095.580735] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 1095.780076] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 1095.980101] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 1096.180117] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
> [ 1105.255464] wlan0: deauthenticating from 00:24:c4:ab:bd:ef by local choice (reason=2)
> [ 1105.255519] iwlagn 0000:06:00.0: Stopping AGG while state not ON or starting
> [ 1105.265581] cfg80211: Calling CRDA for country: JP
> [ 1105.271476] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 1)
> [ 1105.468105] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 2)
> [ 1105.668110] wlan0: authenticate with 00:24:c4:ab:bd:e0 (try 3)
> [ 1105.868090] wlan0: authentication with 00:24:c4:ab:bd:e0 timed out
> [ 1113.667890] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 1/3)
> [ 1113.864116] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 2/3)
> [ 1114.064095] wlan0: direct probe to 00:24:c4:ab:bd:e0 (try 3/3)
> [ 1114.264109] wlan0: direct probe to 00:24:c4:ab:bd:e0 timed out
>
> Somewhere around 1100 the connection is gone and never comes back again.
>
> I tried removing the driver module from the kernel and reinserting it,
> tried to turn on and off the hardware swithc (rfkill), all without
> no success, the wlan connection remains dead until I reboot.
>
> I am not sure exactely when it started, I guess somewhere in the
> 3.1 cycle, before I was permanently working wiht wlan, now I always
> plug in the cable.
>
> If there is any way to track down this, or any suggestions how I can
> debug it, please let me know.
>
> Hardware: Sony VGN-Z11, Intel(R) WiFi Link 5100 AGN, REV=0x54
> L1 Enabled; Disabling L0S
> device EEPROM VER=0x11e, CALIB=0x4
> Device SKU: 0Xf0
> Tunable channels: 13 802.11bg, 24 802.11a channels
> loaded firmware version 8.83.5.1 build 33692 (EXP)
>
>
> On the other hand, the same laptop with the very same configuration
> works very nicely in my flat's wlan, which is some dirt cheap Japanese
> only wlan router.
>
There have been recent issues in 3.1-rc9 reported with iwlagn, see the
thread at https://lkml.org/lkml/2011/10/15/107 even though you have
different hardware. Adding Wey-Yi Guy from Intel and the linux-wireless
mailing list to the cc.
^ permalink raw reply
* [PATCH] mwifiex: enable SDIO multiport aggregation
From: Bing Zhao @ 2011-10-19 1:22 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Amitkumar Karwar, Kiran Divekar, Yogesh Powar,
Frank Huang, Bing Zhao
From: Amitkumar Karwar <akarwar@marvell.com>
By default SDIO multiport aggregation is disabled. It's useful to
get good throughput results. This patch enables it.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/sdio.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/sdio.c b/drivers/net/wireless/mwifiex/sdio.c
index 283171b..ffaf3f3 100644
--- a/drivers/net/wireless/mwifiex/sdio.c
+++ b/drivers/net/wireless/mwifiex/sdio.c
@@ -1630,14 +1630,14 @@ static int mwifiex_init_sdio(struct mwifiex_adapter *adapter)
card->mpa_tx.pkt_cnt = 0;
card->mpa_tx.start_port = 0;
- card->mpa_tx.enabled = 0;
+ card->mpa_tx.enabled = 1;
card->mpa_tx.pkt_aggr_limit = SDIO_MP_AGGR_DEF_PKT_LIMIT;
card->mpa_rx.buf_len = 0;
card->mpa_rx.pkt_cnt = 0;
card->mpa_rx.start_port = 0;
- card->mpa_rx.enabled = 0;
+ card->mpa_rx.enabled = 1;
card->mpa_rx.pkt_aggr_limit = SDIO_MP_AGGR_DEF_PKT_LIMIT;
/* Allocate buffers for SDIO MP-A */
--
1.7.0.2
^ permalink raw reply related
* [PATCH] ath6kl: Implement support for listen interval from userspace
From: Rishi Panjwani @ 2011-10-19 0:36 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
The patch allows modification of listen interval thereby allowing change
in sleep/awake cycle causing change in power consumption numbers.
Rishi Panjwani (1):
ath6kl: Implement support for listen interval from userspace
drivers/net/wireless/ath/ath6kl/debug.c | 50 +++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH] ath6kl: Implement support for listen interval from userspace
From: Rishi Panjwani @ 2011-10-19 0:36 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
In-Reply-To: <1318984591-10037-1-git-send-email-rpanjwan@qca.qualcomm.com>
In order to allow user space based control of listen interval, we use
available debugfs infrastructure. Listen interval implies how frequently
we want the WLAN chip to wake up and synchronize the beacons in case it
is in sleep mode. The user has to write the listen interval (in msecs) to
the listen_interval file in ath6kl debug directory. The minimum value is
15 and maximum is 5000.
Example:
echo "30" > listen_interval
This will make the listen interval approximately 30 msecs.
Signed-off-by: Rishi Panjwani <rpanjwan@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 50 +++++++++++++++++++++++++++++++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index 3eaa291..41f36d2 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -1488,6 +1488,53 @@ static const struct file_operations fops_bgscan_int = {
.owner = THIS_MODULE,
.llseek = default_llseek,
};
+static ssize_t ath6kl_listen_int_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ u16 listen_int;
+ char buf[32];
+ ssize_t len;
+
+ len = min(count, sizeof(buf) - 1);
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+
+ buf[len] = '\0';
+ if (kstrtou16(buf, 0, &listen_int))
+ return -EINVAL;
+
+ if ((listen_int >= 15) && (listen_int <= 5000)) {
+ ar->listen_intvl_t = listen_int;
+ ath6kl_wmi_listeninterval_cmd(ar->wmi, ar->listen_intvl_t, 0);
+ } else {
+ return -EINVAL;
+ }
+
+ return count;
+}
+
+static ssize_t ath6kl_listen_int_read(struct file *file,
+ char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ char buf[16];
+ int len;
+
+ len = snprintf(buf, sizeof(buf), "%u\n", ar->listen_intvl_t);
+
+ return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static const struct file_operations fops_listen_int = {
+ .read = ath6kl_listen_int_read,
+ .write = ath6kl_listen_int_write,
+ .open = ath6kl_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
int ath6kl_debug_init(struct ath6kl *ar)
{
@@ -1571,6 +1618,9 @@ int ath6kl_debug_init(struct ath6kl *ar)
debugfs_create_file("bgscan_interval", S_IWUSR,
ar->debugfs_phy, ar, &fops_bgscan_int);
+ debugfs_create_file("listen_interval", S_IWUSR, ar->debugfs_phy, ar,
+ &fops_listen_int);
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] ath6kl: Implement support for background scan control from userspace
From: Rishi Panjwani @ 2011-10-19 0:20 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
The feature allows controlling background scan intervals
Rishi Panjwani (1):
ath6kl: Implement support for listen interval from userspace
drivers/net/wireless/ath/ath6kl/debug.c | 34 +++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
^ permalink raw reply
* [PATCH v2] ath6kl: Implement support for background scan control from userspace
From: Rishi Panjwani @ 2011-10-19 0:20 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, Rishi Panjwani
In-Reply-To: <1318983606-8959-1-git-send-email-rpanjwan@qca.qualcomm.com>
In order to allow user space based control of background scan interval,
we use available debugfs infrastructure. The feature has been added for
testing purposes. The user has to write the bgscan interval (in secs) to
the bgscan_interval file in ath6kl debug directory. To disable bgscan,
a '0' is to be written to the bgscan_interval file.
Example:
echo "2" > bgscan_interval
This will make the background scan interval as 2 seconds
Signed-off-by: Rishi Panjwani <rpanjwan@qca.qualcomm.com>
---
drivers/net/wireless/ath/ath6kl/debug.c | 37 +++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/debug.c b/drivers/net/wireless/ath/ath6kl/debug.c
index e109f29..3eaa291 100644
--- a/drivers/net/wireless/ath/ath6kl/debug.c
+++ b/drivers/net/wireless/ath/ath6kl/debug.c
@@ -1455,6 +1455,40 @@ static const struct file_operations fops_delete_qos = {
.llseek = default_llseek,
};
+static ssize_t ath6kl_bgscan_int_write(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+ struct ath6kl *ar = file->private_data;
+ u16 bgscan_int;
+ char buf[32];
+ ssize_t len;
+
+ len = min(count, sizeof(buf) - 1);
+ if (copy_from_user(buf, user_buf, len))
+ return -EFAULT;
+
+ buf[len] = '\0';
+ if (kstrtou16(buf, 0, &bgscan_int))
+ return -EINVAL;
+
+ if (bgscan_int)
+ ath6kl_wmi_scanparams_cmd(ar->wmi, 0, 0, bgscan_int, 0, 0, 0, 3,
+ 0, 0, 0);
+ else
+ ath6kl_wmi_scanparams_cmd(ar->wmi, 0, 0, 0xffff, 0, 0, 0, 3, 0,
+ 0, 0);
+
+ return count;
+}
+
+static const struct file_operations fops_bgscan_int = {
+ .write = ath6kl_bgscan_int_write,
+ .open = ath6kl_debugfs_open,
+ .owner = THIS_MODULE,
+ .llseek = default_llseek,
+};
+
int ath6kl_debug_init(struct ath6kl *ar)
{
ar->debug.fwlog_buf.buf = vmalloc(ATH6KL_FWLOG_SIZE);
@@ -1534,6 +1568,9 @@ int ath6kl_debug_init(struct ath6kl *ar)
debugfs_create_file("delete_qos", S_IWUSR, ar->debugfs_phy, ar,
&fops_delete_qos);
+ debugfs_create_file("bgscan_interval", S_IWUSR,
+ ar->debugfs_phy, ar, &fops_bgscan_int);
+
return 0;
}
--
1.7.0.4
^ permalink raw reply related
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-18 23:01 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111018T233233-298@post.gmane.org>
On 10/18/2011 04:50 PM, v4mp wrote:
>
>
> yes, i know that the awus036h uses a different driver,
> i just wanna say that it
> has no conflicts with xhci_hcd as happen when loading
> the rtl8192cu driver for the 036nhr
>
> the driver i downloaded from realtek is what you can find here
> http://www.alfa.com.tw /in/front/bin/ ptlist.phtml?Category=105397
> for the awus036nhr, and it works fine without any kind of errors,
> detection of APs and connections
>
> every compat wireless i download does not with rtl8192cu and my alfa,
> i tested all the specific kernel version of compat-wireless and the latest
> bleeding edge compat wireless, i'm hating this fuckin errors :)
And I get really pissed off at people that have bleeding-edge hardware and get
mad because a driver doesn't work. Do you want to debug this issue by yourself?
If not, then you had better control your temper and your language. I am just a
volunteer. From what I see on my computer, the device, which I bought with my
own money, works fine. Thus - no problem.
Larry
^ permalink raw reply
* [PATCH] rtl8192cu: Add new device IDs
From: Larry Finger @ 2011-10-18 22:52 UTC (permalink / raw)
To: John W Linville; +Cc: linux-wireless
The latest vendor (non-mac80211) driver of 9/22/2011 shows some new
device IDs for rtl8192cu. In addition, some typos in the table are
fixed and one duplicate is removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
---
Index: wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
===================================================================
--- wireless-testing-new.orig/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
+++ wireless-testing-new/drivers/net/wireless/rtlwifi/rtl8192cu/sw.c
@@ -274,6 +274,8 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8191, rtl92cu_hal_cfg)},
/****** 8188CU ********/
+ /* RTL8188CTV */
+ {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x018a, rtl92cu_hal_cfg)},
/* 8188CE-VAU USB minCard */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8170, rtl92cu_hal_cfg)},
/* 8188cu 1*1 dongle */
@@ -290,14 +292,14 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817e, rtl92cu_hal_cfg)},
/* 8188RU in Alfa AWUS036NHR */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817f, rtl92cu_hal_cfg)},
+ /* RTL8188CUS-VL */
+ {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x818a, rtl92cu_hal_cfg)},
/* 8188 Combo for BC4 */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8754, rtl92cu_hal_cfg)},
/****** 8192CU ********/
- /* 8191cu 1*2 */
- {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8177, rtl92cu_hal_cfg)},
/* 8192cu 2*2 */
- {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817b, rtl92cu_hal_cfg)},
+ {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8178, rtl92cu_hal_cfg)},
/* 8192CE-VAU USB minCard */
{RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x817c, rtl92cu_hal_cfg)},
@@ -308,13 +310,17 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(0x07b8, 0x8188, rtl92cu_hal_cfg)}, /*Abocom - Abocom*/
{RTL_USB_DEVICE(0x07b8, 0x8189, rtl92cu_hal_cfg)}, /*Funai - Abocom*/
{RTL_USB_DEVICE(0x0846, 0x9041, rtl92cu_hal_cfg)}, /*NetGear WNA1000M*/
- {RTL_USB_DEVICE(0x0Df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
+ {RTL_USB_DEVICE(0x0df6, 0x0052, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
+ {RTL_USB_DEVICE(0x0df6, 0x005c, rtl92cu_hal_cfg)}, /*Sitecom - Edimax*/
{RTL_USB_DEVICE(0x0eb0, 0x9071, rtl92cu_hal_cfg)}, /*NO Brand - Etop*/
/* HP - Lite-On ,8188CUS Slim Combo */
{RTL_USB_DEVICE(0x103c, 0x1629, rtl92cu_hal_cfg)},
{RTL_USB_DEVICE(0x13d3, 0x3357, rtl92cu_hal_cfg)}, /* AzureWave */
{RTL_USB_DEVICE(0x2001, 0x3308, rtl92cu_hal_cfg)}, /*D-Link - Alpha*/
+ {RTL_USB_DEVICE(0x2019, 0x4902, rtl92cu_hal_cfg)}, /*Planex - Etop*/
{RTL_USB_DEVICE(0x2019, 0xab2a, rtl92cu_hal_cfg)}, /*Planex - Abocom*/
+ /*SW-WF02-AD15 -Abocom*/
+ {RTL_USB_DEVICE(0x2019, 0xab2e, rtl92cu_hal_cfg)},
{RTL_USB_DEVICE(0x2019, 0xed17, rtl92cu_hal_cfg)}, /*PCI - Edimax*/
{RTL_USB_DEVICE(0x20f4, 0x648b, rtl92cu_hal_cfg)}, /*TRENDnet - Cameo*/
{RTL_USB_DEVICE(0x7392, 0x7811, rtl92cu_hal_cfg)}, /*Edimax - Edimax*/
@@ -325,14 +331,36 @@ static struct usb_device_id rtl8192c_usb
{RTL_USB_DEVICE(0x4855, 0x0091, rtl92cu_hal_cfg)}, /* NetweeN-Feixun */
{RTL_USB_DEVICE(0x9846, 0x9041, rtl92cu_hal_cfg)}, /* Netgear Cameo */
+ /****** 8188 RU ********/
+ /* Netcore */
+ {RTL_USB_DEVICE(USB_VENDER_ID_REALTEK, 0x317f, rtl92cu_hal_cfg)},
+
+ /****** 8188CUS Slim Solo********/
+ {RTL_USB_DEVICE(0x04f2, 0xaff7, rtl92cu_hal_cfg)}, /*Xavi*/
+ {RTL_USB_DEVICE(0x04f2, 0xaff9, rtl92cu_hal_cfg)}, /*Xavi*/
+ {RTL_USB_DEVICE(0x04f2, 0xaffa, rtl92cu_hal_cfg)}, /*Xavi*/
+
+ /****** 8188CUS Slim Combo ********/
+ {RTL_USB_DEVICE(0x04f2, 0xaff8, rtl92cu_hal_cfg)}, /*Xavi*/
+ {RTL_USB_DEVICE(0x04f2, 0xaffb, rtl92cu_hal_cfg)}, /*Xavi*/
+ {RTL_USB_DEVICE(0x04f2, 0xaffc, rtl92cu_hal_cfg)}, /*Xavi*/
+ {RTL_USB_DEVICE(0x2019, 0x1201, rtl92cu_hal_cfg)}, /*Planex-Vencer*/
+
/****** 8192CU ********/
+ {RTL_USB_DEVICE(0x050d, 0x2102, rtl92cu_hal_cfg)}, /*Belcom-Sercomm*/
+ {RTL_USB_DEVICE(0x050d, 0x2103, rtl92cu_hal_cfg)}, /*Belcom-Edimax*/
{RTL_USB_DEVICE(0x0586, 0x341f, rtl92cu_hal_cfg)}, /*Zyxel -Abocom*/
{RTL_USB_DEVICE(0x07aa, 0x0056, rtl92cu_hal_cfg)}, /*ATKK-Gemtek*/
{RTL_USB_DEVICE(0x07b8, 0x8178, rtl92cu_hal_cfg)}, /*Funai -Abocom*/
+ {RTL_USB_DEVICE(0x0846, 0x9021, rtl92cu_hal_cfg)}, /*Netgear-Sercomm*/
+ {RTL_USB_DEVICE(0x0b05, 0x17ab, rtl92cu_hal_cfg)}, /*ASUS-Edimax*/
+ {RTL_USB_DEVICE(0x0df6, 0x0061, rtl92cu_hal_cfg)}, /*Sitecom-Edimax*/
+ {RTL_USB_DEVICE(0x0e66, 0x0019, rtl92cu_hal_cfg)}, /*Hawking-Edimax*/
{RTL_USB_DEVICE(0x2001, 0x3307, rtl92cu_hal_cfg)}, /*D-Link-Cameo*/
{RTL_USB_DEVICE(0x2001, 0x3309, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2001, 0x330a, rtl92cu_hal_cfg)}, /*D-Link-Alpha*/
{RTL_USB_DEVICE(0x2019, 0xab2b, rtl92cu_hal_cfg)}, /*Planex -Abocom*/
+ {RTL_USB_DEVICE(0x20f4, 0x624d, rtl92cu_hal_cfg)}, /*TRENDNet*/
{RTL_USB_DEVICE(0x7392, 0x7822, rtl92cu_hal_cfg)}, /*Edimax -Edimax*/
{}
};
^ permalink raw reply
* lockdep in mac80211
From: Arik Nemtsov @ 2011-10-18 22:12 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
http://pastebin.com/qX3SLy2H
This appears to be a legitimate lockdep (when trying to re-connect to
an AP whose password I just changed).
These take the locks in reverse order:
ieee80211_work_work() -> ieee80211_authenticate() (Inlined in the
lockdep print).
ieee80211_sta_rx_queued_mgmt() -> ieee80211_rx_mgmt_disassoc()
I don't know the state machine well enough and it's getting kind of
late here. I'll probably have time to take a closer look in a couple
of days (unless Johannes finds this one trivial).
Arik
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-18 21:50 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4E9D9953.3020601@lwfinger.net>
yes, i know that the awus036h uses a different driver,
i just wanna say that it
has no conflicts with xhci_hcd as happen when loading
the rtl8192cu driver for the 036nhr
the driver i downloaded from realtek is what you can find here
http://www.alfa.com.tw /in/front/bin/ ptlist.phtml?Category=105397
for the awus036nhr, and it works fine without any kind of errors,
detection of APs and connections
every compat wireless i download does not with rtl8192cu and my alfa,
i tested all the specific kernel version of compat-wireless and the latest
bleeding edge compat wireless, i'm hating this fuckin errors :)
^ permalink raw reply
* Re: [patch] ath9k_hw: min_t() casts u32 to int
From: Pavel Roskin @ 2011-10-18 20:19 UTC (permalink / raw)
To: Dan Carpenter
Cc: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
Senthil Balasubramanian, John W. Linville, linux-wireless,
ath9k-devel, kernel-janitors
In-Reply-To: <20111017072823.GA7812@elgon.mountain>
On Mon, 17 Oct 2011 10:28:23 +0300
Dan Carpenter <dan.carpenter@oracle.com> wrote:
> The code here treats very large values of "limit" as less than
> MAX_POWER_RATE because of the cast to int. We should do the compare
> as u32 instead.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Pavel Roskin <proski@gnu.org>
I don't think it can actually happen. ath9k_hw_set_txpowerlimit() is
called twice. In one case, limit is MAX_RATE_POWER, in another case,
it's an argument of type u16. Still, it's better not to have the code
that looks wrong.
ath9k_cmn_update_txpow() also has code that _looks_ wrong. *txpower is
not assigned a value if the new power happens to be equal to the
current one. Also, the second argument (cur_txpow) is not used.
Returning a value by a pointer seems unnecessary if the function returns
void. It could simply return the new tx power. I'll submit a patch
shortly.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: rt3090 rt2800
From: Larry Finger @ 2011-10-18 19:55 UTC (permalink / raw)
To: Daniel; +Cc: wireless
In-Reply-To: <CAMuSxx78MUAm8aM8ptKynbqNk=EkhDGdk_PUEma7G-U0Wqs0hQ@mail.gmail.com>
On 10/18/2011 02:39 PM, Daniel wrote:
> Hi.
>
> This
> commit (http://git.kernel.org/?p=linux/kernel/git/next/linux-next-history.git;a=commit;h=fefecc6989b4b24276797270c0e229c07be02ad3)
> you removed the driver rt2860stathat worked with my RT3090 wireless card, the
> current driver rt2800pci does not work with WPA. Will you have some way to help
> me in this direction?
First of all, this question needs to be placed on the wireless mailing list,
which I have added to this reply.
Although I do not have a card that uses rt2800pci, I am quite certain that it
works with WPA. Driver rt2800usb, which contains much of the same code,
certainly does. Try unloading the module and reloading with 'modprobe rt2800pci
nohwcrypt=1".
We also need a bit more information about your system. What distro? What kernel?
Do you use NetworkManager? Is the firmware available? What do the logs say? You
should check the output of dmesg, the system log, and the NM log (if you use it).
Larry
^ permalink raw reply
* [RFC] mac80211: Support forcing station to disable 11n.
From: greearb @ 2011-10-18 19:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
This allows a user to configure a wifi station interface
to disable 802.11n, even if the AP and NIC supports it.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
Is this of any interest? If so, I can post a patch against the
wireless-testing kernel and the matching hostap patch.
NOTE: The additional netlink bits is to allow this patch to work on 3.0
with the latest hostap and should not be included in the final patch.
:100644 100644 c7ccaae... ef65049... M include/linux/nl80211.h
:100644 100644 069b048... df3d71c... M include/net/cfg80211.h
:100644 100644 a8f25cc... 8a3e6f9... M net/mac80211/cfg.c
:100644 100644 090b0ec... b42dfb4... M net/mac80211/ieee80211_i.h
:100644 100644 d5ebae7... a12cf4d... M net/mac80211/mlme.c
:100644 100644 b3650af... 9fe4a28... M net/wireless/nl80211.c
include/linux/nl80211.h | 34 ++++++++++++++++++++++++++++++++++
include/net/cfg80211.h | 4 +++-
net/mac80211/cfg.c | 3 +++
net/mac80211/ieee80211_i.h | 2 ++
net/mac80211/mlme.c | 3 +++
net/wireless/nl80211.c | 8 ++++++++
6 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/include/linux/nl80211.h b/include/linux/nl80211.h
index c7ccaae..ef65049 100644
--- a/include/linux/nl80211.h
+++ b/include/linux/nl80211.h
@@ -996,6 +996,9 @@ enum nl80211_commands {
* are managed in software: interfaces of these types aren't subject to
* any restrictions in their number or combinations.
*
+ * @NL80211_ATTR_DISABLE_80211N: Force /n capable stations to instead
+ * function as /a/b/g stations.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1193,6 +1196,37 @@ enum nl80211_attrs {
NL80211_ATTR_INTERFACE_COMBINATIONS,
NL80211_ATTR_SOFTWARE_IFTYPES,
+ NL80211_ATTR_REKEY_DATA,
+
+ NL80211_ATTR_MAX_NUM_SCHED_SCAN_SSIDS,
+ NL80211_ATTR_MAX_SCHED_SCAN_IE_LEN,
+
+ NL80211_ATTR_SCAN_SUPP_RATES,
+
+ NL80211_ATTR_HIDDEN_SSID,
+
+ NL80211_ATTR_IE_PROBE_RESP,
+ NL80211_ATTR_IE_ASSOC_RESP,
+
+ NL80211_ATTR_STA_WME,
+ NL80211_ATTR_SUPPORT_AP_UAPSD,
+
+ NL80211_ATTR_ROAM_SUPPORT,
+
+ NL80211_ATTR_SCHED_SCAN_MATCH,
+ NL80211_ATTR_MAX_MATCH_SETS,
+
+ NL80211_ATTR_PMKSA_CANDIDATE,
+
+ NL80211_ATTR_TX_NO_CCK_RATE,
+
+ NL80211_ATTR_TDLS_ACTION,
+ NL80211_ATTR_TDLS_DIALOG_TOKEN,
+ NL80211_ATTR_TDLS_OPERATION,
+ NL80211_ATTR_TDLS_SUPPORT,
+ NL80211_ATTR_TDLS_EXTERNAL_SETUP,
+
+ NL80211_ATTR_DISABLE_11N,
/* add attributes here, update the policy in nl80211.c */
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 069b048..df3d71c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -259,9 +259,11 @@ struct ieee80211_supported_band {
/**
* struct vif_params - describes virtual interface parameters
* @use_4addr: use 4-address frames
+ * @disable_11n: Don't use 11n features (HT, etc)
*/
struct vif_params {
- int use_4addr;
+ int use_4addr;
+ int disable_11n;
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a8f25cc..8a3e6f9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -56,6 +56,9 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
int ret;
+ if (params->disable_11n != -1)
+ sdata->cfg_disable_11n = params->disable_11n;
+
ret = ieee80211_if_change_type(sdata, type);
if (ret)
return ret;
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 090b0ec..b42dfb4 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -564,6 +564,8 @@ struct ieee80211_sub_if_data {
/* to detect idle changes */
bool old_idle;
+ bool cfg_disable_11n; /* configured to disable 11n? */
+
/* Fragment table for host-based reassembly */
struct ieee80211_fragment_entry fragments[IEEE80211_FRAGMENT_MAX];
unsigned int fragment_next;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index d5ebae7..a12cf4d 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2450,6 +2450,9 @@ int ieee80211_mgd_assoc(struct ieee80211_sub_if_data *sdata,
ifmgd->flags |= IEEE80211_STA_DISABLE_11N;
+ if (sdata->cfg_disable_11n)
+ ifmgd->flags |= IEEE80211_STA_DISABLE_11N;
+
if (req->ie && req->ie_len) {
memcpy(wk->ie, req->ie, req->ie_len);
wk->ie_len = req->ie_len;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index b3650af..9fe4a28 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -1569,6 +1569,14 @@ static int nl80211_set_interface(struct sk_buff *skb, struct genl_info *info)
change = true;
}
+ if (info->attrs[NL80211_ATTR_DISABLE_11N]) {
+ params.disable_11n = !!nla_get_u8(info->attrs[NL80211_ATTR_DISABLE_11N]);
+ change = true;
+ }
+ else {
+ params.disable_11n = -1;
+ }
+
if (change)
err = cfg80211_change_iface(rdev, dev, ntype, flags, ¶ms);
else
--
1.7.3.4
^ permalink raw reply related
* Compat-wireless release for 2011-10-18 is baked
From: Compat-wireless cronjob account @ 2011-10-18 19:02 UTC (permalink / raw)
To: linux-wireless
>From git://github.com/mcgrof/compat-wireless
49eb82e..ee66508 master -> origin/master
* [new tag] compat-wireless-2011-10-14 -> compat-wireless-2011-10-14
compat-wireless code metrics
814119 - Total upstream lines of code being pulled
2431 - backport code changes
2113 - backport code additions
318 - backport code deletions
8588 - backport from compat module
11019 - total backport code
1.3535 - % of code consists of backport work
^ permalink raw reply
* Re: 3.1.0-rc9+ : wlan stops working w/o any error messages
From: Guy, Wey-Yi @ 2011-10-18 17:51 UTC (permalink / raw)
To: Toralf Förster
Cc: werner, David Rientjes, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <201110181957.49894.toralf.foerster@gmx.de>
On Tue, 2011-10-18 at 10:57 -0700, Toralf Förster wrote:
> wwguy wrote at 19:13:33
> > hmm, something broken there, it should be in the .config file, what tree
> > you are using?
> >
> tfoerste@n22 ~/devel/linux $ git describe
> v3.1-rc10
> tfoerste@n22 ~/devel/linux $ grep -B2 url .git/config
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> --
> merge = refs/heads/master
> [remote "remote_stable"]
> url = git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-
> stable.git
>
>
>
you did not enable MAC80211_DEBUGFS
Wey
^ permalink raw reply
* [PATCH V2] Set IEEE80211_TX_RC_MCS on MCS rates on TX complete.
From: Pontus Fuchs @ 2011-10-18 18:38 UTC (permalink / raw)
To: linux-wireless; +Cc: coelho
IEEE80211_TX_RC_MCS was not set correctly leading to incorrect link
speed calculation.
Reviewed-by: Luciano Coelho <coelho@ti.com>
Signed-off-by: Pontus Fuchs <pontus.fuchs@gmail.com>
---
Version 2: Added missing sign-off.
drivers/net/wireless/wl12xx/conf.h | 4 ++++
drivers/net/wireless/wl12xx/tx.c | 12 +++++++++++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/conf.h b/drivers/net/wireless/wl12xx/conf.h
index 04bb8fb..b3f9592 100644
--- a/drivers/net/wireless/wl12xx/conf.h
+++ b/drivers/net/wireless/wl12xx/conf.h
@@ -91,6 +91,10 @@ enum {
CONF_HW_RXTX_RATE_UNSUPPORTED = 0xff
};
+/* Rates between and including these are MCS rates */
+#define CONF_HW_RXTX_RATE_MCS_MIN CONF_HW_RXTX_RATE_MCS7
+#define CONF_HW_RXTX_RATE_MCS_MAX CONF_HW_RXTX_RATE_MCS0
+
enum {
CONF_SG_DISABLE = 0,
CONF_SG_PROTECTIVE,
diff --git a/drivers/net/wireless/wl12xx/tx.c b/drivers/net/wireless/wl12xx/tx.c
index c7ad4f5..40c5669 100644
--- a/drivers/net/wireless/wl12xx/tx.c
+++ b/drivers/net/wireless/wl12xx/tx.c
@@ -798,6 +798,14 @@ out:
mutex_unlock(&wl->mutex);
}
+static u8 wl1271_tx_get_rate_flags(u8 rate_class_index)
+{
+ if (rate_class_index >= CONF_HW_RXTX_RATE_MCS_MIN &&
+ rate_class_index <= CONF_HW_RXTX_RATE_MCS_MAX)
+ return IEEE80211_TX_RC_MCS;
+ return 0;
+}
+
static void wl1271_tx_complete_packet(struct wl1271 *wl,
struct wl1271_tx_hw_res_descr *result)
{
@@ -807,6 +815,7 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,
struct sk_buff *skb;
int id = result->id;
int rate = -1;
+ u8 rate_flags = 0;
u8 retries = 0;
/* check for id legality */
@@ -833,6 +842,7 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,
info->flags |= IEEE80211_TX_STAT_ACK;
rate = wl1271_rate_to_idx(result->rate_class_index,
wlvif->band);
+ rate_flags = wl1271_tx_get_rate_flags(result->rate_class_index);
retries = result->ack_failures;
} else if (result->status == TX_RETRY_EXCEEDED) {
wl->stats.excessive_retries++;
@@ -841,7 +851,7 @@ static void wl1271_tx_complete_packet(struct wl1271 *wl,
info->status.rates[0].idx = rate;
info->status.rates[0].count = retries;
- info->status.rates[0].flags = 0;
+ info->status.rates[0].flags = rate_flags;
info->status.ack_signal = -1;
wl->stats.retry_count += result->ack_failures;
--
1.7.4.1
^ permalink raw reply related
* RE: [patch 3/4] mwifiex: prevent corruption instead of just warning
From: Bing Zhao @ 2011-10-18 18:27 UTC (permalink / raw)
To: Johannes Berg
Cc: Dan Carpenter, John W. Linville, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org, Amitkumar Karwar, Kiran Divekar
In-Reply-To: <1318962180.3958.30.camel@jlt3.sipsolutions.net>
SGkgSm9oYW5uZXMsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50Lg0KDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvaGFubmVzIEJlcmcgW21haWx0bzpqb2hhbm5lc0Bz
aXBzb2x1dGlvbnMubmV0XQ0KPiBTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDE4LCAyMDExIDExOjIz
IEFNDQo+IFRvOiBCaW5nIFpoYW8NCj4gQ2M6IERhbiBDYXJwZW50ZXI7IEpvaG4gVy4gTGludmls
bGU7IGxpbnV4LXdpcmVsZXNzQHZnZXIua2VybmVsLm9yZzsga2VybmVsLWphbml0b3JzQHZnZXIu
a2VybmVsLm9yZw0KPiBTdWJqZWN0OiBSRTogW3BhdGNoIDMvNF0gbXdpZmlleDogcHJldmVudCBj
b3JydXB0aW9uIGluc3RlYWQgb2YganVzdCB3YXJuaW5nDQo+IA0KPiBPbiBUdWUsIDIwMTEtMTAt
MTggYXQgMTE6MTkgLTA3MDAsIEJpbmcgWmhhbyB3cm90ZToNCj4gDQo+ID4gPiBAQCAtMTIyOCw5
ICsxMjI4LDExIEBAIHN0YXRpYyBpbnQgbXdpZmlleF9wY2llX2V2ZW50X2NvbXBsZXRlKHN0cnVj
dCBtd2lmaWV4X2FkYXB0ZXIgKmFkYXB0ZXIsDQo+ID4gPiAgCWlmICghc2tiKQ0KPiA+ID4gIAkJ
cmV0dXJuIDA7DQo+ID4gPg0KPiA+ID4gLQlpZiAocmRwdHIgPj0gTVdJRklFWF9NQVhfRVZUX0JE
KQ0KPiA+ID4gKwlpZiAocmRwdHIgPj0gTVdJRklFWF9NQVhfRVZUX0JEKSB7DQo+ID4gPiAgCQlk
ZXZfZXJyKGFkYXB0ZXItPmRldiwgImV2ZW50X2NvbXBsZXRlOiBJbnZhbGlkIHJkcHRyIDB4JXhc
biIsDQo+ID4gPiAgCQkJCQlyZHB0cik7DQo+ID4gPiArCQlyZXR1cm4gLUVJTlZBTDsNCj4gPg0K
PiA+IEluc3RlYWQgb2YgcmV0dXJuaW5nIGRpcmVjdGx5LCB3ZSBzaG91bGQgc2V0IHRoZSBlcnJv
ciBjb2RlIGFuZCBnbyB0aHJvdWdoIHRoZSBlcnJvciBoYW5kbGluZzoNCj4gPiAJCXJldCA9IC1F
SU5WQUw7DQo+ID4gCQlnb3RvIGRvbmU7DQo+IA0KPiBBcmUgeW91IHN1cmU/IFlvdSBkb24ndCBn
byB0byBlcnJvciBoYW5kbGluZyBhIGZldyBsaW5lcyBlYXJsaWVyLg0KDQpUaGUgZXJyb3IgaGFu
ZGxpbmcgd2lsbCBmcmVlIHRoZSBza2IuIElmIHNrYiBpcyBOVUxMIHRoZXJlIGlzIG5vIG5lZWQg
dG8gZnJlZS4NCg0KVGhhbmtzLA0KQmluZw0KDQo+IA0KPiBqb2hhbm5lcw0KDQo=
^ permalink raw reply
* RE: [patch 3/4] mwifiex: prevent corruption instead of just warning
From: Johannes Berg @ 2011-10-18 18:23 UTC (permalink / raw)
To: Bing Zhao
Cc: Dan Carpenter, John W. Linville, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <477F20668A386D41ADCC57781B1F70430817F59764@SC-VEXCH1.marvell.com>
On Tue, 2011-10-18 at 11:19 -0700, Bing Zhao wrote:
> > @@ -1228,9 +1228,11 @@ static int mwifiex_pcie_event_complete(struct mwifiex_adapter *adapter,
> > if (!skb)
> > return 0;
> >
> > - if (rdptr >= MWIFIEX_MAX_EVT_BD)
> > + if (rdptr >= MWIFIEX_MAX_EVT_BD) {
> > dev_err(adapter->dev, "event_complete: Invalid rdptr 0x%x\n",
> > rdptr);
> > + return -EINVAL;
>
> Instead of returning directly, we should set the error code and go through the error handling:
> ret = -EINVAL;
> goto done;
Are you sure? You don't go to error handling a few lines earlier.
johannes
^ permalink raw reply
* RE: [patch 3/4] mwifiex: prevent corruption instead of just warning
From: Bing Zhao @ 2011-10-18 18:19 UTC (permalink / raw)
To: Dan Carpenter
Cc: John W. Linville, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20111018061514.GI27732@elgon.mountain>
Hi Dan,
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Monday, October 17, 2011 11:15 PM
> To: Bing Zhao
> Cc: John W. Linville; linux-wireless@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [patch 3/4] mwifiex: prevent corruption instead of just warning
>
> We may as well put a return here instead of just printing a warning
> message and then corrupting memory. The caller doesn't check the
> return code.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
> index d12d440..40b154d 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1228,9 +1228,11 @@ static int mwifiex_pcie_event_complete(struct mwifiex_adapter *adapter,
> if (!skb)
> return 0;
>
> - if (rdptr >= MWIFIEX_MAX_EVT_BD)
> + if (rdptr >= MWIFIEX_MAX_EVT_BD) {
> dev_err(adapter->dev, "event_complete: Invalid rdptr 0x%x\n",
> rdptr);
> + return -EINVAL;
Instead of returning directly, we should set the error code and go through the error handling:
ret = -EINVAL;
goto done;
Could you please resend v2?
Thanks,
Bing
> + }
>
> /* Read the event ring write pointer set by firmware */
> if (mwifiex_read_reg(adapter, REG_EVTBD_WRPTR, &wrptr)) {
^ permalink raw reply
* RE: [patch 2/4] mwifiex: remove an unneeded NULL check
From: Bing Zhao @ 2011-10-18 17:59 UTC (permalink / raw)
To: Dan Carpenter
Cc: John W. Linville, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20111018061409.GH27732@elgon.mountain>
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Monday, October 17, 2011 11:14 PM
> To: Bing Zhao
> Cc: John W. Linville; linux-wireless@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [patch 2/4] mwifiex: remove an unneeded NULL check
>
> We dereference adapter in the error handling code so this needed to
> be fixed. This function is always called like:
> adapter->if_ops.host_to_card(adapter, ...);
> so adapter can never be NULL and I've removed the NULL check.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Thanks,
Bing
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
> index 4466976..d12d440 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -1671,9 +1671,8 @@ static int mwifiex_pcie_host_to_card(struct mwifiex_adapter *adapter, u8 type,
> struct sk_buff *skb,
> struct mwifiex_tx_param *tx_param)
> {
> - if (!adapter || !skb) {
> - dev_err(adapter->dev, "Invalid parameter in %s <%p, %p>\n",
> - __func__, adapter, skb);
> + if (!skb) {
> + dev_err(adapter->dev, "Passed NULL skb to %s\n", __func__);
> return -1;
> }
>
^ permalink raw reply
* RE: [patch 1/4] mwifiex: remove unneeded kfree(NULL);
From: Bing Zhao @ 2011-10-18 17:57 UTC (permalink / raw)
To: Dan Carpenter
Cc: John W. Linville, linux-wireless@vger.kernel.org,
kernel-janitors@vger.kernel.org
In-Reply-To: <20111018061306.GG27732@elgon.mountain>
Hi Dan,
Thanks for your patch series.
> -----Original Message-----
> From: Dan Carpenter [mailto:dan.carpenter@oracle.com]
> Sent: Monday, October 17, 2011 11:13 PM
> To: Bing Zhao
> Cc: John W. Linville; linux-wireless@vger.kernel.org; kernel-janitors@vger.kernel.org
> Subject: [patch 1/4] mwifiex: remove unneeded kfree(NULL);
>
> The previous if statement means this that pointer is NULL so there
> is no need to free it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Bing Zhao <bzhao@marvell.com>
Regards,
Bing
>
> diff --git a/drivers/net/wireless/mwifiex/pcie.c b/drivers/net/wireless/mwifiex/pcie.c
> index d34acf0..4466976 100644
> --- a/drivers/net/wireless/mwifiex/pcie.c
> +++ b/drivers/net/wireless/mwifiex/pcie.c
> @@ -386,7 +386,6 @@ static int mwifiex_pcie_create_txbd_ring(struct mwifiex_adapter *adapter)
> card->txbd_ring_vbase = kzalloc(card->txbd_ring_size, GFP_KERNEL);
> if (!card->txbd_ring_vbase) {
> dev_err(adapter->dev, "Unable to allocate buffer for txbd ring.\n");
> - kfree(card->txbd_ring_vbase);
> return -1;
> }
> card->txbd_ring_pbase = virt_to_phys(card->txbd_ring_vbase);
^ 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