* Re: LIBIPW
From: Randy Dunlap @ 2011-01-25 18:06 UTC (permalink / raw)
To: James; +Cc: linux-wireless Mailing List
In-Reply-To: <4D3F0DBC.90302@lockie.ca>
On Tue, January 25, 2011 9:51 am, James wrote:
> /usr/src/compat-wireless-2011-01-24 $ sudo make
> /usr/src/compat-wireless-2011-01-24/config.mk:202: "WARNING:
> CONFIG_CFG80211_WEXT will be deactivated or not working because kernel
> was compiled with CONFIG_WIRELESS_EXT=n. Tools using wext interface like
> iwconfig will not work. To activate it build your kernel e.g. with
> CONFIG_LIBIPW=m."
>
>
> $ sudo grep LIBIPW ../linux/.config
> ''
>
>
> What does LIBIPW depend on?
> I don't even see a choice to turn it on.
It's not a user-visible prompted symbol.
It's selected by IPW2100 or IPW2200.
Also, the help text for LIBIPW (in 2.6.37) says:
This option enables the hardware independent IEEE 802.11
networking stack. This component is deprecated in favor of the
mac80211 component.
--
~Randy
^ permalink raw reply
* Re: [PATCH 6/6] ath: Fix WEP hardware encryption
From: Jouni Malinen @ 2011-01-25 18:32 UTC (permalink / raw)
To: Bruno Randolf; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20110125041549.6944.15800.stgit@localhost6.localdomain6>
On Tue, Jan 25, 2011 at 01:15:49PM +0900, Bruno Randolf wrote:
> In AP mode hardware encryption for WEP was not used on the RX side because
> there was a mismatch in the key indices. The key index in the WLAN header is
> 0-3 while the hardware key cache was configured for key indices >= 4. This is
> ok for transmit but received packets were not decrypted in HW and therefore
> mac80211 had to decrypt them in SW - this can be easily seen by adding some
> debug prints in mac80211/wep.c (around line 296). I have noticed it by watching
> the system CPU load under high traffic.
>
> This patch configures WEP keys into the "standard" key indices 0-4 which were
> reserved for that.
Have you tested this with multiple vifs? I would assume it would break
things pretty completely for all but one vif.. As such, I'm not sure
that it would be that good of an idea to try to improve on something
like WEP which is known to be completely insecure and unusable with
802.11n when it is likely to break use cases that are much more relevant
in modern, post-WEP, time..
If you really think you need this, there would need to be code somewhere
kicking out the default keys from key cache if another vif is added.
When working with the key cache implementation for ath9k, the extra
effort did not seem to be justifiable for WEP and it is now couple of
years from that and surely there is even less justification now.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: wl12xx tree rebased
From: Luciano Coelho @ 2011-01-25 19:33 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1295907199.4430.15.camel@pimenta>
On Mon, 2011-01-24 at 23:13 +0100, Coelho, Luciano wrote:
> Hi,
>
> I have rebased the wl12xx master and wl12xx-next branches with latest
> wireless-testing and wireless-next, respectively, as a base.
>
> Please update your local trees.
We have experienced a few problems with 2.6.38-rc1 at least on the Zoom
boards (failing to boot), so I have created a tag with the old tree,
which is still based on 2.6.37. The tag is wl12xx-2010-01-10. It
doesn't contain all the latest patches for wl12xx, but at least it's
something that is proven to work.
If the problem is not solved soon, I'll add the latest patches on top of
the old tree too, so we can continue developing and testing with Zoom
boards.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] rt2x00: add device id for windy31 usb device
From: Ivo Van Doorn @ 2011-01-25 19:34 UTC (permalink / raw)
To: Greg KH; +Cc: Gertjan van Wingerde, John W. Linville, linux-wireless, users, rf
In-Reply-To: <20110125094229.GA16055@suse.de>
Hi,
> From: Greg Kroah-Hartman <gregkh@suse.de>
>
> This patch adds the device id for the windy31 USB device to the rt73usb
> driver.
>
> Thanks to Ralf Flaxa for reporting this and providing testing and a
> sample device.
>
> Reported-by: Ralf Flaxa <rf@suse.de>
> Tested-by: Ralf Flaxa <rf@suse.de>
> Cc: stable <stable@kernel.org>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Acked-by: Ivo van Doorn <IvDoorn@gmail.com>
> --- a/drivers/net/wireless/rt2x00/rt73usb.c
> +++ b/drivers/net/wireless/rt2x00/rt73usb.c
> @@ -2446,6 +2446,7 @@ static struct usb_device_id rt73usb_device_table[] = {
> { USB_DEVICE(0x04bb, 0x093d), USB_DEVICE_DATA(&rt73usb_ops) },
> { USB_DEVICE(0x148f, 0x2573), USB_DEVICE_DATA(&rt73usb_ops) },
> { USB_DEVICE(0x148f, 0x2671), USB_DEVICE_DATA(&rt73usb_ops) },
> + { USB_DEVICE(0x0812, 0x3101), USB_DEVICE_DATA(&rt73usb_ops) },
> /* Qcom */
> { USB_DEVICE(0x18e8, 0x6196), USB_DEVICE_DATA(&rt73usb_ops) },
> { USB_DEVICE(0x18e8, 0x6229), USB_DEVICE_DATA(&rt73usb_ops) },
>
^ permalink raw reply
* Compat-wireless release for 2011-01-25 is baked
From: Compat-wireless cronjob account @ 2011-01-25 20:03 UTC (permalink / raw)
To: linux-wireless
compat-wireless code metrics
782984 - Total upstream lines of code being pulled
2103 - backport code changes
1843 - backport code additions
260 - backport code deletions
7279 - backport from compat module
9382 - total backport code
1.1982 - % of code consists of backport work
1531 - Crap changes not yet posted
1488 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.1955 - % of crap code
Base tree: linux-next.git
Base tree version: next-20110121
compat-wireless release: compat-wireless-2011-01-06-3-g8db1608-pc
^ permalink raw reply
* Re: wl12xx tree rebased
From: Luciano Coelho @ 2011-01-25 20:49 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <1295984005.30502.146.camel@pimenta>
On Tue, 2011-01-25 at 20:33 +0100, Coelho, Luciano wrote:
> We have experienced a few problems with 2.6.38-rc1 at least on the Zoom
> boards (failing to boot), so I have created a tag with the old tree,
> which is still based on 2.6.37. The tag is wl12xx-2010-01-10. It
> doesn't contain all the latest patches for wl12xx, but at least it's
> something that is proven to work.
>
> If the problem is not solved soon, I'll add the latest patches on top of
> the old tree too, so we can continue developing and testing with Zoom
> boards.
Due to an incredible demand (well, at least one person asked for
it! :P), I have created a new tag that is the same as wl12xx-2010-01-10
but with all the latest patches on top: wl12xx-2010-01-10-2
--
Cheers,
Luca.
^ permalink raw reply
* ?File list?
From: Brzezowski, Karen @ 2011-01-25 21:26 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org; +Cc: Brzezowski, Karen
Is there any way to easily figure out what files have been added/modified to the Linux kernel/drivers
to implement the wl1271 ?
I know there is a directory ..net/wireless/wl12xx ....
but I'm sure there are other files that were modified/added to maybe arch/arm, etc?
I know you haven't heard from me lately... :-)
I am "porting" wl1271 for i.MX233, on Linux 2.6.35...but wonder if I should get the latest/greatest
of all your guys' hard work on the wl1271...
Any ideas/suggestions?
Thanks,
Karen
^ permalink raw reply
* Re: [PATCH RESEND 09/11] ath9k: Try all queues when looking for next packet to send.
From: John W. Linville @ 2011-01-25 21:37 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1294643513-18820-10-git-send-email-greearb@candelatech.com>
On Sun, Jan 09, 2011 at 11:11:51PM -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> There can be multiple struct ath_atx_ac entries for each
> txq, so if the first one doesn't have any packets to send
> now, try the rest of them. This should help keep xmit
> going when using multiple stations, especially with AMPDU
> enabled.
>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
This one doesn't seem to apply any more. Can I persuade you to rebase
and resubmit it?
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
* bcm4313/bcrm80211 and debian liquirix
From: Richard Riley @ 2011-01-25 21:48 UTC (permalink / raw)
To: linux-wireless
According to docs I googled up the brcm80211 driver should work with the
bcm4313 wireless device.
I have installed the debian firmware-brcm80211 package but when I
modprobe the bcrm80211 module there is kernel panic, I get the black
screen of death and a dump saying (reading off the
laptop screen)
!(sdu->cloned) failed : file wlc_mac80211.c line 5140
I'm fairly new to all this so any pointers greatfully received. My
kernel is:-
Linux asus1015pem 2.6.37-0.slh.7-aptosid-686 #1 SMP PREEMPT Sun Jan 16
23:16:55 UTC 2011 i686 GNU/Linux
If I can provide more info please let me know and let me know how.
regards
r.
^ permalink raw reply
* Re: [PATCH v2] mac80211: use DECLARE_EVENT_CLASS
From: John W. Linville @ 2011-01-25 21:58 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1295777573.3639.30.camel@jlt3.sipsolutions.net>
On Sun, Jan 23, 2011 at 11:12:53AM +0100, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> For events that include only the local struct as
> their parameter, we can use DECLARE_EVENT_CLASS
> and save quite some binary size across segments
> as well lines of code.
>
> text data bss dec hex filename
> 375745 19296 916 395957 60ab5 mac80211.ko.before
> 367473 17888 916 386277 5e4e5 mac80211.ko.after
> -8272 -1408 0 -9680 -25d0 delta
>
> Some more tracepoints with identical arguments
> could be combined like this but for now this is
> the one that benefits most.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
OK, so what am I doing wrong?
Kernel: arch/x86/boot/bzImage is ready (#11)
Building modules, stage 2.
MODPOST 2218 modules
ERROR: "__tracepoint_drv_return_void" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_api_remain_on_channel_expired" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_get_tsf" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_tx_last_beacon" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_reset_tsf" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_stop" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_sw_scan_start" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_sw_scan_complete" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_api_restart_hw" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_api_ready_on_channel" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_cancel_remain_on_channel" [net/mac80211/mac80211.ko] undefined!
ERROR: "__tracepoint_drv_start" [net/mac80211/mac80211.ko] undefined!
WARNING: modpost: Found 5 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2
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 RESEND 09/11] ath9k: Try all queues when looking for next packet to send.
From: Ben Greear @ 2011-01-25 22:01 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <20110125213710.GD2927@tuxdriver.com>
On 01/25/2011 01:37 PM, John W. Linville wrote:
> On Sun, Jan 09, 2011 at 11:11:51PM -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> There can be multiple struct ath_atx_ac entries for each
>> txq, so if the first one doesn't have any packets to send
>> now, try the rest of them. This should help keep xmit
>> going when using multiple stations, especially with AMPDU
>> enabled.
>>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>
> This one doesn't seem to apply any more. Can I persuade you to rebase
> and resubmit it?
I think this is already taken care of, or at least the important
parts.
Felix did some initial work in this area, and then I
followed on with this one:
ath9k: Try more than one queue when scheduling new aggregate.
The only ath9k patches I have in my queue that are not upstream
are:
(From Louis Rodriguez)
ath9k: warn when we get a ATH9K_INT_TIM_TIMER and are idle
and my:
ath9k: Implement rx copy-break.
Which appears DOA as folks seem to like paged-skbs instead.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* RE: bcm4313/bcrm80211 and debian liquirix
From: Brett Rudley @ 2011-01-25 22:07 UTC (permalink / raw)
To: Richard Riley, linux-wireless@vger.kernel.org
In-Reply-To: <vnbp34slhy.fsf@news.eternal-september.org>
Yes it should. This issue recently appeared and I believe a patch has already been submitted.
The fix is to simply delete that offending line. (It was a bogus check in the first place).
Thanks
Brett
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Richard Riley
> Sent: Tuesday, January 25, 2011 1:48 PM
> To: linux-wireless@vger.kernel.org
> Subject: bcm4313/bcrm80211 and debian liquirix
>
>
> According to docs I googled up the brcm80211 driver should work with the
> bcm4313 wireless device.
>
> I have installed the debian firmware-brcm80211 package but when I
> modprobe the bcrm80211 module there is kernel panic, I get the black
> screen of death and a dump saying (reading off the
> laptop screen)
>
> !(sdu->cloned) failed : file wlc_mac80211.c line 5140
>
>
> I'm fairly new to all this so any pointers greatfully received. My
> kernel is:-
>
> Linux asus1015pem 2.6.37-0.slh.7-aptosid-686 #1 SMP PREEMPT Sun Jan 16
> 23:16:55 UTC 2011 i686 GNU/Linux
>
>
> If I can provide more info please let me know and let me know how.
>
> regards
>
> r.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Bob Copeland @ 2011-01-26 1:50 UTC (permalink / raw)
To: Stanislaw Gruszka
Cc: linville, linux-wireless, mickflemm, Bruno Randolf, jirislaby,
lrodriguez
In-Reply-To: <20110125135249.GA2610@redhat.com>
From: Bob Copeland <me@bobcopeland.com>
Date: Mon, 24 Jan 2011 09:25:11 -0500
Subject: [PATCH] ath5k: fix error handling in ath5k_hw_dma_stop
Review spotted a problem with the error handling in ath5k_hw_dma_stop:
a successful return from ath5k_hw_stop_tx_dma will be treated as
an error, so we always bail out of the loop after processing a single
active queue. As a result, we may not actually stop some queues during
reset.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
---
> Patch is good, but does not make code fully correct. When last queue
> is inactive, we return -EINVAL from ath5_hw_dma_stop(). So we need
> also:
>
> if (err && err != -EINVAL)
> return err;
> + err = 0;
> }
> But perhaps, would be better just return 0 from
> ath5k_hw_stop_tx_dma() when queue is inactive.
How about this version instead? Although returning 0 in the inactive
queue case would be ok, I'd like to keep the diff small since this
seems to fix some reset problems people are now seeing in Linus's tree
and if so I'd like to get it in 2.6.38.
> I think that could fix "ath5k phy0: can't reset hardware (-5)"
> bugs reported in a few places, so patch should go to stable
> as well.
I thought this was older code but it actually landed after 2.6.37
so no need for stable CC.
As a side note, we still quit when the first error is encountered.
Maybe we should try stopping all of the queues anyway if one fails?
On the other hand we could spend a lot of time polling the registers
if the card is truly hosed, so I think this is best for now.
drivers/net/wireless/ath/ath5k/dma.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
index 0064be7..21091c2 100644
--- a/drivers/net/wireless/ath/ath5k/dma.c
+++ b/drivers/net/wireless/ath/ath5k/dma.c
@@ -838,9 +838,9 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
for (i = 0; i < qmax; i++) {
err = ath5k_hw_stop_tx_dma(ah, i);
/* -EINVAL -> queue inactive */
- if (err != -EINVAL)
+ if (err && err != -EINVAL)
return err;
}
- return err;
+ return 0;
}
--
1.7.1.1
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply related
* Re: [PATCH 6/6] ath: Fix WEP hardware encryption
From: Bruno Randolf @ 2011-01-26 2:38 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linville, ath5k-devel, linux-wireless
In-Reply-To: <20110125183205.GA29410@jm.kir.nu>
On Wed January 26 2011 03:32:05 Jouni Malinen wrote:
> On Tue, Jan 25, 2011 at 01:15:49PM +0900, Bruno Randolf wrote:
> > In AP mode hardware encryption for WEP was not used on the RX side
> > because there was a mismatch in the key indices. The key index in the
> > WLAN header is 0-3 while the hardware key cache was configured for key
> > indices >= 4. This is ok for transmit but received packets were not
> > decrypted in HW and therefore mac80211 had to decrypt them in SW - this
> > can be easily seen by adding some debug prints in mac80211/wep.c (around
> > line 296). I have noticed it by watching the system CPU load under high
> > traffic.
> >
> > This patch configures WEP keys into the "standard" key indices 0-4 which
> > were reserved for that.
>
> Have you tested this with multiple vifs? I would assume it would break
> things pretty completely for all but one vif.. As such, I'm not sure
> that it would be that good of an idea to try to improve on something
> like WEP which is known to be completely insecure and unusable with
> 802.11n when it is likely to break use cases that are much more relevant
> in modern, post-WEP, time..
>
> If you really think you need this, there would need to be code somewhere
> kicking out the default keys from key cache if another vif is added.
> When working with the key cache implementation for ath9k, the extra
> effort did not seem to be justifiable for WEP and it is now couple of
> years from that and surely there is even less justification now.
Please let's not go into the discussion about the usefulness of WEP - there is
no need to convince me. But unfortunately there are users and customers who
still want to use WEP for a variety of reasons. Yes it's legacy, yes it's
flawed especially with regards to multiple vifs, but we still need to support
it.
Even without my patch, WEP does not work with multiple vifs.
(As far as i understand it, with WEP the lookup is just done based on the key
index in the WLAN header field. mac80211 (or is it hostapd?) sets up both keys
for both interfaces with a key index of 0, which causes the lookup to go to
the same key for both vifs. I guess mac80211 or hostapd would need to be
changed to use different key indices for different vif WEP keys, but then of
course we can only use 4 different WEP keys in sum, and not 4 different WEP
keys per vif. No big deal imho.)
My patch just adds a special case for WEP, so it does not break anything for
the other use cases. It improves the performance for the one vif case where
WEP works right now.
bruno
^ permalink raw reply
* Re: [PATCH v2 4/6] mac80211: Save probe response data for BSS
From: Arik Nemtsov @ 2011-01-26 5:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295869126.3639.4.camel@jlt3.sipsolutions.net>
On Mon, Jan 24, 2011 at 13:38, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>
>> +static int ieee80211_set_probe_resp(struct wiphy *wiphy,
>> + struct net_device *dev, u8 *resp,
>> + size_t resp_len)
>> +{
>> + struct ieee80211_sub_if_data *sdata;
>> + struct sk_buff *new, *old;
>> +
>> + sdata = IEEE80211_DEV_TO_SUB_IF(dev);
>> + old = sdata->u.ap.probe_resp;
>> +
>> + if (!resp || !resp_len)
>> + return -EINVAL;
>> +
>> + new = dev_alloc_skb(resp_len);
>> + if (!new) {
>> + printk(KERN_DEBUG "%s: failed to allocate buffer for probe "
>> + "response template\n", sdata->name);
>> + return -ENOMEM;
>
> I'd remove that message -- userspace already knows, and it's the only
> thing that really needs to?
>
Sure. I'll fix this in v3 (somehow missed this email before).
Arik
^ permalink raw reply
* Re: [PATCH v2 2/6] nl80211: Pass probe response data to drivers
From: Arik Nemtsov @ 2011-01-26 6:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295950325.3650.5.camel@jlt3.sipsolutions.net>
On Tue, Jan 25, 2011 at 12:12, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2011-01-24 at 22:47 +0200, Arik Nemtsov wrote:
>> On Mon, Jan 24, 2011 at 13:35, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > On Sun, 2011-01-23 at 23:02 +0200, Arik Nemtsov wrote:
>> >> Allow usermode to pass probe-response data. This data can be used as a
>> >> template probe-response offloading.
>> >
>> > Why use a separate command for this, and not do it like the SSID? I also
>>
>> Its only relevant to AP-mode (at least for now) so bss_conf didn't
>> seem appropriate.
>> Also since its a dynamically allocated buffer it should be protected by RCU.
>
> But all that is unrelated to the nl80211 API, no? Also the SSID already
> uses bss_conf too, and it's AP mode too...
Do you have a preferred alternative?
>
>> About compatibility - good point there. Currently the probe response
>> template is set according to the beacon for compatibility. As for SSID
>> - with the current wl12xx we'll set an empty SSID when a
>> non-supporting hostapd is encountered. I'll fix that (in a v3). Other
>> than that, we should be able to operate with either one configured.
>
> Does that mean if you set an empty SSID it won't reply but pass them up?
> Then you could implement the behaviour I just asked for ...
Well no. The FW never passes up beacons. You've helped uncover a bug
where a non-supporting hostapd doesn't set the SSID and consequently
we'll have an empty SSID configured to FW.
In this case we should fallback to use the SSID extracted from the beacon.
Arik
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-26 6:08 UTC (permalink / raw)
To: Jouni Malinen
Cc: linux-wireless, Luciano Coelho, Johannes Berg, John W. Linville
In-Reply-To: <20110125094130.GA25962@jm.kir.nu>
On Tue, Jan 25, 2011 at 11:41, Jouni Malinen <j@w1.fi> wrote:
> On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
>> The SSID-as-attr not used for the probe-resp template. It is used by
>> FW to filter out which probe-reqs should be responded to when
>> operating with a hidden SSID.
>
> OK, that would be useful to mention in nl80211.h comments and
> cfg80211.h, too, I'd guess.
Sure. I'll put in a few words.
>
>> The wl12xx FW updates the timestamp and DA. I mentioned in the
>> documentation of ieee80211_proberesp_get (and various other parts)
>> that the DA should be set manually and that this should be used as a
>> template (which also implies timestamp should be set). If some part is
>> unclear can you point out a specific patch?
>
> DA should be pretty obvious. Timestamp is something that I hope is clear
> for whoever is implementing a driver, but it could be mentioned
> somewhere.
Sure.
>
>> Perhaps we can start with these AP-mode only patches and expand the
>> functionality when it is needed for p2p?
>
> I'm fine with them if there is a capability flag that allows user space
> to know that the driver does not use user space -based Probe Request
> processing. With that, hostapd/wpa_supplicant can disable functionality
> like multi-SSID support, WPS 2.0, P2P until we get more complete
> capability information on what devices that process Probe Request frames
> internally can do.
Makes sense. I'll look into it.
Arik
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-26 6:24 UTC (permalink / raw)
To: Jouni Malinen
Cc: linux-wireless, Luciano Coelho, Johannes Berg, John W. Linville
In-Reply-To: <AANLkTimybq=P+mJW36yYCyQeEq7SeACa8ZDewYsy2w38@mail.gmail.com>
On Wed, Jan 26, 2011 at 08:08, Arik Nemtsov <arik@wizery.com> wrote:
> On Tue, Jan 25, 2011 at 11:41, Jouni Malinen <j@w1.fi> wrote:
>> On Mon, Jan 24, 2011 at 11:16:43PM +0200, Arik Nemtsov wrote:
>>> The SSID-as-attr not used for the probe-resp template. It is used by
>>> FW to filter out which probe-reqs should be responded to when
>>> operating with a hidden SSID.
>>
>> OK, that would be useful to mention in nl80211.h comments and
>> cfg80211.h, too, I'd guess.
>
> Sure. I'll put in a few words.
>
>>
>>> The wl12xx FW updates the timestamp and DA. I mentioned in the
>>> documentation of ieee80211_proberesp_get (and various other parts)
>>> that the DA should be set manually and that this should be used as a
>>> template (which also implies timestamp should be set). If some part is
>>> unclear can you point out a specific patch?
>>
>> DA should be pretty obvious. Timestamp is something that I hope is clear
>> for whoever is implementing a driver, but it could be mentioned
>> somewhere.
>
> Sure.
>
>>
>>> Perhaps we can start with these AP-mode only patches and expand the
>>> functionality when it is needed for p2p?
>>
>> I'm fine with them if there is a capability flag that allows user space
>> to know that the driver does not use user space -based Probe Request
>> processing. With that, hostapd/wpa_supplicant can disable functionality
>> like multi-SSID support, WPS 2.0, P2P until we get more complete
>> capability information on what devices that process Probe Request frames
>> internally can do.
>
> Makes sense. I'll look into it.
>
Just to clear up - I don't want to disable p2p or wps support in
hostapd if probe-resp offloading is configured. The low level
driver/fw could realistically differentiate between regular and
non-support probe requests, and only handle the former.
The kind of capability flag you asked won't work with such a low lever
driver/fw combo. Is muti-ssid support currently implemented?
How about a different solution - I'll just disable p2p IEs for the
probe-resp template for now. Let's assume the FW behaves correctly in
this case and passes up the probe-requests. The code for generating
the WPS IE for the probe-resp seems to not depend on the probe-req. Is
the feature of WPS 2.0 you mentioned currently implemented? If so this
can be disabled as well.
Arik
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-26 6:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295950241.3650.3.camel@jlt3.sipsolutions.net>
On Tue, Jan 25, 2011 at 12:10, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>
>> Well a wiphy flag won't do here. Probe requests may be filtered in
>> some modes (AP-mode) but needed in others (p2p?).
>> I think flexibility is a nice added bonus here. A FW can decide to
>> handle most standard probe-requests and simply not pass them up.
>> Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>>
>> The current patches leave this policy in the hands of the driver/fw.
>
> That is _very_ dangerous. If the user has older firmware that doesn't
> know about WSC2, how would the user know not to configure WSC2 in
> hostapd? That needs to be known to hostapd so it can verify this
> situation. For P2P, we already know whether or not P2P is supported, but
> that's rather vague in case there will ever be a revision of the P2P
> spec with say different IEs.
Well basically the FW should white-list probe-requests it knows about
and pass up all the rest.
>
> Additionally, a "regular AP" (not P2P, not WSC) would still want to
> reply to probe requests from WSC/P2P devices with the normal template.
>
> IMHO it would be smarter to rework the firmware to only reply to probe
> requests if the probe response is configured. Then, if WSC, P2P, or
> similar technologies are in use on the interface, hostapd can simply
> decide to not configure the probe response and have host-based
> processing. Would that be a change you could still make?
With the current set of patches the decision is left at the hands of
the driver/fw. Hostapd currently doesn't have a way of toggling
probe-resp offloading in the low level driver.
This kind of plumbing is not needed in case the FW handles what it can
and passes up unknown probe-requests.
Arik
^ permalink raw reply
* Re: [PATCH v2 0/6] Probe-resp offloading support
From: Arik Nemtsov @ 2011-01-26 6:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295952127.3650.12.camel@jlt3.sipsolutions.net>
On Tue, Jan 25, 2011 at 12:42, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2011-01-25 at 11:10 +0100, Johannes Berg wrote:
>> On Mon, 2011-01-24 at 23:21 +0200, Arik Nemtsov wrote:
>>
>> > Well a wiphy flag won't do here. Probe requests may be filtered in
>> > some modes (AP-mode) but needed in others (p2p?).
>> > I think flexibility is a nice added bonus here. A FW can decide to
>> > handle most standard probe-requests and simply not pass them up.
>> > Others ("complicated" ones) it can pass up to hostapd and expect it to reply.
>> >
>> > The current patches leave this policy in the hands of the driver/fw.
>>
>> That is _very_ dangerous. If the user has older firmware that doesn't
>> know about WSC2, how would the user know not to configure WSC2 in
>> hostapd? That needs to be known to hostapd so it can verify this
>> situation. For P2P, we already know whether or not P2P is supported, but
>> that's rather vague in case there will ever be a revision of the P2P
>> spec with say different IEs.
>>
>> Additionally, a "regular AP" (not P2P, not WSC) would still want to
>> reply to probe requests from WSC/P2P devices with the normal template.
>>
>> IMHO it would be smarter to rework the firmware to only reply to probe
>> requests if the probe response is configured. Then, if WSC, P2P, or
>> similar technologies are in use on the interface, hostapd can simply
>> decide to not configure the probe response and have host-based
>> processing. Would that be a change you could still make?
>
>
> Of course, firmware can reply to non-p2p/non-wsc2 probe requests with a
> static probe response template.
>
> The question is how much knowledge you want to put into the firmware
> about those protocols. If you want to put all knowledge in there, then
> at least you need to indicate to hostapd which protocols the firmware
> knows not to reply to.
>
> Also, a way to turn off this behaviour would still be good for future
> protocol changes. If P2P changes in 3 years, I'm sure this firmware
> won't be updated to match since you'll be a few hardware generations
> ahead. Then, being able to turn off the offload completely would allow
> users to take advantage of new protocols without changing hardware. Of
> course, you may want to force users to buy new hardware that way -- but
> in that case we *still* need the advertisement of what's possible so
> users know right away that they need to buy new hardware and don't try
> to configure something that just fails in strange ways.
>
Like I said in a previous email - I think a white list (or black list)
of IEs in FW is the way to go here. Not all probe-responses should be
offloaded.
Its also conceivable that an old driver/fw won't work when some
protocol is changed/updated, even if hostapd supports it.
I'm not sure the probe-resp will be the culprit here..
Arik
^ permalink raw reply
* Re: [PATCH 1/2] ath5k: fix error handling in ath5k_hw_dma_stop
From: Stanislaw Gruszka @ 2011-01-26 7:05 UTC (permalink / raw)
To: Bob Copeland
Cc: linville, linux-wireless, mickflemm, Bruno Randolf, jirislaby,
lrodriguez
In-Reply-To: <20110126015034.GA8600@hash.localnet>
On Tue, Jan 25, 2011 at 08:50:34PM -0500, Bob Copeland wrote:
> From: Bob Copeland <me@bobcopeland.com>
> Date: Mon, 24 Jan 2011 09:25:11 -0500
> Subject: [PATCH] ath5k: fix error handling in ath5k_hw_dma_stop
>
> Review spotted a problem with the error handling in ath5k_hw_dma_stop:
> a successful return from ath5k_hw_stop_tx_dma will be treated as
> an error, so we always bail out of the loop after processing a single
> active queue. As a result, we may not actually stop some queues during
> reset.
>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
> ---
>
> > Patch is good, but does not make code fully correct. When last queue
> > is inactive, we return -EINVAL from ath5_hw_dma_stop(). So we need
> > also:
> >
> > if (err && err != -EINVAL)
> > return err;
> > + err = 0;
> > }
>
> > But perhaps, would be better just return 0 from
> > ath5k_hw_stop_tx_dma() when queue is inactive.
>
> How about this version instead?
It's better :)
> diff --git a/drivers/net/wireless/ath/ath5k/dma.c b/drivers/net/wireless/ath/ath5k/dma.c
> index 0064be7..21091c2 100644
> --- a/drivers/net/wireless/ath/ath5k/dma.c
> +++ b/drivers/net/wireless/ath/ath5k/dma.c
> @@ -838,9 +838,9 @@ int ath5k_hw_dma_stop(struct ath5k_hw *ah)
> for (i = 0; i < qmax; i++) {
> err = ath5k_hw_stop_tx_dma(ah, i);
> /* -EINVAL -> queue inactive */
> - if (err != -EINVAL)
> + if (err && err != -EINVAL)
> return err;
> }
>
> - return err;
> + return 0;
> }
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
^ permalink raw reply
* Re: [RFC] iwl3945: remove check_plcp_health
From: Stanislaw Gruszka @ 2011-01-26 7:15 UTC (permalink / raw)
To: John W. Linville
Cc: Wey-Yi Guy, Abhijeet Kolekar, linux-wireless,
Intel Linux Wireless
In-Reply-To: <20110125151445.GA2927@tuxdriver.com>
On Tue, Jan 25, 2011 at 10:14:46AM -0500, John W. Linville wrote:
> On Tue, Jan 25, 2011 at 10:35:28AM +0100, Stanislaw Gruszka wrote:
> > This patch helps some users currently complaining about iwl3945
> > performance.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=654599
> > https://bugs.launchpad.net/ubuntu/maverick/+source/linux/+bug/621265/+index?comments=all
> >
> > Patch does not helps all users, but they seems to be affected
> > by different bug or bugs.
> >
> > Patch effectively reverts commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
> > "iwl3945: add plcp error checking". It is minimal fix intended to
> > -stable posting. I will post cleaning up patch, if fix will be accepted.
> >
> > ---
> > drivers/net/wireless/iwlwifi/iwl-3945.c | 1 -
> > 1 files changed, 0 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/iwlwifi/iwl-3945.c b/drivers/net/wireless/iwlwifi/iwl-3945.c
> > index 8cacb4e..eb916d7 100644
> > --- a/drivers/net/wireless/iwlwifi/iwl-3945.c
> > +++ b/drivers/net/wireless/iwlwifi/iwl-3945.c
> > @@ -2832,7 +2832,6 @@ static struct iwl_lib_ops iwl3945_lib = {
> > .config_ap = iwl3945_config_ap,
> > .manage_ibss_station = iwl3945_manage_ibss_station,
> > .recover_from_tx_stall = iwl_bg_monitor_recover,
> > - .check_plcp_health = iwl3945_good_plcp_health,
> >
> > .debugfs_ops = {
> > .rx_stats_read = iwl3945_ucode_rx_stats_read,
>
> Did you experiment with different values for
> IWL_MAX_PLCP_ERR_LONG_THRESHOLD_DEF for iwl3945?
No, I'm not able to reproduce the problem. I will request that
via bugzilla to users hitting bug.
> Should we simply revert commit a29576a7844326c5223f4d4adbfd3f4d64173d4c
> instead?
Due to massive other automatic revert fails on upstream code, also
it would be relatively hard to backport. So I decided to do oneliner
fix for stable, and clean up (revert all not necessary code) only
upstream separately.
Cheers
Stanislaw
^ permalink raw reply
* Re: [PATCH v2] mac80211: use DECLARE_EVENT_CLASS
From: Johannes Berg @ 2011-01-26 8:16 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20110125215810.GE2927@tuxdriver.com>
On Tue, 2011-01-25 at 16:58 -0500, John W. Linville wrote:
> On Sun, Jan 23, 2011 at 11:12:53AM +0100, Johannes Berg wrote:
> > From: Johannes Berg <johannes.berg@intel.com>
> >
> > For events that include only the local struct as
> > their parameter, we can use DECLARE_EVENT_CLASS
> > and save quite some binary size across segments
> > as well lines of code.
> >
> > text data bss dec hex filename
> > 375745 19296 916 395957 60ab5 mac80211.ko.before
> > 367473 17888 916 386277 5e4e5 mac80211.ko.after
> > -8272 -1408 0 -9680 -25d0 delta
> >
> > Some more tracepoints with identical arguments
> > could be combined like this but for now this is
> > the one that benefits most.
> >
> > Signed-off-by: Johannes Berg <johannes.berg@intel.com>
>
> OK, so what am I doing wrong?
>
> Kernel: arch/x86/boot/bzImage is ready (#11)
> Building modules, stage 2.
> MODPOST 2218 modules
> ERROR: "__tracepoint_drv_return_void" [net/mac80211/mac80211.ko] undefined!
Oh, apparently that happens when you compile without the tracing in
mac80211. How strange. I'll have to figure that out.
johannes
^ permalink raw reply
* [PATCH v3] mac80211: use DECLARE_EVENT_CLASS
From: Johannes Berg @ 2011-01-26 8:22 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <20110125215810.GE2927@tuxdriver.com>
From: Johannes Berg <johannes.berg@intel.com>
For events that include only the local struct as
their parameter, we can use DECLARE_EVENT_CLASS
and save quite some binary size across segments
as well lines of code.
text data bss dec hex filename
375745 19296 916 395957 60ab5 mac80211.ko.before
367473 17888 916 386277 5e4e5 mac80211.ko.after
-8272 -1408 0 -9680 -25d0 delta
Some more tracepoints with identical arguments
could be combined like this but for now this is
the one that benefits most.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
v3: fix compile w/o mac80211 events -- I had forgotten
we have a "manual override" in that case
net/mac80211/driver-trace.h | 202 +++++++-------------------------------------
1 file changed, 33 insertions(+), 169 deletions(-)
--- wireless-testing.orig/net/mac80211/driver-trace.h 2011-01-25 11:21:05.000000000 +0100
+++ wireless-testing/net/mac80211/driver-trace.h 2011-01-26 09:20:48.000000000 +0100
@@ -9,6 +9,11 @@
#undef TRACE_EVENT
#define TRACE_EVENT(name, proto, ...) \
static inline void trace_ ## name(proto) {}
+#undef DECLARE_EVENT_CLASS
+#define DECLARE_EVENT_CLASS(...)
+#undef DEFINE_EVENT
+#define DEFINE_EVENT(evt_class, name, proto, ...) \
+static inline void trace_ ## name(proto) {}
#endif
#undef TRACE_SYSTEM
@@ -38,7 +43,7 @@ static inline void trace_ ## name(proto)
* Tracing for driver callbacks.
*/
-TRACE_EVENT(drv_return_void,
+DECLARE_EVENT_CLASS(local_only_evt,
TP_PROTO(struct ieee80211_local *local),
TP_ARGS(local),
TP_STRUCT__entry(
@@ -50,6 +55,11 @@ TRACE_EVENT(drv_return_void,
TP_printk(LOCAL_PR_FMT, LOCAL_PR_ARG)
);
+DEFINE_EVENT(local_only_evt, drv_return_void,
+ TP_PROTO(struct ieee80211_local *local),
+ TP_ARGS(local)
+);
+
TRACE_EVENT(drv_return_int,
TP_PROTO(struct ieee80211_local *local, int ret),
TP_ARGS(local, ret),
@@ -78,40 +88,14 @@ TRACE_EVENT(drv_return_u64,
TP_printk(LOCAL_PR_FMT " - %llu", LOCAL_PR_ARG, __entry->ret)
);
-TRACE_EVENT(drv_start,
+DEFINE_EVENT(local_only_evt, drv_start,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
-TRACE_EVENT(drv_stop,
+DEFINE_EVENT(local_only_evt, drv_stop,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
TRACE_EVENT(drv_add_interface,
@@ -439,40 +423,14 @@ TRACE_EVENT(drv_hw_scan,
)
);
-TRACE_EVENT(drv_sw_scan_start,
+DEFINE_EVENT(local_only_evt, drv_sw_scan_start,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
-TRACE_EVENT(drv_sw_scan_complete,
+DEFINE_EVENT(local_only_evt, drv_sw_scan_complete,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
TRACE_EVENT(drv_get_stats,
@@ -702,23 +660,9 @@ TRACE_EVENT(drv_conf_tx,
)
);
-TRACE_EVENT(drv_get_tsf,
+DEFINE_EVENT(local_only_evt, drv_get_tsf,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT,
- LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
TRACE_EVENT(drv_set_tsf,
@@ -742,41 +686,14 @@ TRACE_EVENT(drv_set_tsf,
)
);
-TRACE_EVENT(drv_reset_tsf,
+DEFINE_EVENT(local_only_evt, drv_reset_tsf,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
-TRACE_EVENT(drv_tx_last_beacon,
+DEFINE_EVENT(local_only_evt, drv_tx_last_beacon,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT,
- LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
TRACE_EVENT(drv_ampdu_action,
@@ -962,22 +879,9 @@ TRACE_EVENT(drv_remain_on_channel,
)
);
-TRACE_EVENT(drv_cancel_remain_on_channel,
+DEFINE_EVENT(local_only_evt, drv_cancel_remain_on_channel,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
/*
@@ -1072,23 +976,9 @@ TRACE_EVENT(api_stop_tx_ba_cb,
)
);
-TRACE_EVENT(api_restart_hw,
+DEFINE_EVENT(local_only_evt, api_restart_hw,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT,
- LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
TRACE_EVENT(api_beacon_loss,
@@ -1217,40 +1107,14 @@ TRACE_EVENT(api_chswitch_done,
)
);
-TRACE_EVENT(api_ready_on_channel,
+DEFINE_EVENT(local_only_evt, api_ready_on_channel,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
-TRACE_EVENT(api_remain_on_channel_expired,
+DEFINE_EVENT(local_only_evt, api_remain_on_channel_expired,
TP_PROTO(struct ieee80211_local *local),
-
- TP_ARGS(local),
-
- TP_STRUCT__entry(
- LOCAL_ENTRY
- ),
-
- TP_fast_assign(
- LOCAL_ASSIGN;
- ),
-
- TP_printk(
- LOCAL_PR_FMT, LOCAL_PR_ARG
- )
+ TP_ARGS(local)
);
/*
^ permalink raw reply
* [PATCH 1/2] wl12xx: Enable the IEEE80211_HW_SPECTRUM_MGMT hw flag
From: juuso.oikarinen @ 2011-01-26 8:29 UTC (permalink / raw)
To: coelho; +Cc: linux-wireless
In-Reply-To: <1296030565-23778-1-git-send-email-juuso.oikarinen@nokia.com>
From: Juuso Oikarinen <juuso.oikarinen@nokia.com>
It's mandatory to support this along with 11a.
Signed-off-by: Juuso Oikarinen <juuso.oikarinen@nokia.com>
---
drivers/net/wireless/wl12xx/main.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index dfab21e..bc09812 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -3215,7 +3215,8 @@ int wl1271_init_ieee80211(struct wl1271 *wl)
IEEE80211_HW_SUPPORTS_UAPSD |
IEEE80211_HW_HAS_RATE_CONTROL |
IEEE80211_HW_CONNECTION_MONITOR |
- IEEE80211_HW_SUPPORTS_CQM_RSSI;
+ IEEE80211_HW_SUPPORTS_CQM_RSSI |
+ IEEE80211_HW_SPECTRUM_MGMT;
wl->hw->wiphy->cipher_suites = cipher_suites;
wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
--
1.7.1
^ permalink raw reply related
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