* Re: Further improvements to the software scan implementation
From: Johannes Berg @ 2009-07-16 9:46 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Luis Rodriguez
In-Reply-To: <200907161138.58874.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 869 bytes --]
On Thu, 2009-07-16 at 11:38 +0200, Helmut Schaa wrote:
> Hi,
>
> as already discussed with Johannes we can further optimize the scan
> implementation by allowing (on an active channel) to send probes as
> soon as any other frame is received (and updated the NAV) instead of
> ever waiting 30ms.
There's even two ways of implementing this:
1) the easy way -- just check for received frames in mac80211
2) the good way -- ask the driver to notify us of _any_ received frames
or poll the driver or something like that
1) is clearly very easy, but if it's seeing e.g. a control frame or a
frame for a different BSS then the device might not pass it up.
But to be honest, I wouldn't worry about 2) and let Jouni implement it
if he cares :) And if we want to make this improvement, 1) is good for
all hardware anyway.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Helmut Schaa @ 2009-07-16 9:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247736318.24433.10.camel@johannes.local>
Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> On Thu, 2009-07-16 at 11:09 +0200, Helmut Schaa wrote:
>
> Looks nice! Some nitpicks ;)
Great, thanks ;)
> > Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.>
>
> Missing "com" :)
Oops.
> > +/**
> > + * enum mac80211_scan_flag - currently active scan mode
> > + *
> > + * @SCAN_SW_SCANNING: We're off our operating channel for scanning
> > + * @SCAN_HW_SCANNING: The hardware is scanning for us, we have no way to
> > + * determine if we are on the operating channel or not
> > + * @SCAN_BG_SCANNING: We're currently in the process of scanning but may
> > + * as well be on the operating channel
> > + */
> > enum mac80211_scan_flag {
> > SCAN_SW_SCANNING = 1,"SCAN_ENTER_OPER_CHANNEL"
> > SCAN_HW_SCANNING = 2,
> > + SCAN_BG_SCANNING = 4,
>
> There's some random stuff in there that doesn't belong.
Right, that does not belong there.
> Also I would
> prefer you used BIT(0) etc. or maybe __test_bit().
Fine with me.
> > --- a/net/mac80211/iface.c
> > +++ b/net/mac80211/iface.c
> > @@ -513,7 +513,7 @@ static int ieee80211_stop(struct net_device *dev)
> > * the scan_sdata is NULL already don't send out a
> > * scan event to userspace -- the scan is incomplete.
> > */
> > - if (local->scanning & SCAN_SW_SCANNING)
> > + if (local->scanning & SCAN_BG_SCANNING)
> > ieee80211_scan_completed(&local->hw, true);
> > }
>
> That doesn't seem correct -- it should be kept I think.
See below.
> > diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> > index a1b4887..a87522f 100644
> > --- a/net/mac80211/main.c
> > +++ b/net/mac80211/main.c
> > @@ -198,7 +198,7 @@ void ieee80211_bss_info_change_notify(struct ieee80211_sub_if_data *sdata,
> > }
> >
> > if (changed & BSS_CHANGED_BEACON_ENABLED) {
> > - if (local->scanning & SCAN_SW_SCANNING) {
> > + if (local->scanning & SCAN_BG_SCANNING) {
> > sdata->vif.bss_conf.enable_beacon = false;
>
> That too.
>
> > diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
> > index 3df8a6e..24739ab 100644
> > --- a/net/mac80211/rx.c
> > +++ b/net/mac80211/rx.c
> > @@ -2136,7 +2136,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
> > return;
> > }
> >
> > - if (unlikely(local->scanning))
> > + if (unlikely((local->scanning & SCAN_HW_SCANNING) || (local->scanning & SCAN_SW_SCANNING)))
>
> I would prefer
> if (unlikely(local->scanning & (SCAN_HW_SCANNING | SCAN_SW_SCANNING)))
Ack.
> > rx.flags |= IEEE80211_RX_IN_SCAN;
> >
> > ieee80211_parse_qos(&rx);
> > diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
> > index b4cc556..8f33fb5 100644
> > --- a/net/mac80211/scan.c
> > +++ b/net/mac80211/scan.c
> > @@ -282,7 +282,7 @@ void ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted)
> > cfg80211_scan_done(local->scan_req, aborted);
> > local->scan_req = NULL;
> >
> > - was_hw_scan = local->scanning & SCAN_HW_SCANNING;
> > + was_hw_scan = !!(local->scanning & SCAN_HW_SCANNING);
>
> Should that be in the other patch?
Yep.
> > @@ -435,7 +434,7 @@ static int __ieee80211_start_scan(struct ieee80211_sub_if_data *sdata,
> > if (local->ops->hw_scan)
> > local->scanning |= SCAN_HW_SCANNING;
> > else
> > - local->scanning |= SCAN_SW_SCANNING;
> > + local->scanning |= SCAN_BG_SCANNING;
>
> Ok now I'm confused. Did you really intend to replace all these?
>
> Based on your initial description I thought it was going to be
> scanning == SW_SCANNING
> or
> scanning == SW_SCANNING | BG_SCANNING
It's exactly the other way round :)
It is either BG_SCANNING or SW_SCANNING | BG_SCANNING.
I already thought that this might cause confusion but I think
BG_SCANNING better reflects that we are currently running a scan
(independant of the current scan state) whereas SW_SCANNING better
reflects that we are on a different channel for scanning.
Maybe I should use other terms. Ideas?
> > + if (local->scan_channel) {
> > + /*
> > + * we're currently scanning a different channel, let's
> > + * switch back to the operating channel now if at least
> > + * one interface is associated. Otherwise just scan the
> > + * next channel
> > + */
> > + if (associated)
> > + local->scan_state = SCAN_ENTER_OPER_CHANNEL;
> > + else
> > + local->scan_state = SCAN_SET_CHANNEL;
>
> :)
>
> > + /* advance to the next channel to be scanned */
> > + *next_delay = HZ / 10;
> > + local->scan_state = SCAN_SET_CHANNEL;
>
> Maybe we should rename scan_state to next_scan_state.
Makes sense.
> > + if (ieee80211_hw_config(local,
> > + IEEE80211_CONF_CHANGE_CHANNEL))
>
> That looks weird. I don't think you really need to care about the return
> value anyway, now that we have rfkill integrated it shouldn't ever be
> nonzero (and if it is, while rfkill is being activated, it doesn't
> really matter since we're taking down interfaces)
Ok, will change that.
> > + /*
> > + * notify the AP about us being back and restart all STA interfaces
> > + */
> > + mutex_lock(&local->iflist_mtx);
> > + list_for_each_entry(sdata, &local->interfaces, list) {
> > + if (!netif_running(sdata->dev))
> > + continue;
> > +
> > + /* Tell AP we're back */
> > + if (sdata->vif.type == NL80211_IFTYPE_STATION) {
> > + if (sdata->u.mgd.associated) {
> > + ieee80211_scan_ps_disable(sdata);
> > + }
>
> Could drop a set of {} here.
Right.
> > @@ -657,7 +760,7 @@ void ieee80211_scan_cancel(struct ieee80211_local *local)
> > * queued -- mostly at suspend under RTNL.
> > */
> > mutex_lock(&local->scan_mtx);
> > - swscan = !!(local->scanning & SCAN_SW_SCANNING);
> > + swscan = !!(local->scanning & SCAN_BG_SCANNING);
>
> and another one -- please explain?
See above.
> Anyway looks pretty good to me! How does it fare during ping -f or
> something?
I compared it to the hw_scan implementation of iwlwifi. We loose a few
more frames (I guess due to not flushing the queues before channel switch)
but it's not really much, it was <1% for ping -f).
I didn't do much performance testing, just a single wget and the performance
dropped to about 50%. I still have to run some iperf tests (both RX and TX) to
see how it behaves.
Helmut
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Joel Roth @ 2009-07-16 10:07 UTC (permalink / raw)
To: Johannes Berg; +Cc: Joel Roth, Bob Copeland, linux-wireless
In-Reply-To: <1247734019.19467.0.camel@johannes.local>
On Thu, Jul 16, 2009 at 10:46:59AM +0200, Johannes Berg wrote:
> On Wed, 2009-07-15 at 20:14 -1000, Joel Roth wrote:
>
> > # iwlist wlan0 ap
> >
> > wlan0 Interface doesn't have a list of Peers/Access-Points
>
> # iwlist wlan0 scan
>
> should have worked, but I'm glad you're making good use of iw :)
Hmm. It does work _now_, provided the interface is UP.
That may be thanks to having a recent kernel with the latest
compat-wireless drivers.
I was also misled by assuming iwlist's 'ap' option would
provide useful information.
To summarize what I now know, the steps to follow for basic
wireless connectivity to an unencrypted network would be:
1. kernel and driver setup - use compat-wireless
2. set wireless interface to UP
ifconfig <interface> up
3. find available networks using
iw dev <interface> scan
or
iwlist <interface> scan
4. connect to a network using
iw dev <interface> connect <SSID>
5. acquire IP address, typically by
dhclient <interface>
Regards,
Joel
> johannes
--
Joel Roth
^ permalink raw reply
* Re: ath5k and Atheros AR242x - No scan results
From: Johannes Berg @ 2009-07-16 10:13 UTC (permalink / raw)
To: Joel Roth; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <20090716100743.GC3867@sprite>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On Thu, 2009-07-16 at 00:07 -1000, Joel Roth wrote:
> Hmm. It does work _now_, provided the interface is UP.
Yes, it has to be UP.
> That may be thanks to having a recent kernel with the latest
> compat-wireless drivers.
>
> I was also misled by assuming iwlist's 'ap' option would
> provide useful information.
It hasn't for many years, really. Oh well, not much we can do about it.
> To summarize what I now know, the steps to follow for basic
> wireless connectivity to an unencrypted network would be:
>
> 1. kernel and driver setup - use compat-wireless
>
> 2. set wireless interface to UP
>
> ifconfig <interface> up
>
> 3. find available networks using
>
> iw dev <interface> scan
> or
> iwlist <interface> scan
This isn't strictly necessary if you know the SSID already.
> 4. connect to a network using
>
> iw dev <interface> connect <SSID>
The old way of doing this would be
iwconfig wlan0 essid <SSID>
But as long as you don't need ancient hardware, you're probably better
off using iw. You can also use
iw dev <interface> connect -w <SSID>
if you run a current git snapshot, and it will wait for the connection
to be established or fail and print the status.
Oh and if you're just doing this on the command line you can do
iw <interface> connect <SSID>
(i.e. leave out the "dev"), but please don't script it that way :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Johannes Berg @ 2009-07-16 10:16 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <200907161150.54237.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1714 bytes --]
On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote:
> > Based on your initial description I thought it was going to be
> > scanning == SW_SCANNING
> > or
> > scanning == SW_SCANNING | BG_SCANNING
>
> It's exactly the other way round :)
>
> It is either BG_SCANNING or SW_SCANNING | BG_SCANNING.
>
> I already thought that this might cause confusion but I think
> BG_SCANNING better reflects that we are currently running a scan
> (independant of the current scan state) whereas SW_SCANNING better
> reflects that we are on a different channel for scanning.
>
> Maybe I should use other terms. Ideas?
Ah, ok. Since your patch 4/5 changes sw_scanning to SW_SCANNING, I think
at least change it to BG_SCANNING there already. OTOH, I think people
are used to sw_scanning so it would be better to keep it. Maybe do
SW_SCANNING
and
SW_SCANNING | OFF_CHANNEL
or maybe
SW_SCANNING | PROBING
or something like that?
> > Anyway looks pretty good to me! How does it fare during ping -f or
> > something?
>
> I compared it to the hw_scan implementation of iwlwifi. We loose a few
> more frames (I guess due to not flushing the queues before channel switch)
> but it's not really much, it was <1% for ping -f).
Yeah, we still need to add a queue flush callback for the hardware, but
that can wait some more.
> I didn't do much performance testing, just a single wget and the performance
> dropped to about 50%. I still have to run some iperf tests (both RX and TX) to
> see how it behaves.
I'd be more interested in the rtt stats that ping -f prints after you
abort it:
rtt min/avg/max/mdev = 0.021/0.028/1.726/0.051 ms
(this was on 127.0.0.1)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] wl12xx: loop off by one.
From: Roel Kluin @ 2009-07-16 10:36 UTC (permalink / raw)
To: Roel Kluin; +Cc: kalle.valo, linux-wireless, Andrew Morton
In-Reply-To: <4A524E91.9040400@gmail.com>
With `while (loop++ < INIT_LOOP)' `loop' becomes INIT_LOOP + 1 after
the loop.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
>> with `while (loop++ < INIT_LOOP)' `loop' reaches -1 after the loop.
>
> Sorry, my brains are on vacation mode right now and I can't understand
> how loop can reach -1.
The confusion is my fault. The changelog should have as above. The patch
is correct though.
> Here's the code:
> loop = 0;
> while (loop++ < INIT_LOOP) {
> ...
> }
>
> if (loop >= INIT_LOOP) {
> wl1251_error("timeout waiting for the hardware to "
> "complete initialization");
> return -EIO;
> }
In the last iteration `loop' is `INIT_LOOP -1', the test occurs and then
the increment to `INIT_LOOP'. If just then the break occurs:
`if (interrupt & wl->chip.intr_init_complete)' evaluates to true, then
we error out, although there was no timeout. This could be very unlikely
to occur.
> Also the patch won't apply to wireless-testing because main.c is renamed
> to wl1251_main.c.
Ok, this is against your tree
diff --git a/drivers/net/wireless/wl12xx/wl1251_boot.c b/drivers/net/wireless/wl12xx/wl1251_boot.c
index d8a155d..b2ae71c 100644
--- a/drivers/net/wireless/wl12xx/wl1251_boot.c
+++ b/drivers/net/wireless/wl12xx/wl1251_boot.c
@@ -247,7 +247,7 @@ int wl1251_boot_run_firmware(struct wl1251 *wl)
}
}
- if (loop >= INIT_LOOP) {
+ if (loop > INIT_LOOP) {
wl1251_error("timeout waiting for the hardware to "
"complete initialization");
return -EIO;
^ permalink raw reply related
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Helmut Schaa @ 2009-07-16 10:40 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1247739394.29762.9.camel@johannes.local>
Am Donnerstag, 16. Juli 2009 schrieb Johannes Berg:
> On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote:
> > Maybe I should use other terms. Ideas?
>
> Ah, ok. Since your patch 4/5 changes sw_scanning to SW_SCANNING, I think
> at least change it to BG_SCANNING there already. OTOH, I think people
> are used to sw_scanning so it would be better to keep it. Maybe do
> SW_SCANNING
> and
> SW_SCANNING | OFF_CHANNEL
>
> or maybe
> SW_SCANNING | PROBING
> or something like that?
Yes, something like this sounds better and does not cause so much confusion.
> > > Anyway looks pretty good to me! How does it fare during ping -f or
> > > something?
> >
> > I compared it to the hw_scan implementation of iwlwifi. We loose a few
> > more frames (I guess due to not flushing the queues before channel switch)
> > but it's not really much, it was <1% for ping -f).
>
> Yeah, we still need to add a queue flush callback for the hardware, but
> that can wait some more.
Right, that can wait :)
> > I didn't do much performance testing, just a single wget and the performance
> > dropped to about 50%. I still have to run some iperf tests (both RX and TX) to
> > see how it behaves.
>
> I'd be more interested in the rtt stats that ping -f prints after you
> abort it:
>
> rtt min/avg/max/mdev = 0.021/0.028/1.726/0.051 ms
I don't have any stats here anymore but if I remember correctly the max rtt I
got was around 250ms. Will try that again when I'm back in the evening.
Helmut
^ permalink raw reply
* prism54 firmware cannot initialize pcmcia card
From: Dave @ 2009-07-16 12:09 UTC (permalink / raw)
To: linux-wireless
First, some generic info about the laptop I'm using
gentoo kernel-2.6.29
prism54-firmware-2.13.2 (listed as working with in-kernel >=2.6.29 driver)
yenta_cardbus driver
Everything seems to work. The driver is loaded, the card is recognized, the
driver requests the correct firmware name, then the firmware seems to have
issues initializing the card. I have posted the relevant entries in dmesg to
http://pastebin.com/f7514c9c0
Any help is appreciated. Thanks!
Regards,
Dave
^ permalink raw reply
* RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Zhu, Yi @ 2009-07-16 12:23 UTC (permalink / raw)
To: Zhu, Yi, Winkler, Tomas, drzeus-list@drzeus.cx,
netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: Winkler, Tomas
In-Reply-To: <AFAB8585072C7E48BC5C6F9C87F9B79703BA8388BB@pdsmsx502.ccr.corp.intel.com>
> Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
BTW, subject should be "iwmc3200".
Thanks,
-yi
^ permalink raw reply
* Re: [PATCH] wl12xx: loop off by one.
From: Kalle Valo @ 2009-07-16 13:44 UTC (permalink / raw)
To: Roel Kluin; +Cc: linux-wireless, Andrew Morton, John W. Linville
In-Reply-To: <4A5F02C9.50505@gmail.com>
Roel Kluin <roel.kluin@gmail.com> writes:
> With `while (loop++ < INIT_LOOP)' `loop' becomes INIT_LOOP + 1 after
> the loop.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
> ---
>>> with `while (loop++ < INIT_LOOP)' `loop' reaches -1 after the loop.
>>
>> Sorry, my brains are on vacation mode right now and I can't understand
>> how loop can reach -1.
>
> The confusion is my fault. The changelog should have as above. The patch
> is correct though.
Ah. Thanks for explaining this to me, I understand this now. Good catch,
thanks for fixing this.
Acked-by: Kalle Valo <kalle.valo@nokia.com>
John, please take this patch. Please holler if we need to resend it.
--
Kalle Valo
^ permalink raw reply
* Re: Further improvements to the software scan implementation
From: Johannes Berg @ 2009-07-16 14:15 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Luis Rodriguez
In-Reply-To: <200907161138.58874.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]
On Thu, 2009-07-16 at 11:38 +0200, Helmut Schaa wrote:
> Another optimization I thought of while reading [1] would be to take the
> same approach as Intel in their ucode. If a frame is received while
> scanning a passive channel switch to active scan mode and send out probes.
> That should allow us to shorten the time needed to stay on that channel.
> Luis, do you think this is ok in regard to regulatory restrictions?
One problem I could see with that is the TX power to use.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC/RFT 5/5] mac80211: implement basic background scanning
From: Johannes Berg @ 2009-07-16 14:20 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless
In-Reply-To: <200907161150.54237.helmut.schaa@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 818 bytes --]
On Thu, 2009-07-16 at 11:50 +0200, Helmut Schaa wrote:
> > > + if (ieee80211_hw_config(local,
> > > + IEEE80211_CONF_CHANGE_CHANNEL))
> >
> > That looks weird. I don't think you really need to care about the return
> > value anyway, now that we have rfkill integrated it shouldn't ever be
> > nonzero (and if it is, while rfkill is being activated, it doesn't
> > really matter since we're taking down interfaces)
>
> Ok, will change that.
Oh and you can also pass 0 as the change flags, the routine will detect
scan_channel and set the flag accordingly. Doesn't matter much, except
in the case where you're not actually changing the channel because it's
the same as the operational channel (which would be easy to optimise
away by just sending probes on the current oper_channel)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Patch/merge delays -- apologies!
From: John W. Linville @ 2009-07-16 14:22 UTC (permalink / raw)
To: linux-wireless
Greetings,
As some of you may know, I've been in Montreal this week for Linux
Symposium. The network both here and the at the hotel has been
marginal, and events such as this are not conducive to much "real"
work anyway...
Just wanted to let everyone know that I'm still here and I am
getting your patches, it just may be a few more days before I get
back into swing. At least after this I won't be travelling again
for several weeks.
Thanks for your patience!
John
P.S. If there are particular patches that you really need/want to
see merged ASAP, feel free to send me a note about them.
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
¡Viva Honduras Libre!
^ permalink raw reply
* Re: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Tomas Winkler @ 2009-07-16 15:04 UTC (permalink / raw)
To: Zhu, Yi
Cc: drzeus-list@drzeus.cx, netdev@vger.kernel.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <AFAB8585072C7E48BC5C6F9C87F9B79703BA839300@pdsmsx502.ccr.corp.intel.com>
On Thu, Jul 16, 2009 at 3:23 PM, Zhu, Yi <yi.zhu@intel.com> wrote:
>
> > Subject: RE: [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
>
> BTW, subject should be "iwmc3200".
Thanks. I'll address all comments although I'm not sure how to split
the patch since adding SDIO_VENDOR_ID_INTEL to sdio_ids.h it affects
all the drivers anyhow, so I'm suggesting to route it through netdev.
Thanks
Tomas
^ permalink raw reply
* [PATCH 1/1] rt2x00: Fix chipset detection for rt2500usb
From: Andy Whitcroft @ 2009-07-16 15:28 UTC (permalink / raw)
To: Ivo van Doorn, John W. Linville
Cc: Andy Whitcroft, linux-wireless, linux-kernel
The commit below changed the semantics of rt2x00_check_rev so that it no
longer checked the bottom 4 bits of the rev were non-zero. During that
conversion this part of the check was not propogated to the rt2500usb
initialisation.
commit 358623c22c9fd837b3b1b444377037f72553dc9f
Author: Ivo van Doorn <ivdoorn@gmail.com>
Date: Tue May 5 19:46:08 2009 +0200
rt2x00: Simplify rt2x00_check_rev
Without this check rt73 devices are miss recognised as rt2500 devices and
two drivers are loaded. Preventing the device being used. Reinstate this
check.
Signed-off-by: Andy Whitcroft <apw@canonical.com>
---
drivers/net/wireless/rt2x00/rt2500usb.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 66daf68..ce75426 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1550,7 +1550,9 @@ static int rt2500usb_init_eeprom(struct rt2x00_dev *rt2x00dev)
rt2500usb_register_read(rt2x00dev, MAC_CSR0, ®);
rt2x00_set_chip(rt2x00dev, RT2570, value, reg);
- if (!rt2x00_check_rev(&rt2x00dev->chip, 0x000ffff0, 0)) {
+ if (!rt2x00_check_rev(&rt2x00dev->chip, 0x000ffff0, 0) ||
+ rt2x00_check_rev(&rt2x00dev->chip, 0x0000000f, 0)) {
+
ERROR(rt2x00dev, "Invalid RT chipset detected.\n");
return -ENODEV;
}
--
1.6.3.rc3.199.g24398
^ permalink raw reply related
* Re: Further improvements to the software scan implementation
From: Luis R. Rodriguez @ 2009-07-16 16:09 UTC (permalink / raw)
To: Helmut Schaa, David Quan, Michael Green; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <200907161138.58874.helmut.schaa@gmail.com>
Adding David Quan and Michael Green, my reply in-line below.
On Thu, Jul 16, 2009 at 2:38 AM, Helmut
Schaa<helmut.schaa@googlemail.com> wrote:
> Hi,
>
> as already discussed with Johannes we can further optimize the scan
> implementation by allowing (on an active channel) to send probes as
> soon as any other frame is received (and updated the NAV) instead of
> ever waiting 30ms.
>
> Another optimization I thought of while reading [1] would be to take the
> same approach as Intel in their ucode. If a frame is received while
> scanning a passive channel switch to active scan mode and send out probes.
> That should allow us to shorten the time needed to stay on that channel.
> Luis, do you think this is ok in regard to regulatory restrictions?
Good question. We already enable active scanning if a beacon is
received from an AP and are world roaming. We do this in mac80211
through a beacon regulatory hint to the wireless core --
regulatory_hint_found_beacon(). The assumption of the beacon
regulatory hint is that APs *must* be compliant, and some cards world
roam therefore only allowing passive scan on some channels, when you
receive a beacon from an AP on a non-DFS channel or channel 12-14 it
is safe to assume you can actively scan and beacon on that same
channel. Reason for the passive scan flag to exist is for a way to
enable some cards to world roam on some channels. Because all APs must
beacon and since we will lift this passive scan flag during an initial
scan I am inclined to believe we shouldn't bother with processing
other 802.11 frames. So in summary I'd suggest to not do this because:
1) We already have the beacons during an initial scan
2) We'd have to figure out a way to ensure the frame was indeed from an AP
Luis
> Thanks,
> Helmut
>
> [1] http://sourceforge.net/mailarchive/forum.php?thread_name=200907061428.55840.jung%40ecos.de&forum_name=ipw3945-devel
>
^ permalink raw reply
* Re: Unable to load iwlagn module: Failed to register hw (error -17)
From: Luis R. Rodriguez @ 2009-07-16 16:13 UTC (permalink / raw)
To: John Ranson
Cc: Johannes Berg, reinette chatre, linux-wireless@vger.kernel.org
In-Reply-To: <bcd1ba70907152058m14249f40gf0ebff1620e56674@mail.gmail.com>
On Wed, Jul 15, 2009 at 8:58 PM, John Ranson<ranson@analager.net> wrote:
> The release is master-2009-07-08-3-g3615cdf
>
> /sys/class/ieee80211/ is empty
>
> I'm running Gentoo on an Lenovo R61. I don't think that there is
> anything too special about my configuration.
>
> Is there any more information that I can provide that will help debug?
You can try wireless-testing directly:
http://wireless.kernel.org/en/developers/Documentation/git-guide
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Luis R. Rodriguez @ 2009-07-16 16:14 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wfljmpm4xl.fsf@calligramme.charmers>
On Thu, Jul 16, 2009 at 1:02 AM, Jon
Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>
> A machine I want to set up as an AP has only PCI express slots free...
I'd recommend ath9k.
http://wireless.kernel.org/en/users/Drivers/ath9k
Luis
^ permalink raw reply
* Re: Build instructions for cross-compilation environment
From: Luis R. Rodriguez @ 2009-07-16 16:19 UTC (permalink / raw)
To: Philip A. Prindeville; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <4A5E5AD6.5090509@redfish-solutions.com>
On Wed, Jul 15, 2009 at 3:40 PM, Philip A.
Prindeville<philipp_subx@redfish-solutions.com> wrote:
Patch applied, thanks.
Luis
^ permalink raw reply
* Re: [RFC/RFT 4/5] mac80211: Replace {sw,hw}_scanning variables with a bitfield
From: Luis R. Rodriguez @ 2009-07-16 16:30 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless, Johannes Berg
In-Reply-To: <200907161108.57436.helmut.schaa@gmail.com>
On Thu, Jul 16, 2009 at 2:08 AM, Helmut
Schaa<helmut.schaa@googlemail.com> wrote:
> Use a bitfield to store the current scan mode instead of two boolean
> variables {sw,hw}_scanning. This patch does not introduce functional
> changes.
>
> +enum mac80211_scan_flag {
> + SCAN_SW_SCANNING = 1,
> + SCAN_HW_SCANNING = 2,
> +};
> +
But why is that needed? The commit log doesn't state that. We won't
use both at the same time.
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Pavel Roskin @ 2009-07-16 16:36 UTC (permalink / raw)
To: Jon Fairbairn; +Cc: linux-wireless
In-Reply-To: <wfljmpm4xl.fsf@calligramme.charmers>
On Thu, 2009-07-16 at 09:02 +0100, Jon Fairbairn wrote:
> I've seen adverts for the Abit WLP-01, and elsewhere on the net seen
> implications that it's 168c:001c, which isn't listed at
> <http://wireless.kernel.org/en/users/Devices/PCI>, but
> <http://wireless.kernel.org/en/users/Drivers/ath5k> does list it and
> says AP mode not working, but mentions
> <http://madwifi-project.org/wiki/Compatibility/Abit>, which suggest AP
> mode works with madwifi. What's the current status?
ath5k will support the AP mode in Linux 2.6.31. It's already in Linux
2.6.31-rc3.
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [PATCH 2/8] ar9170: Remove unused DECLARE_MAC_BUF
From: Luis R. Rodriguez @ 2009-07-16 16:39 UTC (permalink / raw)
To: Tobias Klauser
Cc: chunkeey, linville, johannes, yi.zhu, linux-wireless, netdev
In-Reply-To: <1247734381-20718-1-git-send-email-klto@zhaw.ch>
On Thu, Jul 16, 2009 at 1:53 AM, Tobias Klauser<klto@zhaw.ch> wrote:
> Is not needed anymore because of the %pM printk conversion specifier.
>
> Signed-off-by: Tobias Klauser <klto@zhaw.ch>
> ---
> drivers/net/wireless/ath/ar9170/main.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
This is already patched by Johannes through the patch titled:
[PATCH] wireless: remove print_mac uses
Please see and resubmit if there is anything missing:
http://marc.info/?l=linux-wireless&m=124767211929848&w=2
Luis
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Jon Fairbairn @ 2009-07-16 16:39 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <43e72e890907160914gdaa700amb2394d8b859d95cb@mail.gmail.com>
"Luis R. Rodriguez" <mcgrof@gmail.com>
writes:
> On Thu, Jul 16, 2009 at 1:02 AM, Jon
> Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>>
>> A machine I want to set up as an AP has only PCI express slots free...
>
> I'd recommend ath9k.
> http://wireless.kernel.org/en/users/Drivers/ath9k
Thanks, but I've seen that page and "products with supported ath9k
cards" points to a page that lists "Laptops with ath9k cards" (I'm
looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
cards". Before I can buy a card, I need to know what it is called in the
shops (on-line or otherwise), not what chipset it has.
I realise this is the manufacturer's fault, but this is a perennial
problem for Linux users who want to buy an new card for something: "OK,
I want something with such-and-such a chipset, but the on-line shops
just don't say what the chipset is.
--
Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2009-01-31)
^ permalink raw reply
* Re: [RFC/RFT 4/5] mac80211: Replace {sw,hw}_scanning variables with a bitfield
From: Johannes Berg @ 2009-07-16 16:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Helmut Schaa, linux-wireless
In-Reply-To: <43e72e890907160930ra5111e1qac13701aed15974e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Thu, 2009-07-16 at 09:30 -0700, Luis R. Rodriguez wrote:
> On Thu, Jul 16, 2009 at 2:08 AM, Helmut
> Schaa<helmut.schaa@googlemail.com> wrote:
> > Use a bitfield to store the current scan mode instead of two boolean
> > variables {sw,hw}_scanning. This patch does not introduce functional
> > changes.
> >
>
> > +enum mac80211_scan_flag {
> > + SCAN_SW_SCANNING = 1,
> > + SCAN_HW_SCANNING = 2,
> > +};
> > +
>
> But why is that needed? The commit log doesn't state that. We won't
> use both at the same time.
You're nitpicking ;)
We currently have two variables, and this just changes them into two
bits instead, so he can extend the sw-scanning case with another bit :)
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: PCI express card that does AP mode? (abit wlp-01?)
From: Luis R. Rodriguez @ 2009-07-16 16:48 UTC (permalink / raw)
To: Jon Fairbairn, Pen Li; +Cc: linux-wireless
In-Reply-To: <wf63dsmvjg.fsf@calligramme.charmers>
On Thu, Jul 16, 2009 at 9:39 AM, Jon
Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
> "Luis R. Rodriguez" <mcgrof@gmail.com>
> writes:
>
>> On Thu, Jul 16, 2009 at 1:02 AM, Jon
>> Fairbairn<jon.fairbairn@cl.cam.ac.uk> wrote:
>>>
>>> A machine I want to set up as an AP has only PCI express slots free...
>>
>> I'd recommend ath9k.
>
>> http://wireless.kernel.org/en/users/Drivers/ath9k
>
> Thanks, but I've seen that page and "products with supported ath9k
> cards" points to a page that lists "Laptops with ath9k cards" (I'm
> looking for PCIe, not mini-PCIe) and "APs with ath9k cards", not "ath9k
> cards". Before I can buy a card, I need to know what it is called in the
> shops (on-line or otherwise), not what chipset it has.
The page lists all products and the manufacturer names of the products.
But yeah, I am not aware of PCI-Express devices sold in the market
with separately. Adding Pen Li in case he is aware.
Pen, this e-mail is in a public mailing list.
Luis
^ 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