* [RFC 3/4] mac80211: support for IEEE80211N in IBSS
From: Alexander Simon @ 2011-01-20 9:26 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1295447708.4685.5.camel@jlt3.sipsolutions.net>
Parse a new stations HT IE.
ieee80211_ibss_add_sta is called with a new argument, ht capabilities of that
new station.
Luckily there was that function ieee80211_ht_cap_ie_to_sta_ht_cap that is
called. This inserts these HT capabilities into the sta_info struct that is eg
used by the rate algorithm.
As mentioned before, this parameter will be NULL when called from rx.c (main
receive path).
diff -Nrup compat-wireless-2011-01-17.2/net/mac80211/ibss.c
compat-wireless-2011-01-17.3//net/mac80211/ibss.c
--- compat-wireless-2011-01-17.2/net/mac80211/ibss.c 2011-01-20
10:02:16.000000000 +0100
+++ compat-wireless-2011-01-17.3//net/mac80211/ibss.c 2011-01-20
10:03:11.000000000 +0100
@@ -391,7 +391,7 @@ static void ieee80211_rx_bss_info(struct
}
} else
sta = ieee80211_ibss_add_sta(sdata, mgmt->bssid,
- mgmt->sa, supp_rates,
+ mgmt->sa, supp_rates, elems->ht_cap_elem,
GFP_ATOMIC);
}
@@ -490,7 +490,7 @@ static void ieee80211_rx_bss_info(struct
ieee80211_sta_join_ibss(sdata, bss);
supp_rates = ieee80211_sta_get_rates(local, elems, band);
ieee80211_ibss_add_sta(sdata, mgmt->bssid, mgmt->sa,
- supp_rates, GFP_KERNEL);
+ supp_rates, elems->ht_cap_elem, GFP_KERNEL);
}
put_bss:
@@ -503,8 +503,8 @@ static void ieee80211_rx_bss_info(struct
* must be callable in atomic context.
*/
struct sta_info *ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
- u8 *bssid,u8 *addr, u32 supp_rates,
- gfp_t gfp)
+ u8 *bssid, u8 *addr, u32 supp_rates,
+ struct ieee80211_ht_cap *ht_cap, gfp_t gfp)
{
struct ieee80211_if_ibss *ifibss = &sdata->u.ibss;
struct ieee80211_local *local = sdata->local;
@@ -544,6 +544,10 @@ struct sta_info *ieee80211_ibss_add_sta(
sta->sta.supp_rates[band] = supp_rates |
ieee80211_mandatory_rates(local, band);
+ if (ht_cap)
+ ieee80211_ht_cap_ie_to_sta_ht_cap(local->hw.wiphy->bands[band],
+ ht_cap, &sta->sta.ht_cap);
+
rate_control_rate_init(sta);
/* If it fails, maybe we raced another insertion? */
diff -Nrup compat-wireless-2011-01-17.2/net/mac80211/ieee80211_i.h
compat-wireless-2011-01-17.3//net/mac80211/ieee80211_i.h
--- compat-wireless-2011-01-17.2/net/mac80211/ieee80211_i.h 2011-01-20
10:01:56.000000000 +0100
+++ compat-wireless-2011-01-17.3//net/mac80211/ieee80211_i.h 2011-01-20
10:03:11.000000000 +0100
@@ -1111,7 +1111,7 @@ void ieee80211_ibss_notify_scan_complete
void ieee80211_ibss_setup_sdata(struct ieee80211_sub_if_data *sdata);
struct sta_info *ieee80211_ibss_add_sta(struct ieee80211_sub_if_data *sdata,
u8 *bssid, u8 *addr, u32 supp_rates,
- gfp_t gfp);
+ struct ieee80211_ht_cap *ht_cap, gfp_t gfp);
int ieee80211_ibss_join(struct ieee80211_sub_if_data *sdata,
struct cfg80211_ibss_params *params);
int ieee80211_ibss_leave(struct ieee80211_sub_if_data *sdata);
diff -Nrup compat-wireless-2011-01-17.2/net/mac80211/rx.c
compat-wireless-2011-01-17.3//net/mac80211/rx.c
--- compat-wireless-2011-01-17.2/net/mac80211/rx.c 2011-01-17 21:03:26.000000000
+0100
+++ compat-wireless-2011-01-17.3//net/mac80211/rx.c 2011-01-20
10:03:11.000000000 +0100
@@ -2618,7 +2618,7 @@ static int prepare_for_handlers(struct i
else
rate_idx = status->rate_idx;
rx->sta = ieee80211_ibss_add_sta(sdata, bssid,
- hdr->addr2, BIT(rate_idx), GFP_ATOMIC);
+ hdr->addr2, BIT(rate_idx), NULL, GFP_ATOMIC);
}
break;
case NL80211_IFTYPE_MESH_POINT:
^ permalink raw reply
* [RFC 4/4] mac80211: support for IEEE80211N in IBSS
From: Alexander Simon @ 2011-01-20 9:37 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1295447708.4685.5.camel@jlt3.sipsolutions.net>
This adds some ifs to let the packet aggregation also
work while being in IBSS mode.
diff -Nrup compat-wireless-2011-01-17.1/net/mac80211/agg-rx.c
compat-wireless-2011-01-17/net/mac80211/agg-rx.c
--- compat-wireless-2011-01-17.1/net/mac80211/agg-rx.c 2011-01-17
21:03:25.000000000 +0100
+++ compat-wireless-2011-01-17/net/mac80211/agg-rx.c 2011-01-19
17:40:36.000000000 +0100
@@ -160,6 +160,8 @@ static void ieee80211_send_addba_resp(st
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+ else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
diff -Nrup compat-wireless-2011-01-17.1/net/mac80211/agg-tx.c
compat-wireless-2011-01-17/net/mac80211/agg-tx.c
--- compat-wireless-2011-01-17.1/net/mac80211/agg-tx.c 2011-01-17
21:03:25.000000000 +0100
+++ compat-wireless-2011-01-17/net/mac80211/agg-tx.c 2011-01-19
17:40:36.000000000 +0100
@@ -83,6 +83,8 @@ static void ieee80211_send_addba_request
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+ else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
@@ -376,7 +378,8 @@ int ieee80211_start_tx_ba_session(struct
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
- sdata->vif.type != NL80211_IFTYPE_AP)
+ sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_ADHOC)
return -EINVAL;
if (test_sta_flags(sta, WLAN_STA_BLOCK_BA)) {
diff -Nrup compat-wireless-2011-01-17.1/net/mac80211/ht.c
compat-wireless-2011-01-17/net/mac80211/ht.c
--- compat-wireless-2011-01-17.1/net/mac80211/ht.c
2011-01-17 21:03:25.000000000
+0100
+++ compat-wireless-2011-01-17/net/mac80211/ht.c
2011-01-19 17:40:36.000000000 +0100
@@ -179,6 +179,8 @@ void ieee80211_send_delba(struct ieee802
memcpy(mgmt->bssid, sdata->vif.addr, ETH_ALEN);
else if (sdata->vif.type == NL80211_IFTYPE_STATION)
memcpy(mgmt->bssid, sdata->u.mgd.bssid, ETH_ALEN);
+ else if (sdata->vif.type == NL80211_IFTYPE_ADHOC)
+ memcpy(mgmt->bssid, sdata->u.ibss.bssid, ETH_ALEN);
mgmt->frame_control = cpu_to_le16(IEEE80211_FTYPE_MGMT |
IEEE80211_STYPE_ACTION);
diff -Nrup compat-wireless-2011-01-17.1/net/mac80211/rx.c
compat-wireless-2011-01-17/net/mac80211/rx.c
--- compat-wireless-2011-01-17.1/net/mac80211/rx.c
2011-01-17 21:03:26.000000000
+0100
+++ compat-wireless-2011-01-17/net/mac80211/rx.c
2011-01-19 17:40:36.000000000 +0100
@@ -2063,7 +2063,8 @@ ieee80211_rx_h_action(struct ieee80211_r
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
- sdata->vif.type != NL80211_IFTYPE_AP)
+ sdata->vif.type != NL80211_IFTYPE_AP &&
+ sdata->vif.type != NL80211_IFTYPE_ADHOC)
break;
/* verify action_code is present */
^ permalink raw reply
* Re: [RFC 1/4] mac80211: support for IEEE80211N in IBSS
From: Alexander Simon @ 2011-01-20 9:48 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1295515469.3693.17.camel@jlt3.sipsolutions.net>
Johannes Berg <johannes@...> writes:
>
> On Thu, 2011-01-20 at 09:10 +0000, Alexander Simon wrote:
>
> > What do you mean with a "not so refactoring version"? I am adding a new IE.
> > These are only insertions, no other changes. Or do you mean that
dev_alloc_skb?
> > However, i took the last "try" from Benoit.
>
> Well, then maybe I just discussed this with him -- there's similar code
> building the HT IEs for stations, that code should be shared.
So you mean my patch 2/4? It could work but you would have to change util.c of
course. I was pretty sure you wouldn't have accepted that.
> Yes all of that might be necessary, but can you post patches that do one
> thing at a time? Like at least one cfg80211/nl80211 patch that adds the
> configurability, and then a mac80211 patch that will use it.
>
> Also, I think cfg80211 should support advertising to userspace that it's
> supported.
>
> Yes, I sometimes accept combined cfg80211/mac80211 patches, but I think
> this feature is bigger than that.
Ok, separating cfg from mac. No big deal. I'll have to look how to advertise
something...
But i would appreciate if you could comment on the design of the patch itself.
Basically i just took Benoits approach and made it running. A separate option
for setting channel_type isn't necessary. You could also tell by iw whether to
use HT or not. Or no option at all, a module option ibss_ht etc. Or even setting
full options as hostapd does via iw.
Thanks, Alex
^ permalink raw reply
* Re: [RFC 4/4] mac80211: support for IEEE80211N in IBSS
From: Johannes Berg @ 2011-01-20 9:49 UTC (permalink / raw)
To: Alexander Simon; +Cc: linux-wireless
In-Reply-To: <loom.20110120T102902-813@post.gmane.org>
On Thu, 2011-01-20 at 09:37 +0000, Alexander Simon wrote:
> This adds some ifs to let the packet aggregation also
> work while being in IBSS mode.
>
Ok this one's a pretty well-split up patch, but
* the subject should be more specific, like
"mac80211: allow aggregation in IBSS mode"
* the description should be more results-oriented,
for example: "Allow aggregation sessions to be
started in IBSS mode." The stuff about "add ifs"
really isn't necessary we can all look at the code :-)
* you missed Signed-off-by
* your patch was line-wrapped, so it can't be applied
As for the other three patches, I don't think they were split up well --
the first one should be cfg80211 specific, and 2/3 should probably be
just one patch? Also for patches 1-3 the line wrapping in the commit log
was very awkward, try to stay < 72 characters per line.
However, if you combine 2 and 3, I still think you need a preliminary
patch to do the refactoring between the code that builds the HT IEs for
IBSS and ieee80211_add_ht_ie(). In fact, I notice there's similar code
in ieee80211_build_preq_ies() so a really good refactoring would take
code from both and replace it with a shared version that IBSS becomes
the third user of.
Have you seen
http://wireless.kernel.org/en/developers/Documentation/SubmittingPatches?
Thanks for your effort!
johannes
^ permalink raw reply
* Re: [RFC 1/4] mac80211: support for IEEE80211N in IBSS
From: Johannes Berg @ 2011-01-20 9:54 UTC (permalink / raw)
To: Alexander Simon; +Cc: linux-wireless
In-Reply-To: <loom.20110120T103741-140@post.gmane.org>
On Thu, 2011-01-20 at 09:48 +0000, Alexander Simon wrote:
> > Well, then maybe I just discussed this with him -- there's similar code
> > building the HT IEs for stations, that code should be shared.
> So you mean my patch 2/4? It could work but you would have to change util.c of
> course. I was pretty sure you wouldn't have accepted that.
Of course I'd accept that :-) Reducing duplicated code is good, and I
can deal with patches touching many files. Though it'd be nice to do the
necessary refactoring first.
A nice touch, btw, would be if you included a diffstat. Maybe you should
look at using quilt or git to submit patches which help you automate a
lot of things.
> Ok, separating cfg from mac. No big deal. I'll have to look how to advertise
> something...
Look at WIPHY_FLAG_IBSS_RSN in net/wireless and net/mac80211 -- that's
how things can be advertised. Also, for this one of course you have
NL80211_ATTR_SUPPORT_IBSS_RSN.
> But i would appreciate if you could comment on the design of the patch itself.
> Basically i just took Benoits approach and made it running. A separate option
> for setting channel_type isn't necessary. You could also tell by iw whether to
> use HT or not. Or no option at all, a module option ibss_ht etc. Or even setting
> full options as hostapd does via iw.
I'm sorry, I don't understand what you mean by "a separate option"? With
the approach that you've posted patches for you need to tell iw whether
you want HT or not, right?
johannes
^ permalink raw reply
* Re: [RFC 1/4] mac80211: support for IEEE80211N in IBSS
From: Alexander Simon @ 2011-01-20 10:15 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1295517283.3693.31.camel@jlt3.sipsolutions.net>
> Of course I'd accept that Reducing duplicated code is good, and I
> can deal with patches touching many files. Though it'd be nice to do the
> necessary refactoring first.
Ok give me some time and I'll have a look at util.c.
>
> A nice touch, btw, would be if you included a diffstat. Maybe you should
> look at using quilt or git to submit patches which help you automate a
> lot of things.
Actually I don't like git, but when this is getting something bigger,I'll agree
to use it :)
> > But i would appreciate if you could comment on the design of the patch
itself.
> > Basically i just took Benoits approach and made it running. A separate
option
> > for setting channel_type isn't necessary. You could also tell by iw whether
to
> > use HT or not. Or no option at all, a module option ibss_ht etc. Or even
setting
> > full options as hostapd does via iw.
>
> I'm sorry, I don't understand what you mean by "a separate option"? With
> the approach that you've posted patches for you need to tell iw whether
> you want HT or not, right?
What i mean is, right now there's just one option - setting the HT channel.
There could be less (the card automatically enables HT and uses it for a station
that advertises HT), or even more (as in hostapd.confs HT section). Or there
could be a module option to switch ht for ibss on or off. So, i'm asking about
the "ideal" interface...
^ permalink raw reply
* Re: [RFC 1/4] mac80211: support for IEEE80211N in IBSS
From: Johannes Berg @ 2011-01-20 10:20 UTC (permalink / raw)
To: Alexander Simon; +Cc: linux-wireless
In-Reply-To: <loom.20110120T110320-779@post.gmane.org>
On Thu, 2011-01-20 at 10:15 +0000, Alexander Simon wrote:
> > Of course I'd accept that Reducing duplicated code is good, and I
> > can deal with patches touching many files. Though it'd be nice to do the
> > necessary refactoring first.
> Ok give me some time and I'll have a look at util.c.
Thanks.
> > A nice touch, btw, would be if you included a diffstat. Maybe you should
> > look at using quilt or git to submit patches which help you automate a
> > lot of things.
> Actually I don't like git, but when this is getting something bigger,I'll agree
> to use it :)
I personally rarely use it for the kernel (even if I know how to very
well), mostly because rebasing is slow for me ... quilt helps a lot too.
If you intend to submit more patches than this series I suggest you
learn at least one of them, it'll make your life easier :-)
> > I'm sorry, I don't understand what you mean by "a separate option"? With
> > the approach that you've posted patches for you need to tell iw whether
> > you want HT or not, right?
> What i mean is, right now there's just one option - setting the HT channel.
> There could be less (the card automatically enables HT and uses it for a station
> that advertises HT), or even more (as in hostapd.confs HT section). Or there
> could be a module option to switch ht for ibss on or off. So, i'm asking about
> the "ideal" interface...
Hmm, I guess you have a point there -- restricting it to HT40- doesn't
make much sense since then you can't merge with another IBSS that is
using HT40+. I guess just enable/disable HT makes more sense?
johannes
^ permalink raw reply
* Re: carl9170 802.11n-AP
From: Helge Lenz @ 2011-01-20 10:28 UTC (permalink / raw)
To: linux-wireless
Thomas <messier31@...> writes:
>
> Today I tried a different wifi card on the client side, instead of
the Intel
> 5100, but the problem remains the same. The carl9170 driver on my server
> crashes at some point randomly (only in 802.11n mode). The traceback
shows
> the error at tx.c but everytime in a different line. So I guess there
must
> be a race condition somewhere.
>
> Here you can find the error report of some crashes:
> http://www.mikrocontroller.net/attachment/95144/bugreport.txt
>
> Server hardware is a Seagate Dockstar with OpenWrt running on it. I
heard
> from another user with Debian, who has the same problem.
>
> Regards,
>
> Thomas
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-wireless" in
> the body of a message to majordomo@...
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
Any news about this issue? I have the same problem on a Seagate Goflex
Net running debian (Linux debian 2.6.35.4 #9 PREEMPT Tue Jan 18 13:03:42
UTC 2011 armv5tel GNU/Linux). The kernel and the wireless drivers
(compat-wireless-v2.6.37-4) are compiled natively on the box and when I
try to transmit some data I get the following errors in dmesg:
------------[ cut here ]------------
[ 1015.070483] WARNING: at
/usr/src/compat-wireless-2.6.37-4/drivers/net/wireless/ath/carl9170/tx.c:1239
carl9170_op_tx+0x628/0x858 [carl9170]()
[ 1015.083442] Modules linked in:
[ 1015.086361] usb 1-1.2: restart device (5)
[ 1015.090604] carl9170 mac80211 ath cfg80211 compat ipv6 hmac
sha1_generic sata_mv mv_cesa [last unloaded: compat]
[ 1015.101057] [<c003058c>] (unwind_backtrace+0x0/0xf0) from
[<c003d6c4>] (warn_slowpath_common+0x4c/0x64)
[ 1015.110504] [<c003d6c4>] (warn_slowpath_common+0x4c/0x64) from
[<c003d6f4>] (warn_slowpath_null+0x18/0x1c)
[ 1015.120248] [<c003d6f4>] (warn_slowpath_null+0x18/0x1c) from
[<bf1841c4>] (carl9170_op_tx+0x628/0x858 [carl9170])
[ 1015.130702] [<bf1841c4>] (carl9170_op_tx+0x628/0x858 [carl9170]) from
[<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211])
[ 1015.141928] [<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211]) from
[<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211])
[ 1015.152885] [<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211]) from
[<bf1549e0>] (ieee80211_tx_pending+0x138/0x2a8 [mac80211])
[ 1015.164325] [<bf1549e0>] (ieee80211_tx_pending+0x138/0x2a8
[mac80211]) from [<c00426d0>] (tasklet_action+0x84/0xe4)
[ 1015.174835] [<c00426d0>] (tasklet_action+0x84/0xe4) from [<c0042d14>]
(__do_softirq+0x8c/0x124)
[ 1015.183594] [<c0042d14>] (__do_softirq+0x8c/0x124) from [<c0042df4>]
(irq_exit+0x48/0xa0)
[ 1015.191832] [<c0042df4>] (irq_exit+0x48/0xa0) from [<c002b070>]
(asm_do_IRQ+0x70/0x8c)
[ 1015.199799] [<c002b070>] (asm_do_IRQ+0x70/0x8c) from [<c03b15a8>]
(__irq_svc+0x48/0xa8)
[ 1015.207855] Exception stack(0xc04d7f48 to 0xc04d7f90)
[ 1015.212943] 7f40: 000f1d68 000003e8 000f1d68
20000013 c04dd8d8 c04dd8d8
[ 1015.221175] 7f60: c05a6960 c04da330 00024068 56251311 00023f30
00000000 3b0add45 c04d7f90
[ 1015.229394] 7f80: c005cecc c0034608 20000013 ffffffff
[ 1015.234490] [<c03b15a8>] (__irq_svc+0x48/0xa8) from [<c0034608>]
(kirkwood_enter_idle+0x64/0x90)
[ 1015.243342] [<c0034608>] (kirkwood_enter_idle+0x64/0x90) from
[<c02de684>] (cpuidle_idle_call+0xb0/0x110)
[ 1015.252976] [<c02de684>] (cpuidle_idle_call+0xb0/0x110) from
[<c002c9e0>] (cpu_idle+0x60/0xb8)
[ 1015.261649] [<c002c9e0>] (cpu_idle+0x60/0xb8) from [<c0008988>]
(start_kernel+0x280/0x2e0)
[ 1015.269965] [<c0008988>] (start_kernel+0x280/0x2e0) from [<00008034>]
(0x8034)
[ 1015.277231] ---[ end trace 2ef0e9214ceebf4c ]---
[ 1515.714312] ------------[ cut here ]------------
[ 1515.719006] WARNING: at
/usr/src/compat-wireless-2.6.37-4/drivers/net/wireless/ath/carl9170/tx.c:300
carl9170_tx_status+0x230/0x3e4 [carl9170]()
[ 1515.732047] Modules linked in: carl9170 mac80211 ath cfg80211 compat
ipv6 hmac sha1_generic sata_mv mv_cesa [last unloaded: compat]
[ 1515.744065] [<c003058c>] (unwind_backtrace+0x0/0xf0) from
[<c003d6c4>] (warn_slowpath_common+0x4c/0x64)
[ 1515.753525] [<c003d6c4>] (warn_slowpath_common+0x4c/0x64) from
[<c003d6f4>] (warn_slowpath_null+0x18/0x1c)
[ 1515.763263] [<c003d6f4>] (warn_slowpath_null+0x18/0x1c) from
[<bf183388>] (carl9170_tx_status+0x230/0x3e4 [carl9170])
[ 1515.773980] [<bf183388>] (carl9170_tx_status+0x230/0x3e4 [carl9170])
from [<bf184320>] (carl9170_op_tx+0x784/0x858 [carl9170])
[ 1515.785557] [<bf184320>] (carl9170_op_tx+0x784/0x858 [carl9170]) from
[<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211])
[ 1515.797154] [<bf153b8c>] (__ieee80211_tx+0x14c/0x1c8 [mac80211]) from
[<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211])
[ 1515.808120] [<bf153cf4>] (ieee80211_tx+0xec/0x29c [mac80211]) from
[<bf15406c>] (ieee80211_xmit+0x1c8/0x1fc [mac80211])
[ 1515.819079] [<bf15406c>] (ieee80211_xmit+0x1c8/0x1fc [mac80211]) from
[<bf15538c>] (ieee80211_subif_start_xmit+0x804/0x83c [mac80211])
[ 1515.831306] [<bf15538c>] (ieee80211_subif_start_xmit+0x804/0x83c
[mac80211]) from [<c0315020>] (dev_hard_start_xmit+0x2a0/0x3ac)
[ 1515.842948] [<c0315020>] (dev_hard_start_xmit+0x2a0/0x3ac) from
[<c03273d8>] (sch_direct_xmit+0x80/0x204)
[ 1515.852580] [<c03273d8>] (sch_direct_xmit+0x80/0x204) from
[<c03155d0>] (dev_queue_xmit+0x368/0x5b0)
[ 1515.861785] [<c03155d0>] (dev_queue_xmit+0x368/0x5b0) from
[<c035ecf0>] (arp_process+0x32c/0x6f8)
[ 1515.870722] [<c035ecf0>] (arp_process+0x32c/0x6f8) from [<c0313fd0>]
(__netif_receive_skb+0x474/0x4cc)
[ 1515.880134] [<c0313fd0>] (__netif_receive_skb+0x474/0x4cc) from
[<bf14ef58>] (ieee80211_deliver_skb+0x130/0x168 [mac80211])
[ 1515.891445] [<bf14ef58>] (ieee80211_deliver_skb+0x130/0x168
[mac80211]) from [<bf150614>] (ieee80211_rx_handlers+0x1308/0x18b0
[mac80211])
[ 1515.904526] [<bf150614>] (ieee80211_rx_handlers+0x1308/0x18b0
[mac80211]) from [<bf1514c8>]
(ieee80211_prepare_and_rx_handle+0x90c/0x960 [mac80211])
[ 1515.918092] [<bf1514c8>] (ieee80211_prepare_and_rx_handle+0x90c/0x960
[mac80211]) from [<bf151d88>] (ieee80211_rx+0x86c/0x924 [mac80211])
[ 1515.930594] [<bf151d88>] (ieee80211_rx+0x86c/0x924 [mac80211]) from
[<bf185100>] (__carl9170_rx+0x808/0x860 [carl9170])
[ 1515.941482] [<bf185100>] (__carl9170_rx+0x808/0x860 [carl9170]) from
[<bf185328>] (carl9170_rx_stream+0x1d0/0x334 [carl9170])
[ 1515.952890] [<bf185328>] (carl9170_rx_stream+0x1d0/0x334 [carl9170])
from [<bf17d61c>] (carl9170_usb_tasklet+0x68/0xcc [carl9170])
[ 1515.964720] [<bf17d61c>] (carl9170_usb_tasklet+0x68/0xcc [carl9170])
from [<c00425f0>] (tasklet_hi_action+0x88/0xe4)
[ 1515.975565] [<c00425f0>] (tasklet_hi_action+0x88/0xe4) from
[<c0042d14>] (__do_softirq+0x8c/0x124)
[ 1515.984582] [<c0042d14>] (__do_softirq+0x8c/0x124) from [<c0042df4>]
(irq_exit+0x48/0xa0)
[ 1515.992821] [<c0042df4>] (irq_exit+0x48/0xa0) from [<c002b070>]
(asm_do_IRQ+0x70/0x8c)
[ 1516.000943] [<c002b070>] (asm_do_IRQ+0x70/0x8c) from [<c03b15a8>]
(__irq_svc+0x48/0xa8)
[ 1516.008990] Exception stack(0xc04d7f48 to 0xc04d7f90)
[ 1516.014083] 7f40: 0009c1d3 000003e8 0009c1d3
20000013 c04dd868 c04dd878
[ 1516.022312] 7f60: c05a6960 c04da330 00024068 56251311 00023f30
00000000 261d2322 c04d7f90
[ 1516.030531] 7f80: c005cecc c0034608 20000013 ffffffff
[ 1516.035628] [<c03b15a8>] (__irq_svc+0x48/0xa8) from [<c0034608>]
(kirkwood_enter_idle+0x64/0x90)
[ 1516.044480] [<c0034608>] (kirkwood_enter_idle+0x64/0x90) from
[<c02de684>] (cpuidle_idle_call+0xb0/0x110)
[ 1516.054112] [<c02de684>] (cpuidle_idle_call+0xb0/0x110) from
[<c002c9e0>] (cpu_idle+0x60/0xb8)
[ 1516.062786] [<c002c9e0>] (cpu_idle+0x60/0xb8) from [<c0008988>]
(start_kernel+0x280/0x2e0)
[ 1516.071111] [<c0008988>] (start_kernel+0x280/0x2e0) from [<00008034>]
(0x8034)
[ 1516.078367] ---[ end trace 2ef0e9214ceebf4d ]---
If I can do anything to debug the error any further I am more then
willing to help.
Thanks, Helge.
^ permalink raw reply
* Re: [RFT 0/8] Clean proto/ethernet.h and remove it.
From: Jonas Gorski @ 2011-01-20 11:12 UTC (permalink / raw)
To: Arend Van Spriel
Cc: linux-wireless@vger.kernel.org, devel@linuxdriverproject.org,
gregkh@suse.de, Brett Rudley, Henry Ptasinski, Dowan Kim,
Roland Vossen
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F05954D@SJEXCHCCR02.corp.ad.broadcom.com>
Hi Arend,
On 20/01/2011, Arend Van Spriel <arend@broadcom.com> wrote:
> The brcm80211 driver is currently a staging driver and as such maintained by
> GregKH
Oh, you are right. I only looked at the brcm80211 entry in
MAINTAINERS, which did no mention of both.
> (git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6.git). In
> the staging-next branch of that repository similar patches have already been
> posted. Maybe they are still in the queue.
The last commit I could found in staging-2.6.git was from December
16th, so I thought I was safe, but appearently I wasn't. (I also
didn't see that there was a separate ML for staging drivers). Thanks
for the head-up.
So please ignore this patch series ;-).
Regards,
Jonas Gorski
^ permalink raw reply
* Re: [PATCH] Kernel Panic on Associate with brcm80211.
From: zach @ 2011-01-20 11:21 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4D3521FD.9020001@mythicnet.org>
Ilya Kogan <ikogan@...> writes:
>
> I'm going to admit I'm fairly new to this but after some reading, I
> couldn't quite understand why there is an assertion ensuring that the
> sk_buff being sent is not cloned. I was going to see what exploded if I
> removed it and to my surprise...nothing did. In fact, except for a few
>
> [12014.013409] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
> 382/256 dur 3562/1504
>
> things seem to work fine. I'll be doing some more testing with this over
> the next couple of days. What obvious thing does this break horribly?
>
Hi, I think I had the same panic on emachines em350 with BCM4313 using Fedora 14
and kernel 2.6.38-rc1. Network manager applet shows little blue dots going round
and then panic. Applying your change solved it. Thanks!
Photo of panic
http://picasaweb.google.com/lh/photo/hWEO_uFGNO-jAKjqhyJvkLevz6n8KX8fvZ44UIlA3yw?feat=directlink
config http://pastebin.com/9z8AmJ3E
zach
^ permalink raw reply
* iwl4965: 11n broken
From: Helmut Schaa @ 2011-01-20 11:42 UTC (permalink / raw)
To: linux-wireless; +Cc: Wey-Yi Guy, Johannes Berg
Hi,
I've just updated my workstation to wireless-testing from last
week (2.6.37-wl-default+). When associating to a 11n router the
card only associates as 11g, the assoc request doesn't contain
any HT IEs.
The causing commit is:
commit 21a5b3c6b19a8b8972ccdd55389be28a8b7c9180
Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Wed Nov 10 13:32:59 2010 -0800
iwlagn: use SKU information in the EEPROM
EEPROM contain the SKU information for the device, use it.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Seems as if the device eeprom hasn't set EEPROM_SKU_CAP_11N_ENABLE and thus
iwlagn thinks the device is not 11n capable.
Ideas? Should we just revert the 4965 part of the patch and modify
iwl_eeprom_check_sku to allow overwriting the sku field? Do 4965 devices
exists that are not 11n capable?
Thanks,
Helmut
^ permalink raw reply
* RE: [PATCH] Kernel Panic on Associate with brcm80211.
From: Arend Van Spriel @ 2011-01-20 12:23 UTC (permalink / raw)
To: zach, linux-wireless@vger.kernel.org
In-Reply-To: <loom.20110120T120235-29@post.gmane.org>
Hi Zach, Ilya,
I posted an official patch (removing the assert) to the staging repository as I did run into this same issue. It will take some time before it is propagated. As this is a staging driver patches are to be sent to devel@linuxdriverproject.org (see http://driverdev.linuxdriverproject.org/pipermail/devel/).
Gr. AvS
________________________________________
From: linux-wireless-owner@vger.kernel.org [linux-wireless-owner@vger.kernel.org] On Behalf Of zach [conflatulence@gmail.com]
Sent: Thursday, January 20, 2011 12:21 PM
To: linux-wireless@vger.kernel.org
Subject: Re: [PATCH] Kernel Panic on Associate with brcm80211.
Ilya Kogan <ikogan@...> writes:
>
> I'm going to admit I'm fairly new to this but after some reading, I
> couldn't quite understand why there is an assertion ensuring that the
> sk_buff being sent is not cloned. I was going to see what exploded if I
> removed it and to my surprise...nothing did. In fact, except for a few
>
> [12014.013409] wl0: wlc_d11hdrs_mac80211: AC_BE txop exceeded phylen
> 382/256 dur 3562/1504
>
> things seem to work fine. I'll be doing some more testing with this over
> the next couple of days. What obvious thing does this break horribly?
>
Hi, I think I had the same panic on emachines em350 with BCM4313 using Fedora 14
and kernel 2.6.38-rc1. Network manager applet shows little blue dots going round
and then panic. Applying your change solved it. Thanks!
Photo of panic
http://picasaweb.google.com/lh/photo/hWEO_uFGNO-jAKjqhyJvkLevz6n8KX8fvZ44UIlA3yw?feat=directlink
config http://pastebin.com/9z8AmJ3E
zach
--
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: htc dream wl1251 and MSM_GPIO_TO_INT(29)
From: Denis 'GNUtoo' Carikli @ 2011-01-20 12:55 UTC (permalink / raw)
To: Bob Copeland; +Cc: Kalle Valo, Grazvydas Ignotas, linux-wireless
In-Reply-To: <20110117150853.GC20703@hash.localnet>
> > fail_irq:
> > printk("trout wifi GPIO failed\n");
> > gpio_free(TROUT_WIFI_IRQ_GPIO);
>
> But you always free a gpio here, shouldn't there be a return in there
> before the fail_irq label?
I forgot the return, I wrote/copied(from omap3-pandora ) the code when I
was tired,I shouldn't write code when I'm that tired.
> also make sure you still have the dummy msm_wifi platform device too,
yes I have it
> and
> that the msm_wifi driver is getting a struct wifi_platform_data.
it seem to get it
> Unfortunately, I don't know of an easy way to debug livelocks due to
> interrupt storms other than by disabling everything and then enabling one
> thing at a time until it breaks again.
>
> It's obviously going to be a lot of work, but if you can manage to get
> a current kernel booting on your hardware and dump the msm_wifi module,
> that would be the ideal approach.
I've an old linux-next kernel booting but with no way to control the
phone, fortunately the gadget driver was merged in linux-next recently.
I'll try to resolve some compilation issues and to make it work first.
Denis.
^ permalink raw reply
* RE: [PATCH] Kernel Panic on Associate with brcm80211.
From: Ilya Kogan @ 2011-01-20 13:51 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <400C43189542CE41BC0A5B252FC90136952F059551@SJEXCHCCR02.corp.ad.broadcom.com>
Hey,
> I posted an official patch (removing the assert) to the staging repository
as
> I did run into this same issue. It will take some time before it is
propagated.
> As this is a staging driver patches are to be sent to
devel@linuxdriverproject.org
> (see http://driverdev.linuxdriverproject.org/pipermail/devel/).
Thanks very much, guess I'm not as crazy as I thought. I'm seeing a lot more
of the
AC_BE txop exceeded phylen errors. For some reason, I cannot maintain TCP
connections either. I haven't had a chance to wireshark the behavior, but
even if
I'm not doing a lot of data transfers, my connections will die randomly with
no indications
as to why. I don't lose my AP association and nothing gets reinitialized.
I'm not sure if
this problem is related to the errors as they don't reliably happen around
when the
connections give out. By the way, in case there's any question, I've
confirmed that the
card works correctly on Windows.
Thanks,
-- Ilya Kogan
^ permalink raw reply
* Re: iwl4965: 11n broken
From: Guy, Wey-Yi @ 2011-01-20 15:35 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <201101201242.24680.helmut.schaa@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
Hi Helmut,
On Thu, 2011-01-20 at 03:42 -0800, Helmut Schaa wrote:
> Hi,
>
> I've just updated my workstation to wireless-testing from last
> week (2.6.37-wl-default+). When associating to a 11n router the
> card only associates as 11g, the assoc request doesn't contain
> any HT IEs.
>
> The causing commit is:
>
> commit 21a5b3c6b19a8b8972ccdd55389be28a8b7c9180
> Author: Wey-Yi Guy <wey-yi.w.guy@intel.com>
> Date: Wed Nov 10 13:32:59 2010 -0800
>
> iwlagn: use SKU information in the EEPROM
>
> EEPROM contain the SKU information for the device, use it.
>
> Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
>
>
> Seems as if the device eeprom hasn't set EEPROM_SKU_CAP_11N_ENABLE and thus
> iwlagn thinks the device is not 11n capable.
>
> Ideas? Should we just revert the 4965 part of the patch and modify
> iwl_eeprom_check_sku to allow overwriting the sku field? Do 4965 devices
> exists that are not 11n capable?
>
Sorry for the mistake, here I attach the patch to address this issue.
Please give a try to see if it fix it, I will also push this patch
upstream if works for you.
Thanks
Wey
[-- Attachment #2: 0001-iwlwifi-don-t-read-sku-information-from-EEPROM-for.patch --]
[-- Type: text/x-patch, Size: 2094 bytes --]
>From 98af51fc1635b2b2138e66def03acc1fe8eb8329 Mon Sep 17 00:00:00 2001
From: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Date: Thu, 20 Jan 2011 07:32:06 -0800
Subject: [PATCH 1/1] iwlwifi: don't read sku information from EEPROM for 4965
For all the new devices, the sku information should read from EEPROM
but for legacy devices such as 4965, appearly the EEPROM does not
contain the necessary information. so skip the read from EEPROM
and go back to use software configuration.
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 11 +++++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index dada0c3..6eae0b0 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2621,6 +2621,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.fw_name_pre = IWL4965_FW_PRE,
.ucode_api_max = IWL4965_UCODE_API_MAX,
.ucode_api_min = IWL4965_UCODE_API_MIN,
+ .sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_ABC,
.eeprom_ver = EEPROM_4965_EEPROM_VERSION,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 14ceb4d..27b5a3e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -152,11 +152,14 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
eeprom_sku = iwl_eeprom_query16(priv, EEPROM_SKU_CAP);
- priv->cfg->sku = ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
+ if (!priv->cfg->sku) {
+ /* not using sku overwrite */
+ priv->cfg->sku =
+ ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
EEPROM_SKU_CAP_BAND_POS);
- if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
- priv->cfg->sku |= IWL_SKU_N;
-
+ if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
+ priv->cfg->sku |= IWL_SKU_N;
+ }
if (!priv->cfg->sku) {
IWL_ERR(priv, "Invalid device sku\n");
return -EINVAL;
--
1.6.0.4
^ permalink raw reply related
* Re: iwl4965: 11n broken
From: Helmut Schaa @ 2011-01-20 15:46 UTC (permalink / raw)
To: Guy, Wey-Yi; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1295537707.21281.1.camel@wwguy-ubuntu>
Am Donnerstag, 20. Januar 2011 schrieb Guy, Wey-Yi:
> Sorry for the mistake, here I attach the patch to address this issue.
> Please give a try to see if it fix it, I will also push this patch
> upstream if works for you.
Sure, works fine. Feel free to add a
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
to the patch when submitting.
Thanks,
Helmut
^ permalink raw reply
* Re: iwl4965: 11n broken
From: Guy, Wey-Yi @ 2011-01-20 15:49 UTC (permalink / raw)
To: Helmut Schaa; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <201101201646.21583.helmut.schaa@googlemail.com>
On Thu, 2011-01-20 at 07:46 -0800, Helmut Schaa wrote:
> Am Donnerstag, 20. Januar 2011 schrieb Guy, Wey-Yi:
> > Sorry for the mistake, here I attach the patch to address this issue.
> > Please give a try to see if it fix it, I will also push this patch
> > upstream if works for you.
>
> Sure, works fine. Feel free to add a
>
> Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
>
> to the patch when submitting.
>
Thank you for the quick response and sorry for the mistake
Wey
^ permalink raw reply
* [PATCH wireless-2.6.38] iwlwifi: don't read sku information from EEPROM for 4965
From: Wey-Yi Guy @ 2011-01-20 16:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, ipw3945-devel, Wey-Yi Guy
For all the new devices, the sku information should read from EEPROM
but for legacy devices such as 4965, appearly the EEPROM does not
contain the necessary information. so skip the read from EEPROM
and go back to use software configuration.
Reported-by: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Tested-by: Helmut Schaa <helmut.schaa@googlemail.com>
---
this patch is also available from wireless-2.6 branch on
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-2.6.git
---
drivers/net/wireless/iwlwifi/iwl-4965.c | 1 +
drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c | 11 +++++++----
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 3f1e5f1..91a9f52 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -2624,6 +2624,7 @@ struct iwl_cfg iwl4965_agn_cfg = {
.fw_name_pre = IWL4965_FW_PRE,
.ucode_api_max = IWL4965_UCODE_API_MAX,
.ucode_api_min = IWL4965_UCODE_API_MIN,
+ .sku = IWL_SKU_A|IWL_SKU_G|IWL_SKU_N,
.valid_tx_ant = ANT_AB,
.valid_rx_ant = ANT_ABC,
.eeprom_ver = EEPROM_4965_EEPROM_VERSION,
diff --git a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
index 14ceb4d..27b5a3e 100644
--- a/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
+++ b/drivers/net/wireless/iwlwifi/iwl-agn-eeprom.c
@@ -152,11 +152,14 @@ int iwl_eeprom_check_sku(struct iwl_priv *priv)
eeprom_sku = iwl_eeprom_query16(priv, EEPROM_SKU_CAP);
- priv->cfg->sku = ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
+ if (!priv->cfg->sku) {
+ /* not using sku overwrite */
+ priv->cfg->sku =
+ ((eeprom_sku & EEPROM_SKU_CAP_BAND_SELECTION) >>
EEPROM_SKU_CAP_BAND_POS);
- if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
- priv->cfg->sku |= IWL_SKU_N;
-
+ if (eeprom_sku & EEPROM_SKU_CAP_11N_ENABLE)
+ priv->cfg->sku |= IWL_SKU_N;
+ }
if (!priv->cfg->sku) {
IWL_ERR(priv, "Invalid device sku\n");
return -EINVAL;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] ath9k: Try more than one queue when scheduling new aggregate.
From: Felix Fietkau @ 2011-01-20 17:12 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, ath9k-devel
In-Reply-To: <1295400600-20596-1-git-send-email-greearb@candelatech.com>
On 2011-01-19 2:30 AM, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Try all xmit queues until the hardware buffers are full.
Acked-by: Felix Fietkau <nbd@openwrt.org>
^ permalink raw reply
* [RFC 3/3] ath9k: Support scanning on current channel.
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This adds support for scanning on only the current
channel. We do not need to flush xmit queues or
otherwise impede traffic in this scenario.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 dab0271... fa5bd0d... M drivers/net/wireless/ath/ath9k/ath9k.h
:100644 100644 333486d... ef182d1... M drivers/net/wireless/ath/ath9k/debug.c
:100644 100644 f01de0e... a2454ba... M drivers/net/wireless/ath/ath9k/main.c
:100644 100644 d205c66... 261a68a... M drivers/net/wireless/ath/ath9k/virtual.c
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/debug.c | 2 ++
drivers/net/wireless/ath/ath9k/main.c | 22 ++++++++++++++++++----
drivers/net/wireless/ath/ath9k/virtual.c | 6 ++++--
4 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index dab0271..fa5bd0d 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -672,6 +672,7 @@ struct ath_wiphy {
ATH_WIPHY_PAUSING,
ATH_WIPHY_PAUSED,
ATH_WIPHY_SCAN,
+ ATH_WIPHY_SCAN_CUR,
} state;
bool idle;
int chan_idx;
diff --git a/drivers/net/wireless/ath/ath9k/debug.c b/drivers/net/wireless/ath/ath9k/debug.c
index 333486d..ef182d1 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -394,6 +394,8 @@ static const char * ath_wiphy_state_str(enum ath_wiphy_state state)
return "PAUSED";
case ATH_WIPHY_SCAN:
return "SCAN";
+ case ATH_WIPHY_SCAN_CUR:
+ return "SCAN_CUR";
}
return "?";
}
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index f01de0e..a2454ba 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -1220,7 +1220,9 @@ static int ath9k_tx(struct ieee80211_hw *hw,
struct ath_tx_control txctl;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
- if (aphy->state != ATH_WIPHY_ACTIVE && aphy->state != ATH_WIPHY_SCAN) {
+ if (aphy->state != ATH_WIPHY_ACTIVE &&
+ aphy->state != ATH_WIPHY_SCAN_CUR &&
+ aphy->state != ATH_WIPHY_SCAN) {
ath_dbg(common, ATH_DBG_XMIT,
"ath9k: %s: TX in unexpected wiphy state %d\n",
wiphy_name(hw->wiphy), aphy->state);
@@ -1803,6 +1805,7 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
sc->sc_flags &= ~SC_OP_OFFCHANNEL;
if (aphy->state == ATH_WIPHY_SCAN ||
+ aphy->state == ATH_WIPHY_SCAN_CUR ||
aphy->state == ATH_WIPHY_ACTIVE)
ath9k_wiphy_pause_all_forced(sc, aphy);
else {
@@ -2262,7 +2265,8 @@ static int ath9k_get_survey(struct ieee80211_hw *hw, int idx,
return 0;
}
-static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
+static void ath9k_sw_scan_start_cur(struct ieee80211_hw *hw,
+ bool cur_only)
{
struct ath_wiphy *aphy = hw->priv;
struct ath_softc *sc = aphy->sc;
@@ -2280,11 +2284,20 @@ static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
return;
}
- aphy->state = ATH_WIPHY_SCAN;
- ath9k_wiphy_pause_all_forced(sc, aphy);
+ if (cur_only)
+ aphy->state = ATH_WIPHY_SCAN_CUR;
+ else {
+ aphy->state = ATH_WIPHY_SCAN;
+ ath9k_wiphy_pause_all_forced(sc, aphy);
+ }
mutex_unlock(&sc->mutex);
}
+static void ath9k_sw_scan_start(struct ieee80211_hw *hw)
+{
+ ath9k_sw_scan_start_cur(hw, false);
+}
+
/*
* XXX: this requires a revisit after the driver
* scan_complete gets moved to another place/removed in mac80211.
@@ -2331,6 +2344,7 @@ struct ieee80211_ops ath9k_ops = {
.ampdu_action = ath9k_ampdu_action,
.get_survey = ath9k_get_survey,
.sw_scan_start = ath9k_sw_scan_start,
+ .sw_scan_start_cur = ath9k_sw_scan_start_cur,
.sw_scan_complete = ath9k_sw_scan_complete,
.rfkill_poll = ath9k_rfkill_poll_state,
.set_coverage_class = ath9k_set_coverage_class,
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index d205c66..261a68a 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -176,11 +176,13 @@ static bool ath9k_wiphy_pausing(struct ath_softc *sc)
static bool __ath9k_wiphy_scanning(struct ath_softc *sc)
{
int i;
- if (sc->pri_wiphy->state == ATH_WIPHY_SCAN)
+ if (sc->pri_wiphy->state == ATH_WIPHY_SCAN ||
+ sc->pri_wiphy->state == ATH_WIPHY_SCAN_CUR)
return true;
for (i = 0; i < sc->num_sec_wiphy; i++) {
if (sc->sec_wiphy[i] &&
- sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN)
+ (sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN ||
+ sc->sec_wiphy[i]->state == ATH_WIPHY_SCAN_CUR))
return true;
}
return false;
--
1.7.2.3
^ permalink raw reply related
* [RFC 1/3] mac80211: Support sw_scan_start_cur
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
From: Ben Greear <greearb@candelatech.com>
This method is called when driver can support
scanning the currect active channel without otherwise
impeding traffic on that channel. The mac80211 scan
logic may call this when we are only scanning on the
active channel and thus do not need to go off channel.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 d6b0045... 3e89ae7... M include/net/mac80211.h
include/net/mac80211.h | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d6b0045..3e89ae7 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1672,6 +1672,12 @@ enum ieee80211_ampdu_mlme_action {
* is started. Can be NULL, if the driver doesn't need this notification.
* The callback can sleep.
*
+ * @sw_scan_start_cur: Notifier function that is called just before a software
+ * scan on only the current channel is started. If NULL, sw_scan_start
+ * will be used instead. sw_scan_start_cur with second argument set to
+ * false should be treated identically to sw_scan_start.
+ * The callback can sleep.
+ *
* @sw_scan_complete: Notifier function that is called just after a
* software scan finished. Can be NULL, if the driver doesn't need
* this notification.
@@ -1820,6 +1826,8 @@ struct ieee80211_ops {
int (*hw_scan)(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
struct cfg80211_scan_request *req);
void (*sw_scan_start)(struct ieee80211_hw *hw);
+ void (*sw_scan_start_cur)(struct ieee80211_hw *hw,
+ bool cur_channel_only);
void (*sw_scan_complete)(struct ieee80211_hw *hw);
int (*get_stats)(struct ieee80211_hw *hw,
struct ieee80211_low_level_stats *stats);
--
1.7.2.3
^ permalink raw reply related
* [RFC 2/3] mac80211: Support scanning only current active channel.
From: greearb @ 2011-01-20 17:32 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
From: Ben Greear <greearb@candelatech.com>
This allows user-space to request scan on only the current
channel and have that not interfere with other traffic.
Especially useful when using virtual stations that must
all run on the same channel anyway.
Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 78af32d... 7cd7af8... M net/mac80211/driver-ops.h
:100644 100644 fbabbc2... 8c6d253... M net/mac80211/driver-trace.h
:100644 100644 c47d7c0... 388db0e... M net/mac80211/ieee80211_i.h
:100644 100644 1236710... b1767a5... M net/mac80211/rx.c
:100644 100644 fb274db... b42e5ad... M net/mac80211/scan.c
net/mac80211/driver-ops.h | 12 ++++++++
net/mac80211/driver-trace.h | 18 ++++++++++++
net/mac80211/ieee80211_i.h | 3 ++
net/mac80211/rx.c | 1 +
net/mac80211/scan.c | 61 +++++++++++++++++++++++++++++++-----------
5 files changed, 79 insertions(+), 16 deletions(-)
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 78af32d..7cd7af8 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -201,6 +201,18 @@ static inline void drv_sw_scan_start(struct ieee80211_local *local)
trace_drv_return_void(local);
}
+static inline void drv_sw_scan_start_cur(struct ieee80211_local *local,
+ bool cur_channel_only)
+{
+ might_sleep();
+
+ trace_drv_sw_scan_start_cur(local);
+ if (local->ops->sw_scan_start_cur)
+ local->ops->sw_scan_start_cur(&local->hw,
+ cur_channel_only);
+ trace_drv_return_void(local);
+}
+
static inline void drv_sw_scan_complete(struct ieee80211_local *local)
{
might_sleep();
diff --git a/net/mac80211/driver-trace.h b/net/mac80211/driver-trace.h
index fbabbc2..8c6d253 100644
--- a/net/mac80211/driver-trace.h
+++ b/net/mac80211/driver-trace.h
@@ -457,6 +457,24 @@ TRACE_EVENT(drv_sw_scan_start,
)
);
+TRACE_EVENT(drv_sw_scan_start_cur,
+ 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
+ )
+);
+
TRACE_EVENT(drv_sw_scan_complete,
TP_PROTO(struct ieee80211_local *local),
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index c47d7c0..388db0e 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -660,6 +660,8 @@ struct tpt_led_trigger {
* that the scan completed.
* @SCAN_ABORTED: Set for our scan work function when the driver reported
* a scan complete for an aborted scan.
+ * @SCAN_ON_CUR_CHANNEL: Set when we are scanning only on the current
+ * channel. This means no off/on-channel logic needs to be run.
*/
enum {
SCAN_SW_SCANNING,
@@ -667,6 +669,7 @@ enum {
SCAN_OFF_CHANNEL,
SCAN_COMPLETED,
SCAN_ABORTED,
+ SCAN_ON_CUR_CHANNEL,
};
/**
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 1236710..b1767a5 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2749,6 +2749,7 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw,
local->dot11ReceivedFragmentCount++;
if (unlikely(test_bit(SCAN_HW_SCANNING, &local->scanning) ||
+ test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning) ||
test_bit(SCAN_OFF_CHANNEL, &local->scanning)))
status->rx_flags |= IEEE80211_RX_IN_SCAN;
diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
index fb274db..b42e5ad 100644
--- a/net/mac80211/scan.c
+++ b/net/mac80211/scan.c
@@ -293,11 +293,17 @@ static void __ieee80211_scan_completed_finish(struct ieee80211_hw *hw,
{
struct ieee80211_local *local = hw_to_local(hw);
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+
if (!was_hw_scan) {
ieee80211_configure_filter(local);
drv_sw_scan_complete(local);
- ieee80211_offchannel_return(local, true);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ /* Don't call this if we never left the channel. */
+ ieee80211_offchannel_return(local, true);
+ else
+ __clear_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
}
mutex_lock(&local->mtx);
@@ -338,15 +344,28 @@ static int ieee80211_start_sw_scan(struct ieee80211_local *local)
* nullfunc frames and probe requests will be dropped in
* ieee80211_tx_h_check_assoc().
*/
- drv_sw_scan_start(local);
- ieee80211_offchannel_stop_beaconing(local);
+ if (local->ops->sw_scan_start_cur &&
+ local->scan_req->n_channels == 1 &&
+ local->scan_req->channels[0] == local->hw.conf.channel) {
+ __set_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
+ drv_sw_scan_start_cur(local, true);
+ } else
+ drv_sw_scan_start(local);
+
+ /* If we are scanning one channel, and only our own channel
+ * then we don't need to call the off-channel logic.
+ */
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning)) {
+ ieee80211_offchannel_stop_beaconing(local);
+ local->leave_oper_channel_time = 0;
+ }
- local->leave_oper_channel_time = 0;
local->next_scan_state = SCAN_DECISION;
local->scan_channel_idx = 0;
- drv_flush(local, false);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ drv_flush(local, false);
ieee80211_configure_filter(local);
@@ -522,10 +541,14 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
local->next_scan_state = SCAN_SET_CHANNEL;
} else {
/*
- * we're on the operating channel currently, let's
- * leave that channel now to scan another one
+ * We're on the operating channel currently, Leave that
+ * channel only if we are probing more than the current
+ * channel.
*/
- local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
+ if (test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning))
+ local->next_scan_state = SCAN_SET_CHANNEL;
+ else
+ local->next_scan_state = SCAN_LEAVE_OPER_CHANNEL;
}
*next_delay = 0;
@@ -559,14 +582,19 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
{
/* switch back to the operating channel */
local->scan_channel = NULL;
- ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
- /*
- * Only re-enable station mode interface now; beaconing will be
- * re-enabled once the full scan has been completed.
+ /* We only return if we ever left, and should never leave if
+ * scanning single channel that is also the operating channel.
*/
- ieee80211_offchannel_return(local, false);
+ if (!test_bit(SCAN_ON_CUR_CHANNEL, &local->scanning)) {
+ ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
+ /*
+ * Only re-enable station mode interface now; beaconing will be
+ * re-enabled once the full scan has been completed.
+ */
+ ieee80211_offchannel_return(local, false);
+ }
__clear_bit(SCAN_OFF_CHANNEL, &local->scanning);
*next_delay = HZ / 5;
@@ -583,8 +611,9 @@ static void ieee80211_scan_state_set_channel(struct ieee80211_local *local,
chan = local->scan_req->channels[local->scan_channel_idx];
local->scan_channel = chan;
- if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
- skip = 1;
+ if (local->hw.conf.channel != chan)
+ if (ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL))
+ skip = 1;
/* advance state machine to next channel/band */
local->scan_channel_idx++;
--
1.7.2.3
^ permalink raw reply related
* Re: [RFC 1/3] mac80211: Support sw_scan_start_cur
From: Johannes Berg @ 2011-01-20 17:37 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1295544750-6704-1-git-send-email-greearb@candelatech.com>
On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This method is called when driver can support
> scanning the currect active channel without otherwise
> impeding traffic on that channel. The mac80211 scan
> logic may call this when we are only scanning on the
> active channel and thus do not need to go off channel.
I frankly don't see any point telling the driver about this. Looking at
the ath9k patch you sent, it seems to avoid some things like flushing --
but the flushing should be controlled by mac80211 already (or converted
to be) so that it's not necessary to have this.
johannes
^ permalink raw reply
* Re: [RFC 2/3] mac80211: Support scanning only current active channel.
From: Johannes Berg @ 2011-01-20 17:39 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless
In-Reply-To: <1295544750-6704-2-git-send-email-greearb@candelatech.com>
On Thu, 2011-01-20 at 09:32 -0800, greearb@candelatech.com wrote:
> - ieee80211_offchannel_stop_beaconing(local);
> + if (local->ops->sw_scan_start_cur &&
> + local->scan_req->n_channels == 1 &&
> + local->scan_req->channels[0] == local->hw.conf.channel) {
> + __set_bit(SCAN_ON_CUR_CHANNEL, &local->scanning);
> + drv_sw_scan_start_cur(local, true);
> + } else
> + drv_sw_scan_start(local);
This doesn't seem to make much sense either -- even if we do a scan over
multiple channels we should be able to optimise the part on the current
channel (maybe put it at the beginning or end too).
johannes
^ permalink raw reply
* Re: [RFC PATCH 10/17] zd1211rw: implement beacon fetching and handling ieee80211_get_buffered_bc()
From: Christian Lamparter @ 2011-01-20 17:43 UTC (permalink / raw)
To: Jussi Kivilinna; +Cc: linux-wireless, Daniel Drake, Ulrich Kunitz
In-Reply-To: <20110120101606.53052h18mlpyp8w0@hayate.sektori.org>
On Thursday 20 January 2011 09:16:06 Jussi Kivilinna wrote:
> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>> On Wednesday 19 January 2011 19:49:03 Jussi Kivilinna wrote:
>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>> On Sunday 09 January 2011 16:46:56 Jussi Kivilinna wrote:
>>>>> Quoting Christian Lamparter <chunkeey@googlemail.com>:
>>>>>> Since zd_beacon_done also uploads the next beacon so long in advance,
>>>>>> there could be an equally long race between the outdated state of the
>>>>>> next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
>>>>>> which -in your case- was uploaded almost a beacon interval ago and
>>>>>> the xmit of ieee80211_get_buffered_bc *now*.
>>>>>>
>>>>>> The dtim bc/mc bit might be not set, when a mc/bc arrived after the
>>>>>> beacon was uploaded, but before the "beacon done event" from the
>>>>>> hardware. So, dozing stations don't expect the broadcast traffic
>>>>>> and of course, they might miss it completely.
>>>>>>
>>>>>> It's probably better to fix this in mac80211 (see the attached hack).
>>>>>
>>>>> Ok, should I add this to my patchset?
>>>> well, difficult to say. As far as I can say, it should be correct for "your
>>>> case". But, on the other hand: what about solutions that can't buffer
>>>> mc/bc frames (and needs to call ieee80211_get_buffered_bc), however the
>>>> firmware is clever enough to maintain a beacon internally (so they
>>>> won't call ieee80211_beacon_get and only relies on set_tim)?
>>>>
>>>> Sure, it's just a unlikely corner case... In fact, I didn't check if
>>>> that's even possible, but it does sound reasonable to some extend.
>>>
>>> From what I checked none of currect driver/device is such.
>>> Maybe if such device appears then !bss->dtim_bc_mc check in
>>> ieee80211_beacon_add_tim() could be masked with driver flag (something
>>> like
>>> IEEE80211_HW_CAN_AND_HANDLE_BEACON_BUT_STILL_NEEDS_HOST_BROADCAST_PS_BUFFERING).
>>
>> True, but a recent discussion into this matter have made parts of the
>> API you are planning to use sort-of "deprecated"? [I think?]
>>
>> http://marc.info/?l=linux-wireless&m=129463297300480
>>
>> I don't know the exact details, but I'm sure Kvalo does have his reasons.
>> [afaik it has to do with wl12xx, he even explained it once, but I can't
>> find that mail anymore].
>>
>
> What I understood from that thread is that rt2x00/usb doesn't have HW
> buffering and doesn't enable IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING
> (rt2x00/pci does), and yet enables AP-mode. Driver has this comment:
> /*
> * Initialize all hw fields.
> *
> * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING unless we are
> * capable of sending the buffered frames out after the DTIM
> * transmission using rt2x00lib_beacondone. This will send out
> * multicast and broadcast traffic immediately instead of buffering it
> * infinitly and thus dropping it after some time.
> */
My bad, you are right. This is not something to worry about anymore.
> > One more thing, is there a tx-control flag to instruct the HW/FW to write
> > the TSF into probe response frames, just like it does for beacons frames?
> >
> > Sure, this feature is far more important for IBSS, but the 802.11-2007
> > specs @11.1.4 says that a STA might use beacons or probe responses to
> > synchronize its timers. [However 11.1.1.1 and 11.1.3.4 say that STAs
> > should "only" pick this information from beacons, if I'm not mistaken?!]
> > (Also a uniform "0..0" timestamp in every probe-response looks so sad.)
> >
>
> No such flag I'm afraid. Vendor driver appears to be reading
> tsf-register from driver and writing value to probe response frames,
> maybe something I should add to zd1211rw too.
It's more of a cosmetic thing, but very difficult to get it right without
firmware/hw support [over an usb]. So you might just leave it as it
is...
Best regards,
Christian
^ permalink raw reply
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