* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Christian Lamparter @ 2011-01-20 17:43 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110120101606.53052h18mlpyp8w0@hayate.sektori.org>
On Thursday 20 January 2011 09:16:06 Jussi Kivilinna wrote:
> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>> On Wednesday 19 January 2011 19:49:03 Jussi Kivilinna wrote:
>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>> On Sunday 09 January 2011 16:46:56 Jussi Kivilinna wrote:
>>>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>>>> Since zd_beacon_done also uploads the next beacon so long in advance,
>>>>>> there could be an equally long race between the outdated state of the
>>>>>> next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
>>>>>> which -in your case- was uploaded almost a beacon interval ago and
>>>>>> the xmit of ieee80211_get_buffered_bc *now*.
>>>>>>
>>>>>> The dtim bc/mc bit might be not set, when a mc/bc arrived after the
>>>>>> beacon was uploaded, but before the "beacon done event" from the
>>>>>> hardware. So, dozing stations don't expect the broadcast traffic
>>>>>> and of course, they might miss it completely.
>>>>>>
>>>>>> It's probably better to fix this in mac80211 (see the attached hack).
>>>>>
>>>>> Ok, should I add this to my patchset?
>>>> well, difficult to say. As far as I can say, it should be correct for "your
>>>> case". But, on the other hand: what about solutions that can't buffer
>>>> mc/bc frames (and needs to call ieee80211_get_buffered_bc), however the
>>>> firmware is clever enough to maintain a beacon internally (so they
>>>> won't call ieee80211_beacon_get and only relies on set_tim)?
>>>>
>>>> Sure, it's just a unlikely corner case... In fact, I didn't check if
>>>> that's even possible, but it does sound reasonable to some extend.
>>>
>>> From what I checked none of currect driver/device is such.
>>> Maybe if such device appears then !bss->dtim_bc_mc check in
>>> ieee80211_beacon_add_tim() could be masked with driver flag (something
>>> like
>>> IEEE80211_HW_CAN_AND_HANDLE_BEACON_BUT_STILL_NEEDS_HOST_BROADCAST_PS_BUFFERING).
>>
>> True, but a recent discussion into this matter have made parts of the
>> API you are planning to use sort-of "deprecated"? [I think?]
>>
>> http://marc.info/?l=linux-wireless&m=129463297300480
>>
>> I don't know the exact details, but I'm sure Kvalo does have his reasons.
>> [afaik it has to do with wl12xx, he even explained it once, but I can't
>> find that mail anymore].
>>
>
> What I understood from that thread is that rt2x00/usb doesn't have HW
> buffering and doesn't enable IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING
> (rt2x00/pci does), and yet enables AP-mode. Driver has this comment:
> /*
> * Initialize all hw fields.
> *
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING unless we are
> * capable of sending the buffered frames out after the DTIM
> * transmission using rt2x00lib_beacondone. This will send out
> * multicast and broadcast traffic immediately instead of buffering it
> * infinitly and thus dropping it after some time.
> */
My bad, you are right. This is not something to worry about anymore.
> > One more thing, is there a tx-control flag to instruct the HW/FW to write
> > the TSF into probe response frames, just like it does for beacons frames?
> >
> > Sure, this feature is far more important for IBSS, but the 802.11-2007
> > specs @11.1.4 says that a STA might use beacons or probe responses to
> > synchronize its timers. [However 11.1.1.1 and 11.1.3.4 say that STAs
> > should "only" pick this information from beacons, if I'm not mistaken?!]
> > (Also a uniform "0..0" timestamp in every probe-response looks so sad.)
> >
>
> No such flag I'm afraid. Vendor driver appears to be reading
> tsf-register from driver and writing value to probe response frames,
> maybe something I should add to zd1211rw too.
It's more of a cosmetic thing, but very difficult to get it right without
firmware/hw support [over an usb]. So you might just leave it as it
is...
Best regards,
Christian
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Support sw_scan_start_cur
From: Ben Greear @ 2011-01-20 17:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295545044.3693.43.camel@jlt3.sipsolutions.net>
On 01/20/2011 09:37 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This method is called when driver can support
>> scanning the currect active channel without otherwise
>> impeding traffic on that channel. The mac80211 scan
>> logic may call this when we are only scanning on the
>> active channel and thus do not need to go off channel.
>
> I frankly don't see any point telling the driver about this. Looking at
> the ath9k patch you sent, it seems to avoid some things like flushing --
> but the flushing should be controlled by mac80211 already (or converted
> to be) so that it's not necessary to have this.
mac80211 + ath9k is a house of cards, and this seemed the least
invasive approach. It also lets us not change behaviour for
the rest of the drivers until they are audited and potentially
updated. At best I can test/hack on ath5k and ath9k. These are
touchy enough, and other drivers may be even more twitchy...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Ben Greear @ 2011-01-20 18:06 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295545143.3693.44.camel@jlt3.sipsolutions.net>
On 01/20/2011 09:39 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
>
>> - ieee80211_offchannel_stop_beaconing(local);
>> + if (local->ops->sw_scan_start_cur&&
>> + local->scan_req->n_channels == 1&&
>> + local->scan_req->channels[0] == local->hw.conf.channel) {
>> + __set_bit(SCAN_ON_CUR_CHANNEL,&local->scanning);
>> + drv_sw_scan_start_cur(local, true);
>> + } else
>> + drv_sw_scan_start(local);
>
> This doesn't seem to make much sense either -- even if we do a scan over
> multiple channels we should be able to optimise the part on the current
> channel (maybe put it at the beginning or end too).
Maybe..but user-space can specify the channels it wants to scan,
and I assume that means what order to scan them in. I have no
idea if changing that order would confuse some application.
It seems to me that it would take quite a bit of re-work of the
mac80211 scanning logic to deal with scanning on the current
channel w/out affecting other tx/rx packets (as my patch attempts
to do), without setting some explicit flag before you enter
the scan state machine.
Thanks,
Ben
>
> johannes
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 18:17 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4D3879A6.2060909@candelatech.com>
On Thu, 2011-01-20 at 10:06 -0800, Ben Greear wrote:
> > This doesn't seem to make much sense either -- even if we do a scan over
> > multiple channels we should be able to optimise the part on the current
> > channel (maybe put it at the beginning or end too).
>
> Maybe..but user-space can specify the channels it wants to scan,
> and I assume that means what order to scan them in. I have no
> idea if changing that order would confuse some application.
No, it can't actually determine the order -- we sort them in cfg80211
anyway to de-duplicate them.
> It seems to me that it would take quite a bit of re-work of the
> mac80211 scanning logic to deal with scanning on the current
> channel w/out affecting other tx/rx packets (as my patch attempts
> to do), without setting some explicit flag before you enter
> the scan state machine.
Yeah, so maybe it needs some re-work, but I think what you're doing is a
pretty strange hack.
johannes
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Ben Greear @ 2011-01-20 18:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1295547439.3693.46.camel@jlt3.sipsolutions.net>
On 01/20/2011 10:17 AM, Johannes Berg wrote:
> On Thu, 2011-01-20 at 10:06 -0800, Ben Greear wrote:
>
>>> This doesn't seem to make much sense either -- even if we do a scan over
>>> multiple channels we should be able to optimise the part on the current
>>> channel (maybe put it at the beginning or end too).
>>
>> Maybe..but user-space can specify the channels it wants to scan,
>> and I assume that means what order to scan them in. I have no
>> idea if changing that order would confuse some application.
>
> No, it can't actually determine the order -- we sort them in cfg80211
> anyway to de-duplicate them.
Ok, so assuming we re-work scanning across the board, maybe the first
thing is to sort them such that the current channel is always first
(if it's in the list at all)?
>> It seems to me that it would take quite a bit of re-work of the
>> mac80211 scanning logic to deal with scanning on the current
>> channel w/out affecting other tx/rx packets (as my patch attempts
>> to do), without setting some explicit flag before you enter
>> the scan state machine.
>
> Yeah, so maybe it needs some re-work, but I think what you're doing is a
> pretty strange hack.
If you have time to write some patches, I'll be happy to test them on
our ath9k and ath5k systems.
If you don't, then I can make an attempt. Suggestions for an acceptable
way to go about doing this would be welcome.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 18:25 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless
In-Reply-To: <4D387D25.7080902@candelatech.com>
On Thu, 2011-01-20 at 10:21 -0800, Ben Greear wrote:
> > No, it can't actually determine the order -- we sort them in cfg80211
> > anyway to de-duplicate them.
>
> Ok, so assuming we re-work scanning across the board, maybe the first
> thing is to sort them such that the current channel is always first
> (if it's in the list at all)?
Yeah I guess mac80211 could do that -- I wouldn't necessarily do it in
cfg80211. However, I'm not convinced it's necessary.
> >> It seems to me that it would take quite a bit of re-work of the
> >> mac80211 scanning logic to deal with scanning on the current
> >> channel w/out affecting other tx/rx packets (as my patch attempts
> >> to do), without setting some explicit flag before you enter
> >> the scan state machine.
> >
> > Yeah, so maybe it needs some re-work, but I think what you're doing is a
> > pretty strange hack.
>
> If you have time to write some patches, I'll be happy to test them on
> our ath9k and ath5k systems.
I don't, unfortunately, at least not now.
> If you don't, then I can make an attempt. Suggestions for an acceptable
> way to go about doing this would be welcome.
Well I'd start by looking at the offchannel code and seeing if it has
the flushing in all the right places. I don't think it does, so drivers
attempt to work around it by flushing on channel changes. That could be
improved first.
Then I'd again look at the offchannel code and see how it can behave
better when it's not actually going offchannel -- not stop beaconing
etc., just reprogram the filters or so. That way, I'm not even sure if
modifying much of the scan code will even be necessary, and I think you
wouldn't even have to sort the channel list differently.
johannes
^ permalink raw reply
* Re: carl9170 802.11n-AP
From: Christian Lamparter @ 2011-01-20 18:31 UTC (permalink / raw)
To: Helge Lenz; +Cc: linux-wireless
In-Reply-To: <4D380E46.6070906@gmail.com>
On Thursday 20 January 2011 11:28:22 Helge Lenz wrote:
> Any news about this issue?
no news, unless you have news about a new generation of ar9170 chip.
The current one has serve problems with 802.11e - which has become
mandatory for 802.11n - and aggregation. So going for full 802.11n
support [including AP] is sort of pointless...
If you are looking for a 802.11n AP, so why not start with one?
Best Regards,
Chr
^ permalink raw reply
* Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Luis R. Rodriguez @ 2011-01-20 18:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Paul Fertser, Christian Lamparter
In-Reply-To: <20110120183210.13527.33808@he.sipsolutions.net>
Huh?
---------- Forwarded message ----------
From: Linux Wireless <johannes@sipsolutions.net>
Date: Thu, Jan 20, 2011 at 10:32 AM
Subject: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
To: Linux Wireless <johannes@sipsolutions.net>
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Linux
Wireless" for change notification.
The "en/users/Drivers/carl9170" page has been changed by PaulFertser:
http://linuxwireless.org/en/users/Drivers/carl9170?action=diff&rev1=17&rev2=18
Comment:
Information about QoS^AMPDU and WOL support
== 802.11n Compatibility ==
It's worth mentioning that the chip was designed, produced and sold
in the early 802.11n-draft period.
- Compatibility will always be an issue.
+ Compatibility will always be an issue.
+
+ A [[http://git.kernel.org/?p=linux/kernel/git/chr/carl9170fw.git;a=commitdiff;h=39be7dc384e0dd45dc36b4b517fd9fae874b06f0|known
problem]] is that hardware can not support
+ [[http://en.wikipedia.org/wiki/IEEE_802.11n-2009#Frame_aggregation|frame
+ aggregation]] and
+ [[QoS|http://en.wikipedia.org/wiki/Wireless_Multimedia_Extensions]] at
+ the same time, meaning the device is not suitable for any serious
+ 802.11n setup.
||Hardware||||Problem||||Solution?||
||'''BCM4313'''||||''Hardware incompatibility''||||''replace hardware''||
@@ -70, +77 @@
* Input device for WPS button event (depending on hardware)
* automatic recovery from several fatal events
* Regulatory domain restrictions
+ * [[http://git.kernel.org/?p=linux/kernel/git/chr/carl9170fw.git;a=commit;h=6476369c2c6d4ba487408cb5daff8df0480d6b4a|Wake-on-LAN
+ support]] (can resume your system from suspend-to-ram)
== not working yet ==
* Power Save Mode, It's implemented but buggy
^ permalink raw reply
* Re: Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Paul Fertser @ 2011-01-20 18:43 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <AANLkTi=EDRimawaentk_ppcrsTf1Rex7H9QJspktaa3C@mail.gmail.com>
On Thu, Jan 20, 2011 at 10:37:20AM -0800, Luis R. Rodriguez wrote:
> Huh?
Christian asked me to add that info to the wiki, is something i wrote wrong? It
wasn't me who added the mailing list to the recepients of change notifications
if you're about that. :)
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
^ permalink raw reply
* Re: ath9k problem with kernel 2.6.37
From: James @ 2011-01-20 18:45 UTC (permalink / raw)
To: Mohammed Shafi; +Cc: linux-wireless
In-Reply-To: <AANLkTikhpK09=wyq=g6kHbsgd-C13A4Vc1TrA29utd5k@mail.gmail.com>
On 01/20/11 03:35, Mohammed Shafi wrote:
> On Thu, Jan 20, 2011 at 12:52 PM, James <bjlockie@lockie.ca> wrote:
>> phy0: Atheros AR5416 MAC/BB Rev:2 AR2133 RF Rev:81
>> mem=0xffffc90001880000, irq=17
>>
>> I get few or no results when I do
>> iwlist wlan1 scan with kernel 2.6.37
>>
> We will check it out
>
>> but it is consistently good with kernel 2.6.36.2
>>
>> Is there a way to compare the kernel configs to make sure I didn't
>> change anything?
> Please try with latest compat wireless, which might be helpful
I got:
http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-2.6.tar.bz2
I can't compile it:
/usr/src/compat-wireless-2011-01-19 $ sudo make
/usr/src/compat-wireless-2011-01-19/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."
./scripts/gen-compat-autoconf.sh config.mk > include/linux/compat_autoconf.h
make -C /lib/modules/2.6.37/build M=/usr/src/compat-wireless-2011-01-19
modules
make[1]: Entering directory `/usr/src/linux-2.6.37'
CC [M] /usr/src/compat-wireless-2011-01-19/compat/main.o
CC [M] /usr/src/compat-wireless-2011-01-19/compat/compat-2.6.38.o
LD [M] /usr/src/compat-wireless-2011-01-19/compat/compat.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/hci_vhci.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/bcm203x.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/bpa10x.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/bfusb.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/btusb.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/ath3k.o
CC [M]
/usr/src/compat-wireless-2011-01-19/drivers/bluetooth/btmrvl_main.o
LD [M] /usr/src/compat-wireless-2011-01-19/drivers/bluetooth/btmrvl.o
CC [M]
/usr/src/compat-wireless-2011-01-19/drivers/misc/eeprom/eeprom_93cx6.o
CC [M] /usr/src/compat-wireless-2011-01-19/drivers/net/b44.o
/usr/src/compat-wireless-2011-01-19/drivers/net/b44.c:13:1: warning:
"pr_fmt" redefined
In file included from include/linux/kernel.h:20,
from include/linux/skbuff.h:17,
from include/linux/if_ether.h:125,
from include/linux/netdevice.h:29,
from
/usr/src/compat-wireless-2011-01-19/include/linux/compat-2.6.29.h:5,
from
/usr/src/compat-wireless-2011-01-19/include/linux/compat-2.6.h:24,
from <command-line>:0:
include/linux/printk.h:161:1: warning: this is the location of the
previous definition
/usr/src/compat-wireless-2011-01-19/drivers/net/b44.c: In function
'b44_pci_init':
/usr/src/compat-wireless-2011-01-19/drivers/net/b44.c:2345: error:
implicit declaration of function 'ssb_pcihost_register'
make[3]: *** [/usr/src/compat-wireless-2011-01-19/drivers/net/b44.o] Error 1
make[2]: *** [/usr/src/compat-wireless-2011-01-19/drivers/net] Error 2
make[1]: *** [_module_/usr/src/compat-wireless-2011-01-19] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.37'
make: *** [modules] Error 2
Do I understand it correctly that it is just newer and will be in the
kernel eventually?
How can I see what version of the driver I am using?
>> --
>> 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
>>
> --
> 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: Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Luis R. Rodriguez @ 2011-01-20 18:50 UTC (permalink / raw)
To: Paul Fertser; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <20110120184336.GK3333@home.lan>
On Thu, Jan 20, 2011 at 10:43 AM, Paul Fertser <fercerpav@gmail.com> wrote:
> On Thu, Jan 20, 2011 at 10:37:20AM -0800, Luis R. Rodriguez wrote:
>> Huh?
>
> Christian asked me to add that info to the wiki, is something i wrote wrong?
It is unclear to me, are you saying carl9170 does not support QoS and
aggregation?
Luis
^ permalink raw reply
* Re: Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Paul Fertser @ 2011-01-20 18:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Christian Lamparter
In-Reply-To: <AANLkTimFGzFgjNWs4QyHuyGixgCiDm_uAb_z4t4m7nD8@mail.gmail.com>
On Thu, Jan 20, 2011 at 10:50:43AM -0800, Luis R. Rodriguez wrote:
> On Thu, Jan 20, 2011 at 10:43 AM, Paul Fertser <fercerpav@gmail.com> wrote:
> > On Thu, Jan 20, 2011 at 10:37:20AM -0800, Luis R. Rodriguez wrote:
> >> Huh?
> >
> > Christian asked me to add that info to the wiki, is something i wrote wrong?
>
> It is unclear to me, are you saying carl9170 does not support QoS and
> aggregation?
At the same time, apparently, yes. This commit[1] has more
clarifications.
[1] http://git.kernel.org/?p=linux/kernel/git/chr/carl9170fw.git;a=commitdiff;h=39be7dc384e0dd45dc36b4b517fd9fae874b06f0
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
^ permalink raw reply
* Re: Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Christian Lamparter @ 2011-01-20 19:02 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Paul Fertser, linux-wireless
In-Reply-To: <AANLkTimFGzFgjNWs4QyHuyGixgCiDm_uAb_z4t4m7nD8@mail.gmail.com>
On Thursday 20 January 2011 19:50:43 Luis R. Rodriguez wrote:
> On Thu, Jan 20, 2011 at 10:43 AM, Paul Fertser <fercerpav@gmail.com> wrote:
> > On Thu, Jan 20, 2011 at 10:37:20AM -0800, Luis R. Rodriguez wrote:
> >> Huh?
> >
> > Christian asked me to add that info to the wiki, is something i wrote wrong?
>
> It is unclear to me, are you saying carl9170 does not support QoS and
> aggregation?
It's not only carl9170, it's AR9170 (the chip) .
Take a look into the original firmware:
<http://git.kernel.org/?p=linux/kernel/git/mcgrof/ar9170-fw.git;a=blob;f=STA/hostif.c;h=aa277d14ee5ec4c222b83975d7dc2d5c66dbf91c;hb=2e3574ce10c74a82047a06b046855de14d969948#l107>
107 /* TxQ number */
108 //txqNum = (buf[2] >> 13);
109 //if (txqNum > 4)
110 {
111 txqNum = 0;
112 }
113
114 zfDmaPutPacket(&zgTxQ[txqNum], desc);
115 /* Trigger WLAN TX DMA */
116 zm_wl_dma_trigger_reg = (1 << txqNum);
So yes, someone took a shortcut along the way.
Regards,
Chr
^ permalink raw reply
* Re: Fwd: [Linux Wireless] Update of "en/users/Drivers/carl9170" by PaulFertser
From: Johannes Berg @ 2011-01-20 19:07 UTC (permalink / raw)
To: Paul Fertser; +Cc: Luis R. Rodriguez, linux-wireless, Christian Lamparter
In-Reply-To: <20110120185440.GA25136@home.lan>
On Thu, 2011-01-20 at 21:54 +0300, Paul Fertser wrote:
> On Thu, Jan 20, 2011 at 10:50:43AM -0800, Luis R. Rodriguez wrote:
> > On Thu, Jan 20, 2011 at 10:43 AM, Paul Fertser <fercerpav@gmail.com> wrote:
> > > On Thu, Jan 20, 2011 at 10:37:20AM -0800, Luis R. Rodriguez wrote:
> > >> Huh?
> > >
> > > Christian asked me to add that info to the wiki, is something i wrote wrong?
> >
> > It is unclear to me, are you saying carl9170 does not support QoS and
> > aggregation?
>
> At the same time, apparently, yes. This commit[1] has more
> clarifications.
>
> [1] http://git.kernel.org/?p=linux/kernel/git/chr/carl9170fw.git;a=commitdiff;h=39be7dc384e0dd45dc36b4b517fd9fae874b06f0
It could still do QoS but refuse aggregation sessions on anything but
TID 0 and 1?
johannes
^ permalink raw reply
* Compat-wireless release for 2011-01-20 is baked
From: Compat-wireless cronjob account @ 2011-01-20 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
143a29f..fc5eb2b history -> origin/history
+ a3d484f...212a2fa master -> origin/master (forced update)
* [new tag] next-20110120 -> next-20110120
compat-wireless code metrics
783319 - 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.1977 - % 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-20110120
compat-wireless release: compat-wireless-2011-01-06-3-g8db1608-pc
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Helmut Schaa @ 2011-01-20 19:14 UTC (permalink / raw)
To: Ben Greear; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <4D387D25.7080902@candelatech.com>
Am Donnerstag, 20. Januar 2011 schrieb Ben Greear:
> On 01/20/2011 10:17 AM, Johannes Berg wrote:
> > Yeah, so maybe it needs some re-work, but I think what you're doing is a
> > pretty strange hack.
>
> If you have time to write some patches, I'll be happy to test them on
> our ath9k and ath5k systems.
Try this, I only ran a quick test with iwlagn (disable_hw_scan=1), seems to
work fine. However, I did not think much about it yet ;)
Helmut
From: Helmut Schaa <helmut.schaa@googlemail.com>
Date: Thu, 20 Jan 2011 20:11:51 +0100
Subject: [PATCH] mac80211: Scan operating channel without enabling PS
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
net/mac80211/rx.c | 13 +++++++++----
net/mac80211/scan.c | 43 ++++++++++++++++++++++++++++---------------
2 files changed, 37 insertions(+), 19 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index a6701ed..d710149 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -388,6 +388,7 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
struct ieee80211_local *local = rx->local;
struct ieee80211_rx_status *status = IEEE80211_SKB_RXCB(rx->skb);
struct sk_buff *skb = rx->skb;
+ int ret;
if (likely(!(status->rx_flags & IEEE80211_RX_IN_SCAN)))
return RX_CONTINUE;
@@ -396,10 +397,14 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
return ieee80211_scan_rx(rx->sdata, skb);
if (test_bit(SCAN_SW_SCANNING, &local->scanning)) {
- /* drop all the other packets during a software scan anyway */
- if (ieee80211_scan_rx(rx->sdata, skb) != RX_QUEUED)
+ ret = ieee80211_scan_rx(rx->sdata, skb);
+ /* drop all the other packets while scanning off channel */
+ if (ret != RX_QUEUED &&
+ test_bit(SCAN_OFF_CHANNEL, &local->scanning)) {
dev_kfree_skb(skb);
- return RX_QUEUED;
+ return RX_QUEUED;
+ }
+ return ret;
}
/* scanning finished during invoking of handlers */
@@ -2730,7 +2735,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
local->dot11ReceivedFragmentCount++;
if (unlikely(test_bit(SCAN_HW_SCANNING, &local->scanning) ||
- test_bit(SCAN_OFF_CHANNEL, &local->scanning)))
+ test_bit(SCAN_SW_SCANNING, &local->scanning)))
status->rx_flags |= IEEE80211_RX_IN_SCAN;
if (ieee80211_is_mgmt(fc))
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..bcc8a3e 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -486,7 +486,15 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
}
mutex_unlock(&local->iflist_mtx);
- if (local->scan_channel) {
+ if (local->scan_channel == local->oper_channel ||
+ local->scan_channel == NULL) {
+ /*
+ * we're on the operating channel currently, let's
+ * leave that channel now to scan another one
+ */
+ local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
+ }
+ else {
/*
* we're currently scanning a different channel, let's
* see if we can scan another channel without interfering
@@ -520,12 +528,6 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
local->next_scan_state = SCAN_ENTER_OPER_CHANNEL;
else
local->next_scan_state = SCAN_SET_CHANNEL;
- } else {
- /*
- * we're on the operating channel currently, let's
- * leave that channel now to scan another one
- */
- local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
}
*next_delay = 0;
@@ -534,6 +536,21 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
static void ieee80211_scan_state_leave_oper_channel(struct ieee80211_local *local,
unsigned long *next_delay)
{
+ struct ieee80211_channel *chan;
+ chan = local->scan_req->channels[local->scan_channel_idx];
+
+ /* remember when we left the operating channel */
+ local->leave_oper_channel_time = jiffies;
+
+ /* advance to the next channel to be scanned */
+ local->next_scan_state = SCAN_SET_CHANNEL;
+
+ /* Scanning operating channel, take the shortcut */
+ if (chan == local->oper_channel) {
+ *next_delay = 0;
+ return;
+ }
+
ieee80211_offchannel_stop_station(local);
__set_bit(SCAN_OFF_CHANNEL, &local->scanning);
@@ -546,12 +563,6 @@ static void ieee80211_scan_state_leave_oper_channel(struct ieee80211_local *loca
*next_delay = 0;
else
*next_delay = HZ / 10;
-
- /* remember when we left the operating channel */
- local->leave_oper_channel_time = jiffies;
-
- /* advance to the next channel to be scanned */
- local->next_scan_state = SCAN_SET_CHANNEL;
}
static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *local,
@@ -583,8 +594,10 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
chan = local->scan_req->channels[local->scan_channel_idx];
local->scan_channel = chan;
- if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
- skip = 1;
+
+ if (chan != local->oper_channel)
+ if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
+ skip = 1;
/* advance state machine to next channel/band */
local->scan_channel_idx++;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] staging: brcm80211: fix suspend/resume issue in brcmsmac
From: Greg KH @ 2011-01-20 20:17 UTC (permalink / raw)
To: Arend van Spriel; +Cc: gregkh, devel, linux-wireless
In-Reply-To: <1294855167-3718-1-git-send-email-arend@broadcom.com>
On Wed, Jan 12, 2011 at 06:59:27PM +0100, Arend van Spriel wrote:
> PCI PM suspend callback took down the interface and resume brought
> it back up. In the mac80211 context this is done in subsequent calls.
> Rework implementation so that suspend only stores config, and sets
> PCI power state. The resume return to full power state (D0), restores
> the config, and brings hardware back up. Full bringup is done by
> subsequent mac80211 calls.
>
> Reviewed-by: Brett Rudley <brudley@broadcom.com>
> Signed-off-by: Arend van Spriel <arend@broadcom.com>
> ---
> drivers/staging/brcm80211/brcmsmac/wl_mac80211.c | 28 ++++++++++++---------
> drivers/staging/brcm80211/brcmsmac/wl_mac80211.h | 4 +--
> 2 files changed, 17 insertions(+), 15 deletions(-)
This patch doesn't apply to Linus's tree, which is where it needs to go
right now. Can you please redo it so that I can apply it?
thanks,
greg k-h
^ permalink raw reply
* [PATCH 3/3] wl12xx: AP mode - support hidden SSID
From: Arik Nemtsov @ 2011-01-20 20:28 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295555306-20005-1-git-send-email-arik@wizery.com>
Detect whether our SSID is hidden by comparing beacon data with
the SSID in bss_conf.
If a hidden SSID is requested, generate a probe response tamplate
containing the real SSID.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
drivers/net/wireless/wl12xx/cmd.c | 23 ++++------
drivers/net/wireless/wl12xx/main.c | 81 ++++++++++++++++++++++++++++++++----
2 files changed, 83 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/cmd.c b/drivers/net/wireless/wl12xx/cmd.c
index e28d9ca..7a6f39e 100644
--- a/drivers/net/wireless/wl12xx/cmd.c
+++ b/drivers/net/wireless/wl12xx/cmd.c
@@ -966,16 +966,6 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
wl1271_debug(DEBUG_CMD, "cmd start bss");
- /*
- * FIXME: We currently do not support hidden SSID. The real SSID
- * should be fetched from mac80211 first.
- */
- if (wl->ssid_len == 0) {
- wl1271_warning("Hidden SSID currently not supported for AP");
- ret = -EINVAL;
- goto out;
- }
-
cmd = kzalloc(sizeof(*cmd), GFP_KERNEL);
if (!cmd) {
ret = -ENOMEM;
@@ -993,9 +983,16 @@ int wl1271_cmd_start_bss(struct wl1271 *wl)
cmd->dtim_interval = bss_conf->dtim_period;
cmd->beacon_expiry = WL1271_AP_DEF_BEACON_EXP;
cmd->channel = wl->channel;
- cmd->ssid_len = wl->ssid_len;
- cmd->ssid_type = SSID_TYPE_PUBLIC;
- memcpy(cmd->ssid, wl->ssid, wl->ssid_len);
+
+ /* We use a visible SSID if the beacon SSID matches bss_conf */
+ if (wl->ssid_len > 0 && wl->ssid_len == bss_conf->ssid_len &&
+ !memcmp(wl->ssid, bss_conf->ssid, wl->ssid_len))
+ cmd->ssid_type = SSID_TYPE_PUBLIC;
+ else
+ cmd->ssid_type = SSID_TYPE_HIDDEN;
+
+ cmd->ssid_len = bss_conf->ssid_len;
+ memcpy(cmd->ssid, bss_conf->ssid, bss_conf->ssid_len);
switch (wl->band) {
case IEEE80211_BAND_2GHZ:
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 9076555..b73d750 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -2041,6 +2041,66 @@ static int wl1271_ssid_set(struct wl1271 *wl, struct sk_buff *skb,
return -ENOENT;
}
+static int wl1271_ap_set_probe_resp_tmpl(struct wl1271 *wl,
+ u8 *probe_rsp_data,
+ size_t probe_rsp_len,
+ u32 rates)
+{
+ struct ieee80211_bss_conf *bss_conf = &wl->vif->bss_conf;
+ u8 probe_rsp_templ[WL1271_CMD_TEMPL_MAX_SIZE];
+ int ssid_ie_offset, ie_offset, templ_len;
+ u8 *ptr;
+
+ /* no need to change probe response if the SSID is set correctly */
+ if (wl->ssid_len > 0 && wl->ssid_len == bss_conf->ssid_len &&
+ !memcmp(wl->ssid, bss_conf->ssid, wl->ssid_len))
+ return wl1271_cmd_template_set(wl,
+ CMD_TEMPL_AP_PROBE_RESPONSE,
+ probe_rsp_data,
+ probe_rsp_len, 0,
+ rates);
+
+ if (probe_rsp_len + bss_conf->ssid_len > WL1271_CMD_TEMPL_MAX_SIZE) {
+ wl1271_error("probe_rsp template too big");
+ return -EINVAL;
+ }
+
+ /* start searching from IE offset */
+ ie_offset = offsetof(struct ieee80211_mgmt, u.probe_resp.variable);
+ ptr = probe_rsp_data + ie_offset;
+
+ while (ptr < probe_rsp_data + probe_rsp_len) {
+ if (ptr[0] == WLAN_EID_SSID)
+ break;
+ ptr += (ptr[1] + 2);
+ }
+
+ if (ptr == probe_rsp_data + probe_rsp_len)
+ return -EINVAL;
+
+ ssid_ie_offset = ptr - probe_rsp_data;
+ ptr += (ptr[1] + 2);
+
+ memcpy(probe_rsp_templ, probe_rsp_data, ssid_ie_offset);
+
+ /* insert SSID from bss_conf */
+ probe_rsp_templ[ssid_ie_offset] = WLAN_EID_SSID;
+ probe_rsp_templ[ssid_ie_offset + 1] = bss_conf->ssid_len;
+ memcpy(probe_rsp_templ + ssid_ie_offset + 2,
+ bss_conf->ssid, bss_conf->ssid_len);
+ templ_len = ssid_ie_offset + 2 + bss_conf->ssid_len;
+
+ memcpy(probe_rsp_templ + ssid_ie_offset + 2 + bss_conf->ssid_len,
+ ptr, probe_rsp_len - (ptr - probe_rsp_data));
+ templ_len += probe_rsp_len - (ptr - probe_rsp_data);
+
+ return wl1271_cmd_template_set(wl,
+ CMD_TEMPL_AP_PROBE_RESPONSE,
+ probe_rsp_templ,
+ templ_len, 0,
+ rates);
+}
+
static int wl1271_bss_erp_info_changed(struct wl1271 *wl,
struct ieee80211_bss_conf *bss_conf,
u32 changed)
@@ -2126,20 +2186,25 @@ static int wl1271_bss_beacon_info_changed(struct wl1271 *wl,
hdr = (struct ieee80211_hdr *) beacon->data;
hdr->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_PROBE_RESP);
-
- tmpl_id = is_ap ? CMD_TEMPL_AP_PROBE_RESPONSE :
- CMD_TEMPL_PROBE_RESPONSE;
- ret = wl1271_cmd_template_set(wl,
- tmpl_id,
- beacon->data,
- beacon->len, 0,
- wl1271_tx_min_rate_get(wl));
+ if (is_ap)
+ ret = wl1271_ap_set_probe_resp_tmpl(wl,
+ beacon->data,
+ beacon->len,
+ wl1271_tx_min_rate_get(wl));
+ else
+ ret = wl1271_cmd_template_set(wl,
+ CMD_TEMPL_PROBE_RESPONSE,
+ beacon->data,
+ beacon->len, 0,
+ wl1271_tx_min_rate_get(wl));
dev_kfree_skb(beacon);
if (ret < 0)
goto out;
}
out:
+ if (ret != 0)
+ wl1271_error("beacon info change failed: %d", ret);
return ret;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] nl80211: allow passing SSID in nl80211_set_bss
From: Arik Nemtsov @ 2011-01-20 20:28 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
wl12xx cards require knowledge of the real SSID when operating as AP
with SSID hidden in beacon data. Allow passing the real SSID from
usermode apart from beacon data.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/net/cfg80211.h | 5 +++++
net/wireless/nl80211.c | 8 ++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 1322695..03b1b0c 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -607,6 +607,9 @@ struct mpath_info {
* @ap_isolate: do not forward packets between connected stations
* @ht_opmode: HT Operation mode
* (u16 = opmode, -1 = do not change)
+ * @ssid_len: length of ssid string
+ * (>0 = ssid_len, -1 = do not change)
+ * @ssid: SSID string (for AP mode). NULL termination not required.
*/
struct bss_parameters {
int use_cts_prot;
@@ -616,6 +619,8 @@ struct bss_parameters {
u8 basic_rates_len;
int ap_isolate;
int ht_opmode;
+ int ssid_len;
+ u8 *ssid;
};
/*
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 9b62710..ce5453d 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2576,6 +2576,7 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
params.use_short_slot_time = -1;
params.ap_isolate = -1;
params.ht_opmode = -1;
+ params.ssid_len = -1;
if (info->attrs[NL80211_ATTR_BSS_CTS_PROT])
params.use_cts_prot =
@@ -2597,6 +2598,13 @@ static int nl80211_set_bss(struct sk_buff *skb, struct genl_info *info)
if (info->attrs[NL80211_ATTR_BSS_HT_OPMODE])
params.ht_opmode =
nla_get_u16(info->attrs[NL80211_ATTR_BSS_HT_OPMODE]);
+ if (info->attrs[NL80211_ATTR_SSID]) {
+ params.ssid = nla_data(info->attrs[NL80211_ATTR_SSID]);
+ params.ssid_len = nla_len(info->attrs[NL80211_ATTR_SSID]);
+ if (params.ssid_len == 0 ||
+ params.ssid_len > IEEE80211_MAX_SSID_LEN)
+ return -EINVAL;
+ }
if (!rdev->ops->change_bss)
return -EOPNOTSUPP;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] mac80211: add SSID for AP mode with change notification
From: Arik Nemtsov @ 2011-01-20 20:28 UTC (permalink / raw)
To: linux-wireless
Cc: Luciano Coelho, Johannes Berg, John W. Linville, Arik Nemtsov
In-Reply-To: <1295555306-20005-1-git-send-email-arik@wizery.com>
When operating as AP, save SSID data as part of the ieee80211_bss_conf
struct. Allow low level drivers to receive notifications about SSID
changes.
Signed-off-by: Arik Nemtsov <arik@wizery.com>
---
include/net/mac80211.h | 6 ++++++
net/mac80211/cfg.c | 7 +++++++
net/mac80211/util.c | 7 ++++++-
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 62c0ce2..ff3bad1 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -164,6 +164,7 @@ struct ieee80211_low_level_stats {
* @BSS_CHANGED_QOS: QoS for this association was enabled/disabled. Note
* that it is only ever disabled for station mode.
* @BSS_CHANGED_IDLE: Idle changed for this BSS/interface.
+ * @BSS_CHANGED_SSID: SSID changed for this BSS (AP mode)
*/
enum ieee80211_bss_change {
BSS_CHANGED_ASSOC = 1<<0,
@@ -181,6 +182,7 @@ enum ieee80211_bss_change {
BSS_CHANGED_ARP_FILTER = 1<<12,
BSS_CHANGED_QOS = 1<<13,
BSS_CHANGED_IDLE = 1<<14,
+ BSS_CHANGED_SSID = 1<<15,
/* when adding here, make sure to change ieee80211_reconfig */
};
@@ -243,6 +245,8 @@ enum ieee80211_bss_change {
* @idle: This interface is idle. There's also a global idle flag in the
* hardware config which may be more appropriate depending on what
* your driver/device needs to do.
+ * @ssid_len: Length of @ssid in octets (in AP mode)
+ * @ssid: SSID for this BSS (in AP mode)
*/
struct ieee80211_bss_conf {
const u8 *bssid;
@@ -269,6 +273,8 @@ struct ieee80211_bss_conf {
bool arp_filter_enabled;
bool qos;
bool idle;
+ u8 ssid_len;
+ u8 ssid[IEEE80211_MAX_SSID_LEN];
};
/**
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 4bc8a92..a2a75e9 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -1172,6 +1172,13 @@ static int ieee80211_change_bss(struct wiphy *wiphy,
changed |= BSS_CHANGED_HT;
}
+ if (params->ssid_len > 0) {
+ memcpy(sdata->vif.bss_conf.ssid, params->ssid,
+ params->ssid_len);
+ sdata->vif.bss_conf.ssid_len = params->ssid_len;
+ changed |= BSS_CHANGED_SSID;
+ }
+
ieee80211_bss_info_change_notify(sdata, changed);
return 0;
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index cf68700..a2d2f73 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1212,10 +1212,15 @@ int ieee80211_reconfig(struct ieee80211_local *local)
changed |= BSS_CHANGED_ASSOC;
ieee80211_bss_info_change_notify(sdata, changed);
break;
+ case NL80211_IFTYPE_AP:
+ changed |= BSS_CHANGED_SSID |
+ BSS_CHANGED_BEACON |
+ BSS_CHANGED_BEACON_ENABLED;
+ ieee80211_bss_info_change_notify(sdata, changed);
+ break;
case NL80211_IFTYPE_ADHOC:
changed |= BSS_CHANGED_IBSS;
/* fall through */
- case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_MESH_POINT:
changed |= BSS_CHANGED_BEACON |
BSS_CHANGED_BEACON_ENABLED;
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] nl80211: allow passing SSID in nl80211_set_bss
From: Johannes Berg @ 2011-01-20 20:52 UTC (permalink / raw)
To: Arik Nemtsov; +Cc: linux-wireless, Luciano Coelho, John W. Linville
In-Reply-To: <1295555306-20005-1-git-send-email-arik@wizery.com>
On Thu, 2011-01-20 at 22:28 +0200, Arik Nemtsov wrote:
> wl12xx cards require knowledge of the real SSID when operating as AP
> with SSID hidden in beacon data. Allow passing the real SSID from
> usermode apart from beacon data.
As I also just commented on the corresponding hostapd patch, I'm not
sure this is sufficient. If this is necessary for probe response
offloading, I'm tempted to say that we should be honest about it and let
userspace determine the entire probe response (which will contain the
correct SSID) since it can be different from the beacon which presumably
you're now using to generate probe responses.
johannes
^ permalink raw reply
* [PATCH 2/2] ath9k: clean up the code that wakes the mac80211 queues
From: Felix Fietkau @ 2011-01-20 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1295557051-64138-1-git-send-email-nbd@openwrt.org>
Instead of spreading ath_wake_mac80211_queue() calls over multiple places
in the tx path that process the tx queue for completion, call it only
where the pending frames counter gets decremented, eliminating some
redundant checks.
To prevent queue draining from waking the queues prematurely (e.g. during
a hardware reset), reset the queue stop state when draining all queues,
as the caller in main.c will run ieee80211_wake_queues(hw) anyway.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/main.c | 2 +
drivers/net/wireless/ath/ath9k/xmit.c | 43 ++++++++++++--------------------
2 files changed, 18 insertions(+), 27 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index c03184e..bee1db1 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -295,6 +295,8 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
}
ps_restore:
+ ieee80211_wake_queues(hw);
+
spin_unlock_bh(&sc->sc_pcu_lock);
ath9k_ps_restore(sc);
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index ad569e1..4695abc 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1208,8 +1208,17 @@ bool ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
ath_err(common, "Failed to stop TX DMA!\n");
for (i = 0; i < ATH9K_NUM_TX_QUEUES; i++) {
- if (ATH_TXQ_SETUP(sc, i))
- ath_draintxq(sc, &sc->tx.txq[i], retry_tx);
+ if (!ATH_TXQ_SETUP(sc, i))
+ continue;
+
+ /*
+ * The caller will resume queues with ieee80211_wake_queues.
+ * Mark the queue as not stopped to prevent ath_tx_complete
+ * from waking the queue too early.
+ */
+ txq = &sc->tx.txq[i];
+ txq->stopped = false;
+ ath_draintxq(sc, txq, retry_tx);
}
return !npend;
@@ -1863,6 +1872,11 @@ static void ath_tx_complete(struct ath_softc *sc, struct sk_buff *skb,
spin_lock_bh(&txq->axq_lock);
if (WARN_ON(--txq->pending_frames < 0))
txq->pending_frames = 0;
+
+ if (txq->stopped && txq->pending_frames < ATH_MAX_QDEPTH) {
+ if (ath_mac80211_start_queue(sc, q))
+ txq->stopped = 0;
+ }
spin_unlock_bh(&txq->axq_lock);
}
@@ -1972,19 +1986,6 @@ static void ath_tx_rc_status(struct ath_buf *bf, struct ath_tx_status *ts,
tx_info->status.rates[tx_rateindex].count = ts->ts_longretry + 1;
}
-static void ath_wake_mac80211_queue(struct ath_softc *sc, int qnum)
-{
- struct ath_txq *txq;
-
- txq = sc->tx.txq_map[qnum];
- spin_lock_bh(&txq->axq_lock);
- if (txq->stopped && txq->pending_frames < ATH_MAX_QDEPTH) {
- if (ath_mac80211_start_queue(sc, qnum))
- txq->stopped = 0;
- }
- spin_unlock_bh(&txq->axq_lock);
-}
-
static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
{
struct ath_hw *ah = sc->sc_ah;
@@ -1995,7 +1996,6 @@ static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
struct ath_tx_status ts;
int txok;
int status;
- int qnum;
ath_dbg(common, ATH_DBG_QUEUE, "tx queue %d (%x), link %p\n",
txq->axq_qnum, ath9k_hw_gettxbuf(sc->sc_ah, txq->axq_qnum),
@@ -2074,17 +2074,12 @@ static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
ath_tx_rc_status(bf, &ts, 1, txok ? 0 : 1, txok, true);
}
- qnum = skb_get_queue_mapping(bf->bf_mpdu);
-
if (bf_isampdu(bf))
ath_tx_complete_aggr(sc, txq, bf, &bf_head, &ts, txok,
true);
else
ath_tx_complete_buf(sc, bf, txq, &bf_head, &ts, txok, 0);
- if (txq == sc->tx.txq_map[qnum])
- ath_wake_mac80211_queue(sc, qnum);
-
spin_lock_bh(&txq->axq_lock);
if (sc->sc_flags & SC_OP_TXAGGR)
ath_txq_schedule(sc, txq);
@@ -2153,7 +2148,6 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
struct list_head bf_head;
int status;
int txok;
- int qnum;
for (;;) {
status = ath9k_hw_txprocdesc(ah, NULL, (void *)&txs);
@@ -2199,8 +2193,6 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
ath_tx_rc_status(bf, &txs, 1, txok ? 0 : 1, txok, true);
}
- qnum = skb_get_queue_mapping(bf->bf_mpdu);
-
if (bf_isampdu(bf))
ath_tx_complete_aggr(sc, txq, bf, &bf_head, &txs,
txok, true);
@@ -2208,9 +2200,6 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
ath_tx_complete_buf(sc, bf, txq, &bf_head,
&txs, txok, 0);
- if (txq == sc->tx.txq_map[qnum])
- ath_wake_mac80211_queue(sc, qnum);
-
spin_lock_bh(&txq->axq_lock);
if (!list_empty(&txq->txq_fifo_pending)) {
INIT_LIST_HEAD(&bf_head);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/2] ath9k: remove a bogus error message
From: Felix Fietkau @ 2011-01-20 20:57 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
When beacons are being added or removed for an interface, ieee80211_beacon_get
will sometimes not return a beacon. This is normal and should not result in
useless logspam.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/beacon.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/beacon.c b/drivers/net/wireless/ath/ath9k/beacon.c
index 8de591e..ab8c05c 100644
--- a/drivers/net/wireless/ath/ath9k/beacon.c
+++ b/drivers/net/wireless/ath/ath9k/beacon.c
@@ -279,10 +279,8 @@ int ath_beacon_alloc(struct ath_wiphy *aphy, struct ieee80211_vif *vif)
/* NB: the beacon data buffer must be 32-bit aligned. */
skb = ieee80211_beacon_get(sc->hw, vif);
- if (skb == NULL) {
- ath_err(common, "ieee80211_beacon_get failed\n");
+ if (skb == NULL)
return -ENOMEM;
- }
tstamp = ((struct ieee80211_mgmt *)skb->data)->u.beacon.timestamp;
sc->beacon.bc_tstamp = le64_to_cpu(tstamp);
--
1.7.3.2
^ permalink raw reply related
* [PATCH] Fix NULL dereference in rtlwifi driver
From: Jesper Juhl @ 2011-01-20 22:18 UTC (permalink / raw)
To: Larry Finger
Cc: netdev, linux-wireless, linux-kernel, John W. Linville,
Chaoming Li
In drivers/net/wireless/rtlwifi/pci.c::_rtl_pci_rx_interrupt() we call
dev_alloc_skb(), which may fail and return NULL, but we do not check the
returned value against NULL before dereferencing the returned pointer.
This may lead to a NULL pointer dereference which means we'll crash - not
good.
This patch tries to solve the issue by testing for NULL and bailing out if
we couldn't allocate a skb. However, I don't know this code well, so I'm
not sure that jumping to the 'done' label here is the correct action to
take. Someone more knowledgable about this code than me should definately
review it before it is applied anywhere.
While I was in the area I also moved an assignment in
_rtl_pci_init_rx_ring() a bit - if the dev_alloc_skb() call in that
function fails there's no reason to waste clock cycles assigning to the
local variable 'entry', we may as well do that after the NULL check and
potential bail out.
Here's the proposed patch, but please don't take it as much more than a
bug report. If it happens to be correct, then by all means apply it, but
I'm not personally making any guarantees.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
---
pci.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
compile tested only, I don't have the hardware to test for real.
diff --git a/drivers/net/wireless/rtlwifi/pci.c b/drivers/net/wireless/rtlwifi/pci.c
index 0fa36aa..5e99f89 100644
--- a/drivers/net/wireless/rtlwifi/pci.c
+++ b/drivers/net/wireless/rtlwifi/pci.c
@@ -619,6 +619,13 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
struct sk_buff *uskb = NULL;
u8 *pdata;
uskb = dev_alloc_skb(skb->len + 128);
+ if (!uskb) {
+ RT_TRACE(rtlpriv,
+ (COMP_INTR | COMP_RECV),
+ DBG_DMESG,
+ ("can't alloc rx skb\n"));
+ goto done;
+ }
memcpy(IEEE80211_SKB_RXCB(uskb),
&rx_status,
sizeof(rx_status));
@@ -1066,9 +1073,9 @@ static int _rtl_pci_init_rx_ring(struct ieee80211_hw *hw)
struct sk_buff *skb =
dev_alloc_skb(rtlpci->rxbuffersize);
u32 bufferaddress;
- entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
if (!skb)
return 0;
+ entry = &rtlpci->rx_ring[rx_queue_idx].desc[i];
/*skb->dev = dev; */
--
Jesper Juhl <jj@chaosbits.net> http://www.chaosbits.net/
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please.
^ permalink raw reply related
* [PATCH 3/4] ath9k: remove the bf->aphy field
From: Felix Fietkau @ 2011-01-20 22:25 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
In-Reply-To: <1295562349-17161-2-git-send-email-nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ath9k.h | 3 +-
drivers/net/wireless/ath/ath9k/xmit.c | 38 +++++++++++++------------------
2 files changed, 17 insertions(+), 24 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 3caa54d..fe6a69c 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -32,6 +32,7 @@
*/
struct ath_node;
+struct ath_wiphy;
/* Macro to expand scalars to 64-bit objects */
@@ -233,7 +234,6 @@ struct ath_buf {
bool bf_stale;
u16 bf_flags;
struct ath_buf_state bf_state;
- struct ath_wiphy *aphy;
};
struct ath_atx_tid {
@@ -556,7 +556,6 @@ struct ath_ant_comb {
#define PS_WAIT_FOR_TX_ACK BIT(3)
#define PS_BEACON_SYNC BIT(4)
-struct ath_wiphy;
struct ath_rate_table;
struct ath9k_vif_iter_data {
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index a7c3048..80dc0cc 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -57,8 +57,9 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
static void ath_tx_txqaddbuf(struct ath_softc *sc, struct ath_txq *txq,
struct list_head *head);
static void ath_buf_set_rate(struct ath_softc *sc, struct ath_buf *bf, int len);
-static void ath_tx_rc_status(struct ath_buf *bf, struct ath_tx_status *ts,
- int nframes, int nbad, int txok, bool update_rc);
+static void ath_tx_rc_status(struct ath_softc *sc, struct ath_buf *bf,
+ struct ath_tx_status *ts, int nframes, int nbad,
+ int txok, bool update_rc);
static void ath_tx_update_baw(struct ath_softc *sc, struct ath_atx_tid *tid,
int seqno);
@@ -297,7 +298,6 @@ static struct ath_buf* ath_clone_txbuf(struct ath_softc *sc, struct ath_buf *bf)
ATH_TXBUF_RESET(tbf);
- tbf->aphy = bf->aphy;
tbf->bf_mpdu = bf->bf_mpdu;
tbf->bf_buf_addr = bf->bf_buf_addr;
memcpy(tbf->bf_desc, bf->bf_desc, sc->sc_ah->caps.tx_desc_len);
@@ -345,7 +345,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
struct ath_node *an = NULL;
struct sk_buff *skb;
struct ieee80211_sta *sta;
- struct ieee80211_hw *hw;
+ struct ieee80211_hw *hw = sc->hw;
struct ieee80211_hdr *hdr;
struct ieee80211_tx_info *tx_info;
struct ath_atx_tid *tid = NULL;
@@ -364,7 +364,6 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
hdr = (struct ieee80211_hdr *)skb->data;
tx_info = IEEE80211_SKB_CB(skb);
- hw = bf->aphy->hw;
memcpy(rates, tx_info->control.rates, sizeof(rates));
@@ -383,7 +382,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
!bf->bf_stale || bf_next != NULL)
list_move_tail(&bf->list, &bf_head);
- ath_tx_rc_status(bf, ts, 1, 1, 0, false);
+ ath_tx_rc_status(sc, bf, ts, 1, 1, 0, false);
ath_tx_complete_buf(sc, bf, txq, &bf_head, ts,
0, 0);
@@ -489,10 +488,10 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
if (rc_update && (acked_cnt == 1 || txfail_cnt == 1)) {
memcpy(tx_info->control.rates, rates, sizeof(rates));
- ath_tx_rc_status(bf, ts, nframes, nbad, txok, true);
+ ath_tx_rc_status(sc, bf, ts, nframes, nbad, txok, true);
rc_update = false;
} else {
- ath_tx_rc_status(bf, ts, nframes, nbad, txok, false);
+ ath_tx_rc_status(sc, bf, ts, nframes, nbad, txok, false);
}
ath_tx_complete_buf(sc, bf, txq, &bf_head, ts,
@@ -516,7 +515,7 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
bf->bf_state.bf_type |=
BUF_XRETRY;
- ath_tx_rc_status(bf, ts, nframes,
+ ath_tx_rc_status(sc, bf, ts, nframes,
nbad, 0, false);
ath_tx_complete_buf(sc, bf, txq,
&bf_head,
@@ -1667,7 +1666,6 @@ static struct ath_buf *ath_tx_setup_buffer(struct ieee80211_hw *hw,
ATH_TXBUF_RESET(bf);
- bf->aphy = aphy;
bf->bf_flags = setup_tx_flags(skb);
bf->bf_mpdu = skb;
@@ -1821,8 +1819,7 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
/*****************/
static void ath_tx_complete(struct ath_softc *sc, struct sk_buff *skb,
- struct ath_wiphy *aphy, int tx_flags, int ftype,
- struct ath_txq *txq)
+ int tx_flags, int ftype, struct ath_txq *txq)
{
struct ieee80211_hw *hw = sc->hw;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
@@ -1832,9 +1829,6 @@ static void ath_tx_complete(struct ath_softc *sc, struct sk_buff *skb,
ath_dbg(common, ATH_DBG_XMIT, "TX complete: skb: %p\n", skb);
- if (aphy)
- hw = aphy->hw;
-
if (tx_flags & ATH_TX_BAR)
tx_info->flags |= IEEE80211_TX_STAT_AMPDU_NO_BACK;
@@ -1908,7 +1902,7 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
complete(&sc->paprd_complete);
} else {
ath_debug_stat_tx(sc, bf, ts);
- ath_tx_complete(sc, skb, bf->aphy, tx_flags,
+ ath_tx_complete(sc, skb, tx_flags,
bf->bf_state.bfs_ftype, txq);
}
/* At this point, skb (bf->bf_mpdu) is consumed...make sure we don't
@@ -1924,14 +1918,14 @@ static void ath_tx_complete_buf(struct ath_softc *sc, struct ath_buf *bf,
spin_unlock_irqrestore(&sc->tx.txbuflock, flags);
}
-static void ath_tx_rc_status(struct ath_buf *bf, struct ath_tx_status *ts,
- int nframes, int nbad, int txok, bool update_rc)
+static void ath_tx_rc_status(struct ath_softc *sc, struct ath_buf *bf,
+ struct ath_tx_status *ts, int nframes, int nbad,
+ int txok, bool update_rc)
{
struct sk_buff *skb = bf->bf_mpdu;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
- struct ieee80211_hw *hw = bf->aphy->hw;
- struct ath_softc *sc = bf->aphy->sc;
+ struct ieee80211_hw *hw = sc->hw;
struct ath_hw *ah = sc->sc_ah;
u8 i, tx_rateindex;
@@ -2067,7 +2061,7 @@ static void ath_tx_processq(struct ath_softc *sc, struct ath_txq *txq)
*/
if (ts.ts_status & ATH9K_TXERR_XRETRY)
bf->bf_state.bf_type |= BUF_XRETRY;
- ath_tx_rc_status(bf, &ts, 1, txok ? 0 : 1, txok, true);
+ ath_tx_rc_status(sc, bf, &ts, 1, txok ? 0 : 1, txok, true);
}
if (bf_isampdu(bf))
@@ -2186,7 +2180,7 @@ void ath_tx_edma_tasklet(struct ath_softc *sc)
if (!bf_isampdu(bf)) {
if (txs.ts_status & ATH9K_TXERR_XRETRY)
bf->bf_state.bf_type |= BUF_XRETRY;
- ath_tx_rc_status(bf, &txs, 1, txok ? 0 : 1, txok, true);
+ ath_tx_rc_status(sc, bf, &txs, 1, txok ? 0 : 1, txok, true);
}
if (bf_isampdu(bf))
--
1.7.3.2
^ 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