* Re: OOPS in cfg80211_conn_work
From: Johannes Berg @ 2009-10-30 6:49 UTC (permalink / raw)
To: Parag Warudkar; +Cc: LKML, linux-wireless
In-Reply-To: <f7848160910291617q2b168089l5ce489d2f47ebe96@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 382 bytes --]
On Thu, 2009-10-29 at 19:17 -0400, Parag Warudkar wrote:
> Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
> deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
> Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
> probe to AP 00:16:01:d6:6f:12 (try 1)
sorry, I can't read this log. please provide a non-wrapped version
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC] ath9k: fix listening to idle requests
From: Vasanthakumar Thiagarajan @ 2009-10-30 6:33 UTC (permalink / raw)
To: Luis Rodriguez
Cc: Vasanth Thiagarajan, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Luis Rodriguez
In-Reply-To: <1256849546-15119-1-git-send-email-lrodriguez@atheros.com>
On Fri, Oct 30, 2009 at 02:22:26AM +0530, Luis Rodriguez wrote:
> The way idle configuration detection was implemented as
> busted due to the fact that it assumed the ath9k virtual wiphy,
> the aphy, would be marked as inactive if it was not used but
> it turns out an aphy is always active if its the only wiphy
> present. We need to distinguish between aphy activity and
> idleness so we now add an idle bool for the aphy and mark
> it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
> from mac80211.
>
> Previous to all_wiphys_idle would never be true when using
> only one device so we never really were using
> IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
> off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
> changes depended on all_wiphys_idle being true either to
> turn the radio on or off. Since it was always false for
> one device this code was doing nothing.
>
> Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
> ---
>
> Vasanth, what do you think?
Still we will have issue when bringing up a sec wiphy while the
primary wiphy is in idle state. ath9k_start() does not brought up
the newly created wiphy interface when the state of at least one
previously created interface is in ACTIVE state. Unless already
brought up interfaces are put down we hit this situation whenever
we try to bring up a new secondary wiphy interface. So with this
patch the actual h/w will remain radio disabled state even after
a new interface is in active state. We need to bring the h/w into
active state if all old interfaces are in idle state in
ath9k_start().
Vasanth
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-30 5:59 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910292248.42229.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 11:48 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> _really_ prefer to spend your time in pointless arguments, go ahead.
>
> I don't think that my technical arguments are pointless.
>
> Quite the contrary, I'm pretty confident that addressing my review concerns
> would result in better RT28x00 / RT30x0 support in the very near future.
I don't think your technical arguments are pointless either. However,
asking Dave to revert something over John and then arguing about it is
pointless and will likely just piss people off and make them ignore
you.
Pekka
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Zhu Yi @ 2009-10-30 2:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Luis R. Rodriguez, Chatre, Reinette, linville@tuxdriver.com,
linux-wireless@vger.kernel.org
In-Reply-To: <1256842728.3865.128.camel@johannes.local>
On Fri, 2009-10-30 at 02:58 +0800, Johannes Berg wrote:
> Step 1)
> fix a few corner cases other drivers might have, and stick the bit
> of
> code iwlwifi has right before passing the frame to mac80211 into
> mac80211 as the first thing it does with the frame
>
> Step 2)
> Look through rx.c and check how much stuff it really needs
> linearised,
> and where. I suspect that most of the time it _only_ needs the first
> two bytes, until it comes to actually passing the frame up.
>
> Step 3)
> After the audit, push down the linearizing to where needed, i.e.
> management frames completely, other frames up to and including the
> ethernet header, software decryption all of the frame
>
> Step 4)
> make software decryption aware of paged SKBs, and remove the
> linearising in that case
Yes, this sounds like a very good plan.
Thanks,
-yi
^ permalink raw reply
* OOPS in cfg80211_conn_work
From: Parag Warudkar @ 2009-10-29 23:17 UTC (permalink / raw)
To: LKML; +Cc: linux-wireless
Oct 29 18:59:06 parag-laptop kernel: [ 143.180037] wlan0:
deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
Oct 29 18:59:06 parag-laptop kernel: [ 143.181137] wlan0: direct
probe to AP 00:16:01:d6:6f:12 (try 1)
Oct 29 18:59:06 parag-laptop kernel: [ 143.181148] wlan0:
deauthenticating from 00:16:01:d6:6f:12 by local choice (reason=3)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203375] BUG: unable to
handle kernel NULL pointer dereference at (null)
Oct 29 18:59:06 parag-laptop kernel: [ 143.203432] IP:
[<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.203476] PGD 138abc067 PUD
136d87067 PMD 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203530] Oops: 0000 [#1] SMP
Oct 29 18:59:06 parag-laptop kernel: [ 143.203571] last sysfs file:
/sys/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1/controlC1/uevent
Oct 29 18:59:06 parag-laptop kernel: [ 143.203597] CPU 0
Oct 29 18:59:06 parag-laptop kernel: [ 143.203629] Modules linked in:
aes_generic radeon ttm drm_kms_helper drm i2c_algo_bit cfbcopyarea
cfbimgblt cfbfillrect binfmt_misc snd_hda_codec_atihdmi rfcomm
snd_hda_codec_analog sco bnep ppdev l2cap snd_hda_intel arc4
snd_hda_codec snd_pcm_oss snd_mixer_oss snd_hwdep snd_seq_dummy
snd_pcm snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event iwlagn
iptable_filter ext3 snd_seq iwlcore snd_timer led_class snd_seq_device
ip_tables jbd snd mac80211 psmouse btusb x_tables tpm_infineon
soundcore serio_raw bluetooth snd_page_alloc cfg80211 tpm tpm_bios
evdev lp parport ext4 mbcache jbd2 fuse ahci libata video output
intel_agp e1000e
Oct 29 18:59:06 parag-laptop kernel: [ 143.204560] Pid: 9, comm:
events/0 Not tainted 2.6.32-rc5 #2 HP EliteBook 8530p
Oct 29 18:59:06 parag-laptop kernel: [ 143.204588] RIP:
0010:[<ffffffffa0139161>] [<ffffffffa0139161>]
cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.204634] RSP:
0000:ffff88013f8b5dc0 EFLAGS: 00010246
Oct 29 18:59:06 parag-laptop kernel: [ 143.204656] RAX:
0000000000000000 RBX: ffff88013e8db690 RCX: ffff88013cb80118
Oct 29 18:59:06 parag-laptop kernel: [ 143.204679] RDX:
0000000000000000 RSI: 0000000000000282 RDI: ffff88013e8db690
Oct 29 18:59:06 parag-laptop kernel: [ 143.204702] RBP:
ffff88013f8b5e30 R08: 0000000000000000 R09: 0000000000000001
Oct 29 18:59:06 parag-laptop kernel: [ 143.204724] R10:
0000000000000000 R11: ffff880028295718 R12: ffff88013e8db6b8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204747] R13:
ffff88013cb800a8 R14: ffff88013cb80000 R15: ffff88013f8b5df0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204770] FS:
0000000000000000(0000) GS:ffff880028200000(0000)
knlGS:0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204799] CS: 0010 DS: 0018
ES: 0018 CR0: 000000008005003b
Oct 29 18:59:06 parag-laptop kernel: [ 143.204820] CR2:
0000000000000000 CR3: 000000013dde3000 CR4: 00000000000406f0
Oct 29 18:59:06 parag-laptop kernel: [ 143.204843] DR0:
0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.204866] DR3:
0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Oct 29 18:59:06 parag-laptop kernel: [ 143.204889] Process events/0
(pid: 9, threadinfo ffff88013f8b4000, task ffff88013f885980)
Oct 29 18:59:06 parag-laptop kernel: [ 143.204917] Stack:
Oct 29 18:59:06 parag-laptop kernel: [ 143.204936] ffff88013f8b5dc0
ffff88013f8b5dc0 0000000000000282 ffffffff8162afb8
Oct 29 18:59:06 parag-laptop kernel: [ 143.204996] <0>
ffff88013cb80018 ffff88013cb80088 ffff880028218040 ffff88013f8b5fd8
Oct 29 18:59:06 parag-laptop kernel: [ 143.205085] <0>
ffff88013f8b5e10 ffff88013cb80130 ffff880028218040 ffffffffa01390b0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205190] Call Trace:
Oct 29 18:59:06 parag-laptop kernel: [ 143.205215]
[<ffffffffa01390b0>] ? cfg80211_conn_work+0x0/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.205242]
[<ffffffff8106c86f>] worker_thread+0x17f/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205265]
[<ffffffff810710d0>] ? autoremove_wake_function+0x0/0x40
Oct 29 18:59:06 parag-laptop kernel: [ 143.205289]
[<ffffffff8106c6f0>] ? worker_thread+0x0/0x2c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205311]
[<ffffffff81070cfe>] kthread+0x8e/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205334]
[<ffffffff81012f2a>] child_rip+0xa/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205356]
[<ffffffff81070c70>] ? kthread+0x0/0xa0
Oct 29 18:59:06 parag-laptop kernel: [ 143.205378]
[<ffffffff81012f20>] ? child_rip+0x0/0x20
Oct 29 18:59:06 parag-laptop kernel: [ 143.205399] Code: 63 28 4c 89
e7 e8 c0 02 2b e1 48 8b 43 20 f6 40 48 01 74 c6 83 bb 8c 00 00 00 01
75 bd 48 8b 83 90 00 00 00 48 89 df 48 8b 40 08 <8b> 10 41 89 17 0f b7
40 04 66 41 89 47 04 e8 fc ee ff ff 85 c0
Oct 29 18:59:06 parag-laptop kernel: [ 143.206242] RIP
[<ffffffffa0139161>] cfg80211_conn_work+0xb1/0x140 [cfg80211]
Oct 29 18:59:06 parag-laptop kernel: [ 143.206286] RSP <ffff88013f8b5dc0>
Oct 29 18:59:06 parag-laptop kernel: [ 143.206306] CR2: 0000000000000000
Oct 29 18:59:06 parag-laptop kernel: [ 143.206327] ---[ end trace
ccb079f99bd67991 ]---
Oct 29 18:59:58 parag-laptop kernel: Kernel logging (proc) stopped.
^ permalink raw reply
* fyi - ath9k virtual wiphy - another thing we would need to synch
From: Luis R. Rodriguez @ 2009-10-29 23:03 UTC (permalink / raw)
To: Jouni.Malinen; +Cc: linux-wireless
sc->sc_ah->opmode
is used and checked for filtering for example, so if another wiphy is
selected it should update its mode there.
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 21:48 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <84144f020910291245l1a7a3fd6o8822ecd4ce3b5504@mail.gmail.com>
On Thursday 29 October 2009 20:45:07 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> lots of cleanups to the staging drivers, why not direct some of that
> >> energy to the drivers/net/wireless ones?
> >
> > When did we start to apply "fix it yourself" rule instead of "submitter
> > should fix it" one to the _new_ code..
>
> Don't be silly, I didn't say that.
Sorry, I must have misunderstood you.
> I was simply pointing out that your time would probably be better
> spent in improving the "proper" ralink wireless drivers but if you
Thanks for the concern. However recent discussions made my realize how
I should really be spending my time effectively way too well.
> _really_ prefer to spend your time in pointless arguments, go ahead.
I don't think that my technical arguments are pointless.
Quite the contrary, I'm pretty confident that addressing my review concerns
would result in better RT28x00 / RT30x0 support in the very near future.
> It should be pretty obvious by now that the best way to improve things
> is to work with the relevant maintainers, not against them. (Unless
> you wish your work to be ignored, of course.)
I work with a lot of other maintainers. I would say that providing valuable
review feedback is also "working with" (at least I would be very happy with
such feedback in my projects).
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 21:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <1256851738.3865.149.camel@johannes.local>
On Thu, Oct 29, 2009 at 2:28 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-29 at 14:19 -0700, Luis R. Rodriguez wrote:
>> On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> >> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>> >>> I ran into this when ath5k with wpa_supplicant with config file with
>> >>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>> >>> and lets you assoc but later it deauths you -- I guess after it
>> >>> determines you are auth credentials failed. When this happens I get:
>> >>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>> >>
>> >> I'm guessing that you're using -Dnl80211. You need this patch, or
>> >> equivalent:
>> >> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>> >
>> > Indeed, it fixes my woes, thanks.
>>
>> Well almost, after a while of being connected it then does this:
>>
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Associated with 00:0b:85:5b:8d:6c
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Associated with 00:0b:85:5b:9a:bc
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
>> OpenSSL: tls_connection_handshake - Failed to read possible
>> Application Data error:00000000:lib(0):func(0):reason(0)
>>
>> And I then end up with the same:
>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>
> Might be due to that bssid_changed check I was unsure about -- try
> removing that.
OK will do -- it took a while to trigger so will wait and see if it
happens again, and if it happens often enough I can at least confirm
it would fix it. Otherwise not sure what triggered it. I failed to
check the logs to see what disconnect event exactly triggered.
Luis
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Johannes Berg @ 2009-10-29 21:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <43e72e890910291419j7feb7a3dg33cd5b02e064eeee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
On Thu, 2009-10-29 at 14:19 -0700, Luis R. Rodriguez wrote:
> On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
> >>> I ran into this when ath5k with wpa_supplicant with config file with
> >>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
> >>> and lets you assoc but later it deauths you -- I guess after it
> >>> determines you are auth credentials failed. When this happens I get:
> >>>
> >>> mcgrof@tux ~ $ iw dev wlan0 link
> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
> >>> Not connected.
> >>
> >> I'm guessing that you're using -Dnl80211. You need this patch, or
> >> equivalent:
> >> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
> >
> > Indeed, it fixes my woes, thanks.
>
> Well almost, after a while of being connected it then does this:
>
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> CTRL-EVENT-SCAN-RESULTS
> Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
> Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
> Associated with 00:0b:85:5b:8d:6c
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> CTRL-EVENT-SCAN-RESULTS
> Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
> Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
> Associated with 00:0b:85:5b:9a:bc
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
> OpenSSL: tls_connection_handshake - Failed to read possible
> Application Data error:00000000:lib(0):func(0):reason(0)
>
> And I then end up with the same:
>
> >>> mcgrof@tux ~ $ iw dev wlan0 link
> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
> >>> Not connected.
Might be due to that bssid_changed check I was unsure about -- try
removing that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 21:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <43e72e890910291355l5fc4ec2ctb9a777b6e8b07baa@mail.gmail.com>
On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>>> I ran into this when ath5k with wpa_supplicant with config file with
>>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>>> and lets you assoc but later it deauths you -- I guess after it
>>> determines you are auth credentials failed. When this happens I get:
>>>
>>> mcgrof@tux ~ $ iw dev wlan0 link
>>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>>> Not connected.
>>
>> I'm guessing that you're using -Dnl80211. You need this patch, or
>> equivalent:
>> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>
> Indeed, it fixes my woes, thanks.
Well almost, after a while of being connected it then does this:
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
Associated with 00:0b:85:5b:8d:6c
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
Associated with 00:0b:85:5b:9a:bc
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible
Application Data error:00000000:lib(0):func(0):reason(0)
And I then end up with the same:
>>> mcgrof@tux ~ $ iw dev wlan0 link
>>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>>> Not connected.
But this time if I hit ctrl-c it gets cleared and I can auth/assoc
fine after that. But an issue is still present.
Luis
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 20:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <1256761485.4237.260.camel@johannes.local>
On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>> I ran into this when ath5k with wpa_supplicant with config file with
>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>> and lets you assoc but later it deauths you -- I guess after it
>> determines you are auth credentials failed. When this happens I get:
>>
>> mcgrof@tux ~ $ iw dev wlan0 link
>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> Not connected.
>
> I'm guessing that you're using -Dnl80211. You need this patch, or
> equivalent:
> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
Indeed, it fixes my woes, thanks.
Luis
^ permalink raw reply
* [RFC] ath9k: fix listening to idle requests
From: Luis R. Rodriguez @ 2009-10-29 20:52 UTC (permalink / raw)
To: vasanth; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
The way idle configuration detection was implemented as
busted due to the fact that it assumed the ath9k virtual wiphy,
the aphy, would be marked as inactive if it was not used but
it turns out an aphy is always active if its the only wiphy
present. We need to distinguish between aphy activity and
idleness so we now add an idle bool for the aphy and mark
it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
from mac80211.
Previous to all_wiphys_idle would never be true when using
only one device so we never really were using
IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
changes depended on all_wiphys_idle being true either to
turn the radio on or off. Since it was always false for
one device this code was doing nothing.
Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Vasanth, what do you think?
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +
drivers/net/wireless/ath/ath9k/main.c | 33 +++++++++++++++++++++++------
drivers/net/wireless/ath/ath9k/virtual.c | 17 ++++++++++++--
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 13dd020..da53578 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -620,6 +620,7 @@ struct ath_wiphy {
ATH_WIPHY_PAUSED,
ATH_WIPHY_SCAN,
} state;
+ bool idle;
int chan_idx;
int chan_is_ht;
};
@@ -691,6 +692,7 @@ void ath9k_wiphy_pause_all_forced(struct ath_softc *sc,
bool ath9k_wiphy_scanning(struct ath_softc *sc);
void ath9k_wiphy_work(struct work_struct *work);
bool ath9k_all_wiphys_idle(struct ath_softc *sc);
+void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle);
int ath_tx_get_qnum(struct ath_softc *sc, int qtype, int haltype);
#endif /* ATH9K_H */
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 9fefc51..bdce0ab 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2688,22 +2688,37 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ieee80211_conf *conf = &hw->conf;
struct ath_hw *ah = sc->sc_ah;
- bool all_wiphys_idle = false, disable_radio = false;
+ bool disable_radio;
mutex_lock(&sc->mutex);
- /* Leave this as the first check */
+ /*
+ * Leave this as the first check because we need to turn on the
+ * radio if it was disabled before prior to processing the rest
+ * of the changes. Likewise we must only disable the radio towards
+ * the end.
+ */
if (changed & IEEE80211_CONF_CHANGE_IDLE) {
+ bool enable_radio;
+ bool all_wiphys_idle;
+ bool idle = !!(conf->flags & IEEE80211_CONF_IDLE);
spin_lock_bh(&sc->wiphy_lock);
all_wiphys_idle = ath9k_all_wiphys_idle(sc);
+ ath9k_set_wiphy_idle(aphy, idle);
+
+ if (!idle && all_wiphys_idle)
+ enable_radio = true;
+
+ /*
+ * After we unlock here its possible another wiphy
+ * can be re-renabled so to account for that we will
+ * only disable the radio toward the end of this routine
+ * if by then all wiphys are still idle.
+ */
spin_unlock_bh(&sc->wiphy_lock);
- if (conf->flags & IEEE80211_CONF_IDLE){
- if (all_wiphys_idle)
- disable_radio = true;
- }
- else if (all_wiphys_idle) {
+ if (enable_radio) {
ath_radio_enable(sc);
ath_print(common, ATH_DBG_CONFIG,
"not-idle: enabling radio\n");
@@ -2779,6 +2794,10 @@ skip_chan_change:
if (changed & IEEE80211_CONF_CHANGE_POWER)
sc->config.txpowlimit = 2 * conf->power_level;
+ spin_lock_bh(&sc->wiphy_lock);
+ disable_radio = ath9k_all_wiphys_idle(sc);
+ spin_unlock_bh(&sc->wiphy_lock);
+
if (disable_radio) {
ath_print(common, ATH_DBG_CONFIG, "idle: disabling radio\n");
ath_radio_disable(sc);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index bc7d173..e6a50f3 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -668,15 +668,26 @@ void ath9k_wiphy_set_scheduler(struct ath_softc *sc, unsigned int msec_int)
bool ath9k_all_wiphys_idle(struct ath_softc *sc)
{
unsigned int i;
- if (sc->pri_wiphy->state != ATH_WIPHY_INACTIVE) {
+ if (!sc->pri_wiphy->idle)
return false;
- }
for (i = 0; i < sc->num_sec_wiphy; i++) {
struct ath_wiphy *aphy = sc->sec_wiphy[i];
if (!aphy)
continue;
- if (aphy->state != ATH_WIPHY_INACTIVE)
+ if (!aphy->idle)
return false;
}
return true;
}
+
+/* caller must hold wiphy_lock */
+void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle)
+{
+ struct ath_softc *sc = aphy->sc;
+
+ aphy->idle = idle;
+ ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_CONFIG,
+ "Marking %s as %s\n",
+ wiphy_name(aphy->hw->wiphy),
+ idle ? "idle" : "not-idle");
+}
--
1.6.0.4
^ permalink raw reply related
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-29 19:45 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291514.40318.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> lots of cleanups to the staging drivers, why not direct some of that
>> energy to the drivers/net/wireless ones?
>
> When did we start to apply "fix it yourself" rule instead of "submitter
> should fix it" one to the _new_ code..
Don't be silly, I didn't say that.
I was simply pointing out that your time would probably be better
spent in improving the "proper" ralink wireless drivers but if you
_really_ prefer to spend your time in pointless arguments, go ahead.
It should be pretty obvious by now that the best way to improve things
is to work with the relevant maintainers, not against them. (Unless
you wish your work to be ignored, of course.)
Pekka
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Johannes Berg @ 2009-10-29 18:58 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Reinette Chatre, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910291152g5325718ah1c55912e928896e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
On Thu, 2009-10-29 at 11:52 -0700, Luis R. Rodriguez wrote:
> > Can you elaborate on the planned paged skb support on mac80211 you
> > have. Do you have any queued up patches I can look at this point?
>
> OK I see git show 924e10
>
> Anyone taking the mac80211 paged skb support on? Any idea how long it
> may take to complete?
It's not very hard.
Step 1)
fix a few corner cases other drivers might have, and stick the bit of
code iwlwifi has right before passing the frame to mac80211 into
mac80211 as the first thing it does with the frame
Step 2)
Look through rx.c and check how much stuff it really needs linearised,
and where. I suspect that most of the time it _only_ needs the first
two bytes, until it comes to actually passing the frame up.
Step 3)
After the audit, push down the linearizing to where needed, i.e.
management frames completely, other frames up to and including the
ethernet header, software decryption all of the frame
Step 4)
make software decryption aware of paged SKBs, and remove the
linearising in that case
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Luis R. Rodriguez @ 2009-10-29 18:52 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910290918v1ca66bbdk4270eabcae6f5798@mail.gmail.com>
On Thu, Oct 29, 2009 at 9:18 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
> <reinette.chatre@intel.com> wrote:
>> From: Zhu Yi <yi.zhu@intel.com>
>>
>> This fixed a BUG_ON in __skb_trim() when paged rx is used in
>> iwlwifi driver. Yes, the whole mac80211 stack doesn't support
>> paged SKB yet. But let's start the work slowly from small
>> code snippets.
>
> So I just noticed ar9271 segments some frames upon RX. The current
> implementation approach is to stitch them back together through a
> newly allocated skb after all segments are received. How does iwlwifi
> ues paged skbs? How do you keep track of which page is for what frame?
>
> Can you elaborate on the planned paged skb support on mac80211 you
> have. Do you have any queued up patches I can look at this point?
OK I see git show 924e10
Anyone taking the mac80211 paged skb support on? Any idea how long it
may take to complete?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Johannes Berg @ 2009-10-29 18:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Reinette Chatre, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910290918v1ca66bbdk4270eabcae6f5798@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
On Thu, 2009-10-29 at 09:18 -0700, Luis R. Rodriguez wrote:
> On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
> <reinette.chatre@intel.com> wrote:
> > From: Zhu Yi <yi.zhu@intel.com>
> >
> > This fixed a BUG_ON in __skb_trim() when paged rx is used in
> > iwlwifi driver. Yes, the whole mac80211 stack doesn't support
> > paged SKB yet. But let's start the work slowly from small
> > code snippets.
>
> So I just noticed ar9271 segments some frames upon RX. The current
> implementation approach is to stitch them back together through a
> newly allocated skb after all segments are received. How does iwlwifi
> ues paged skbs? How do you keep track of which page is for what frame?
>
> Can you elaborate on the planned paged skb support on mac80211 you
> have. Do you have any queued up patches I can look at this point?
Look at commit 924e103a665300f4f25538889bdd37b256d8f787 -- the magic is
in this bit of code:
+ /* mac80211 currently doesn't support paged SKB. Convert it to
+ * linear SKB for management frame and data frame requires
+ * software decryption or software defragementation. */
+ if (ieee80211_is_mgmt(hdr->frame_control) ||
+ ieee80211_has_protected(hdr->frame_control) ||
+ ieee80211_has_morefrags(hdr->frame_control) ||
+ le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG)
+ ret = skb_linearize(skb);
+ else
+ ret = __pskb_pull_tail(skb, min_t(u16, IWL_LINK_HDR_MAX, len)) ?
+ 0 : -ENOMEM;
+
+ if (ret) {
+ kfree_skb(skb);
+ goto out;
+ }
I plan on moving that into mac80211 so that you can just pass an
arbitrarily fragmented frame into mac80211.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 17:49 UTC (permalink / raw)
To: David Miller; +Cc: penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072101.109209962.davem@davemloft.net>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:14:40 +0100
>
> > Dave, if you have problems with executing the command locally I'll be
> > happy to supply you with the patch.
>
> This is not the issue.
>
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
Lets look at the technical merits of this work.
It is 5 KLOC of dead code and it should be 1-2 KLOC of working code
(we may turn the blink eye on "working" part but FFS at least fix other
parts)..
Hey, Linus. We have a new driver for ya. It doesn't work, has design
problems and is not even half-finished but most wireless folks are fine
with it!
I wonder when things went so wrong here..
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is a waste of time since technical merit doesn't find much love there.
Sorry Dave but you're making me go over your head now and go into unpleasant
mode again..
Looking on how you just reverted cmd64x change which you were so proud while
taking IDE over shows where the real problem is -- in subsystems supervised
by you loyalty and rank is everything while you are busy playing the pointy
haired boss everywhere from arm to ide.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] libertas: remove internal buffers from GSPI driver
From: Andrey Yurovsky @ 2009-10-29 17:48 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless, libertas-dev, sebatian, george.shore
In-Reply-To: <1256749998.3850.45.camel@localhost.localdomain>
On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw@redhat.com> wrote:
> Looks OK to me, but I don't have any of the SPI hardware so when you get
> a Tested-by:, let me know and I'll ack.
Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
this patch (that is, I can reproduce it without the patch applied) so
we'll need to address that separately. So at this point we have:
Tested-by: George Shore <george.shore@imgtec.com>
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
^ permalink raw reply
* Re: mesh support for rt73
From: Andrey Yurovsky @ 2009-10-29 17:43 UTC (permalink / raw)
To: Dan Rosenqvist; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <209743CECB91EB4F84169A51F300410D97BA47DBF4@MAIL02.ug.kth.se>
Hi Dan,
On Thu, Oct 29, 2009 at 6:19 AM, Dan Rosenqvist <danro@kth.se> wrote:
> Hi,
>
> I'm currently trying to set up a small 802.11s mesh network. As I've come to understand there's no support for mesh networking at the moment for rt 73 based cards (using DWL-G122 C1).
>
> Is it possible to implement the changes mentioned in http://linuxwireless.org/en/developers/Documentation/mac80211/API to support mesh networks for rt 73 as well?
> Is there someone out there currently working on this? Otherwise, how could I contribute to make this work?
>
> Regards,
> Dan--
rt73 devices are driven by the rt2x00 driver, in my case the interface
driver is rt73usb and the core driver is rt2x00. That does support
mesh although there's an issue related to beaconing:
http://bugzilla.kernel.org/show_bug.cgi?id=13752
-Andrey
^ permalink raw reply
* Re: [PATCH] libertas: remove internal buffers from GSPI driver
From: Andrey Yurovsky @ 2009-10-29 17:29 UTC (permalink / raw)
To: George Shore; +Cc: linux-wireless, libertas-dev, sebatian, dcbw
In-Reply-To: <0D107966AF6D79418315B7C5549F4B5101150D82@lemail1.le.imgtec.org>
Thanks George,
On Thu, Oct 29, 2009 at 7:27 AM, George Shore <George.Shore@imgtec.com> wrote:
> I've tested this on our in-house dev board with our in-house CPU, on the
> 8686 in GSPI mode. Everything works as expected :)
>
> Tested-by: George Shore <george.shore@imgtec.com>
Can you please tell us what you were able to test? I'm curious about:
1) were you able to turn IEEE PS on and off?
2) were you able to use WPA2?
3) were you able to use WPA2 with IEEE PS at the same time?
(3) is really tricky and may need additional work. One issue that I'm
seeing is that the driver gets out of sync with the device, the way
I'm reproducing this is:
1) use wpa_supplicant to associate to an AP with WPA2 security.
2) iwconfig eth1 power on -- you should see the LED blinking to
indicate IEEE PS (the LED is off while the device is sleeping)
3) issue a command or two to temporarily take the device out of IEEE
PS mode (ex: iwconfig with no arguments to look at the configuration
and stats)
4) the LED should be temporarily solid-on and then return to blinking
after the driver re-enables IEEE PS mode
Thanks again,
-Andrey
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Luis R. Rodriguez @ 2009-10-29 16:18 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless, Zhu Yi
In-Reply-To: <1256760832-29063-1-git-send-email-reinette.chatre@intel.com>
On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
<reinette.chatre@intel.com> wrote:
> From: Zhu Yi <yi.zhu@intel.com>
>
> This fixed a BUG_ON in __skb_trim() when paged rx is used in
> iwlwifi driver. Yes, the whole mac80211 stack doesn't support
> paged SKB yet. But let's start the work slowly from small
> code snippets.
So I just noticed ar9271 segments some frames upon RX. The current
implementation approach is to stitch them back together through a
newly allocated skb after all segments are received. How does iwlwifi
ues paged skbs? How do you keep track of which page is for what frame?
Can you elaborate on the planned paged skb support on mac80211 you
have. Do you have any queued up patches I can look at this point?
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis R. Rodriguez @ 2009-10-29 15:08 UTC (permalink / raw)
To: Michael Buesch
Cc: Gertjan van Wingerde, David Miller, bzolnier, penberg,
linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291548.27235.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.
But you were :-P
Luis
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:48 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: David Miller, bzolnier, penberg, linux-wireless, netdev,
linux-kernel, linville
In-Reply-To: <14add3d10910290744n3abd1cf8w42a6311108eb2fa7@mail.gmail.com>
On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
>
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.
So Bart is not a maintainer? That of course changes the situation.
--
Greetings, Michael.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Gertjan van Wingerde @ 2009-10-29 14:44 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, bzolnier, penberg, linux-wireless, netdev,
linux-kernel, linville
In-Reply-To: <200910291539.16476.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 3:39 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:21:01 David Miller wrote:
>> The issue is that John disagrees with you can you can't handle
>> that.
>>
>> So instead of continuing to discuss things with him and the
>> other wireless folks, you want me to just overreach everybody
>> and revert someone else's work.
>
> In the end this results in the driver maintainer being forced to maintain
> code and handle bugreports for code that he disagrees with in the first place.
> This is unacceptable and has to be resolved in some way.
> If it's not possible to get it reverted through John (for whatever reason),
> you're in charge to help the actual code maintainer out.
>
>> I'm not going to do that sorry, learn how to work with the
>> wireless people instead.
>
> This is not the problem.
> The problem is that stuff is merged without ack from the maintainer
> and it's virtually impossible to get the stuff reverted. The only real
> way for the maintainer to resolve this is 1) live with it or 2) fix it.
> And that's bad, because it completely invalidates his priority queue.
>
> Just like you must not bypass John, the driver maintainers must not be bypassed, too.
> The quality control does _only_ work if nobody in the chain is bypassed.
> But in this situation the quality control did already fail and it should be
> tried hard to resolve (=revert) the situation instead of pointing at John.
>
Hold on here. In this case it is the driver maintainer (i.e. Ivo for
the rt2x00 project) that
submitted this driver for inclusion, so the driver maintainer has not
been bypassed in
this case.
Apparently Bart has issues with the code submitted by the maintainers
and has been
unsuccessful in convincing others about these issues.
---
Gertjan.
^ permalink raw reply
* RE: [PATCH] libertas: remove internal buffers from GSPI driver
From: George Shore @ 2009-10-29 14:27 UTC (permalink / raw)
To: Andrey Yurovsky, linux-wireless; +Cc: libertas-dev, sebatian, dcbw
In-Reply-To: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Andrey Yurovsky
> Sent: 27 October 2009 23:52
> To: linux-wireless@vger.kernel.org
> Cc: libertas-dev@lists.infradead.org; sebatian@breakpoint.cc;
> dcbw@redhat.com; Andrey Yurovsky
> Subject: [PATCH] libertas: remove internal buffers from GSPI driver
>
> This patch removes the internal command and data buffers that the GSPI
> driver
> maintained and instead relies on the Libertas core to synchronize
access
> to the command and data ports as with the other interface drivers.
This
> cleanup reduces the GSPI driver's memory footprint and should improve
> performance by removing the need to copy to these internal buffers.
> This also simplifies the bottom half of the interrupt handler.
>
> This is an incremental cleanup: after removing the redundant buffers,
we
> can further improve the driver to use a threaded IRQ handler instead
of
> maintaining its own thread. However I would like a few folks to test
> the buffer removal first and make sure that I'm not introducing
> regressions.
>
> Tested on Blackfin BF527 with DMA disabled due to an issue with the
SPI
> host controller driver in the current bleeding-edge Blackfin kernel.
I
> would appreciate it if someone with working DMA could test this patch
> and provide feedback.
>
I've tested this on our in-house dev board with our in-house CPU, on the
8686 in GSPI mode. Everything works as expected :)
Tested-by: George Shore <george.shore@imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
> ---
> drivers/net/wireless/libertas/if_spi.c | 136
++-------------------------
> -----
> 1 files changed, 6 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c
> b/drivers/net/wireless/libertas/if_spi.c
> index 06df2e1..9e0096d 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -32,12 +32,6 @@
> #include "dev.h"
> #include "if_spi.h"
>
> -struct if_spi_packet {
> - struct list_head list;
> - u16 blen;
> - u8 buffer[0]
__attribute__((aligned(4)));
> -};
> -
> struct if_spi_card {
> struct spi_device *spi;
> struct lbs_private *priv;
> @@ -66,33 +60,10 @@ struct if_spi_card {
> struct semaphore spi_thread_terminated;
>
> u8 cmd_buffer[IF_SPI_CMD_BUF_SIZE];
> -
> - /* A buffer of incoming packets from libertas core.
> - * Since we can't sleep in hw_host_to_card, we have to buffer
> - * them. */
> - struct list_head cmd_packet_list;
> - struct list_head data_packet_list;
> -
> - /* Protects cmd_packet_list and data_packet_list */
> - spinlock_t buffer_lock;
> };
>
> static void free_if_spi_card(struct if_spi_card *card)
> {
> - struct list_head *cursor, *next;
> - struct if_spi_packet *packet;
> -
> - BUG_ON(card->run_thread);
> - list_for_each_safe(cursor, next, &card->cmd_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> - list_for_each_safe(cursor, next, &card->data_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> spi_set_drvdata(card->spi, NULL);
> kfree(card);
> }
> @@ -774,40 +745,6 @@ out:
> return err;
> }
>
> -/* Move data or a command from the host to the card. */
> -static void if_spi_h2c(struct if_spi_card *card,
> - struct if_spi_packet *packet, int type)
> -{
> - int err = 0;
> - u16 int_type, port_reg;
> -
> - switch (type) {
> - case MVMS_DAT:
> - int_type = IF_SPI_CIC_TX_DOWNLOAD_OVER;
> - port_reg = IF_SPI_DATA_RDWRPORT_REG;
> - break;
> - case MVMS_CMD:
> - int_type = IF_SPI_CIC_CMD_DOWNLOAD_OVER;
> - port_reg = IF_SPI_CMD_RDWRPORT_REG;
> - break;
> - default:
> - lbs_pr_err("can't transfer buffer of type %d\n", type);
> - err = -EINVAL;
> - goto out;
> - }
> -
> - /* Write the data to the card */
> - err = spu_write(card, port_reg, packet->buffer, packet->blen);
> - if (err)
> - goto out;
> -
> -out:
> - kfree(packet);
> -
> - if (err)
> - lbs_pr_err("%s: error %d\n", __func__, err);
> -}
> -
> /* Inform the host about a card event */
> static void if_spi_e2h(struct if_spi_card *card)
> {
> @@ -837,8 +774,6 @@ static int lbs_spi_thread(void *data)
> int err;
> struct if_spi_card *card = data;
> u16 hiStatus;
> - unsigned long flags;
> - struct if_spi_packet *packet;
>
> while (1) {
> /* Wait to be woken up by one of two things. First, our
ISR
> @@ -877,43 +812,9 @@ static int lbs_spi_thread(void *data)
> if (hiStatus & IF_SPI_HIST_CMD_DOWNLOAD_RDY ||
> (card->priv->psstate != PS_STATE_FULL_POWER &&
> (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY))) {
> - /* This means two things. First of all,
> - * if there was a previous command sent, the
card has
> - * successfully received it.
> - * Secondly, it is now ready to download another
> - * command.
> - */
> lbs_host_to_card_done(card->priv);
> -
> - /* Do we have any command packets from the host
to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->cmd_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - cmd_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
> -
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_CMD);
> }
> - if (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY) {
> - /* Do we have any data packets from the host to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->data_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - data_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
>
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_DAT);
> - }
> if (hiStatus & IF_SPI_HIST_CARD_EVENT)
> if_spi_e2h(card);
>
> @@ -942,40 +843,18 @@ static int if_spi_host_to_card(struct
lbs_private
> *priv,
> u8 type, u8 *buf, u16 nb)
> {
> int err = 0;
> - unsigned long flags;
> struct if_spi_card *card = priv->card;
> - struct if_spi_packet *packet;
> - u16 blen;
>
> lbs_deb_enter_args(LBS_DEB_SPI, "type %d, bytes %d", type, nb);
>
> - if (nb == 0) {
> - lbs_pr_err("%s: invalid size requested: %d\n", __func__,
nb);
> - err = -EINVAL;
> - goto out;
> - }
> - blen = ALIGN(nb, 4);
> - packet = kzalloc(sizeof(struct if_spi_packet) + blen,
GFP_ATOMIC);
> - if (!packet) {
> - err = -ENOMEM;
> - goto out;
> - }
> - packet->blen = blen;
> - memcpy(packet->buffer, buf, nb);
> - memset(packet->buffer + nb, 0, blen - nb);
> + nb = ALIGN(nb, 4);
>
> switch (type) {
> case MVMS_CMD:
> - priv->dnld_sent = DNLD_CMD_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->cmd_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_CMD_RDWRPORT_REG, buf, nb);
> break;
> case MVMS_DAT:
> - priv->dnld_sent = DNLD_DATA_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->data_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_DATA_RDWRPORT_REG, buf,
nb);
> break;
> default:
> lbs_pr_err("can't transfer buffer of type %d", type);
> @@ -983,9 +862,6 @@ static int if_spi_host_to_card(struct lbs_private
> *priv,
> break;
> }
>
> - /* Wake up the spi thread */
> - up(&card->spi_ready);
> -out:
> lbs_deb_leave_args(LBS_DEB_SPI, "err=%d", err);
> return err;
> }
> @@ -1062,9 +938,6 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
>
> sema_init(&card->spi_ready, 0);
> sema_init(&card->spi_thread_terminated, 0);
> - INIT_LIST_HEAD(&card->cmd_packet_list);
> - INIT_LIST_HEAD(&card->data_packet_list);
> - spin_lock_init(&card->buffer_lock);
>
> /* Initialize the SPI Interface Unit */
> err = spu_init(card, pdata->use_dummy_writes);
> @@ -1141,6 +1014,9 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
> goto terminate_thread;
> }
>
> + /* poke the IRQ handler so that we don't miss the first
interrupt */
> + up(&card->spi_ready);
> +
> /* Start the card.
> * This will call register_netdev, and we'll start
> * getting interrupts... */
> --
> 1.5.6.3
>
> --
> 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
-
This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm
Imagination Technologies Ltd is a limited company registered in England No: 1306335
Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ.
Email to and from the company may be monitored for compliance and other administrative purposes.
-
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox