* Re: compat-wireless-2.6.37-rc5 released
From: Luis R. Rodriguez @ 2010-12-10 16:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Senthil Balasubramanian, Felix Fietkau
In-Reply-To: <AANLkTikFnb=ErjA0VeS6oekExHxT1-Mh5_wa28UqEZZ4@mail.gmail.com>
On Thu, Dec 9, 2010 at 5:08 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> 01-ath9k-OTP.patch
>> 03-ath9k-no-aggr-VO.patch
>> 04-mac80211-no-aggr-VO.patch
>> 05-ath9k-Reintroduce-modparam-to-enable-btcoex.patch
I'll skip this one, better synch the modparam with a kernel release
rather than an update like compat-wireless.
>> 06-ath9k_hw-fix-A-MPDU-key-search-issues-on-AR9003.patch
I'm going to start sucking the reset in for a compat-wireless-2.6.37
release. Please let me know if you believe any other patches are
worthy, even if they are for other drivers, etc.
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: Fix deadlock in ieee80211_do_stop.
From: Ben Greear @ 2010-12-10 16:35 UTC (permalink / raw)
To: Tejun Heo; +Cc: Johannes Berg, Luis R. Rodriguez, linux-wireless
In-Reply-To: <4D024307.2060108@gmail.com>
On 12/10/2010 07:11 AM, Tejun Heo wrote:
> Hello, Ben.
>
> On 12/09/2010 11:23 PM, Ben Greear wrote:
>> I saw a brief hang today, and did a sysrq-t, and then saw the timer
>> printout you added here. But, I think that was caused by sysrq-t.
>> The system recovered and ran fine.
>
> It would be nice if you turn on printk timestamp. How brief is brief?
> Can you please turn on printk timestamp? @115200, the dump would have
> taken ~25 seconds so yes it was mostly caused by sysrq-t dump. In the
> dump, iface_work is at the same position in R state. It looks like
> the ifmgd->mtx. Can you please confirm this with gdb? This would
> only happen if the lock is highly contended. Would this be the case
> Johaness?
I'm getting low on time before the holidays and have lots of other
bugs to go after, so not sure I'll get to this soon.
'Brief' was long enough for me to see 'sh' running at 100+ CPU for
a few refreshes in 'top', which is one of the symptoms of this bug
in my case (a bash script is calling 'ip' which is blocked on
rtnl, or some such thing).
>
>> The second time (after several hours of rebooting), the hang was worse
>> and the system ran OOM after maybe 30 seconds. I did a sysrq-t then.
>>
>> I see quite a few printouts from your debug message, but all of them
>> after things start going OOM, and after sysrq-t.
>>
>> Here's the console capture:
>>
>> http://www.candelatech.com/~greearb/minicom_ath9k_log4.txt
>>
>> Let me know if you need more traces like this if I hit it again.
>
> I don't know the code very well but it looks very suspicious. A task
> ends up trying to flush a work which can run for extended period of
> time during which memory is aggressively used for buffering (looks
> like skb's are piling up without any limit), which is likely to
> further slow down other stuff. This sounds like an extremely fragile
> mechanism to me. When the work is being constantly being rescheduled,
> cancel ends up waiting one fewer time then flush. If the work is
> running and pending, flush waits for the pending one to finish, while
> cancel would kill the pending one and waits for only the current one
> to finish. I think it could be that that difference is acting as a
> threshold between going bonkers and staying alive.
>
> Can you please test whether the following patch makes any difference?
> If flush_work() is misbehaving, the following wouldn't fix anything
> but if this livelock is indeed caused by iface_work running too long,
> the problem should go away.
>
> One way or the other, Johannes, please consider fixing the behavior
> here. It's way too fragile.
Perhaps a related bug: On module unload with lots of VIFS passing
traffic, I often see crashes due to what appears to be accessing
stale sdata pointers. Perhaps the logic to disable rx of acks
and other skbs doesn't work properly in the STA shutdown path?
Thanks,
Ben
>
> Thanks.
>
> diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
> index 7aa8559..86bdfdd 100644
> --- a/net/mac80211/iface.c
> +++ b/net/mac80211/iface.c
> @@ -723,6 +723,7 @@ static void ieee80211_iface_work(struct work_struct *work)
> struct sk_buff *skb;
> struct sta_info *sta;
> struct ieee80211_ra_tid *ra_tid;
> + unsigned int cnt = 0;
>
> if (!ieee80211_sdata_running(sdata))
> return;
> @@ -825,6 +826,11 @@ static void ieee80211_iface_work(struct work_struct *work)
> }
>
> kfree_skb(skb);
> +
> + if (++cnt> 100) {
> + ieee80211_queue_work(&local->hw, work);
> + break;
> + }
> }
>
> /* then other type-dependent work */
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] fix hostap registration order
From: David Miller @ 2010-12-10 17:47 UTC (permalink / raw)
To: mroos; +Cc: j, netdev, linux-wireless
In-Reply-To: <alpine.SOC.1.00.1012100918300.15996@math.ut.ee>
From: Meelis Roos <mroos@linux.ee>
Date: Fri, 10 Dec 2010 09:19:51 +0200 (EET)
>> > In 2.6.37-rc4, hostap_pci init gives a WARNING with backtrace telling
>> > that netif_stop_queue is called before register_netdev. Fix it by moving
>> > this call after register_netdev. Removes the warning and seems to work,
>> > but why is the call to netif_stop_queue needed at all after
>> > register_netdev?
>>
>> It should simply not touch the queue state at all at this point.
>>
>> Your change would add a race. At the moment the device is registered
>> it can be brought up, and then your code will eroneously modify
>> the queue state.
>
> OK, I can make a simpler patch for that but I would like to understand
> the original reasons for having netif_stop_queue there. Just a relict or
> still somehow important?
I think it was neither.
The queue state is "don't care" at this point, and always has been,
and a lot of drivers had this unnecessary netif_stop_queue() call
there.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-12-08
From: David Miller @ 2010-12-10 18:01 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20101208210432.GH2423@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 8 Dec 2010 16:04:32 -0500
> Here is the latest batch of updates intended for 2.6.38. It also
> includes my last wireless-2.6 pull request that you just added
> to net-2.6.
>
> This includes the usual batch of drivers updates, with ath9k and
> iwlwifi as the usual standouts. This also includes some mac80211
> documentation updates from Johannes, and a flurry of ath5k updates
> from Nick. This also includes a collection of bluetooth updates by
> way of Gustavo, a couple of libertas updates, some more work on b43
> N-phy support, and a variety of other patches.
So I pulled this in.
Since I did the net-2.6 --> net-next-2.6 merge first, I ended up having
to deal with the ar9003_eeprom.c conflicts in the ath9k driver even
though you took care of that as well in this tree of your's.
But it was a good gut check since we both resolved the conflict pretty
much the same way, so I have confidence in the merge resolution :-)
Anyways, please take a look at net-next-2.6 and double-check what I
did.
Thanks!
^ permalink raw reply
* Re: [ath9k-devel] .36 ath9k patches for .35-longterm
From: Andi Kleen @ 2010-12-10 18:22 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Andi Kleen, linux-wireless, ath9k-devel
In-Reply-To: <AANLkTimnfAbDnKQbxLrwOHTD-CFXn1TJh91PuC=2QuUM@mail.gmail.com>
On Fri, Dec 10, 2010 at 07:56:37AM -0800, Luis R. Rodriguez wrote:
> On Fri, Dec 10, 2010 at 1:32 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > I sent this to the athk9 maintainers earlier, but it looks like
> > Atheros' mailserver doesn't like my mailserver and I got a bounce.
> > Resending to the lists.
>
> Heh, odd.
It complained that my IP was non trusted.
As far as I can see the problem is that your barracuda email
appliance looks for any IP addresses in email headers --
not just the IP address of the delivering mail server --
and since I send from a dynamic address as first
step it fails.
> > ath9k-fix-timeout-on-stopping-rx-dma.patch
> >
> > Some of them apply to .35, but a lot of others do not and I found
> > it difficult to decide which ones are suitable for 2.6.36
>
> You mean for 2.6.35?
yes, sorry for the typo
> Eek, um OK, we'll give this a some good review and get back to you.
Thanks.
> http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat-wireless-2.6.git;a=tree;h=refs/heads/linux-2.6.36.y;hb=refs/heads/linux-2.6.36.y
>
> > Right now I didn't merge any ath9x patches until this is resolved.
>
> This will take a bit of time, as some of these patches may require
> manual backport and as you noted some dependencies. Given that this is
The question is if they are critical for .35. Are they?
If not can you just send the ones which are critical?
> for long term we will do some work to get this to you. Its too bad we
> can't get AR9003 support in there, that's a huge set of patches
> though.
Non trivial new hardware support is out of scope.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2010-12-08
From: John W. Linville @ 2010-12-10 18:20 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev
In-Reply-To: <20101210.100141.183065894.davem@davemloft.net>
On Fri, Dec 10, 2010 at 10:01:41AM -0800, David Miller wrote:
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Wed, 8 Dec 2010 16:04:32 -0500
>
> > Here is the latest batch of updates intended for 2.6.38. It also
> > includes my last wireless-2.6 pull request that you just added
> > to net-2.6.
> >
> > This includes the usual batch of drivers updates, with ath9k and
> > iwlwifi as the usual standouts. This also includes some mac80211
> > documentation updates from Johannes, and a flurry of ath5k updates
> > from Nick. This also includes a collection of bluetooth updates by
> > way of Gustavo, a couple of libertas updates, some more work on b43
> > N-phy support, and a variety of other patches.
>
> So I pulled this in.
>
> Since I did the net-2.6 --> net-next-2.6 merge first, I ended up having
> to deal with the ar9003_eeprom.c conflicts in the ath9k driver even
> though you took care of that as well in this tree of your's.
>
> But it was a good gut check since we both resolved the conflict pretty
> much the same way, so I have confidence in the merge resolution :-)
>
> Anyways, please take a look at net-next-2.6 and double-check what I
> did.
Looks good to me...thanks!
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: b43 N PHY status report
From: Francesco Gringoli @ 2010-12-10 18:30 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafał Miłecki, wireless, b43-dev
In-Reply-To: <4CFFA112.7030800@lwfinger.net>
On Dec 8, 2010, at 4:15 PM, Larry Finger wrote:
> Rafał,
>
> The N PHY driver is remarkably stable. So far, my link has been up for nearly 16
> hours under normal conditions - I have not yet tried any stress tests. Other
> than the PHY errors that you noted, my link has only reported 2 other unusual
> events. I have had 3 "Deauthentication for reason 3" from which it recovered in
> one try. Also logged are 9 instances of "RX: Packet size underrun (2)/Packet
> dropped" events. Again, these caused no problems.
Hi Rafał,
I confirm Larry's feedbacks. I tried both on a 32bit and a 64bit architectures (the first is frodo), and it works. I too see only CCK packets. On 64bit arch (Atom) it works but when I try to unload the module I get this
[ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
and the device is never release (by who?). I have to reboot.
I'm using two cards, one reports
[ 311.439406] b43-phy0: Broadcom 4321 WLAN found (core revision 12)
[ 311.480046] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 2
[ 311.480075] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
The other (an Apple original card) reports
[ 82.726931] b43-phy0: Broadcom 4321 WLAN found (core revision 11)
[ 82.768030] b43-phy0 debug: Found PHY: Analog 5, Type 4, Revision 1
[ 82.768062] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2055, Revision 4
Thanks,
-Francesco
Informativa sulla privacy: http://help.ing.unibs.it/privacy.php
^ permalink raw reply
* Re: b43 N PHY status report
From: Johannes Berg @ 2010-12-10 18:47 UTC (permalink / raw)
To: Francesco Gringoli
Cc: Larry Finger, Rafał Miłecki, wireless, b43-dev
In-Reply-To: <885729A3-72D4-4EFC-AAFE-D2B573E00ED9@ing.unibs.it>
On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>
> and the device is never release (by who?). I have to reboot.
That's a bug in the ipv6 code, upgrade your kernel :-)
johannes
^ permalink raw reply
* Re: b43 N PHY status report
From: Larry Finger @ 2010-12-10 19:00 UTC (permalink / raw)
To: Konstantinos Karantias; +Cc: Rafał Miłecki, wireless, b43-dev
In-Reply-To: <AANLkTik1712si67qH6fBSLzu8iWcjqnX=ntENh0W8UmU@mail.gmail.com>
On 12/10/2010 12:53 PM, Konstantinos Karantias wrote:
> It's not been so stable on my BCM4312, but it's still stable. It can
> keep the connection for ~3 hours here.
Your BCM4312 probably has an LP PHY. We were reporting on the N PHY devices.
I have 2 LP PHY units - both stay connected although one of them gets "cookie
out of order" errors on occasion. Please report the exact details for your device.
Larry
^ permalink raw reply
* Re: b43 N PHY status report
From: Larry Finger @ 2010-12-10 19:02 UTC (permalink / raw)
To: Johannes Berg
Cc: Francesco Gringoli, Rafał Miłecki, wireless, b43-dev
In-Reply-To: <1292006874.3531.4.camel@jlt3.sipsolutions.net>
On 12/10/2010 12:47 PM, Johannes Berg wrote:
> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>
>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>
>> and the device is never release (by who?). I have to reboot.
>
> That's a bug in the ipv6 code, upgrade your kernel :-)
I would not have seen that as IPv6 is disabled in my kernels.
Larry
^ permalink raw reply
* Re: b43 N PHY status report
From: Gábor Stefanik @ 2010-12-10 19:04 UTC (permalink / raw)
To: Larry Finger
Cc: Johannes Berg, Francesco Gringoli, Rafał Miłecki,
wireless, b43-dev
In-Reply-To: <4D02793E.2050004@lwfinger.net>
On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 12/10/2010 12:47 PM, Johannes Berg wrote:
>> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
>>
>>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
>>>
>>> and the device is never release (by who?). I have to reboot.
>>
>> That's a bug in the ipv6 code, upgrade your kernel :-)
>
> I would not have seen that as IPv6 is disabled in my kernels.
Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
>
> Larry
> --
> 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
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
^ permalink raw reply
* Re: b43 N PHY status report
From: Johannes Berg @ 2010-12-10 19:08 UTC (permalink / raw)
To: Gábor Stefanik
Cc: Larry Finger, Francesco Gringoli, Rafał Miłecki,
wireless, b43-dev
In-Reply-To: <AANLkTik2MdDg4g4dFuB6ozZ3Pp3pPORmSAxRAbtznTLP@mail.gmail.com>
On Fri, 2010-12-10 at 20:04 +0100, Gábor Stefanik wrote:
> On Fri, Dec 10, 2010 at 8:02 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 12/10/2010 12:47 PM, Johannes Berg wrote:
> >> On Fri, 2010-12-10 at 19:30 +0100, Francesco Gringoli wrote:
> >>
> >>> [ 1117.516031] unregister_netdevice: waiting for wlan1 to become free. Usage count = 1
> >>>
> >>> and the device is never release (by who?). I have to reboot.
> >>
> >> That's a bug in the ipv6 code, upgrade your kernel :-)
> >
> > I would not have seen that as IPv6 is disabled in my kernels.
>
> Are you serious? Disabling ipv6 with ipv4 exhaustion expected in January?
Can we stop this thread right here and go on-topic again please?
johannes
^ permalink raw reply
* Re: [ath9k-devel] .36 ath9k patches for .35-longterm
From: Luis R. Rodriguez @ 2010-12-10 19:09 UTC (permalink / raw)
To: Andi Kleen
Cc: Luis R. Rodriguez, ath9k-devel@lists.ath9k.org,
linux-wireless@vger.kernel.org
In-Reply-To: <20101210182233.GD3965@basil.fritz.box>
On Fri, Dec 10, 2010 at 10:22:34AM -0800, Andi Kleen wrote:
> On Fri, Dec 10, 2010 at 07:56:37AM -0800, Luis R. Rodriguez wrote:
> > On Fri, Dec 10, 2010 at 1:32 AM, Andi Kleen <andi@firstfloor.org> wrote:
> > > I sent this to the athk9 maintainers earlier, but it looks like
> > > Atheros' mailserver doesn't like my mailserver and I got a bounce.
> > > Resending to the lists.
> >
> > Heh, odd.
>
> It complained that my IP was non trusted.
>
> As far as I can see the problem is that your barracuda email
> appliance looks for any IP addresses in email headers --
> not just the IP address of the delivering mail server --
> and since I send from a dynamic address as first
> step it fails.
Thanks for the details, I'll nag at our IT.
> > > ath9k-fix-timeout-on-stopping-rx-dma.patch
> > >
> > > Some of them apply to .35, but a lot of others do not and I found
> > > it difficult to decide which ones are suitable for 2.6.36
> >
> > You mean for 2.6.35?
>
> yes, sorry for the typo
>
> > Eek, um OK, we'll give this a some good review and get back to you.
>
> Thanks.
>
> > http://git.kernel.org/?p=linux/kernel/git/mcgrof/compat-wireless-2.6.git;a=tree;h=refs/heads/linux-2.6.36.y;hb=refs/heads/linux-2.6.36.y
> >
> > > Right now I didn't merge any ath9x patches until this is resolved.
> >
> > This will take a bit of time, as some of these patches may require
> > manual backport and as you noted some dependencies. Given that this is
>
> The question is if they are critical for .35. Are they?
> If not can you just send the ones which are critical?
The critical ones are all marked as stable accordingly, but since
a lot of stable fixes are for AR9003 and since 2.6.35 does not have
AR9003 support enabled you can disregard all AR9003 stable fixes
on 2.6.36. That itself might get you all the ath9k stable patches
you do need and will likley apply cleanly.
> > for long term we will do some work to get this to you. Its too bad we
> > can't get AR9003 support in there, that's a huge set of patches
> > though.
>
> Non trivial new hardware support is out of scope.
Ok, fair enough.
Luis
^ permalink raw reply
* Re: BUG: Microcode SW error detected / Frequent disconnects
From: Florian Kriener @ 2010-12-10 19:10 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: sedat.dilek@gmail.com, linux-wireless@vger.kernel.org
In-Reply-To: <1291994774.10280.183.camel@wwguy-ubuntu>
On Friday 10 December 2010 16:26:14 Guy, Wey-Yi wrote:
> On Fri, 2010-12-10 at 07:27 -0700, Sedat Dilek wrote:
> > Guessing you are using a Debian kernel from experimental.
> > 'uname -a' is normally not enough, we need the Debian version
> > string. (As there was only one 2.6.36 kernel, it is clear which
> > version you have). There is now a 2.6.37-rc4 in experimental,
> > please try that. bwh has prepared -rc5 a few hours ago and it will
> > be uploaded to experimental soonish.
> > (You check out from SVN and build by yourself or wait, see
> > instructions on Debian kernel team wiki).
The full version string is 2.6.36-1~experimental.1 and I will try 2.6.37
as soon as it hits experimental.
BTW: I have problems with this network since 2.6.32, however I did not
see any microcode sw error messages at first.
> > Another possibility is you use compat-wireless stable or
> > bleeding-edge (in addition to your host 2.6.36 kernel).
> >
> > All these "experiments" only to see if it is a problem in 2.6.36.
> > (Might be the Intel developers know where the problem is exactly).
> >
> > Next question is: You have latest firmware file(s) from non-free?
> > (Or look at Intel's iwlwifi download website).
I have indeed, the version is 8.24.2.12 as you can check in the
truncated dmesg log.
> > BTW, sometimes a full dmesg log is more helpful than a truncated
> > one.
I didn't want to post it in full for privacy reasons but I can send you
one in full directly if you are interested. I will however have to wait
until the problem shows up again. I don't know why, but I did not save
the full log. Sorry.
> Looks like you have 5000 NIC device based on the firmware version.
> Please let me know the problem still happen in 2.6.36. If does, we
> can look into possible firmware problem
Yes, it is a 5300 . I guess you mean 2.6.37 and yes I will let you know.
Sincerely,
Florian.
^ permalink raw reply
* Re: [PATCH 1/4] b43: N-PHY: update init tables
From: ikorot @ 2010-12-10 19:09 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Larry Finger, Hauke Mehrtens, linux-wireless, b43-dev
Rafal,
-----Original Message-----
>From: Rafał Miłecki <zajec5@gmail.com>
>Sent: Dec 9, 2010 10:36 PM
>To: ikorot@earthlink.net
>Cc: Larry Finger <Larry.Finger@lwfinger.net>, Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>
>W dniu 10 grudnia 2010 03:26 użytkownik <ikorot@earthlink.net> napisał:
>> -----Original Message-----
>>>From: Rafał Miłecki <zajec5@gmail.com>
>>>Sent: Dec 9, 2010 6:06 AM
>>>To: ikorot@earthlink.net
>>>Cc: Larry Finger <Larry.Finger@lwfinger.net>, Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>>>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>>>
>>>2010/12/8 <ikorot@earthlink.net>:
>>>> Larry,
>>>>
>>>>
>>>> -----Original Message-----
>>>>>From: Larry Finger <Larry.Finger@lwfinger.net>
>>>>>Sent: Dec 7, 2010 12:00 PM
>>>>>To: ikorot@earthlink.net
>>>>>Cc: Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>>>>>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>>>>>
>>>>>On 12/07/2010 01:49 PM, ikorot@earthlink.net wrote:
>>>>>>> One reason is that these tables changed from non-zero to zero values between
>>>>>>> Broadcom driver 4.174.64.19 and 5.10.56.46. As they might change again, I think
>>>>>>> we should retain the full version.
>>>>>>
>>>>>> Is there a way to check for version of the driver?
>>>>>> This way whoever uses old one won't be screwed...
>>>>>
>>>>>That will not be a problem as no older version of b43 works at all with b43. To
>>>>>help you understand this change, when the 4.174.64.19 Broadcom driver was
>>>>>reverse-engineered, the tables had non-zero values. Rafel later compared the
>>>>>trace dumps of b43 with the latest version of wl and found that the values are
>>>>>now zero. When I rechecked driver 5.10.56.46, I found them to be zero there as
>>>>>well and changed the specs.
>>>>
>>>> Well, it maybe feasible to keep the old values and check
>>>> the version of the driver, since you are saying yourself
>>>> that the value might be changing in the future.
>>>> Maybe for couple of releases only?
>>>
>>>Sorry, but I don't understand that at all. What do you mean by version
>>>of the driver? What driver?
>>
>> #if B43_VERSION <= x.x.x.x
>> // table initialized to some values
>> #else
>> //table initialized to 0's
>> #endif
>
>You want to put condition checking b43 version in... b43 driver? I
>can't follow you.
Yes.
And what you can't follow?
For historical purposes and to better understand the changes and ease the
debugging I proposed this addition.
Besides if for some reason in future versions Broadcom will decide to return to
the same values for init tables, the changes will be very simple.
Thank you.
>
>--
>Rafał
^ permalink raw reply
* Re: [PATCH 1/4] b43: N-PHY: update init tables
From: Rafał Miłecki @ 2010-12-10 19:33 UTC (permalink / raw)
To: ikorot; +Cc: Larry Finger, Hauke Mehrtens, linux-wireless, b43-dev
In-Reply-To: <3300273.1292008199474.JavaMail.root@elwamui-rubis.atl.sa.earthlink.net>
W dniu 10 grudnia 2010 20:09 użytkownik <ikorot@earthlink.net> napisał:
> Rafal,
>
>
> -----Original Message-----
>>From: Rafał Miłecki <zajec5@gmail.com>
>>Sent: Dec 9, 2010 10:36 PM
>>To: ikorot@earthlink.net
>>Cc: Larry Finger <Larry.Finger@lwfinger.net>, Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>>
>>W dniu 10 grudnia 2010 03:26 użytkownik <ikorot@earthlink.net> napisał:
>>> -----Original Message-----
>>>>From: Rafał Miłecki <zajec5@gmail.com>
>>>>Sent: Dec 9, 2010 6:06 AM
>>>>To: ikorot@earthlink.net
>>>>Cc: Larry Finger <Larry.Finger@lwfinger.net>, Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>>>>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>>>>
>>>>2010/12/8 <ikorot@earthlink.net>:
>>>>> Larry,
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>>>From: Larry Finger <Larry.Finger@lwfinger.net>
>>>>>>Sent: Dec 7, 2010 12:00 PM
>>>>>>To: ikorot@earthlink.net
>>>>>>Cc: Hauke Mehrtens <hauke@hauke-m.de>, linux-wireless@vger.kernel.org, b43-dev@lists.infradead.org
>>>>>>Subject: Re: [PATCH 1/4] b43: N-PHY: update init tables
>>>>>>
>>>>>>On 12/07/2010 01:49 PM, ikorot@earthlink.net wrote:
>>>>>>>> One reason is that these tables changed from non-zero to zero values between
>>>>>>>> Broadcom driver 4.174.64.19 and 5.10.56.46. As they might change again, I think
>>>>>>>> we should retain the full version.
>>>>>>>
>>>>>>> Is there a way to check for version of the driver?
>>>>>>> This way whoever uses old one won't be screwed...
>>>>>>
>>>>>>That will not be a problem as no older version of b43 works at all with b43. To
>>>>>>help you understand this change, when the 4.174.64.19 Broadcom driver was
>>>>>>reverse-engineered, the tables had non-zero values. Rafel later compared the
>>>>>>trace dumps of b43 with the latest version of wl and found that the values are
>>>>>>now zero. When I rechecked driver 5.10.56.46, I found them to be zero there as
>>>>>>well and changed the specs.
>>>>>
>>>>> Well, it maybe feasible to keep the old values and check
>>>>> the version of the driver, since you are saying yourself
>>>>> that the value might be changing in the future.
>>>>> Maybe for couple of releases only?
>>>>
>>>>Sorry, but I don't understand that at all. What do you mean by version
>>>>of the driver? What driver?
>>>
>>> #if B43_VERSION <= x.x.x.x
>>> // table initialized to some values
>>> #else
>>> //table initialized to 0's
>>> #endif
>>
>>You want to put condition checking b43 version in... b43 driver? I
>>can't follow you.
>
> Yes.
> And what you can't follow?
>
> For historical purposes and to better understand the changes and ease the
> debugging I proposed this addition.
> Besides if for some reason in future versions Broadcom will decide to return to
> the same values for init tables, the changes will be very simple.
So I guess you meant using "#if 0" for commenting old values?
I guess we could do that instead deleting old values, but fortunately
it's git so we always can browse history and restore old values
without problems :)
--
Rafał
^ permalink raw reply
* Re: [RFC v2 0/2] implementation of scheduled scan
From: Johannes Berg @ 2010-12-10 19:53 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
In-Reply-To: <1291993632-6921-1-git-send-email-luciano.coelho@nokia.com>
On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
> * I kept the return value in the sched_scan_stop chain, because, at least with
> wl12xx, the call can fail (due to OOM for instance). I think it's cleaner
> this way.
What's going to happen then though? Would it make sense to pre-allocate
this at start() time, so it can cleanly stop regardless of what's going
on? I can see start() failing, but stop() failing seems a bit hard to
work with in wpa_supplicant?
johannes
^ permalink raw reply
* Re: [RFC v2 1/2] cfg80211/nl80211: add support for scheduled scans
From: Johannes Berg @ 2010-12-10 20:03 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
In-Reply-To: <1291993632-6921-2-git-send-email-luciano.coelho@nokia.com>
On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
> With this feature we
> can scan automatically for specific SSIDs (or any if not specified) at
> certain intervals.
I'd hope that "if not specified" actually means a passive scan like in
normal scanning, and you need to specify the wildcard if you want to
scan for it?
> + u8 max_sched_scan_ssids;
shouldn't this be advertised in nl80211 as well?
> @@ -647,6 +648,11 @@ static void wdev_cleanup_work(struct work_struct *work)
> ___cfg80211_scan_done(rdev, true);
> }
>
> + if (rdev->sched_scan_req &&
> + rdev->sched_scan_req->dev == wdev->netdev) {
> + nl80211_sched_scan_stopped(rdev, wdev->netdev);
> + }
Hmm, are you sure that shouldn't be a warning like the scan case? If the
driver didn't stop -- maybe this is still going on? I think instead the
netdev down notifier should actually ask the device to stop the sched
scan (core.c).
> + if (!rdev->ops->sched_scan_start) {
> + return -EOPNOTSUPP;
> + }
> +
> + if (rdev->sched_scan_req) {
> + return -EINPROGRESS;
> + }
bit too many braces for my taste :)
> + if (ie_len > wiphy->max_scan_ie_len)
> + return -EINVAL;
So # SSIDs is different, but IE len is the same? Isn't that a bad
assumption to make?
> + request->dev = dev;
> + request->wiphy = &rdev->wiphy;
> +
> + rdev->sched_scan_req = request;
> +
> + err = rdev->ops->sched_scan_start(&rdev->wiphy, dev, request);
> + if (!err) {
> + nl80211_send_sched_scan(rdev, dev,
> + NL80211_CMD_START_SCHED_SCAN);
> + dev_hold(dev);
I don't think you want the dev_hold here. That's a trick I used to warn
about scans that didn't finish when the interface went down. Here,
instead, since it's a longer-running process, you should do what I said
above -- stop the sched scan when the interface is going down.
> + err = rdev->ops->sched_scan_stop(&rdev->wiphy, dev);
> + if (err)
> + goto out;
return err; instead? There's no cleanup code at the out label :)
> + nl80211_send_sched_scan(rdev, dev, NL80211_CMD_STOP_SCHED_SCAN);
> +
> + nl80211_sched_scan_stopped(rdev, dev);
Shouldn't the former be part of the latter function? And actually,
you'll want to roll it all into a helper function that you can call from
the netdev down notifier :)
johannes
^ permalink raw reply
* Re: [RFC v2 1/2] cfg80211/nl80211: add support for scheduled scans
From: Johannes Berg @ 2010-12-10 20:05 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
In-Reply-To: <1291993632-6921-2-git-send-email-luciano.coelho@nokia.com>
On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
> Add NL80211_CMD_START_SCHED_SCAN and NL80211_CMD_STOP_SCHED_SCAN
> commands to the nl80211 interface. When results are available they are
> reported by NL80211_CMD_SCHED_SCAN_RESULTS events.
Oh, also, I think you should check the wiphy flag in the commands,
because otherwise somebody will invariably end up writing a driver that
doesn't set the flag, but still expect it to be working :-)
johannes
^ permalink raw reply
* Compat-wireless release for 2010-12-10 is baked
From: Compat-wireless cronjob account @ 2010-12-10 20:05 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/compat-wireless-2.6
b2c2e68..2852e12 linux-2.6.37.y -> origin/linux-2.6.37.y
4a59d8a..f9f0812 master -> origin/master
* [new tag] compat-wireless-2010-12-09 -> compat-wireless-2010-12-09
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
464643e..d31ffbc history -> origin/history
+ df9e9ad...1b1497f master -> origin/master (forced update)
* [new tag] next-20101210 -> next-20101210
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
compat-wireless code metrics
752676 - Total upstream lines of code being pulled
2198 - backport code changes
1935 - backport code additions
263 - backport code deletions
6637 - backport from compat module
8835 - total backport code
1.1738 - % of code consists of backport work
1532 - Crap changes not yet posted
1489 - Crap additions not yet posted
43 - Crap deletions not yet posted
0.2035 - % of crap code
Base tree: linux-next.git
Base tree version: next-20101210
compat-wireless release: compat-wireless-2010-12-09-pc
^ permalink raw reply
* Re: [RFC v2 2/2] mac80211: add support for HW scheduled scan
From: Johannes Berg @ 2010-12-10 20:15 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
In-Reply-To: <1291993632-6921-3-git-send-email-luciano.coelho@nokia.com>
See ... I see nothing here in main.c that would set the wiphy flag, so
you really should've checked it in cfg8021 :-)
> +struct ieee80211_sched_scan_ies {
> + u8 *ie[IEEE80211_NUM_BANDS];
const?
> + * @sched_scan_start: Ask the hardware to start scanning repeatedly at
> + * specific intervals. The driver must call the
> + * ieee80211_sched_scan_results() function whenever it finds results.
> + * This process will continue until sched_scan_stop is called.
> + *
> + * @sched_scan_stop: Tell the hardware to stop an ongoing periodic scan.
> + *
> + * ieee80211_sched_scan_results() each time it finds some results.
I think that should talk about filtering as well? Maybe a DOC: section
would be good, dunno.
> /**
> + * ieee80211_sched_scan_results - got results from periodic scan
> + *
> + * When a periodic scan is running, this function needs to be called by the
> + * driver whenever there are new scan results availble.
typo: available
> +TRACE_EVENT(drv_sched_scan_results,
> + TP_PROTO(struct ieee80211_local *local),
> +
> + TP_ARGS(local),
> +
> + TP_STRUCT__entry(
> + LOCAL_ENTRY
> + ),
> +
> + TP_fast_assign(
> + LOCAL_ASSIGN;
> + ),
> +
> + TP_printk(
> + LOCAL_PR_FMT, LOCAL_PR_ARG
> + )
> +);
Shouldn't that be in the _api_ section?
> @@ -642,6 +642,7 @@ enum queue_stop_reason {
> * that the scan completed.
> * @SCAN_ABORTED: Set for our scan work function when the driver reported
> * a scan complete for an aborted scan.
> + * @SCAN_SCHED_SCANNING: We're currently performing periodic scans
That reminds me ... can you scan and sched_scan at the same time?
sched_scan while associated? Should these be prohibited, or documented
as being implementation dependent?
Also, how does this interact with IDLE? Obviously, the device won't be
idle with this, but you still want it to be "otherwise" idle, no? Should
we take this out of scanning flags and specify that it must be supported
while the device is told that it's idle by mac80211? Do you expect this
to be stopped before trying to associate?
> @@ -392,7 +392,8 @@ ieee80211_rx_h_passive_scan(struct ieee80211_rx_data *rx)
> if (likely(!(status->rx_flags & IEEE80211_RX_IN_SCAN)))
> return RX_CONTINUE;
>
> - if (test_bit(SCAN_HW_SCANNING, &local->scanning))
> + if (test_bit(SCAN_HW_SCANNING, &local->scanning) ||
> + test_bit(SCAN_SCHED_SCANNING, &local->scanning))
> return ieee80211_scan_rx(rx->sdata, skb);
This won't work while associated...
> + for (i = 0; i < IEEE80211_NUM_BANDS; i++) {
> + local->sched_scan_ies.ie[i] = kzalloc(2 +
> + IEEE80211_MAX_SSID_LEN +
> + local->scan_ies_len,
> + GFP_KERNEL);
Oops ... how about if this allocation fails?
> +void ieee80211_sched_scan_results(struct ieee80211_hw *hw)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> +
> + mutex_lock(&local->mtx);
> +
> + cfg80211_sched_scan_results(hw->wiphy);
> +
> + mutex_unlock(&local->mtx);
Does that really need locking? Seems ... pointless since cfg80211 will
have to take care of its locking.
Finally: how does this interact with HW reset? Should it be re-started
if it was ever started?
johannes
^ permalink raw reply
* [PATCH] ath9k: fix sequence number assigment for non-AMPDU QoS data frames
From: Felix Fietkau @ 2010-12-10 20:16 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, lrodriguez
wireless-testing commit 04caf863750bc7e042d1e8d57e5ce9d6326ab435
('ath9k: more tx setup cleanups') merged tx path code for HT vs
non-HT frames, however it did not pass the tid pointer to
ath_tx_send_normal, causing an inconsistency between AMPDU vs
non-AMPDU sequence number handling.
Fix this by always passing in the tid pointer for all QoS data frames.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/xmit.c | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index 43c0109..96623695 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1685,17 +1685,20 @@ static void ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct list_head bf_head;
- struct ath_atx_tid *tid;
+ struct ath_atx_tid *tid = NULL;
u8 tidno;
spin_lock_bh(&txctl->txq->axq_lock);
- if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && txctl->an) {
+ if (ieee80211_is_data_qos(hdr->frame_control) && txctl->an) {
tidno = ieee80211_get_qos_ctl(hdr)[0] &
IEEE80211_QOS_CTL_TID_MASK;
tid = ATH_AN_2_TID(txctl->an, tidno);
WARN_ON(tid->ac->txq != txctl->txq);
+ }
+
+ if ((tx_info->flags & IEEE80211_TX_CTL_AMPDU) && tid) {
/*
* Try aggregation if it's a unicast data frame
* and the destination is HT capable.
@@ -1712,7 +1715,7 @@ static void ath_tx_start_dma(struct ath_softc *sc, struct ath_buf *bf,
ar9003_hw_set_paprd_txdesc(sc->sc_ah, bf->bf_desc,
bf->bf_state.bfs_paprd);
- ath_tx_send_normal(sc, txctl->txq, NULL, &bf_head);
+ ath_tx_send_normal(sc, txctl->txq, tid, &bf_head);
}
spin_unlock_bh(&txctl->txq->axq_lock);
--
1.7.3.2
^ permalink raw reply related
* Re: [RFC v2 0/2] implementation of scheduled scan
From: Johannes Berg @ 2010-12-10 20:17 UTC (permalink / raw)
To: luciano.coelho; +Cc: linux-wireless
In-Reply-To: <1292010802.3531.6.camel@jlt3.sipsolutions.net>
On Fri, 2010-12-10 at 20:53 +0100, Johannes Berg wrote:
> On Fri, 2010-12-10 at 17:07 +0200, luciano.coelho@nokia.com wrote:
>
> > * I kept the return value in the sched_scan_stop chain, because, at least with
> > wl12xx, the call can fail (due to OOM for instance). I think it's cleaner
> > this way.
>
> What's going to happen then though? Would it make sense to pre-allocate
> this at start() time, so it can cleanly stop regardless of what's going
> on? I can see start() failing, but stop() failing seems a bit hard to
> work with in wpa_supplicant?
Actually so the nl80211 interface has to be able to return something
like "no such operation in progress" or whatever, but I'm not sure about
the driver interface -- -ENOMEM seems like a stupid failure for stopping
something, and then the above applies ...
johannes
^ permalink raw reply
* pull request: wireless-2.6 2010-12-10
From: John W. Linville @ 2010-12-10 20:29 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here is the latest round of wireless bits intended for 2.6.37...
Included are some orinoco fixes, one to avoid the crash in bug 23932 and
two others that render TKIP countermeasures ineffective (i.e. decreased
security). Helmut has provided us a fix to avoid a BUG when using
shared skbs. The ath9k team gives us a fix for failed resumes on
ath9k_htc, a fix for detecting broadcast frames with a MIC failure, a
fix for a null pointer access when generating beacons, and a DMA issue
that can lead to memory corruption. Matteo Croce pitches-in with a fix
to prevent transmitting with too much power. Finally, Javier Cardona
provides a trio of ath5k fixes that restore mesh function on those
devices.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit f19872575ff7819a3723154657a497d9bca66b33:
tcp: protect sysctl_tcp_cookie_size reads (2010-12-08 12:34:09 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
David Kilroy (3):
orinoco: initialise priv->hw before assigning the interrupt
orinoco: clear countermeasure setting on commit
orinoco: fix TKIP countermeasure behaviour
Felix Fietkau (1):
ath9k: fix a DMA related race condition on reset
Helmut Schaa (1):
mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs
Javier Cardona (3):
ath5k: Fix beaconing in mesh mode
ath5k: Prevent mesh interfaces from being counted as ad-hoc
ath5k: Put the right tsf value in mesh beacons
Matteo Croce (1):
ath9k: fix bug in tx power
Rajkumar Manoharan (1):
ath9k: fix beacon resource related race condition
Senthil Balasubramanian (1):
ath9k: Fix STA disconnect issue due to received MIC failed bcast frames
Sujith Manoharan (1):
ath9k_htc: Fix suspend/resume
drivers/net/wireless/ath/ath5k/base.c | 13 +++++++----
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +-
drivers/net/wireless/ath/ath9k/eeprom_def.c | 12 +++++++---
drivers/net/wireless/ath/ath9k/hif_usb.c | 7 ++++++
drivers/net/wireless/ath/ath9k/htc.h | 3 ++
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 6 +++++
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 4 +-
drivers/net/wireless/ath/ath9k/mac.c | 3 +-
drivers/net/wireless/ath/ath9k/main.c | 26 +++++++++---------------
drivers/net/wireless/ath/ath9k/recv.c | 9 +++++++-
drivers/net/wireless/ath/ath9k/xmit.c | 22 +++++---------------
drivers/net/wireless/orinoco/main.c | 6 +++++
drivers/net/wireless/orinoco/orinoco_cs.c | 14 ++++++------
drivers/net/wireless/orinoco/spectrum_cs.c | 14 ++++++------
drivers/net/wireless/orinoco/wext.c | 4 +-
net/mac80211/tx.c | 21 +++++++++++++++++--
16 files changed, 100 insertions(+), 66 deletions(-)
diff --git a/drivers/net/wireless/ath/ath5k/base.c b/drivers/net/wireless/ath/ath5k/base.c
index 8251946..42ed923 100644
--- a/drivers/net/wireless/ath/ath5k/base.c
+++ b/drivers/net/wireless/ath/ath5k/base.c
@@ -1917,7 +1917,8 @@ ath5k_beacon_send(struct ath5k_softc *sc)
sc->bmisscount = 0;
}
- if (sc->opmode == NL80211_IFTYPE_AP && sc->num_ap_vifs > 1) {
+ if ((sc->opmode == NL80211_IFTYPE_AP && sc->num_ap_vifs > 1) ||
+ sc->opmode == NL80211_IFTYPE_MESH_POINT) {
u64 tsf = ath5k_hw_get_tsf64(ah);
u32 tsftu = TSF_TO_TU(tsf);
int slot = ((tsftu % sc->bintval) * ATH_BCBUF) / sc->bintval;
@@ -1949,8 +1950,9 @@ ath5k_beacon_send(struct ath5k_softc *sc)
/* NB: hw still stops DMA, so proceed */
}
- /* refresh the beacon for AP mode */
- if (sc->opmode == NL80211_IFTYPE_AP)
+ /* refresh the beacon for AP or MESH mode */
+ if (sc->opmode == NL80211_IFTYPE_AP ||
+ sc->opmode == NL80211_IFTYPE_MESH_POINT)
ath5k_beacon_update(sc->hw, vif);
ath5k_hw_set_txdp(ah, sc->bhalq, bf->daddr);
@@ -2851,7 +2853,8 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
/* Assign the vap/adhoc to a beacon xmit slot. */
if ((avf->opmode == NL80211_IFTYPE_AP) ||
- (avf->opmode == NL80211_IFTYPE_ADHOC)) {
+ (avf->opmode == NL80211_IFTYPE_ADHOC) ||
+ (avf->opmode == NL80211_IFTYPE_MESH_POINT)) {
int slot;
WARN_ON(list_empty(&sc->bcbuf));
@@ -2870,7 +2873,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
sc->bslot[avf->bslot] = vif;
if (avf->opmode == NL80211_IFTYPE_AP)
sc->num_ap_vifs++;
- else
+ else if (avf->opmode == NL80211_IFTYPE_ADHOC)
sc->num_adhoc_vifs++;
}
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 0d0bec3..0963071 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -329,7 +329,7 @@ int ath_rx_tasklet(struct ath_softc *sc, int flush, bool hp);
struct ath_txq *ath_txq_setup(struct ath_softc *sc, int qtype, int subtype);
void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq);
int ath_tx_setup(struct ath_softc *sc, int haltype);
-void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx);
+bool ath_drain_all_txq(struct ath_softc *sc, bool retry_tx);
void ath_draintxq(struct ath_softc *sc,
struct ath_txq *txq, bool retry_tx);
void ath_tx_node_init(struct ath_softc *sc, struct ath_node *an);
diff --git a/drivers/net/wireless/ath/ath9k/eeprom_def.c b/drivers/net/wireless/ath/ath9k/eeprom_def.c
index 526d7c9..a3ccb1b 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom_def.c
+++ b/drivers/net/wireless/ath/ath9k/eeprom_def.c
@@ -1063,15 +1063,19 @@ static void ath9k_hw_set_def_power_per_rate_table(struct ath_hw *ah,
case 1:
break;
case 2:
- scaledPower -= REDUCE_SCALED_POWER_BY_TWO_CHAIN;
+ if (scaledPower > REDUCE_SCALED_POWER_BY_TWO_CHAIN)
+ scaledPower -= REDUCE_SCALED_POWER_BY_TWO_CHAIN;
+ else
+ scaledPower = 0;
break;
case 3:
- scaledPower -= REDUCE_SCALED_POWER_BY_THREE_CHAIN;
+ if (scaledPower > REDUCE_SCALED_POWER_BY_THREE_CHAIN)
+ scaledPower -= REDUCE_SCALED_POWER_BY_THREE_CHAIN;
+ else
+ scaledPower = 0;
break;
}
- scaledPower = max((u16)0, scaledPower);
-
if (IS_CHAN_2GHZ(chan)) {
numCtlModes = ARRAY_SIZE(ctlModesFor11g) -
SUB_NUM_CTL_MODES_AT_2G_40;
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index dfb6560..0de3c3d 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -1024,6 +1024,13 @@ static int ath9k_hif_usb_suspend(struct usb_interface *interface,
struct hif_device_usb *hif_dev =
(struct hif_device_usb *) usb_get_intfdata(interface);
+ /*
+ * The device has to be set to FULLSLEEP mode in case no
+ * interface is up.
+ */
+ if (!(hif_dev->flags & HIF_USB_START))
+ ath9k_htc_suspend(hif_dev->htc_handle);
+
ath9k_hif_usb_dealloc_urbs(hif_dev);
return 0;
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index 75ecf6a..c3b561d 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -455,6 +455,8 @@ u32 ath9k_htc_calcrxfilter(struct ath9k_htc_priv *priv);
void ath9k_htc_ps_wakeup(struct ath9k_htc_priv *priv);
void ath9k_htc_ps_restore(struct ath9k_htc_priv *priv);
void ath9k_ps_work(struct work_struct *work);
+bool ath9k_htc_setpower(struct ath9k_htc_priv *priv,
+ enum ath9k_power_mode mode);
void ath9k_start_rfkill_poll(struct ath9k_htc_priv *priv);
void ath9k_init_leds(struct ath9k_htc_priv *priv);
@@ -464,6 +466,7 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
u16 devid, char *product);
void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug);
#ifdef CONFIG_PM
+void ath9k_htc_suspend(struct htc_target *htc_handle);
int ath9k_htc_resume(struct htc_target *htc_handle);
#endif
#ifdef CONFIG_ATH9K_HTC_DEBUGFS
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 7c8a38d..8776f49 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -891,6 +891,12 @@ void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
}
#ifdef CONFIG_PM
+
+void ath9k_htc_suspend(struct htc_target *htc_handle)
+{
+ ath9k_htc_setpower(htc_handle->drv_priv, ATH9K_PM_FULL_SLEEP);
+}
+
int ath9k_htc_resume(struct htc_target *htc_handle)
{
int ret;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 9a3be8d..51977ca 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -63,8 +63,8 @@ static enum htc_phymode ath9k_htc_get_curmode(struct ath9k_htc_priv *priv,
return mode;
}
-static bool ath9k_htc_setpower(struct ath9k_htc_priv *priv,
- enum ath9k_power_mode mode)
+bool ath9k_htc_setpower(struct ath9k_htc_priv *priv,
+ enum ath9k_power_mode mode)
{
bool ret;
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 8c13479..c996963 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -703,8 +703,7 @@ int ath9k_hw_rxprocdesc(struct ath_hw *ah, struct ath_desc *ds,
rs->rs_phyerr = phyerr;
} else if (ads.ds_rxstatus8 & AR_DecryptCRCErr)
rs->rs_status |= ATH9K_RXERR_DECRYPT;
- else if ((ads.ds_rxstatus8 & AR_MichaelErr) &&
- rs->rs_keyix != ATH9K_RXKEYIX_INVALID)
+ else if (ads.ds_rxstatus8 & AR_MichaelErr)
rs->rs_status |= ATH9K_RXERR_MIC;
else if (ads.ds_rxstatus8 & AR_KeyMiss)
rs->rs_status |= ATH9K_RXERR_DECRYPT;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index dace215..c0c3464 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -244,11 +244,12 @@ int ath_set_channel(struct ath_softc *sc, struct ieee80211_hw *hw,
* the relevant bits of the h/w.
*/
ath9k_hw_set_interrupts(ah, 0);
- ath_drain_all_txq(sc, false);
+ stopped = ath_drain_all_txq(sc, false);
spin_lock_bh(&sc->rx.pcu_lock);
- stopped = ath_stoprecv(sc);
+ if (!ath_stoprecv(sc))
+ stopped = false;
/* XXX: do not flush receive queue here. We don't want
* to flush data frames already in queue because of
@@ -1519,8 +1520,6 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
struct ath_softc *sc = aphy->sc;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ath_vif *avp = (void *)vif->drv_priv;
- bool bs_valid = false;
- int i;
ath_print(common, ATH_DBG_CONFIG, "Detach Interface\n");
@@ -1534,26 +1533,21 @@ static void ath9k_remove_interface(struct ieee80211_hw *hw,
if ((sc->sc_ah->opmode == NL80211_IFTYPE_AP) ||
(sc->sc_ah->opmode == NL80211_IFTYPE_ADHOC) ||
(sc->sc_ah->opmode == NL80211_IFTYPE_MESH_POINT)) {
+ /* Disable SWBA interrupt */
+ sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
ath9k_ps_wakeup(sc);
+ ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
ath9k_ps_restore(sc);
+ tasklet_kill(&sc->bcon_tasklet);
}
ath_beacon_return(sc, avp);
sc->sc_flags &= ~SC_OP_BEACONS;
- for (i = 0; i < ARRAY_SIZE(sc->beacon.bslot); i++) {
- if (sc->beacon.bslot[i] == vif) {
- printk(KERN_DEBUG "%s: vif had allocated beacon "
- "slot\n", __func__);
- sc->beacon.bslot[i] = NULL;
- sc->beacon.bslot_aphy[i] = NULL;
- } else if (sc->beacon.bslot[i])
- bs_valid = true;
- }
- if (!bs_valid && (sc->sc_ah->imask & ATH9K_INT_SWBA)) {
- /* Disable SWBA interrupt */
- sc->sc_ah->imask &= ~ATH9K_INT_SWBA;
+ if (sc->nbcnvifs) {
+ /* Re-enable SWBA interrupt */
+ sc->sc_ah->imask |= ATH9K_INT_SWBA;
ath9k_ps_wakeup(sc);
ath9k_hw_set_interrupts(sc->sc_ah, sc->sc_ah->imask);
ath9k_ps_restore(sc);
diff --git a/drivers/net/wireless/ath/ath9k/recv.c b/drivers/net/wireless/ath/ath9k/recv.c
index 1a62e35..fdc2ec5 100644
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@ -838,6 +838,10 @@ static bool ath9k_rx_accept(struct ath_common *common,
struct ath_rx_status *rx_stats,
bool *decrypt_error)
{
+#define is_mc_or_valid_tkip_keyix ((is_mc || \
+ (rx_stats->rs_keyix != ATH9K_RXKEYIX_INVALID && \
+ test_bit(rx_stats->rs_keyix, common->tkip_keymap))))
+
struct ath_hw *ah = common->ah;
__le16 fc;
u8 rx_status_len = ah->caps.rx_status_len;
@@ -879,15 +883,18 @@ static bool ath9k_rx_accept(struct ath_common *common,
if (rx_stats->rs_status & ATH9K_RXERR_DECRYPT) {
*decrypt_error = true;
} else if (rx_stats->rs_status & ATH9K_RXERR_MIC) {
+ bool is_mc;
/*
* The MIC error bit is only valid if the frame
* is not a control frame or fragment, and it was
* decrypted using a valid TKIP key.
*/
+ is_mc = !!is_multicast_ether_addr(hdr->addr1);
+
if (!ieee80211_is_ctl(fc) &&
!ieee80211_has_morefrags(fc) &&
!(le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG) &&
- test_bit(rx_stats->rs_keyix, common->tkip_keymap))
+ is_mc_or_valid_tkip_keyix)
rxs->flag |= RX_FLAG_MMIC_ERROR;
else
rx_stats->rs_status &= ~ATH9K_RXERR_MIC;
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index f2ade24..aff0478 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -1120,7 +1120,7 @@ void ath_draintxq(struct ath_softc *sc, struct ath_txq *txq, bool retry_tx)
}
}
-void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
+bool ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
{
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
@@ -1128,7 +1128,7 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
int i, npend = 0;
if (sc->sc_flags & SC_OP_INVALID)
- return;
+ return true;
/* Stop beacon queue */
ath9k_hw_stoptxdma(sc->sc_ah, sc->beacon.beaconq);
@@ -1142,25 +1142,15 @@ void ath_drain_all_txq(struct ath_softc *sc, bool retry_tx)
}
}
- if (npend) {
- int r;
-
- ath_print(common, ATH_DBG_FATAL,
- "Failed to stop TX DMA. Resetting hardware!\n");
-
- spin_lock_bh(&sc->sc_resetlock);
- r = ath9k_hw_reset(ah, sc->sc_ah->curchan, ah->caldata, false);
- if (r)
- ath_print(common, ATH_DBG_FATAL,
- "Unable to reset hardware; reset status %d\n",
- r);
- spin_unlock_bh(&sc->sc_resetlock);
- }
+ if (npend)
+ ath_print(common, ATH_DBG_FATAL, "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);
}
+
+ return !npend;
}
void ath_tx_cleanupq(struct ath_softc *sc, struct ath_txq *txq)
diff --git a/drivers/net/wireless/orinoco/main.c b/drivers/net/wireless/orinoco/main.c
index fa0cf74..f3d396e 100644
--- a/drivers/net/wireless/orinoco/main.c
+++ b/drivers/net/wireless/orinoco/main.c
@@ -1811,6 +1811,12 @@ static int __orinoco_commit(struct orinoco_private *priv)
struct net_device *dev = priv->ndev;
int err = 0;
+ /* If we've called commit, we are reconfiguring or bringing the
+ * interface up. Maintaining countermeasures across this would
+ * be confusing, so note that we've disabled them. The port will
+ * be enabled later in orinoco_commit or __orinoco_up. */
+ priv->tkip_cm_active = 0;
+
err = orinoco_hw_program_rids(priv);
/* FIXME: what about netif_tx_lock */
diff --git a/drivers/net/wireless/orinoco/orinoco_cs.c b/drivers/net/wireless/orinoco/orinoco_cs.c
index 71b3d68..32954c4 100644
--- a/drivers/net/wireless/orinoco/orinoco_cs.c
+++ b/drivers/net/wireless/orinoco/orinoco_cs.c
@@ -151,20 +151,20 @@ orinoco_cs_config(struct pcmcia_device *link)
goto failed;
}
- ret = pcmcia_request_irq(link, orinoco_interrupt);
- if (ret)
- goto failed;
-
- /* We initialize the hermes structure before completing PCMCIA
- * configuration just in case the interrupt handler gets
- * called. */
mem = ioport_map(link->resource[0]->start,
resource_size(link->resource[0]));
if (!mem)
goto failed;
+ /* We initialize the hermes structure before completing PCMCIA
+ * configuration just in case the interrupt handler gets
+ * called. */
hermes_struct_init(hw, mem, HERMES_16BIT_REGSPACING);
+ ret = pcmcia_request_irq(link, orinoco_interrupt);
+ if (ret)
+ goto failed;
+
ret = pcmcia_enable_device(link);
if (ret)
goto failed;
diff --git a/drivers/net/wireless/orinoco/spectrum_cs.c b/drivers/net/wireless/orinoco/spectrum_cs.c
index fb859a5..db34c28 100644
--- a/drivers/net/wireless/orinoco/spectrum_cs.c
+++ b/drivers/net/wireless/orinoco/spectrum_cs.c
@@ -214,21 +214,21 @@ spectrum_cs_config(struct pcmcia_device *link)
goto failed;
}
- ret = pcmcia_request_irq(link, orinoco_interrupt);
- if (ret)
- goto failed;
-
- /* We initialize the hermes structure before completing PCMCIA
- * configuration just in case the interrupt handler gets
- * called. */
mem = ioport_map(link->resource[0]->start,
resource_size(link->resource[0]));
if (!mem)
goto failed;
+ /* We initialize the hermes structure before completing PCMCIA
+ * configuration just in case the interrupt handler gets
+ * called. */
hermes_struct_init(hw, mem, HERMES_16BIT_REGSPACING);
hw->eeprom_pda = true;
+ ret = pcmcia_request_irq(link, orinoco_interrupt);
+ if (ret)
+ goto failed;
+
ret = pcmcia_enable_device(link);
if (ret)
goto failed;
diff --git a/drivers/net/wireless/orinoco/wext.c b/drivers/net/wireless/orinoco/wext.c
index 93505f9..e5afabe 100644
--- a/drivers/net/wireless/orinoco/wext.c
+++ b/drivers/net/wireless/orinoco/wext.c
@@ -911,10 +911,10 @@ static int orinoco_ioctl_set_auth(struct net_device *dev,
*/
if (param->value) {
priv->tkip_cm_active = 1;
- ret = hermes_enable_port(hw, 0);
+ ret = hermes_disable_port(hw, 0);
} else {
priv->tkip_cm_active = 0;
- ret = hermes_disable_port(hw, 0);
+ ret = hermes_enable_port(hw, 0);
}
break;
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index df6aac5..7a637b8 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -1737,15 +1737,13 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
int nh_pos, h_pos;
struct sta_info *sta = NULL;
u32 sta_flags = 0;
+ struct sk_buff *tmp_skb;
if (unlikely(skb->len < ETH_HLEN)) {
ret = NETDEV_TX_OK;
goto fail;
}
- nh_pos = skb_network_header(skb) - skb->data;
- h_pos = skb_transport_header(skb) - skb->data;
-
/* convert Ethernet header to proper 802.11 header (based on
* operation mode) */
ethertype = (skb->data[12] << 8) | skb->data[13];
@@ -1918,6 +1916,20 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
goto fail;
}
+ /*
+ * If the skb is shared we need to obtain our own copy.
+ */
+ if (skb_shared(skb)) {
+ tmp_skb = skb;
+ skb = skb_copy(skb, GFP_ATOMIC);
+ kfree_skb(tmp_skb);
+
+ if (!skb) {
+ ret = NETDEV_TX_OK;
+ goto fail;
+ }
+ }
+
hdr.frame_control = fc;
hdr.duration_id = 0;
hdr.seq_ctrl = 0;
@@ -1936,6 +1948,9 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
encaps_len = 0;
}
+ nh_pos = skb_network_header(skb) - skb->data;
+ h_pos = skb_transport_header(skb) - skb->data;
+
skb_pull(skb, skip_header_bytes);
nh_pos -= skip_header_bytes;
h_pos -= skip_header_bytes;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 0/2] iwlwifi fix for 2.6.37
From: John W. Linville @ 2010-12-10 20:17 UTC (permalink / raw)
To: Wey-Yi Guy; +Cc: linux-wireless, ipw3945-devel
In-Reply-To: <1291918780-10882-1-git-send-email-wey-yi.w.guy@intel.com>
On Thu, Dec 09, 2010 at 10:19:38AM -0800, Wey-Yi Guy wrote:
> The original method used to parsing EEPROM Tx Power Table was hardcode and
> not forward compatible with newer devices. Fix it here to be layout agnostic
>
> John, we split EEPROM reading patches to two stage, for .37 release,
> the existing devices will not change, only the newer devices will use
> the new EEPROM reading method; we will remove the old EEPROM reading method
> all together in separated patch for .38 release. Please let me know if this
> is ok
OK, I think this will do.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
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