* [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: Tim Gardner @ 2009-07-13 19:08 UTC (permalink / raw)
To: yi.zhu; +Cc: ipw3945-devel, linux-kernel, linux-wireless, reinette.chatre
>From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
From: Tim Gardner <tim.gardner@canonical.com>
Date: Mon, 13 Jul 2009 12:53:32 -0600
Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
Added a missing parameter in the macro invocation to correct a
compile error when CONFIG_IWLWIFI_DEBUG is enabled.
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
---
drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
index 2564288..67332fb 100644
--- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
+++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
@@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
}
if (scan->channel_count == 0) {
- IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
+ IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
goto done;
}
--
1.6.3.3
^ permalink raw reply related
* iwlagn 0000:03:00.0: Can not allocate SKB buffers
From: Mackenzie Morgan @ 2009-07-13 20:13 UTC (permalink / raw)
To: linux-wireless
[-- Attachment #1: Type: Text/Plain, Size: 484 bytes --]
I have the error listed in the subject repeating over and over in my syslog.
Ubuntu's kernel team has daily builds of Linus's tree, and I'm using today's
(13 July 2009) on amd64. top is also showing iwlagn with very high CPU usage.
I'm wondering if these are known issues.
I have an Intel 4965 with SSID 8086:1100, and I'm using 802.11g with WPA2 at
the moment (in case that's relevant).
--
Mackenzie Morgan
http://ubuntulinuxtipstricks.blogspot.com
apt-get moo
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: reinette chatre @ 2009-07-13 20:14 UTC (permalink / raw)
To: timg@tpi.com
Cc: Zhu, Yi, ipw3945-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <4A5B9388.4030208@tpi.com>
Hi Tim,
On Mon, 2009-07-13 at 13:05 -0700, Tim Gardner wrote:
> reinette chatre wrote:
> > Hi Tim,
> >
> > On Mon, 2009-07-13 at 12:08 -0700, Tim Gardner wrote:
> >> From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
> >> From: Tim Gardner <tim.gardner@canonical.com>
> >> Date: Mon, 13 Jul 2009 12:53:32 -0600
> >> Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
> >>
> >> Added a missing parameter in the macro invocation to correct a
> >> compile error when CONFIG_IWLWIFI_DEBUG is enabled.
> >>
> >> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
> >> ---
> >> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
> >> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>
> >> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> index 2564288..67332fb 100644
> >> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> >> @@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
> >> }
> >>
> >> if (scan->channel_count == 0) {
> >> - IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
> >> + IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
> >> goto done;
> >> }
> >>
> >
> > On which code did you base this patch?
> >
> > Reinette
> >
> >
>
> Head of Linus' tree, but I see that its already fixed in
> wireless-testing. I guess I pulled the trigger too soon.
I just pulled the latest from Linus but cannot see this problem. We also
do not have anything related to this pending for 2.6.31.
Reinette
^ permalink raw reply
* Re: iwl: potential deadlock?
From: reinette chatre @ 2009-07-13 20:18 UTC (permalink / raw)
To: Jiri Slaby
Cc: Zhu, Yi, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Linux kernel mailing list
In-Reply-To: <4A5B8C60.9000600@gmail.com>
Hi Jiri,
On Mon, 2009-07-13 at 12:34 -0700, Jiri Slaby wrote:
> Hi,
>
> we found a potential deadlock in iwl code by our tool.
What tool is this?
>
> Can this happen:
I don't think so ...
> iwl_update_tkip_key()
> -> spin_lock_irqsave(&priv->sta_lock)
> -> iwl_send_add_sta()
iwl_send_add_sta() is called here with flags = CMD_ASYNC
In iwl_send_add_sta() we have:
if (ret || (flags & CMD_ASYNC))
return ret;
> -> iwl_sta_ucode_activate()
... so this is not run in this case.
> -> spin_lock_irqsave(&priv->sta_lock)
Reinette
^ permalink raw reply
* Re: Add device string to zd1211rw
From: Hin-Tak Leung @ 2009-07-13 20:23 UTC (permalink / raw)
To: Adrián Cereto; +Cc: dsd, kune, linux-wireless
In-Reply-To: <328c675a0907121316r7dacda0fr94b3b56a6c023d86@mail.gmail.com>
On Sun, Jul 12, 2009 at 9:16 PM, Adrián Cereto<ssorgatem@esdebian.org> wrote:
> I have a wireless adapter with the following device string from lsusb:
> "ID 083a:e501 Accton Technology Corp. ZD1211B"
>
> It's device string was not in the zd1211rw driver, so I wondered what
> would happen if I added it to zd_usb.c... and voilà, now it works
> great ;) (i'm writing this connected with that adapter)
>
> I've tried it with compat-wireless-2.6.30, with kernels 2.6.28 (ubuntu
> 9.04) and 2.6.30 (debian sid), and it works. I've tried to do it with
> the bleeding edge compat-wireless, but it wouldn't compile on any of
> my machines (the stable version compiled just fine, though).
compat-wireless latest-and-greatest is a bit broken lately, in the
last week or so. You are not the only one affected - Luis is working
on it, I think.
>
> The only thing I did was to put the following line in the device
> string list in drivers/net/wireless/zd1211rw/zd_usb.c:
>
> { USB_DEVICE(0x083a, 0xe501), .driver_info = DEVICE_ZD1211B }
>
> Do I need to send you a patch?
> (if it weren't such a minute modification I wouldn't doubt it)
> I've never done it before, but i'll learn to do it if necessary ;).
A patch is not necessary, but having the RF type line from your dmesg
would be good.
>
> If you need more testing on this device, count me.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* RT61 antenna diversity in 2.6.30
From: Lars Ericsson @ 2009-07-13 20:24 UTC (permalink / raw)
To: 'Ivo van Doorn'; +Cc: linux-wireless, users
Hi Ivo,
I recently moved from 2.6.26 to 2.6.30 with a HW that do
SW antenna diversity with .26 but not with .30
I have found two problems:
1) The rt2x00mac_config() calls rt2x00lib_config_antenna() and reset the
rt2x00dev->default_ant.
2) The rt2x00lib_antenna_diversity_sample() does not update the sampled
antenna rssi.
I have applied the following patches to correct the problems:
1)
--- a/drivers/net/wireless/rt2x00/rt2x00link.c 2009-07-13
21:48:45.000000000 +0200
+++ b/drivers/net/wireless/rt2x00/rt2x00link.c 2009-07-13
21:52:42.000000000 +0200
@@ -146,8 +151,13 @@ static void rt2x00lib_antenna_diversity_
{
struct link_ant *ant = &rt2x00dev->link.ant;
struct antenna_setup new_ant;
- int sample_a = rt2x00link_antenna_get_rssi_history(rt2x00dev,
ANTENNA_A);
- int sample_b = rt2x00link_antenna_get_rssi_history(rt2x00dev,
ANTENNA_B);
+ int rssi_curr, sample_a, sample_b;
+
+ rssi_curr = rt2x00link_antenna_get_link_rssi(rt2x00dev);
+ rt2x00link_antenna_update_rssi_rx_history(rt2x00dev, rssi_curr);
+
+ sample_a = rt2x00link_antenna_get_rssi_history(rt2x00dev,
ANTENNA_A);
+ sample_b = rt2x00link_antenna_get_rssi_history(rt2x00dev,
ANTENNA_B);
memcpy(&new_ant, &ant->active, sizeof(new_ant));
---
2)
--- a/drivers/net/wireless/rt2x00/rt2x00mac.c 2009-07-13
21:51:26.000000000 +0200
+++ b/drivers/net/wireless/rt2x00/rt2x00mac.c 2009-07-13
21:54:28.000000000 +0200
@@ -375,10 +375,12 @@ int rt2x00mac_config(struct ieee80211_hw
* diversity. But for non-diversity configurations, we need
* to have configured the correct state now.
*/
- if (changed & IEEE80211_CONF_CHANGE_RADIO_ENABLED)
+ if (changed & IEEE80211_CONF_CHANGE_RADIO_ENABLED) {
+ rt2x00dev->link.ant.active = rt2x00dev->default_ant;
rt2x00lib_config_antenna(rt2x00dev,
- &rt2x00dev->default_ant);
-
+
&rt2x00dev->link.ant.active);
+ }
+
/* Turn RX back on */
rt2x00lib_toggle_rx(rt2x00dev, STATE_RADIO_RX_ON);
} else {
Regards
Lars
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: Rafał Miłecki @ 2009-07-13 20:30 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247182010.17896.1344.camel@rc-desk>
W dniu 10 lipca 2009 01:26 użytkownik reinette chatre
<reinette.chatre@intel.com> napisał:
>> Can you reveal some plans of upgrading 5100/5300/5350 uCode? Any
>> estimate would be nice to known. This month? This year?
>
> I am not aware of any scheduled date for a new release. Are there
> critical issues that you are aware of that requires a new uCode?
I noticed new bug report about firmware failure on scp (using new
firmware). I use ssh/sftp/scp a lot, so it doesn't sound nice to me.
Moreover it seems to be quite reproductable, so I'm scared of hittint
it quite often.
--
Rafał Miłecki
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: Rafał Miłecki @ 2009-07-13 20:32 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <b170af450907131330o7eda50bakd6119f47af35d564@mail.gmail.com>
W dniu 13 lipca 2009 22:30 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> W dniu 10 lipca 2009 01:26 użytkownik reinette chatre
> <reinette.chatre@intel.com> napisał:
>>> Can you reveal some plans of upgrading 5100/5300/5350 uCode? Any
>>> estimate would be nice to known. This month? This year?
>>
>> I am not aware of any scheduled date for a new release. Are there
>> critical issues that you are aware of that requires a new uCode?
>
> I noticed new bug report about firmware failure on scp (using new
> firmware). I use ssh/sftp/scp a lot, so it doesn't sound nice to me.
>
> Moreover it seems to be quite reproductable, so I'm scared of hittint
> it quite often.
Probably I really should post link to bug report:
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004
--
Rafał Miłecki
^ permalink raw reply
* Re: iwl: potential deadlock?
From: Jiri Slaby @ 2009-07-13 20:33 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, Linux kernel mailing list
In-Reply-To: <1247516320.17896.1640.camel@rc-desk>
On 07/13/2009 10:18 PM, reinette chatre wrote:
> On Mon, 2009-07-13 at 12:34 -0700, Jiri Slaby wrote:
>> we found a potential deadlock in iwl code by our tool.
>
> What tool is this?
It's called stanse[1], we still work on it.
>> iwl_update_tkip_key()
>> -> spin_lock_irqsave(&priv->sta_lock)
>> -> iwl_send_add_sta()
>
> iwl_send_add_sta() is called here with flags = CMD_ASYNC
>
> In iwl_send_add_sta() we have:
> if (ret || (flags & CMD_ASYNC))
> return ret;
Yes, you're right, indeed. Thanks for the explanation.
[1] http://iti.fi.muni.cz/stanse/
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-13 20:38 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <b170af450907131332x65b43bbfxa76ff2abc743317a@mail.gmail.com>
On Mon, 2009-07-13 at 13:32 -0700, Rafał Miłecki wrote:
> W dniu 13 lipca 2009 22:30 użytkownik Rafał Miłecki <zajec5@gmail.com> napisał:
> > W dniu 10 lipca 2009 01:26 użytkownik reinette chatre
> > <reinette.chatre@intel.com> napisał:
> >>> Can you reveal some plans of upgrading 5100/5300/5350 uCode? Any
> >>> estimate would be nice to known. This month? This year?
> >>
> >> I am not aware of any scheduled date for a new release. Are there
> >> critical issues that you are aware of that requires a new uCode?
> >
> > I noticed new bug report about firmware failure on scp (using new
> > firmware). I use ssh/sftp/scp a lot, so it doesn't sound nice to me.
> >
> > Moreover it seems to be quite reproductable, so I'm scared of hittint
> > it quite often.
>
> Probably I really should post link to bug report:
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004
This bug was reported against 5100 series hardware and is not present in
4965. Even so, this bug was fixed in the driver and the patch has
already been pushed upstream.
Reinette
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: Rafał Miłecki @ 2009-07-13 20:43 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247517511.17896.1652.camel@rc-desk>
W dniu 13 lipca 2009 22:38 użytkownik reinette chatre
<reinette.chatre@intel.com> napisał:
>> Probably I really should post link to bug report:
>> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004
>
> This bug was reported against 5100 series hardware and is not present in
> 4965. Even so, this bug was fixed in the driver and the patch has
> already been pushed upstream.
Great, thanks for clarifying. It was reported on 5100, reproduced on
5300, so I was afraid also with my 4965 :)
If I may suggest something, it would be nice to keep current status in
bug report. I was waiting to see any commend about fixing driver of
resolving report by updating firmware.
--
Rafał Miłecki
^ permalink raw reply
* Re: Add device string to zd1211rw
From: Adrià Cereto Massagué @ 2009-07-13 20:46 UTC (permalink / raw)
To: Hin-Tak Leung; +Cc: dsd, kune, linux-wireless
In-Reply-To: <3ace41890907131323t10c5bc15oac1714e63289abd@mail.gmail.com>
A Dilluns, 13 de juliol de 2009 22:23:05, Hin-Tak Leung va escriure:
> On Sun, Jul 12, 2009 at 9:16 PM, Adrián Cereto<ssorgatem@esdebian.org>
wrote:
> > I have a wireless adapter with the following device string from lsusb:
> > "ID 083a:e501 Accton Technology Corp. ZD1211B"
> >
> > It's device string was not in the zd1211rw driver, so I wondered what
> > would happen if I added it to zd_usb.c... and voilà, now it works
> > great ;) (i'm writing this connected with that adapter)
> >
> > I've tried it with compat-wireless-2.6.30, with kernels 2.6.28 (ubuntu
> > 9.04) and 2.6.30 (debian sid), and it works. I've tried to do it with
> > the bleeding edge compat-wireless, but it wouldn't compile on any of
> > my machines (the stable version compiled just fine, though).
>
> compat-wireless latest-and-greatest is a bit broken lately, in the
> last week or so. You are not the only one affected - Luis is working
> on it, I think.
>
> > The only thing I did was to put the following line in the device
> > string list in drivers/net/wireless/zd1211rw/zd_usb.c:
> >
> > { USB_DEVICE(0x083a, 0xe501), .driver_info = DEVICE_ZD1211B }
> >
> > Do I need to send you a patch?
> > (if it weren't such a minute modification I wouldn't doubt it)
> > I've never done it before, but i'll learn to do it if necessary ;).
>
> A patch is not necessary, but having the RF type line from your dmesg
> would be good.
I'm not sure if this is what you need, but here it is:
ssorgatem@sobremesakubuntu:~$ dmesg | grep -i zd1211rw
[ 10.045331] zd1211rw 1-2:1.0: phy0
[ 10.045390] usbcore: registered new interface driver zd1211rw
[ 13.184194] zd1211rw 1-2:1.0: firmware version 4725
[ 13.224200] zd1211rw 1-2:1.0: zd1211b chip 083a:e501 v4810 high 00-1a-2a
AL2230_RF pa0 g--NS
I hope it helps.
> > If you need more testing on this device, count me.
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> > in the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] iwlwifi 3945: Fix IWL_SCAN compile error
From: Tim Gardner @ 2009-07-13 20:47 UTC (permalink / raw)
To: reinette chatre
Cc: Zhu, Yi, ipw3945-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org
In-Reply-To: <1247516054.17896.1634.camel@rc-desk>
reinette chatre wrote:
> Hi Tim,
>
> On Mon, 2009-07-13 at 13:05 -0700, Tim Gardner wrote:
>> reinette chatre wrote:
>>> Hi Tim,
>>>
>>> On Mon, 2009-07-13 at 12:08 -0700, Tim Gardner wrote:
>>>> From 2c7c806570ad72f5af2e778f2fe71aae7d727e02 Mon Sep 17 00:00:00 2001
>>>> From: Tim Gardner <tim.gardner@canonical.com>
>>>> Date: Mon, 13 Jul 2009 12:53:32 -0600
>>>> Subject: [PATCH] iwlwifi 3945: Fix IWL_DEBUG_SCAN compile
>>>>
>>>> Added a missing parameter in the macro invocation to correct a
>>>> compile error when CONFIG_IWLWIFI_DEBUG is enabled.
>>>>
>>>> Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
>>>> ---
>>>> drivers/net/wireless/iwlwifi/iwl3945-base.c | 2 +-
>>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>>> index 2564288..67332fb 100644
>>>> --- a/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>>> +++ b/drivers/net/wireless/iwlwifi/iwl3945-base.c
>>>> @@ -2962,7 +2962,7 @@ static void iwl3945_bg_request_scan(struct work_struct *data)
>>>> }
>>>>
>>>> if (scan->channel_count == 0) {
>>>> - IWL_DEBUG_SCAN("channel count %d\n", scan->channel_count);
>>>> + IWL_DEBUG_SCAN(priv,"channel count %d\n", scan->channel_count);
>>>> goto done;
>>>> }
>>>>
>>> On which code did you base this patch?
>>>
>>> Reinette
>>>
>>>
>> Head of Linus' tree, but I see that its already fixed in
>> wireless-testing. I guess I pulled the trigger too soon.
>
> I just pulled the latest from Linus but cannot see this problem. We also
> do not have anything related to this pending for 2.6.31.
>
> Reinette
>
>
You are correct. It appears I've got a rebase issue. I rebased Ubuntu
Karmic against linus git 4a390e07fc53ce9dd615d7b788e9ecc73f87ad94 and
find that there is one extra commit when comparing the output of 'git
log --pretty=oneline drivers/net/wireless/iwlwifi/iwl3945-base.c' . The
last commit that touches iwl3945-base.c in the Karmic tree is 'iwl3945:
do not send scan command if channel count zero', which is totally
bizarre. If I look at the patches created by 'git log -p
drivers/net/wireless/iwlwifi/iwl3945-base.c', the patch that implements
'iwl3945: do not send scan command if channel count zero' is duplicated.
How can that be? Guess I'll keep digging.
rtg
--
Tim Gardner timg@tpi.com www.tpi.com
OR 503-601-0234 x102 MT 406-443-5357
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-13 20:48 UTC (permalink / raw)
To: Rafał Miłecki
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <b170af450907131343r69af3da6ob49c92ed6682f76f@mail.gmail.com>
On Mon, 2009-07-13 at 13:43 -0700, Rafał Miłecki wrote:
> W dniu 13 lipca 2009 22:38 użytkownik reinette chatre
> <reinette.chatre@intel.com> napisał:
> >> Probably I really should post link to bug report:
> >> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004
> >
> > This bug was reported against 5100 series hardware and is not present in
> > 4965. Even so, this bug was fixed in the driver and the patch has
> > already been pushed upstream.
>
> Great, thanks for clarifying. It was reported on 5100, reproduced on
> 5300, so I was afraid also with my 4965 :)
>
> If I may suggest something, it would be nice to keep current status in
> bug report. I was waiting to see any commend about fixing driver of
> resolving report by updating firmware.
I think the information you are asking for is captured in comments 16
and 17.
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004#c16
http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004#c17
Reinette
^ permalink raw reply
* Re: nl80211 and wext interoperability
From: Dan Williams @ 2009-07-13 20:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: Luis R. Rodriguez, linux-wireless
In-Reply-To: <1247512484.30003.0.camel@johannes.local>
On Mon, 2009-07-13 at 21:14 +0200, Johannes Berg wrote:
> On Mon, 2009-07-13 at 15:10 -0400, Dan Williams wrote:
> > On Mon, 2009-07-13 at 19:54 +0200, Johannes Berg wrote:
> > > On Mon, 2009-07-13 at 13:53 -0400, Dan Williams wrote:
> > >
> > > > Mainly because there's no way to tell WEXT drivers to "stop whatever
> > > > you're doing and just be idle"...
> > > >
> > > > The supplicant clears out the keys on TERM anyway, and in some cases
> > > > (iwlagn) the driver will keep trying to reassociate internally
> > >
> > > Seems unlikely, ITYM ipw?
> >
> > Nope. I saw this behavior with iwlagn (both 3945 and 4965) when I was
> > doing all that hidden stuff back in April with 2.6.27 kernels. Might be
> > different in very recent kernels?
>
> That doesn't sound right, to the best of my knowledge the _driver_ has
> no chance to try to associate, and mac80211 didn't.
For some reason it did. I can't figure out why it would keep doing so,
but the supplicant was dead, and the driver would try to reassociate
every time the AP kicked it off wtih "AP denied association (code=13)"
becuase the supplicant already cleared the keys and IEs but not the
SSID.
All because we can't tell WEXT to just stop doing anything and sit
there.
Dan
^ permalink raw reply
* Re: Add device string to zd1211rw
From: Hin-Tak Leung @ 2009-07-13 20:59 UTC (permalink / raw)
To: ssorgatem; +Cc: dsd, kune, linux-wireless
In-Reply-To: <200907132246.51260.ssorgatem@esdebian.org>
2009/7/13 Adrià Cereto Massagué <ssorgatem@gmail.com>:
> I'm not sure if this is what you need, but here it is:
>
> ssorgatem@sobremesakubuntu:~$ dmesg | grep -i zd1211rw
> [ 10.045331] zd1211rw 1-2:1.0: phy0
> [ 10.045390] usbcore: registered new interface driver zd1211rw
> [ 13.184194] zd1211rw 1-2:1.0: firmware version 4725
> [ 13.224200] zd1211rw 1-2:1.0: zd1211b chip 083a:e501 v4810 high 00-1a-2a
> AL2230_RF pa0 g--NS
Good - The AL2230_RF line is what I asked for.
Hin-Tak
^ permalink raw reply
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: Rafał Miłecki @ 2009-07-13 21:12 UTC (permalink / raw)
To: reinette chatre
Cc: linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <1247518099.17896.1654.camel@rc-desk>
W dniu 13 lipca 2009 22:48 użytkownik reinette chatre
<reinette.chatre@intel.com> napisał:
> I think the information you are asking for is captured in comments 16
> and 17.
>
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004#c16
> http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=2004#c17
Ups, I totally failed in my reading skills :/
--
Rafał Miłecki
^ permalink raw reply
* [RFC/RFT V2] rtl8187: Fix for kernel oops when unloading with LEDs enabled
From: Larry Finger @ 2009-07-13 21:13 UTC (permalink / raw)
To: netrolller.3d
Cc: Herton Ronaldo Krzesinski, Hin-Tak Leung, John W Linville,
linux-wireless
When rtl8187 is unloaded and CONFIG_RTL8187_LEDS is set, the kernel
may oops when the module is unloaded as the workqueue for led_on was
not being cancelled.
Reported-by: Gábor Stefanik <netrolller.3d@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger>
---
V2 - Do not create a new workqueue.
Gábor,
I hope this version of the patch fixes your problem. On my system
I ran more than 20 rmmod/insmod cycles without a problem.
Larry
---
Index: wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
===================================================================
--- wireless-testing.orig/drivers/net/wireless/rtl818x/rtl8187_leds.c
+++ wireless-testing/drivers/net/wireless/rtl818x/rtl8187_leds.c
@@ -208,11 +208,12 @@ void rtl8187_leds_exit(struct ieee80211_
{
struct rtl8187_priv *priv = dev->priv;
- rtl8187_unregister_led(&priv->led_tx);
/* turn the LED off before exiting */
queue_delayed_work(dev->workqueue, &priv->led_off, 0);
cancel_delayed_work_sync(&priv->led_off);
+ cancel_delayed_work_sync(&priv->led_on);
rtl8187_unregister_led(&priv->led_rx);
+ rtl8187_unregister_led(&priv->led_tx);
}
#endif /* def CONFIG_RTL8187_LED */
^ permalink raw reply
* [PATCH] wireless: wl12xx, fix lock imbalance
From: Jiri Slaby @ 2009-07-13 21:24 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-kernel, Jiri Slaby
Add omitted mutex_unlock to one of wl12xx_op_start fail paths (when
wl12xx_chip_wakeup fails).
Not sure if the device should be powered off?
Signed-off-by: Jiri Slaby <jirislaby@gmail.com>
---
drivers/net/wireless/wl12xx/main.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 603d611..d241e4a 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -336,7 +336,7 @@ static int wl12xx_op_start(struct ieee80211_hw *hw)
ret = wl12xx_chip_wakeup(wl);
if (ret < 0)
- return ret;
+ goto unlock;
ret = wl->chip.op_boot(wl);
if (ret < 0)
@@ -357,7 +357,7 @@ static int wl12xx_op_start(struct ieee80211_hw *hw)
out:
if (ret < 0)
wl12xx_power_off(wl);
-
+unlock:
mutex_unlock(&wl->mutex);
return ret;
--
1.6.3.2
^ permalink raw reply related
* Re: [ipw3945-devel] iwlwifi 4965 uCode available
From: reinette chatre @ 2009-07-13 21:42 UTC (permalink / raw)
To: John Ranson
Cc: Helmut Schaa, linux-wireless@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net
In-Reply-To: <bcd1ba70907131252x3d9e21bbx80241aba1edff5ba@mail.gmail.com>
Hi John,
On Mon, 2009-07-13 at 12:52 -0700, John Ranson wrote:
> Reinette,
>
> On Mon, Jul 13, 2009 at 11:56 AM, reinette
> chatre<reinette.chatre@intel.com> wrote:
> > John,
> >
> > On Mon, 2009-07-13 at 11:43 -0700, John Ranson wrote:
> >> I am also seeing frequent loss of association and firmware restarts
> >> with the new firmware. On occasion, I can't recover even when I
> >> reload the driver. Admittedly, I am using an old driver right now
> >> (2.6.29, I think).
> >
> > The better restart work was added in 2.6.31 I think, so it is only in
> > the recent driver that you will have a smooth recovery after a failure.
> > You may thus be seeing the same problem as Helmut, with him running the
> > recent restart code.
>
> Can I also get this with the latest compat wireless release and
> 2.6.30.1? I don't usually switch to a new kernel until it's been
> stable for a while.
yes - compat wireless contains all the latest code, which includes this
restart work.
>
> >
> >>
> >> I'm going to upgrade to 2.6.30.1 with the latest compat-wireless. I'll
> >> file a bug if things continue as they are.
> >
> > Even if the restart code gets you up and running smoothly after a
> > failure, please do submit a bug report so that we can look into this.
>
> I'll be sure to file a bug.
Thank you very much
Reinette
^ permalink raw reply
* p54pci: problems during initialization
From: Fabio Rossi @ 2009-07-11 18:06 UTC (permalink / raw)
To: linux-wireless
I have a PCMCIA card (3com 3CRWE154G72 v2) which has problems during the
device initialization phase. I'm using the current wireless.git and the
firmware included with the working Windows driver (extracted by fwextract).
Sometimes I'm able to get the card working but most of times it doesn't
complete the initialization. When it works dmesg reports:
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:03:00.0: reg 10 32bit mmio: [0x000000-0x001fff]
pci 0000:03:00.0: supports D1 D2
pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:03:00.0: PME# disabled
p54pci 0000:03:00.0: enabling device (0000 -> 0002)
p54pci 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
p54pci 0000:03:00.0: setting latency timer to 64
p54pci 0000:03:00.0: firmware: requesting isl3886pci
phy11: p54 detected a LM86 firmware
phy11: FW rev 2.5.2.0 - Softmac protocol 3.0
phy11: you are using an obsolete firmware. visit
http://wireless.kernel.org/en/users/Drivers/p54 and grab one for "kernel >=
2.6.28"!
phy11: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:no
phy11: hwaddr 00:0e:6a:xx:xx:xx, MAC:isl3890 RF:Frisbee
phy11: Selected rate control algorithm 'minstrel'
Registered led device: p54-phy11::assoc
Registered led device: p54-phy11::tx
Registered led device: p54-phy11::rx
Registered led device: p54-phy11::radio
p54pci 0000:03:00.0: is registered as 'phy11'
When it doesn't work I read:
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pci 0000:03:00.0: reg 10 32bit mmio: [0x000000-0x001fff]
pci 0000:03:00.0: supports D1 D2
pci 0000:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0000:03:00.0: PME# disabled
p54pci 0000:03:00.0: enabling device (0000 -> 0002)
p54pci 0000:03:00.0: PCI INT A -> Link[LNKD] -> GSI 11 (level, low) -> IRQ 11
p54pci 0000:03:00.0: setting latency timer to 64
p54pci 0000:03:00.0: firmware: requesting isl3886pci
phy10: p54 detected a LM86 firmware
phy10: FW rev 2.5.2.0 - Softmac protocol 3.0
phy10: you are using an obsolete firmware. visit
http://wireless.kernel.org/en/users/Drivers/p54 and grab one for "kernel >=
2.6.28"!
phy10: cryptographic accelerator WEP:YES, TKIP:YES, CCMP:no
phy10: device does not respond!
p54pci 0000:03:00.0: PCI INT A disabled
p54pci: probe of 0000:03:00.0 failed with error -16
pcmcia_socket pcmcia_socket0: pccard: card ejected from slot 0
It seems there is a problem inside the function p54_read_eeprom().
I have also tried with other firmwares available here
http://daemonizer.de/prism54/prism54-fw/
with the following results:
2.3.2.0.arm - same behaviour
2.4.2.0.arm - same behaviour
2.4.6.0.arm - same behaviour
2.4.8.0.arm - same behaviour
2.4.11.0.arm - same behaviour
2.4.12.0.arm - same behaviour
2.5.2.0.arm - same behaviour
2.5.3.0.arm - same behaviour
2.5.6.0.arm - same behaviour
2.7.0.0.arm - same behaviour
2.12.0.0.arm - same behaviour
2.13.1.0.arm - same behaviour
2.13.8.0.arm - cannot boot firmware, probe error -110
2.13.12.0.arm - cannot boot firmware, probe error -110
2.17.2.0.arm - cannot boot firmware, probe error -110
Any clue?
Fabio
^ permalink raw reply
* [PATCH] imwc3200: move iwmc3200 SDIO ids to sdio_ids.h
From: Tomas Winkler @ 2009-07-13 22:09 UTC (permalink / raw)
To: drzeus-list, netdev, linux-wireless, linux-kernel; +Cc: Tomas Winkler
1. add intel's sdio vendor id to sdio_ids.h
2. move iwmc3200 sdio devices ids to sdio_ids.h
This patch is against 2.6.31-rc2
7638d5322bd89d49e013a03fe2afaeb6d214fabd
Cc:inaky.perez-gonzalez@intel.com
Cc:cindy.h.kao@intel.com
Cc:samuel.ortiz@intel.com
Cc:yi.zhu@intel.com
Cc:drzeus-list@drzeus.cx
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
---
drivers/net/wimax/i2400m/sdio.c | 10 ++++------
drivers/net/wireless/iwmc3200wifi/sdio.c | 4 +++-
drivers/net/wireless/iwmc3200wifi/sdio.h | 3 ---
include/linux/mmc/sdio_ids.h | 5 +++++
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wimax/i2400m/sdio.c b/drivers/net/wimax/i2400m/sdio.c
index 2538825..3dc1990 100644
--- a/drivers/net/wimax/i2400m/sdio.c
+++ b/drivers/net/wimax/i2400m/sdio.c
@@ -58,6 +58,7 @@
*/
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
#include "i2400m-sdio.h"
@@ -501,14 +502,11 @@ void i2400ms_remove(struct sdio_func *func)
d_fnend(3, dev, "SDIO func %p\n", func);
}
-enum {
- I2400MS_INTEL_VID = 0x89,
-};
-
static
const struct sdio_device_id i2400ms_sdio_ids[] = {
- /* Intel: i2400m WiMAX over SDIO */
- { SDIO_DEVICE(I2400MS_INTEL_VID, 0x1402) },
+ /* Intel: i2400m WiMAX (iwm3200) over SDIO */
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX) },
{ }, /* end: all zeroes */
};
MODULE_DEVICE_TABLE(sdio, i2400ms_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.c b/drivers/net/wireless/iwmc3200wifi/sdio.c
index 9166818..995a3f6 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.c
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.c
@@ -65,6 +65,7 @@
#include <linux/kernel.h>
#include <linux/netdevice.h>
#include <linux/debugfs.h>
+#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio.h>
#include <linux/mmc/sdio_func.h>
@@ -492,7 +493,8 @@ static void iwm_sdio_remove(struct sdio_func *func)
}
static const struct sdio_device_id iwm_sdio_ids[] = {
- { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL, SDIO_DEVICE_ID_IWM) },
+ { SDIO_DEVICE(SDIO_VENDOR_ID_INTEL,
+ SDIO_DEVICE_ID_INTEL_IWMC3200WIFI) },
{ /* end: all zeroes */ },
};
MODULE_DEVICE_TABLE(sdio, iwm_sdio_ids);
diff --git a/drivers/net/wireless/iwmc3200wifi/sdio.h b/drivers/net/wireless/iwmc3200wifi/sdio.h
index b3c156b..aab6b68 100644
--- a/drivers/net/wireless/iwmc3200wifi/sdio.h
+++ b/drivers/net/wireless/iwmc3200wifi/sdio.h
@@ -39,9 +39,6 @@
#ifndef __IWM_SDIO_H__
#define __IWM_SDIO_H__
-#define SDIO_VENDOR_ID_INTEL 0x89
-#define SDIO_DEVICE_ID_IWM 0x1403
-
#define IWM_SDIO_DATA_ADDR 0x0
#define IWM_SDIO_INTR_ENABLE_ADDR 0x14
#define IWM_SDIO_INTR_STATUS_ADDR 0x13
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index 39751c8..b46a57a 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -22,6 +22,11 @@
/*
* Vendors and devices. Sort key: vendor first, device next.
*/
+#define SDIO_VENDOR_ID_INTEL 0x0089
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIMAX 0x1402
+#define SDIO_DEVICE_ID_INTEL_IWMC3200WIFI 0x1403
+#define SDIO_DEVICE_ID_INTEL_IWMC3200TOP 0x1404
+#define SDIO_DEVICE_ID_INTEL_IWMC3200BT 0x1406
#define SDIO_VENDOR_ID_MARVELL 0x02df
#define SDIO_DEVICE_ID_MARVELL_LIBERTAS 0x9103
--
1.6.0.6
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
^ permalink raw reply related
* [PATCH] zd1211rw: adding Accton Technology Corp (083a:e501) as a ZD1211B device
From: Hin-Tak Leung @ 2009-07-13 22:20 UTC (permalink / raw)
To: linux-wireless, linville; +Cc: Hin-Tak Leung, Hin-Tak Leung
New device supported by the zd1211rw driver reported to linux-wireless.
Device string from lsusb:
"ID 083a:e501 Accton Technology Corp. ZD1211B"
RF type from dmesg:
zd1211b chip 083a:e501 v4810 high 00-1a-2a AL2230_RF pa0 g--NS
Signed-off-by: Hin-Tak Leung <htl10@users.sourceforge.net>
Tested-by: Adrián Cereto<ssorgatem@esdebian.org>
---
drivers/net/wireless/zd1211rw/zd_usb.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/net/wireless/zd1211rw/zd_usb.c b/drivers/net/wireless/zd1211rw/zd_usb.c
index dc34791..c1912f8 100644
--- a/drivers/net/wireless/zd1211rw/zd_usb.c
+++ b/drivers/net/wireless/zd1211rw/zd_usb.c
@@ -75,6 +75,7 @@ static struct usb_device_id usb_ids[] = {
{ USB_DEVICE(0x07b8, 0x6001), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x07fa, 0x1196), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x083a, 0x4505), .driver_info = DEVICE_ZD1211B },
+ { USB_DEVICE(0x083a, 0xe501), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x083a, 0xe503), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x083a, 0xe506), .driver_info = DEVICE_ZD1211B },
{ USB_DEVICE(0x0ace, 0x1215), .driver_info = DEVICE_ZD1211B },
--
1.6.2.5
^ permalink raw reply related
* [PATCH 0/3] wireless network namespace work
From: Johannes Berg @ 2009-07-13 22:33 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
Hi,
This series implements most of the net namespace awareness
for wireless (well, those bits that davem doesn't already
have).
This depends on the following commits from net-next-2.6:
commit 30ffee8480c13fbcf8ab6c28e31f79dfff683117
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Fri Jul 10 09:51:35 2009 +0000
net: move and export get_net_ns_by_pid
commit 134e63756d5f3d0f7604dfcca847b09d1b14fd66
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Fri Jul 10 09:51:34 2009 +0000
genetlink: make netns aware
commit 11a28d373ed2539a110d56419457e2e7db221ac7
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Fri Jul 10 09:51:33 2009 +0000
net: make namespace iteration possible under RCU
commit 6c04bb18ddd633b7feac2c8fe2ae0bf61d20ca7a
Author: Johannes Berg <johannes@sipsolutions.net>
Date: Fri Jul 10 09:51:32 2009 +0000
netlink: use call_rcu for netlink_change_ngroups
(well, it only depends on the first and second, but the second
in turn depends on the other two)
Not sure -- can you cherry-pick these and things just work?
johannes
^ permalink raw reply
* [PATCH 1/3] mac80211: cooperate more with network namespaces
From: Johannes Berg @ 2009-07-13 22:33 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <20090713223333.042733013@sipsolutions.net>
There are still two places in mac80211 that hardcode
the initial net namespace (init_net). One of them is
mandated by cfg80211 and will be removed by a separate
patch, the other one is used for finding the network
device of a pending packet via its ifindex.
Remove the latter use by keeping track of the device
pointer itself, via the vif pointer, and avoid it
going stale by dropping pending frames for a given
interface when the interface is removed.
To keep track of the vif pointer for the correct
interface, change the info->control.vif pointer's
internal use to always be the correct vif, and only
move it to the vif the driver expects (or NULL for
monitor interfaces and injected packets) right before
giving the packet to the driver.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
net/mac80211/iface.c | 16 ++++++++++
net/mac80211/rx.c | 2 -
net/mac80211/tx.c | 75 ++++++++++++++++++++-------------------------------
3 files changed, 46 insertions(+), 47 deletions(-)
--- wireless-testing.orig/net/mac80211/iface.c 2009-07-14 00:29:58.000000000 +0200
+++ wireless-testing/net/mac80211/iface.c 2009-07-14 00:30:05.000000000 +0200
@@ -335,7 +335,10 @@ static int ieee80211_stop(struct net_dev
struct ieee80211_local *local = sdata->local;
struct ieee80211_if_init_conf conf;
struct sta_info *sta;
+ unsigned long flags;
+ struct sk_buff *skb, *tmp;
u32 hw_reconf_flags = 0;
+ int i;
/*
* Stop TX on this interface first.
@@ -551,6 +554,18 @@ static int ieee80211_stop(struct net_dev
if (hw_reconf_flags)
ieee80211_hw_config(local, hw_reconf_flags);
+ spin_lock_irqsave(&local->queue_stop_reason_lock, flags);
+ for (i = 0; i < IEEE80211_MAX_QUEUES; i++) {
+ skb_queue_walk_safe(&local->pending[i], skb, tmp) {
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ if (info->control.vif == &sdata->vif) {
+ __skb_unlink(skb, &local->pending[i]);
+ dev_kfree_skb_irq(skb);
+ }
+ }
+ }
+ spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags);
+
return 0;
}
@@ -788,7 +803,6 @@ int ieee80211_if_add(struct ieee80211_lo
memcpy(ndev->dev_addr, local->hw.wiphy->perm_addr, ETH_ALEN);
SET_NETDEV_DEV(ndev, wiphy_dev(local->hw.wiphy));
- ndev->features |= NETIF_F_NETNS_LOCAL;
/* don't use IEEE80211_DEV_TO_SUB_IF because it checks too much */
sdata = netdev_priv(ndev);
--- wireless-testing.orig/net/mac80211/tx.c 2009-07-14 00:29:55.000000000 +0200
+++ wireless-testing/net/mac80211/tx.c 2009-07-14 00:30:05.000000000 +0200
@@ -400,6 +400,7 @@ ieee80211_tx_h_unicast_ps_buf(struct iee
sta_info_set_tim_bit(sta);
info->control.jiffies = jiffies;
+ info->control.vif = &tx->sdata->vif;
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
skb_queue_tail(&sta->ps_tx_buf, tx->skb);
return TX_QUEUED;
@@ -676,7 +677,7 @@ ieee80211_tx_h_sequence(struct ieee80211
* number, if we have no matching interface then we
* neither assign one ourselves nor ask the driver to.
*/
- if (unlikely(!info->control.vif))
+ if (unlikely(info->control.vif->type == NL80211_IFTYPE_MONITOR))
return TX_CONTINUE;
if (unlikely(ieee80211_is_ctl(hdr->frame_control)))
@@ -1071,6 +1072,7 @@ ieee80211_tx_prepare(struct ieee80211_su
} else if (*state != HT_AGG_STATE_IDLE) {
/* in progress */
queued = true;
+ info->control.vif = &sdata->vif;
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
__skb_queue_tail(&tid_tx->pending, skb);
}
@@ -1122,6 +1124,7 @@ static int __ieee80211_tx(struct ieee802
{
struct sk_buff *skb = *skbp, *next;
struct ieee80211_tx_info *info;
+ struct ieee80211_sub_if_data *sdata;
unsigned long flags;
int ret, len;
bool fragm = false;
@@ -1146,7 +1149,24 @@ static int __ieee80211_tx(struct ieee802
next = skb->next;
len = skb->len;
+
+ sdata = vif_to_sdata(info->control.vif);
+
+ switch (sdata->vif.type) {
+ case NL80211_IFTYPE_MONITOR:
+ info->control.vif = NULL;
+ break;
+ case NL80211_IFTYPE_AP_VLAN:
+ info->control.vif = &container_of(sdata->bss,
+ struct ieee80211_sub_if_data, u.ap)->vif;
+ break;
+ default:
+ /* keep */
+ break;
+ }
+
ret = drv_tx(local, skb);
+ info->control.vif = &sdata->vif;
if (WARN_ON(ret != NETDEV_TX_OK && skb->len != len)) {
dev_kfree_skb(skb);
ret = NETDEV_TX_OK;
@@ -1365,11 +1385,6 @@ static void ieee80211_xmit(struct ieee80
struct ieee80211_sub_if_data *tmp_sdata;
int headroom;
bool may_encrypt;
- enum {
- NOT_MONITOR,
- FOUND_SDATA,
- UNKNOWN_ADDRESS,
- } monitor_iface = NOT_MONITOR;
dev_hold(sdata->dev);
@@ -1403,7 +1418,6 @@ static void ieee80211_xmit(struct ieee80
u16 len_rthdr;
info->flags |= IEEE80211_TX_CTL_INJECTED;
- monitor_iface = UNKNOWN_ADDRESS;
len_rthdr = ieee80211_get_radiotap_len(skb->data);
hdr = (struct ieee80211_hdr *)skb->data + len_rthdr;
@@ -1433,7 +1447,6 @@ static void ieee80211_xmit(struct ieee80
dev_hold(tmp_sdata->dev);
dev_put(sdata->dev);
sdata = tmp_sdata;
- monitor_iface = FOUND_SDATA;
break;
}
}
@@ -1455,13 +1468,7 @@ static void ieee80211_xmit(struct ieee80
return;
}
- tmp_sdata = sdata;
- if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
- tmp_sdata = container_of(sdata->bss,
- struct ieee80211_sub_if_data,
- u.ap);
- if (likely(monitor_iface != UNKNOWN_ADDRESS))
- info->control.vif = &tmp_sdata->vif;
+ info->control.vif = &sdata->vif;
ieee80211_select_queue(local, skb);
ieee80211_tx(sdata, skb, false);
@@ -1513,9 +1520,6 @@ int ieee80211_monitor_start_xmit(struct
if (unlikely(skb->len < len_rthdr))
goto fail; /* skb too short for claimed rt header extent */
- /* needed because we set skb device to master */
- skb->iif = dev->ifindex;
-
/*
* fix up the pointers accounting for the radiotap
* header still being in there. We are being given
@@ -1789,8 +1793,6 @@ int ieee80211_subif_start_xmit(struct sk
nh_pos += hdrlen;
h_pos += hdrlen;
- skb->iif = dev->ifindex;
-
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
@@ -1835,32 +1837,13 @@ static bool ieee80211_tx_pending_skb(str
struct ieee80211_sub_if_data *sdata;
struct sta_info *sta;
struct ieee80211_hdr *hdr;
- struct net_device *dev;
int ret;
bool result = true;
- /* does interface still exist? */
- dev = dev_get_by_index(&init_net, skb->iif);
- if (!dev) {
- dev_kfree_skb(skb);
- return true;
- }
-
- sdata = IEEE80211_DEV_TO_SUB_IF(dev);
- if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN)
- sdata = container_of(sdata->bss,
- struct ieee80211_sub_if_data,
- u.ap);
-
- if (unlikely(info->control.vif && info->control.vif != &sdata->vif)) {
- dev_kfree_skb(skb);
- result = true;
- goto out;
- }
+ sdata = vif_to_sdata(info->control.vif);
if (info->flags & IEEE80211_TX_INTFL_NEED_TXPROCESSING) {
- /* do not use sdata, it may have been changed above */
- ieee80211_tx(IEEE80211_DEV_TO_SUB_IF(dev), skb, true);
+ ieee80211_tx(sdata, skb, true);
} else {
hdr = (struct ieee80211_hdr *)skb->data;
sta = sta_info_get(local, hdr->addr1);
@@ -1870,9 +1853,6 @@ static bool ieee80211_tx_pending_skb(str
result = false;
}
- out:
- dev_put(dev);
-
return result;
}
@@ -1900,10 +1880,16 @@ void ieee80211_tx_pending(unsigned long
while (!skb_queue_empty(&local->pending[i])) {
struct sk_buff *skb = __skb_dequeue(&local->pending[i]);
+ struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+ struct ieee80211_sub_if_data *sdata;
+
+ sdata = vif_to_sdata(info->control.vif);
+ dev_hold(sdata->dev);
spin_unlock_irqrestore(&local->queue_stop_reason_lock,
flags);
txok = ieee80211_tx_pending_skb(local, skb);
+ dev_put(sdata->dev);
if (!txok)
__skb_queue_head(&local->pending[i], skb);
spin_lock_irqsave(&local->queue_stop_reason_lock,
@@ -2211,7 +2197,6 @@ void ieee80211_tx_skb(struct ieee80211_s
skb_set_network_header(skb, 0);
skb_set_transport_header(skb, 0);
- skb->iif = sdata->dev->ifindex;
if (!encrypt)
info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT;
--- wireless-testing.orig/net/mac80211/rx.c 2009-07-14 00:29:56.000000000 +0200
+++ wireless-testing/net/mac80211/rx.c 2009-07-14 00:30:05.000000000 +0200
@@ -1539,7 +1539,7 @@ ieee80211_rx_h_mesh_fwding(struct ieee80
info = IEEE80211_SKB_CB(fwd_skb);
memset(info, 0, sizeof(*info));
info->flags |= IEEE80211_TX_INTFL_NEED_TXPROCESSING;
- fwd_skb->iif = rx->dev->ifindex;
+ info->control.vif = &rx->sdata->vif;
ieee80211_select_queue(local, fwd_skb);
if (is_multicast_ether_addr(fwd_hdr->addr3))
memcpy(fwd_hdr->addr1, fwd_hdr->addr3,
--
^ 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