* Re: [PATCH] ath9k: remove usage of deprecated noise value
From: Benoit PAPILLAULT @ 2010-04-27 19:23 UTC (permalink / raw)
To: Joerg Pommnitz; +Cc: linux-wireless
In-Reply-To: <loom.20100427T125258-288@post.gmane.org>
Joerg Pommnitz a écrit :
> Benoit PAPILLAULT <benoit.papillault@...> writes:
>
>> Before removing noise reporting and all related code, wouln't it be
>> better to have a replacement API?
>>
>
> I thought this is what NL80211_CMD_GET_SURVEY is supposed to do...
> See
> http://osdir.com/ml/linux-wireless/2009-11/msg00977.html
>
>
Thanks Joerg! I tried : iw dev wlan0 survey dump and nothing show up.
What drivers are supposed to have this feature implemented?
Anyway, I really like to have it implemented for ath9k before removing
the deprecated noise value. If it's not currently implemented, I'll try
my best to send a patch in the next couple of days. I'll try then to
implement it for ath5k (already done?), ar9170, zd1211rw (if possible),
rt2800usb/pci.
BTW, on rt2800usb/pci, it seems the noise is reported on a per packet
basis by HW. Kinda strange isn't it? :-]
Regards,
Benoit
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: John W. Linville @ 2010-04-27 19:13 UTC (permalink / raw)
To: Helmut Schaa; +Cc: Gertjan van Wingerde, Ivo van Doorn, linux-wireless
In-Reply-To: <201004272112.26905.helmut.schaa@googlemail.com>
On Tue, Apr 27, 2010 at 09:12:26PM +0200, Helmut Schaa wrote:
> Am Dienstag 27 April 2010 schrieb Gertjan van Wingerde:
> John, would you like me to send a followup patch or would you like to
> revert that one and apply a fixed one?
Follow-up patch, please...thanks!
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: Helmut Schaa @ 2010-04-27 19:12 UTC (permalink / raw)
To: Gertjan van Wingerde, John Linville; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <4BD7270B.6050000@gmail.com>
Am Dienstag 27 April 2010 schrieb Gertjan van Wingerde:
> On 04/27/10 08:28, Helmut Schaa wrote:
> > Am Montag 26 April 2010 schrieb Gertjan van Wingerde:
> >> On 04/26/10 13:48, Helmut Schaa wrote:
> >>> Restore the rfcsr initialization for RT305x SoC devices which was removed
> >>> by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
> >>>
> >>> This fixes the rx path on SoC devices.
> >>>
> >>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> >>> ---
> >>> drivers/net/wireless/rt2x00/rt2800lib.c | 34 ++++++++++++++++++++++++++++++-
> >>> 1 files changed, 33 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> >>> index 2648f31..1358d9a 100644
> >>> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> >>> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> >>> @@ -1703,7 +1703,8 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> >>> if (!rt2x00_rt(rt2x00dev, RT3070) &&
> >>> !rt2x00_rt(rt2x00dev, RT3071) &&
> >>> !rt2x00_rt(rt2x00dev, RT3090) &&
> >>> - !rt2x00_rt(rt2x00dev, RT3390))
> >>> + !rt2x00_rt(rt2x00dev, RT3390) &&
> >>> + !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
> >>> return 0;
> >>
> >> As indicated in the separate email, we should also check for the presence of an RF3020, RF3021
> >> or RF3022 RF chipset for the RT2872 case (maybe this should be more generic, because I'm sure
> >> this will also hold for the other RT chipsets).
> >
> > Ok, do you mean we should only check for rfXXX instead of checking for SoC
> > and rt2872? Or should we check for SoC + rfXXX?
>
> I think that at the moment we should be looking at checking for SoC, RT2872 and RFxxxx.
> To be honest I don't completely know what these RF CSR values represent, we can only find them
> in a SoC Ralink driver, so FWIW it may simply be good settings for an AP (the main use case for
> a SoC device) but not so good for an STA.
>
> So properly applying this only to SoC devices with the right RT chipset and right RF chipset
> seems to be the proper thing here.
>
> >
> >>> /*
> >>> @@ -1771,6 +1772,37 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> >>> rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
> >>> rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
> >>> rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
> >>> + } else if (rt2x00_rt(rt2x00dev, RT2872)) {
> >>> + rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> >>> + rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> >>> + rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> >>> + rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> >>> + rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> >>> + rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> >>> + rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> >>> + rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> >>> + rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> >>> + rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> >>> + rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> >>> + rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> >>> + rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> >>> + rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> >>> + rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> >>> + rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> >>> + rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> >>> + rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> >>> + rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> >>> + rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> >>> + rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> >>> + rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> >>> + rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> >>> + rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> >>> + rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> >>> + rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> >>> + rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> >>> + rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> >>> + rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> >>> + rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> >>> }
> >>>
> >>> if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
> >>
> >> Here we need 2 additional rfcsr_writes, for RF CSR 30 and RF CSR 31, both set to value 0x00.
> >> Also, we can add an "return 0" at the end of the sequence, as nothing more needs to be done for RT2872.
> >
> > Ok, thanks for looking that up.
>
> And please add the rt2x00_is_soc(rt2x00dev) test to that hunk as well. It makes it easier to see that
> that piece is for SoC RT2872 devices only.
Agreed, will send a followup tomorrow. And thanks for checking the Ralink
SoC driver.
> P.S. It seems that John already applied this patch without even Ivo or me Acking it, so I guess an
> incremental patch would be best now.
Yeah, but the patch doesn't break anything for PCI and USB devices and
since not many people use the SoC code yet it's no drama ;).
John, would you like me to send a followup patch or would you like to
revert that one and apply a fixed one?
Thanks,
Helmut
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: John W. Linville @ 2010-04-27 18:15 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: Helmut Schaa, Ivo van Doorn, linux-wireless
In-Reply-To: <4BD7270B.6050000@gmail.com>
On Tue, Apr 27, 2010 at 08:03:55PM +0200, Gertjan van Wingerde wrote:
> P.S. It seems that John already applied this patch without even Ivo or me Acking it, so I guess an
> incremental patch would be best now.
Yes, sorry if that offends -- "fix rx path" makes me take things seriously. :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: Gertjan van Wingerde @ 2010-04-27 18:03 UTC (permalink / raw)
To: Helmut Schaa, John Linville; +Cc: Ivo van Doorn, linux-wireless
In-Reply-To: <201004270828.17303.helmut.schaa@googlemail.com>
On 04/27/10 08:28, Helmut Schaa wrote:
> Am Montag 26 April 2010 schrieb Gertjan van Wingerde:
>> On 04/26/10 13:48, Helmut Schaa wrote:
>>> Restore the rfcsr initialization for RT305x SoC devices which was removed
>>> by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
>>>
>>> This fixes the rx path on SoC devices.
>>>
>>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>>> ---
>>> drivers/net/wireless/rt2x00/rt2800lib.c | 34 ++++++++++++++++++++++++++++++-
>>> 1 files changed, 33 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
>>> index 2648f31..1358d9a 100644
>>> --- a/drivers/net/wireless/rt2x00/rt2800lib.c
>>> +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
>>> @@ -1703,7 +1703,8 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
>>> if (!rt2x00_rt(rt2x00dev, RT3070) &&
>>> !rt2x00_rt(rt2x00dev, RT3071) &&
>>> !rt2x00_rt(rt2x00dev, RT3090) &&
>>> - !rt2x00_rt(rt2x00dev, RT3390))
>>> + !rt2x00_rt(rt2x00dev, RT3390) &&
>>> + !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
>>> return 0;
>>
>> As indicated in the separate email, we should also check for the presence of an RF3020, RF3021
>> or RF3022 RF chipset for the RT2872 case (maybe this should be more generic, because I'm sure
>> this will also hold for the other RT chipsets).
>
> Ok, do you mean we should only check for rfXXX instead of checking for SoC
> and rt2872? Or should we check for SoC + rfXXX?
I think that at the moment we should be looking at checking for SoC, RT2872 and RFxxxx.
To be honest I don't completely know what these RF CSR values represent, we can only find them
in a SoC Ralink driver, so FWIW it may simply be good settings for an AP (the main use case for
a SoC device) but not so good for an STA.
So properly applying this only to SoC devices with the right RT chipset and right RF chipset
seems to be the proper thing here.
>
>>> /*
>>> @@ -1771,6 +1772,37 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
>>> rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
>>> rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
>>> rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
>>> + } else if (rt2x00_rt(rt2x00dev, RT2872)) {
>>> + rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
>>> + rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
>>> + rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
>>> + rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
>>> + rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
>>> + rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
>>> + rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
>>> + rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
>>> + rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
>>> + rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
>>> + rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
>>> + rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
>>> + rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
>>> + rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
>>> + rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
>>> + rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
>>> + rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
>>> + rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
>>> + rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
>>> + rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
>>> + rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
>>> + rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
>>> + rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
>>> + rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
>>> + rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
>>> + rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
>>> + rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
>>> + rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
>>> + rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
>>> + rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
>>> }
>>>
>>> if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
>>
>> Here we need 2 additional rfcsr_writes, for RF CSR 30 and RF CSR 31, both set to value 0x00.
>> Also, we can add an "return 0" at the end of the sequence, as nothing more needs to be done for RT2872.
>
> Ok, thanks for looking that up.
And please add the rt2x00_is_soc(rt2x00dev) test to that hunk as well. It makes it easier to see that
that piece is for SoC RT2872 devices only.
P.S. It seems that John already applied this patch without even Ivo or me Acking it, so I guess an
incremental patch would be best now.
---
Gertjan
^ permalink raw reply
* Re: [PATCH 1/1] mac80211: fix rts threshold check
From: Johannes Berg @ 2010-04-27 17:55 UTC (permalink / raw)
To: shanyu.zhao; +Cc: linux-wireless
In-Reply-To: <1272392112-28301-1-git-send-email-shanyu.zhao@intel.com>
On Tue, 2010-04-27 at 11:15 -0700, shanyu.zhao@intel.com wrote:
> From: Shanyu Zhao <shanyu.zhao@intel.com>
>
> Currently whenever rts thresold is set, every packet will use RTS
> protection no matter its size exceeds the threshold or not. This is
> due to a bug in the rts threshold check.
> if (len > tx->local->hw.wiphy->rts_threshold) {
> txrc.rts = rts = true;
> }
> Basically it is comparing an int (len) and a u32 (rts_threshold),
> and the variable len is assigned as:
> len = min_t(int, tx->skb->len + FCS_LEN,
> tx->local->hw.wiphy->frag_threshold);
> However, when frag_threshold is "-1", len is always "-1", which is
> 0xffffffff therefore rts is always set to true.
D'oh. Good catch.
Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
> CC: stable@kernel.org
>
> Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
> ---
> net/mac80211/tx.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> index e2aa972..f3841f4 100644
> --- a/net/mac80211/tx.c
> +++ b/net/mac80211/tx.c
> @@ -593,7 +593,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
> struct ieee80211_hdr *hdr = (void *)tx->skb->data;
> struct ieee80211_supported_band *sband;
> struct ieee80211_rate *rate;
> - int i, len;
> + int i;
> + u32 len;
> bool inval = false, rts = false, short_preamble = false;
> struct ieee80211_tx_rate_control txrc;
> u32 sta_flags;
> @@ -602,7 +603,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
>
> sband = tx->local->hw.wiphy->bands[tx->channel->band];
>
> - len = min_t(int, tx->skb->len + FCS_LEN,
> + len = min_t(u32, tx->skb->len + FCS_LEN,
> tx->local->hw.wiphy->frag_threshold);
>
> /* set up the tx rate control struct we give the RC algo */
^ permalink raw reply
* [PATCH 1/1] mac80211: fix rts threshold check
From: shanyu.zhao @ 2010-04-27 18:15 UTC (permalink / raw)
To: linux-wireless; +Cc: Shanyu Zhao
From: Shanyu Zhao <shanyu.zhao@intel.com>
Currently whenever rts thresold is set, every packet will use RTS
protection no matter its size exceeds the threshold or not. This is
due to a bug in the rts threshold check.
if (len > tx->local->hw.wiphy->rts_threshold) {
txrc.rts = rts = true;
}
Basically it is comparing an int (len) and a u32 (rts_threshold),
and the variable len is assigned as:
len = min_t(int, tx->skb->len + FCS_LEN,
tx->local->hw.wiphy->frag_threshold);
However, when frag_threshold is "-1", len is always "-1", which is
0xffffffff therefore rts is always set to true.
CC: stable@kernel.org
Signed-off-by: Shanyu Zhao <shanyu.zhao@intel.com>
---
net/mac80211/tx.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index e2aa972..f3841f4 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -593,7 +593,8 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
struct ieee80211_hdr *hdr = (void *)tx->skb->data;
struct ieee80211_supported_band *sband;
struct ieee80211_rate *rate;
- int i, len;
+ int i;
+ u32 len;
bool inval = false, rts = false, short_preamble = false;
struct ieee80211_tx_rate_control txrc;
u32 sta_flags;
@@ -602,7 +603,7 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
sband = tx->local->hw.wiphy->bands[tx->channel->band];
- len = min_t(int, tx->skb->len + FCS_LEN,
+ len = min_t(u32, tx->skb->len + FCS_LEN,
tx->local->hw.wiphy->frag_threshold);
/* set up the tx rate control struct we give the RC algo */
--
1.6.0.4
^ permalink raw reply related
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-27 17:05 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <1272384504.2434.9.camel@gnutoo-desktop>
On Tue, 2010-04-27 at 18:08 +0200, GNUtoo wrote:
> On Tue, 2010-04-27 at 18:03 +0200, GNUtoo wrote:
> > On Tue, 2010-04-27 at 15:27 +0200, GNUtoo wrote:
> > > > You need a few more patches for PS to work (on top of current compat-wireless):
> > > > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> > > > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
> > > >
> > > > I'm working on mainline mergeable versions of those..
> > > Denis.
> > oops I don't know why the message wasn't included,maybe I made an error.
> > Anyway it last much longer,but sometimes it only last for about 50 pings
> > and after that no more network,tough iwconfig still say that it's
> > associated.
> > I'll check my hostapd router logs and try to put a wakelock
> Apr 27 18:02:18 router hostapd: wlan0: STA 00:1f:df:f8:ac:7f RADIUS:
> starting accounting session 4BA21E4D-000007D8
> Apr 27 18:03:24 router hostapd: wlan0: STA 00:1f:df:24:0b:7f IEEE
> 802.11: disassociated due to inactivity
> Apr 27 18:03:25 router hostapd: wlan0: STA 00:1f:df:24:0b:7f IEEE
> 802.11: deauthenticated due to inactivity
hmmm....
now it does that:
Apr 27 18:12:43 router hostapd: wlan0: STA 00:1f:df:65:25:23 IEEE
802.11: authenticated
Apr 27 18:12:43 router hostapd: wlan0: STA 00:1f:df:65:25:23 IEEE
802.11: associated (aid 2)
Apr 27 18:12:43 router hostapd: wlan0: STA 00:1f:df:65:25:23 RADIUS:
starting accounting session 4BA21E4D-000007D9
Apr 27 18:13:11 router hostapd: wlan0: STA 00:1f:df:65:25:23 IEEE
802.11: authenticated
Apr 27 18:13:11 router hostapd: wlan0: STA 00:1f:df:65:25:23 IEEE
802.11: associated (aid 2)
Apr 27 18:13:11 router hostapd: wlan0: STA 00:1f:df:65:25:23 RADIUS:
starting accounting session 4BA21E4D-000007DA
--->start pinging
--->ping stopping
with no messages just after the ping stopping,so maybe I need some more
patches...
Denis.
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-27 16:08 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <1272384213.2434.8.camel@gnutoo-desktop>
On Tue, 2010-04-27 at 18:03 +0200, GNUtoo wrote:
> On Tue, 2010-04-27 at 15:27 +0200, GNUtoo wrote:
> > > You need a few more patches for PS to work (on top of current compat-wireless):
> > > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> > > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
> > >
> > > I'm working on mainline mergeable versions of those..
> > Denis.
> oops I don't know why the message wasn't included,maybe I made an error.
> Anyway it last much longer,but sometimes it only last for about 50 pings
> and after that no more network,tough iwconfig still say that it's
> associated.
> I'll check my hostapd router logs and try to put a wakelock
Apr 27 18:02:18 router hostapd: wlan0: STA 00:1f:df:f8:ac:7f RADIUS:
starting accounting session 4BA21E4D-000007D8
Apr 27 18:03:24 router hostapd: wlan0: STA 00:1f:df:24:0b:7f IEEE
802.11: disassociated due to inactivity
Apr 27 18:03:25 router hostapd: wlan0: STA 00:1f:df:24:0b:7f IEEE
802.11: deauthenticated due to inactivity
So I think it's not the driver...
By the way,the thanks were lost in the mail containing only a quote and
"Denis."
so thanks a lot for the patch!!!
Denis
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-27 16:03 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <1272374877.2434.0.camel@gnutoo-desktop>
On Tue, 2010-04-27 at 15:27 +0200, GNUtoo wrote:
> > You need a few more patches for PS to work (on top of current compat-wireless):
> > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> > http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
> >
> > I'm working on mainline mergeable versions of those..
> Denis.
oops I don't know why the message wasn't included,maybe I made an error.
Anyway it last much longer,but sometimes it only last for about 50 pings
and after that no more network,tough iwconfig still say that it's
associated.
I'll check my hostapd router logs and try to put a wakelock
Denis.
^ permalink raw reply
* Re: linux-next: April 27 (wireless/libertas warnings)
From: John W. Linville @ 2010-04-27 15:59 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Kernel Mailing List, linux-wireless@vger.kernel.org,
linux-next, Steve deRosier
In-Reply-To: <4BD70485.1070203@oracle.com>
On Tue, Apr 27, 2010 at 08:36:37AM -0700, Randy Dunlap wrote:
> drivers/net/wireless/libertas_tf/deb_defs.h:12:1: warning: "pr_fmt" redefined
> include/linux/kernel.h:376:1: warning: this is the location of the previous definition
> drivers/net/wireless/libertas_tf/deb_defs.h:12:1: warning: "pr_fmt" redefined
> include/linux/kernel.h:376:1: warning: this is the location of the previous definition
Yup, just had this exchange w/ Stephen...
The problem comes from including slab.h before deb_defs.h (as done
in linux-next). The version in wireless-testing avoids the warning
by including the headers in the other order, but that is a bit ugly.
Does anyone know if it is OK to #undef pr_fmt before defining it
in deb_defs.h?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* linux-next: April 27 (wireless/libertas warnings)
From: Randy Dunlap @ 2010-04-27 15:36 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-wireless@vger.kernel.org,
linux-next
drivers/net/wireless/libertas_tf/deb_defs.h:12:1: warning: "pr_fmt" redefined
include/linux/kernel.h:376:1: warning: this is the location of the previous definition
drivers/net/wireless/libertas_tf/deb_defs.h:12:1: warning: "pr_fmt" redefined
include/linux/kernel.h:376:1: warning: this is the location of the previous definition
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: wl1251_sdio PSM
From: GNUtoo @ 2010-04-27 13:27 UTC (permalink / raw)
To: Grazvydas Ignotas; +Cc: linux-wireless
In-Reply-To: <loom.20100427T143119-272@post.gmane.org>
> You need a few more patches for PS to work (on top of current compat-wireless):
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
> http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
>
> I'm working on mainline mergeable versions of those..
Denis.
^ permalink raw reply
* Re: wl1251_sdio PSM
From: Grazvydas Ignotas @ 2010-04-27 12:39 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1272285416.2364.1.camel@gnutoo-desktop>
GNUtoo writes:
> Unfortunately it didn't work as expected:
> # ping router
> PING router (192.168.1.1): 56 data bytes
> 64 bytes from 192.168.1.1: seq=0 ttl=64 time=7.995 ms
<snip>
> 64 bytes from 192.168.1.1: seq=32 ttl=64 time=4.303 ms
> 64 bytes from 192.168.1.1: seq=33 ttl=64 time=2194.366 ms
> 64 bytes from 192.168.1.1: seq=34 ttl=64 time=1193.634 ms
> 64 bytes from 192.168.1.1: seq=35 ttl=64 time=193.421 ms
> 64 bytes from 192.168.1.1: seq=38 ttl=64 time=760.559 ms
> 64 bytes from 192.168.1.1: seq=39 ttl=64 time=784.851 ms
>
> the power_save feature was activated with iw, just before the
> 64 bytes from 192.168.1.1: seq=33 ttl=64 time=2194.366 ms
> line
> then after 5 lines of ping it stopped displaying the pings.
You need a few more patches for PS to work (on top of current compat-wireless):
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=commitdiff;h=8eb97a1915ae2ab0a19cc6eef1a2753b9514017d
http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-wifi.git;a=commitdiff;h=d16ed8871faa892f5fd4e8161412051ee11c5ecb
I'm working on mainline mergeable versions of those..
^ permalink raw reply
* Re: [PATCH 6/9] rt2x00: Finish rt3070 support in rt2800 register initialization.
From: Antonio Quartulli @ 2010-04-27 11:15 UTC (permalink / raw)
To: Helmut Schaa
Cc: Gertjan van Wingerde, John W. Linville, Ivo van Doorn,
linux-wireless, users, Luis Correia
In-Reply-To: <201004261311.20834.Helmut.Schaa@gmx.de>
On lun, apr 26, 2010 at 01:11:20 +0200, Helmut Schaa wrote:
> Am Montag 26 April 2010 schrieb Helmut Schaa:
> > Am Sonntag 11 April 2010 schrieb Gertjan van Wingerde:
> > > rt2x00 had preliminary support for RT3070 based devices, but the support was
> > > incomplete.
> > > Update the RT3070 register initialization to be similar to the latest Ralink
> > > vendor driver.
> > >
> > > With this patch my rt3070 based devices start showing a sign of life.
> >
> > Gertjan, this patch breaks rx on my 305x SoC device. See inline comments for
> > more details.
>
> Antonio, did that patch also break rx on your PCI device with rt2872?
> If not this is only needed for SoC.
Hi, I cloned the wireless-testing git a few minutes ago.
My card (rt2x00_set_chip: Info - Chipset detected - rt: 2872, rf: 0003,
rev: 0200) on miniPCI works correctly without any kind of problem.
No hangs at all.
Regards
>
> Thanks,
> Helmut
>
> > [...]
> >
> > > @@ -1643,18 +1653,12 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > {
> > > u8 rfcsr;
> > > u8 bbp;
> > > + u32 reg;
> > > + u16 eeprom;
> > >
> > > - if (rt2x00_is_usb(rt2x00dev) &&
> > > - !rt2x00_rt_rev(rt2x00dev, RT3070, REV_RT3070E))
> > > + if (!rt2x00_rt(rt2x00dev, RT3070))
> > > return 0;
> > >
> > > - if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > > - if (!rt2x00_rf(rt2x00dev, RF3020) &&
> > > - !rt2x00_rf(rt2x00dev, RF3021) &&
> > > - !rt2x00_rf(rt2x00dev, RF3022))
> > > - return 0;
> > > - }
> >
> > Any reason why you've removed this part? The following code was executed on
> > pci and soc devices when they had an 3020, 3021 or 3022 rf.
> >
> > > /*
> > > * Init RF calibration.
> > > */
> > > @@ -1665,13 +1669,13 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > rt2x00_set_field8(&rfcsr, RFCSR30_RF_CALIBRATION, 0);
> > > rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
> > >
> > > - if (rt2x00_is_usb(rt2x00dev)) {
> > > + if (rt2x00_rt(rt2x00dev, RT3070)) {
> > > rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > > rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > > rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > > rt2800_rfcsr_write(rt2x00dev, 7, 0x70);
> > > rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > > - rt2800_rfcsr_write(rt2x00dev, 10, 0x71);
> > > + rt2800_rfcsr_write(rt2x00dev, 10, 0x41);
> > > rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > > rt2800_rfcsr_write(rt2x00dev, 12, 0x7b);
> > > rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > > @@ -1684,48 +1688,25 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > > rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > > rt2800_rfcsr_write(rt2x00dev, 24, 0x16);
> > > rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > > - rt2800_rfcsr_write(rt2x00dev, 27, 0x03);
> > > rt2800_rfcsr_write(rt2x00dev, 29, 0x1f);
> > > - } else if (rt2x00_is_pci(rt2x00dev) || rt2x00_is_soc(rt2x00dev)) {
> > > - rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> > > - rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> > > - rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> > > - rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> > > - rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > > - rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > > - rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > > - rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> > > - rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> > > - rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > > - rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> > > - rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > > - rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> > > - rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> > > - rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > > - rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> > > - rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> > > - rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> > > - rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> > > - rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> > > - rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> > > - rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > > - rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> > > - rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> > > - rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> > > - rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > > - rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> > > - rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> > > - rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> > > - rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> >
> > This part is actually needed for getting rx to work on the SoC devices.
> >
> > Should I post a patch that adds this code again and is only executed on SoC
> > devices with rf3020, 3021 and 3022?
> >
> > Thanks,
> > Helmut
> >
--
Antonio Quartulli
Ognuno di noi, da solo, non vale nulla
Ernesto "Che" Guevara
^ permalink raw reply
* Re: ath5k misbehaving affecting other kernel parts unrelated?
From: Pedro Francisco @ 2010-04-27 11:04 UTC (permalink / raw)
To: Jiri Slaby
Cc: me, Vegard Nossum, John W. Linville, linux-kernel, linux-wireless,
mickflemm
In-Reply-To: <201004252224.05509.pedrogfrancisco@gmail.com>
A Domingo, 25 de Abril de 2010 22:24:04 Pedro Francisco escreveu:
> A Domingo, 25 de Abril de 2010 21:29:45 Jiri Slaby escreveu:
> > On 04/25/2010 09:22 PM, me@bobcopeland.com wrote:
> > > On Sat, Apr 24, 2010 at 06:28:36PM +0100, Pedro Francisco wrote:
> > >> ======================================================================
> > >> == ===== [ 2658.663424] BUG kmalloc-4096: Poison overwritten
> > >> [ 2658.663483]
> > >
> > > Ok there are 4 messages here, two of them are definitely 802.11
> > > beacons, which would point the finger squarely at ath5k. We had
> > > reports of this some time ago but a few things got rewritten around
> > > that time. I'd guess the rx DMA code is still subtly broken.
> > >
> > >> 6b 6b kkkkkkkkkkkkkkkk
> > >> [ 2658.664816] Object 0xed3db0c0: c4 00 84 00 00 22 43 89 42 69 4e
> > >> 12 ca 6f 6f 6f �...."C.BiN.�ooo
> > >> [ 4689.945547] Object 0xed3d9080: c4 00 70 00 00 22 43 89 42 69 fe
> > >> 08 eb 14 14 14 �.p.."C.Bi�.�...
> > >
> > > Offhand, I'm not sure what pattern these are.
> >
> > These are CTS frames. So I think ath5k is to blame too :/.
> >
> > regards,
>
> Do note that's on a 2.6.32 kernel. I've however a new dmesg/syslog which on
> a 2.6.34-rc5-daily has the same kind of issues. It's 400kB in size..... Do
> you want me to send it to the mailing list?
>
> Or should I open a bug report on the kernel bugzilla and post them there?
> Or do both?
Now live on... https://bugzilla.kernel.org/show_bug.cgi?id=15861
--
Pedro
^ permalink raw reply
* Re: [PATCH] ath9k: remove usage of deprecated noise value
From: Joerg Pommnitz @ 2010-04-27 10:55 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4BD682AF.6030206@free.fr>
Benoit PAPILLAULT <benoit.papillault@...> writes:
> Before removing noise reporting and all related code, wouln't it be
> better to have a replacement API?
I thought this is what NL80211_CMD_GET_SURVEY is supposed to do...
See
http://osdir.com/ml/linux-wireless/2009-11/msg00977.html
^ permalink raw reply
* [PATCH] mac80211: give virtual interface to hw_scan
From: Johannes Berg @ 2010-04-27 9:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
When scanning, it is somewhat important to scan
on the correct virtual interface. All drivers
that currently implement hw_scan only support a
single virtual interface, but that may change
and then we'd want to be ready.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
drivers/net/wireless/at76c50x-usb.c | 1 +
drivers/net/wireless/iwlwifi/iwl-core.h | 4 +++-
drivers/net/wireless/iwlwifi/iwl-scan.c | 3 ++-
drivers/net/wireless/mac80211_hwsim.c | 1 +
drivers/net/wireless/wl12xx/wl1251_main.c | 1 +
drivers/net/wireless/wl12xx/wl1271_main.c | 1 +
include/net/mac80211.h | 2 +-
net/mac80211/driver-ops.h | 5 +++--
net/mac80211/driver-trace.h | 9 ++++++---
net/mac80211/scan.c | 4 ++--
10 files changed, 21 insertions(+), 10 deletions(-)
--- wireless-testing.orig/drivers/net/wireless/at76c50x-usb.c 2009-12-29 14:31:37.000000000 +0100
+++ wireless-testing/drivers/net/wireless/at76c50x-usb.c 2010-04-27 11:58:52.000000000 +0200
@@ -1889,6 +1889,7 @@ static void at76_dwork_hw_scan(struct wo
}
static int at76_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
struct cfg80211_scan_request *req)
{
struct at76_priv *priv = hw->priv;
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-core.h 2010-04-20 21:14:41.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-core.h 2010-04-27 11:58:52.000000000 +0200
@@ -512,7 +512,9 @@ static inline __le32 iwl_hw_set_rate_n_f
void iwl_init_scan_params(struct iwl_priv *priv);
int iwl_scan_cancel(struct iwl_priv *priv);
int iwl_scan_cancel_timeout(struct iwl_priv *priv, unsigned long ms);
-int iwl_mac_hw_scan(struct ieee80211_hw *hw, struct cfg80211_scan_request *req);
+int iwl_mac_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct cfg80211_scan_request *req);
void iwl_internal_short_hw_scan(struct iwl_priv *priv);
int iwl_force_reset(struct iwl_priv *priv, int mode);
u16 iwl_fill_probe_req(struct iwl_priv *priv, struct ieee80211_mgmt *frame,
--- wireless-testing.orig/drivers/net/wireless/iwlwifi/iwl-scan.c 2010-04-20 21:14:41.000000000 +0200
+++ wireless-testing/drivers/net/wireless/iwlwifi/iwl-scan.c 2010-04-27 11:58:52.000000000 +0200
@@ -313,7 +313,8 @@ static int iwl_scan_initiate(struct iwl_
}
int iwl_mac_hw_scan(struct ieee80211_hw *hw,
- struct cfg80211_scan_request *req)
+ struct ieee80211_vif *vif,
+ struct cfg80211_scan_request *req)
{
struct iwl_priv *priv = hw->priv;
int ret;
--- wireless-testing.orig/drivers/net/wireless/mac80211_hwsim.c 2010-04-27 11:58:18.000000000 +0200
+++ wireless-testing/drivers/net/wireless/mac80211_hwsim.c 2010-04-27 11:58:52.000000000 +0200
@@ -991,6 +991,7 @@ static void hw_scan_done(struct work_str
}
static int mac80211_hwsim_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
struct cfg80211_scan_request *req)
{
struct hw_scan_done *hsd = kzalloc(sizeof(*hsd), GFP_KERNEL);
--- wireless-testing.orig/drivers/net/wireless/wl12xx/wl1251_main.c 2010-04-20 21:14:41.000000000 +0200
+++ wireless-testing/drivers/net/wireless/wl12xx/wl1251_main.c 2010-04-27 11:58:52.000000000 +0200
@@ -857,6 +857,7 @@ out:
}
static int wl1251_op_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
struct cfg80211_scan_request *req)
{
struct wl1251 *wl = hw->priv;
--- wireless-testing.orig/drivers/net/wireless/wl12xx/wl1271_main.c 2010-04-20 21:14:41.000000000 +0200
+++ wireless-testing/drivers/net/wireless/wl12xx/wl1271_main.c 2010-04-27 11:58:52.000000000 +0200
@@ -1524,6 +1524,7 @@ out:
}
static int wl1271_op_hw_scan(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
struct cfg80211_scan_request *req)
{
struct wl1271 *wl = hw->priv;
--- wireless-testing.orig/include/net/mac80211.h 2010-04-27 11:58:17.000000000 +0200
+++ wireless-testing/include/net/mac80211.h 2010-04-27 11:58:52.000000000 +0200
@@ -1666,7 +1666,7 @@ struct ieee80211_ops {
struct ieee80211_key_conf *conf,
struct ieee80211_sta *sta,
u32 iv32, u16 *phase1key);
- int (*hw_scan)(struct ieee80211_hw *hw,
+ int (*hw_scan)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct cfg80211_scan_request *req);
void (*sw_scan_start)(struct ieee80211_hw *hw);
void (*sw_scan_complete)(struct ieee80211_hw *hw);
--- wireless-testing.orig/net/mac80211/driver-ops.h 2010-04-20 21:14:43.000000000 +0200
+++ wireless-testing/net/mac80211/driver-ops.h 2010-04-27 11:58:52.000000000 +0200
@@ -154,14 +154,15 @@ static inline void drv_update_tkip_key(s
}
static inline int drv_hw_scan(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
struct cfg80211_scan_request *req)
{
int ret;
might_sleep();
- ret = local->ops->hw_scan(&local->hw, req);
- trace_drv_hw_scan(local, req, ret);
+ ret = local->ops->hw_scan(&local->hw, &sdata->vif, req);
+ trace_drv_hw_scan(local, sdata, req, ret);
return ret;
}
--- wireless-testing.orig/net/mac80211/driver-trace.h 2010-04-09 11:46:46.000000000 +0200
+++ wireless-testing/net/mac80211/driver-trace.h 2010-04-27 11:58:52.000000000 +0200
@@ -363,23 +363,26 @@ TRACE_EVENT(drv_update_tkip_key,
TRACE_EVENT(drv_hw_scan,
TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
struct cfg80211_scan_request *req, int ret),
- TP_ARGS(local, req, ret),
+ TP_ARGS(local, sdata, req, ret),
TP_STRUCT__entry(
LOCAL_ENTRY
+ VIF_ENTRY
__field(int, ret)
),
TP_fast_assign(
LOCAL_ASSIGN;
+ VIF_ASSIGN;
__entry->ret = ret;
),
TP_printk(
- LOCAL_PR_FMT " ret:%d",
- LOCAL_PR_ARG, __entry->ret
+ LOCAL_PR_FMT VIF_PR_FMT " ret:%d",
+ LOCAL_PR_ARG,VIF_PR_ARG, __entry->ret
)
);
--- wireless-testing.orig/net/mac80211/scan.c 2010-04-20 21:14:43.000000000 +0200
+++ wireless-testing/net/mac80211/scan.c 2010-04-27 11:58:52.000000000 +0200
@@ -411,7 +411,7 @@ static int __ieee80211_start_scan(struct
if (local->ops->hw_scan) {
WARN_ON(!ieee80211_prep_hw_scan(local));
- rc = drv_hw_scan(local, local->hw_scan_req);
+ rc = drv_hw_scan(local, sdata, local->hw_scan_req);
} else
rc = ieee80211_start_sw_scan(local);
@@ -655,7 +655,7 @@ void ieee80211_scan_work(struct work_str
}
if (local->hw_scan_req) {
- int rc = drv_hw_scan(local, local->hw_scan_req);
+ int rc = drv_hw_scan(local, sdata, local->hw_scan_req);
mutex_unlock(&local->scan_mtx);
if (rc)
ieee80211_scan_completed(&local->hw, true);
^ permalink raw reply
* [PATCH 1/2] mac80211: Determine dynamic PS timeout based on ps-qos network latency
From: Juuso Oikarinen @ 2010-04-27 9:47 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Determine the dynamic PS timeout based on the configured ps-qos network
latency. For backwards wext compatibility, allow the dynamic PS timeout
configured by the cfg80211 to overrule the automatically determined value.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/mac80211.h | 5 ++++-
net/mac80211/cfg.c | 4 ++--
net/mac80211/main.c | 2 ++
net/mac80211/mlme.c | 21 +++++++++++++++++++++
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7dc5a67..c26de6c 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -668,6 +668,9 @@ enum ieee80211_smps_mode {
* @dynamic_ps_timeout: The dynamic powersave timeout (in ms), see the
* powersave documentation below. This variable is valid only when
* the CONF_PS flag is set.
+ * @dynamic_ps_forced_timeout: The dynamic powersave timeout (in ms) configured
+ * by cfg80211 (essentially, wext) If set, this value overrules the value
+ * chosen by mac80211 based on ps qos network latency.
*
* @power_level: requested transmit power (in dBm)
*
@@ -687,7 +690,7 @@ enum ieee80211_smps_mode {
*/
struct ieee80211_conf {
u32 flags;
- int power_level, dynamic_ps_timeout;
+ int power_level, dynamic_ps_timeout, dynamic_ps_forced_timeout;
int max_sleep_period;
u16 listen_interval;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 845a6e6..30e9b31 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1399,11 +1399,11 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev,
return -EOPNOTSUPP;
if (enabled == sdata->u.mgd.powersave &&
- timeout == conf->dynamic_ps_timeout)
+ timeout == conf->dynamic_ps_forced_timeout)
return 0;
sdata->u.mgd.powersave = enabled;
- conf->dynamic_ps_timeout = timeout;
+ conf->dynamic_ps_forced_timeout = timeout;
/* no change, but if automatic follow powersave */
mutex_lock(&sdata->u.mgd.mtx);
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 4afe851..ebcca0e 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -569,6 +569,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
local->hw.conf.listen_interval = local->hw.max_listen_interval;
+ local->hw.conf.dynamic_ps_forced_timeout = -1;
+
result = sta_info_start(local);
if (result < 0)
goto fail_sta_info;
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 425f66c..358226f 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -478,6 +478,7 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
{
struct ieee80211_sub_if_data *sdata, *found = NULL;
int count = 0;
+ int timeout;
if (!(local->hw.flags & IEEE80211_HW_SUPPORTS_PS)) {
local->ps_sdata = NULL;
@@ -511,6 +512,26 @@ void ieee80211_recalc_ps(struct ieee80211_local *local, s32 latency)
beaconint_us = ieee80211_tu_to_usec(
found->vif.bss_conf.beacon_int);
+ timeout = local->hw.conf.dynamic_ps_forced_timeout;
+ if (timeout < 0) {
+ /*
+ * The 2 second value is there for compatibility until
+ * the PM_QOS_NETWORK_LATENCY is configured with real
+ * values.
+ */
+ if (latency == 2000000000)
+ timeout = 100;
+ else if (latency <= 50000)
+ timeout = 300;
+ else if (latency <= 100000)
+ timeout = 100;
+ else if (latency <= 500000)
+ timeout = 50;
+ else
+ timeout = 0;
+ }
+ local->hw.conf.dynamic_ps_timeout = timeout;
+
if (beaconint_us > latency) {
local->ps_sdata = NULL;
} else {
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] cfg80211: Remove default dynamic PS timeout value
From: Juuso Oikarinen @ 2010-04-27 9:47 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
In-Reply-To: <1272361661-16811-1-git-send-email-juuso.oikarinen@nokia.com>
Now that the mac80211 is choosing dynamic ps timeouts based on the ps-qos
network latency configuration, configure a default value of -1 as the dynamic
ps timeout in cfg80211. This value allows the mac80211 to determine the value
to be used.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
include/net/cfg80211.h | 2 ++
net/wireless/core.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5a4efe5..a609b4b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1018,6 +1018,8 @@ struct cfg80211_pmksa {
* RSN IE. It allows for faster roaming between WPA2 BSSIDs.
* @del_pmksa: Delete a cached PMKID.
* @flush_pmksa: Flush all cached PMKIDs.
+ * @set_power_mgmt: Configure WLAN power management. A timeout value of -1
+ * allows the driver to adjust the dynamic ps timeout value.
* @set_cqm_rssi_config: Configure connection quality monitor RSSI threshold.
*
*/
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 6ac70c1..37d0e0a 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -705,7 +705,8 @@ static int cfg80211_netdev_notifier_call(struct notifier_block * nb,
wdev->ps = true;
else
wdev->ps = false;
- wdev->ps_timeout = 100;
+ /* allow mac80211 to determine the timeout */
+ wdev->ps_timeout = -1;
if (rdev->ops->set_power_mgmt)
if (rdev->ops->set_power_mgmt(wdev->wiphy, dev,
wdev->ps,
--
1.6.3.3
^ permalink raw reply related
* [PATCH 2/2] ath9k: Avoid corrupt frames being forwarded to mac80211.
From: Vivek Natarajan @ 2010-04-27 7:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, stable, Ranga Rao Ravuri
In-Reply-To: <1272353738-17084-1-git-send-email-vnatarajan@atheros.com>
If bit 29 is set, MAC H/W can attempt to decrypt the received aggregate
with WEP or TKIP, eventhough the received frame may be a CRC failed
corrupted frame. If this bit is set, H/W obeys key type in keycache.
If it is not set and if the key type in keycache is neither open nor
AES, H/W forces key type to be open. But bit 29 should be set to 1
for AsyncFIFO feature to encrypt/decrypt the aggregate with WEP or TKIP.
Cc: stable@kernel.org
Reported-by: Johan Hovold <johan.hovold@lundinova.se>
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
Signed-off-by: Ranga Rao Ravuri <ranga.ravuri@atheros.com>
---
drivers/net/wireless/ath/ath9k/ar5008_initvals.h | 2 +-
drivers/net/wireless/ath/ath9k/ar9002_initvals.h | 8 ++++----
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
index cd953f6..025c31a 100644
--- a/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar5008_initvals.h
@@ -249,7 +249,7 @@ static const u32 ar5416Common[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8000010 },
+ { 0x00008264, 0x88000010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
diff --git a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
index f06313d..dae7f33 100644
--- a/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
+++ b/drivers/net/wireless/ath/ath9k/ar9002_initvals.h
@@ -793,7 +793,7 @@ static const u32 ar9280Common_9280_2[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -1963,7 +1963,7 @@ static const u32 ar9285Common_9285[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -3185,7 +3185,7 @@ static const u32 ar9287Common_9287_1_0[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
@@ -4973,7 +4973,7 @@ static const u32 ar9271Common_9271[][2] = {
{ 0x00008258, 0x00000000 },
{ 0x0000825c, 0x400000ff },
{ 0x00008260, 0x00080922 },
- { 0x00008264, 0xa8a00010 },
+ { 0x00008264, 0x88a00010 },
{ 0x00008270, 0x00000000 },
{ 0x00008274, 0x40000000 },
{ 0x00008278, 0x003e4180 },
--
1.7.0.5
^ permalink raw reply related
* [PATCH 1/2] ath9k_htc: Handle CONF_IDLE during unassociated state to save power.
From: Vivek Natarajan @ 2010-04-27 7:35 UTC (permalink / raw)
To: linville; +Cc: linux-wireless
Signed-off-by: Vivek Natarajan <vnatarajan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 71 ++++++++++++++++++-------
2 files changed, 53 insertions(+), 19 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index b771e20..1ae18bb 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -379,6 +379,7 @@ struct ath9k_htc_priv {
struct mutex htc_pm_lock;
unsigned long ps_usecount;
bool ps_enabled;
+ bool ps_idle;
struct ath_led radio_led;
struct ath_led assoc_led;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 9c9f3e0..26d5f22 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -94,8 +94,11 @@ void ath9k_htc_ps_restore(struct ath9k_htc_priv *priv)
if (--priv->ps_usecount != 0)
goto unlock;
- if (priv->ps_enabled)
+ if (priv->ps_idle)
+ ath9k_hw_setpower(priv->ah, ATH9K_PM_FULL_SLEEP);
+ else if (priv->ps_enabled)
ath9k_hw_setpower(priv->ah, ATH9K_PM_NETWORK_SLEEP);
+
unlock:
mutex_unlock(&priv->htc_pm_lock);
}
@@ -1097,7 +1100,7 @@ fail_tx:
return 0;
}
-static int ath9k_htc_start(struct ieee80211_hw *hw)
+static int ath9k_htc_radio_enable(struct ieee80211_hw *hw)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath_hw *ah = priv->ah;
@@ -1113,8 +1116,6 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
"Starting driver with initial channel: %d MHz\n",
curchan->center_freq);
- mutex_lock(&priv->mutex);
-
/* setup initial channel */
init_channel = ath9k_cmn_get_curchannel(hw, ah);
@@ -1127,7 +1128,7 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
ath_print(common, ATH_DBG_FATAL,
"Unable to reset hardware; reset status %d "
"(freq %u MHz)\n", ret, curchan->center_freq);
- goto mutex_unlock;
+ return ret;
}
ath_update_txpow(priv);
@@ -1135,16 +1136,8 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
mode = ath9k_htc_get_curmode(priv, init_channel);
htc_mode = cpu_to_be16(mode);
WMI_CMD_BUF(WMI_SET_MODE_CMDID, &htc_mode);
- if (ret)
- goto mutex_unlock;
-
WMI_CMD(WMI_ATH_INIT_CMDID);
- if (ret)
- goto mutex_unlock;
-
WMI_CMD(WMI_START_RECV_CMDID);
- if (ret)
- goto mutex_unlock;
ath9k_host_rx_init(priv);
@@ -1157,12 +1150,22 @@ static int ath9k_htc_start(struct ieee80211_hw *hw)
ieee80211_wake_queues(hw);
-mutex_unlock:
+ return ret;
+}
+
+static int ath9k_htc_start(struct ieee80211_hw *hw)
+{
+ struct ath9k_htc_priv *priv = hw->priv;
+ int ret = 0;
+
+ mutex_lock(&priv->mutex);
+ ret = ath9k_htc_radio_enable(hw);
mutex_unlock(&priv->mutex);
+
return ret;
}
-static void ath9k_htc_stop(struct ieee80211_hw *hw)
+static void ath9k_htc_radio_disable(struct ieee80211_hw *hw)
{
struct ath9k_htc_priv *priv = hw->priv;
struct ath_hw *ah = priv->ah;
@@ -1170,11 +1173,8 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
int ret = 0;
u8 cmd_rsp;
- mutex_lock(&priv->mutex);
-
if (priv->op_flags & OP_INVALID) {
ath_print(common, ATH_DBG_ANY, "Device not present\n");
- mutex_unlock(&priv->mutex);
return;
}
@@ -1209,11 +1209,20 @@ static void ath9k_htc_stop(struct ieee80211_hw *hw)
}
priv->op_flags |= OP_INVALID;
- mutex_unlock(&priv->mutex);
ath_print(common, ATH_DBG_CONFIG, "Driver halt\n");
}
+static void ath9k_htc_stop(struct ieee80211_hw *hw)
+{
+ struct ath9k_htc_priv *priv = hw->priv;
+
+ mutex_lock(&priv->mutex);
+ ath9k_htc_radio_disable(hw);
+ mutex_unlock(&priv->mutex);
+}
+
+
static int ath9k_htc_add_interface(struct ieee80211_hw *hw,
struct ieee80211_vif *vif)
{
@@ -1327,6 +1336,23 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
mutex_lock(&priv->mutex);
+ if (changed & IEEE80211_CONF_CHANGE_IDLE) {
+ bool enable_radio = false;
+ bool idle = !!(conf->flags & IEEE80211_CONF_IDLE);
+
+ if (!idle && priv->ps_idle)
+ enable_radio = true;
+
+ priv->ps_idle = idle;
+
+ if (enable_radio) {
+ ath9k_htc_setpower(priv, ATH9K_PM_AWAKE);
+ ath9k_htc_radio_enable(hw);
+ ath_print(common, ATH_DBG_CONFIG,
+ "not-idle: enabling radio\n");
+ }
+ }
+
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
struct ieee80211_channel *curchan = hw->conf.channel;
int pos = curchan->hw_value;
@@ -1370,6 +1396,13 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
}
}
+ if (priv->ps_idle) {
+ ath_print(common, ATH_DBG_CONFIG,
+ "idle: disabling radio\n");
+ ath9k_htc_radio_disable(hw);
+ }
+
+
mutex_unlock(&priv->mutex);
return 0;
--
1.7.0.5
^ permalink raw reply related
* Re: [PATCH] rt2x00: rt2800lib: Fix rx path on SoC devices
From: Helmut Schaa @ 2010-04-27 6:28 UTC (permalink / raw)
To: Gertjan van Wingerde; +Cc: John Linville, Ivo van Doorn, linux-wireless
In-Reply-To: <4BD609C9.1080005@gmail.com>
Am Montag 26 April 2010 schrieb Gertjan van Wingerde:
> On 04/26/10 13:48, Helmut Schaa wrote:
> > Restore the rfcsr initialization for RT305x SoC devices which was removed
> > by "rt2x00: Finish rt3070 support in rt2800 register initialization.".
> >
> > This fixes the rx path on SoC devices.
> >
> > Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> > ---
> > drivers/net/wireless/rt2x00/rt2800lib.c | 34 ++++++++++++++++++++++++++++++-
> > 1 files changed, 33 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
> > index 2648f31..1358d9a 100644
> > --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> > +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> > @@ -1703,7 +1703,8 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > if (!rt2x00_rt(rt2x00dev, RT3070) &&
> > !rt2x00_rt(rt2x00dev, RT3071) &&
> > !rt2x00_rt(rt2x00dev, RT3090) &&
> > - !rt2x00_rt(rt2x00dev, RT3390))
> > + !rt2x00_rt(rt2x00dev, RT3390) &&
> > + !(rt2x00_is_soc(rt2x00dev) && rt2x00_rt(rt2x00dev, RT2872)))
> > return 0;
>
> As indicated in the separate email, we should also check for the presence of an RF3020, RF3021
> or RF3022 RF chipset for the RT2872 case (maybe this should be more generic, because I'm sure
> this will also hold for the other RT chipsets).
Ok, do you mean we should only check for rfXXX instead of checking for SoC
and rt2872? Or should we check for SoC + rfXXX?
> > /*
> > @@ -1771,6 +1772,37 @@ int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
> > rt2800_rfcsr_write(rt2x00dev, 29, 0x8f);
> > rt2800_rfcsr_write(rt2x00dev, 30, 0x20);
> > rt2800_rfcsr_write(rt2x00dev, 31, 0x0f);
> > + } else if (rt2x00_rt(rt2x00dev, RT2872)) {
> > + rt2800_rfcsr_write(rt2x00dev, 0, 0x50);
> > + rt2800_rfcsr_write(rt2x00dev, 1, 0x01);
> > + rt2800_rfcsr_write(rt2x00dev, 2, 0xf7);
> > + rt2800_rfcsr_write(rt2x00dev, 3, 0x75);
> > + rt2800_rfcsr_write(rt2x00dev, 4, 0x40);
> > + rt2800_rfcsr_write(rt2x00dev, 5, 0x03);
> > + rt2800_rfcsr_write(rt2x00dev, 6, 0x02);
> > + rt2800_rfcsr_write(rt2x00dev, 7, 0x50);
> > + rt2800_rfcsr_write(rt2x00dev, 8, 0x39);
> > + rt2800_rfcsr_write(rt2x00dev, 9, 0x0f);
> > + rt2800_rfcsr_write(rt2x00dev, 10, 0x60);
> > + rt2800_rfcsr_write(rt2x00dev, 11, 0x21);
> > + rt2800_rfcsr_write(rt2x00dev, 12, 0x75);
> > + rt2800_rfcsr_write(rt2x00dev, 13, 0x75);
> > + rt2800_rfcsr_write(rt2x00dev, 14, 0x90);
> > + rt2800_rfcsr_write(rt2x00dev, 15, 0x58);
> > + rt2800_rfcsr_write(rt2x00dev, 16, 0xb3);
> > + rt2800_rfcsr_write(rt2x00dev, 17, 0x92);
> > + rt2800_rfcsr_write(rt2x00dev, 18, 0x2c);
> > + rt2800_rfcsr_write(rt2x00dev, 19, 0x02);
> > + rt2800_rfcsr_write(rt2x00dev, 20, 0xba);
> > + rt2800_rfcsr_write(rt2x00dev, 21, 0xdb);
> > + rt2800_rfcsr_write(rt2x00dev, 22, 0x00);
> > + rt2800_rfcsr_write(rt2x00dev, 23, 0x31);
> > + rt2800_rfcsr_write(rt2x00dev, 24, 0x08);
> > + rt2800_rfcsr_write(rt2x00dev, 25, 0x01);
> > + rt2800_rfcsr_write(rt2x00dev, 26, 0x25);
> > + rt2800_rfcsr_write(rt2x00dev, 27, 0x23);
> > + rt2800_rfcsr_write(rt2x00dev, 28, 0x13);
> > + rt2800_rfcsr_write(rt2x00dev, 29, 0x83);
> > }
> >
> > if (rt2x00_rt_rev_lt(rt2x00dev, RT3070, REV_RT3070F)) {
>
> Here we need 2 additional rfcsr_writes, for RF CSR 30 and RF CSR 31, both set to value 0x00.
> Also, we can add an "return 0" at the end of the sequence, as nothing more needs to be done for RT2872.
Ok, thanks for looking that up.
Helmut
^ permalink raw reply
* Re: [PATCH 1/2] cfg80211: add ap isolation support
From: Johannes Berg @ 2010-04-27 6:22 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Felix Fietkau, John W. Linville, Jouni Malinen, linux-wireless
In-Reply-To: <x2i43e72e891004261853p751a5d5bt9cbb99846b2eb1fb@mail.gmail.com>
On Mon, 2010-04-26 at 18:53 -0700, Luis R. Rodriguez wrote:
> >>>>> Yes, if you have an AP with lots of users that aren't expected to
> >>>>> communicate with each other (e.g. only for internet access), it can save
> >>>>> a lot of airtime by not forwarding every broadcast message emitted from
> >>>>> any station.
> >>>>> I'm sure there are a more situations where this can be useful.
> So the other way for an AP to forward traffic from STAs on the BSS to
> others is to transmit broadcast frames and the purpose of this patch
> is to disable that? If so can the description of the command be a
> little more descriptive about this? Perhaps annotating that other
> communication would not be done unless DLS links are created ?
The broadcast thing is a red herring. This applies also to unicast
frames sent between stations.
Basically what this patch does is restrict the network segment to each
station. You can send and receive multicast frames to/from the wired
network, but you would typically attach an AP like this to its own
network segment. And you can send/receive unicast frames, but not to
other stations on the AP. Or think of it as restricting the broadcast
domain. Or, another more expensive way to implement this would be to put
each station into its own VLAN (which should actually be feasible in
practice too).
johannes
^ permalink raw reply
* Re: [PATCH] ath9k: remove usage of deprecated noise value
From: Benoit PAPILLAULT @ 2010-04-27 6:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless
In-Reply-To: <1272312561-22648-1-git-send-email-linville@tuxdriver.com>
John W. Linville a écrit :
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
> ---
> drivers/net/wireless/ath/ath9k/common.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/common.c b/drivers/net/wireless/ath/ath9k/common.c
> index 09effde..b4424a6 100644
> --- a/drivers/net/wireless/ath/ath9k/common.c
> +++ b/drivers/net/wireless/ath/ath9k/common.c
> @@ -212,7 +212,6 @@ int ath9k_cmn_rx_skb_preprocess(struct ath_common *common,
> rx_status->mactime = ath9k_hw_extend_tsf(ah, rx_stats->rs_tstamp);
> rx_status->band = hw->conf.channel->band;
> rx_status->freq = hw->conf.channel->center_freq;
> - rx_status->noise = common->ani.noise_floor;
> rx_status->signal = ATH_DEFAULT_NOISE_FLOOR + rx_stats->rs_rssi;
> rx_status->antenna = rx_stats->rs_antenna;
> rx_status->flag |= RX_FLAG_TSFT;
>
Hey, I'm still using this value here in my setup (I've done some work on
noise floor calibration and can submit a patch that report noise &
signal values that makes more sense to me). I mentioned in an earlier
patch that I was using the {last_signal, last_noise} debugfs file as
well (in February, 17th).
Before removing noise reporting and all related code, wouln't it be
better to have a replacement API? I was told that noise reporting is
buggy for most chipset, but that's a bug in each driver, not in mac80211
then. Such bugs could be fixed by using a default value of -101dBm
(thermal noise at room temperature over a 20 MHz channel) if they are
unable to determine a correct value.
Moreover, it is very convenient to have the {last_signal, last_noise}
sampled at the same time and be in the same location. Likewise for the
radiotap header, it is very easy to plot noise value over time if it is
stored on a per packet basis. Of course, I know noise is a global
property of the channel and not DEFINED on a per packet basis, but once
you know that, it's still useful to have it REPORTED on a per packet basis.
So far, the solution for me was to revert the single patch for making
the noise field deprecated, but I'm not going to revert each & every
patches related to noise. After all, isn't it the purpose of peer review?
Regards,
Benoit
^ 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