* [PATCH 2/2] mac80211: config hw when going back on-channel
From: Eliad Peller @ 2011-10-20 17:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1319130350-15514-1-git-send-email-eliad@wizery.com>
When going back on-channel, we should reconfigure
the hw iff the hardware is not already configured
to the operational channel.
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
net/mac80211/work.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index b4de5dc..92ad8d6 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -1091,7 +1091,6 @@ static void ieee80211_work_work(struct work_struct *work)
}
if (!remain_off_channel && local->tmp_channel) {
- bool on_oper_chan = ieee80211_cfg_on_oper_channel(local);
local->tmp_channel = NULL;
/* If tmp_channel wasn't operating channel, then
* we need to go back on-channel.
@@ -1101,7 +1100,7 @@ static void ieee80211_work_work(struct work_struct *work)
* we still need to do a hardware config. Currently,
* we cannot be here while scanning, however.
*/
- if (ieee80211_cfg_on_oper_channel(local) && !on_oper_chan)
+ if (!ieee80211_cfg_on_oper_channel(local))
ieee80211_hw_config(local, 0);
/* At the least, we need to disable offchannel_ps,
--
1.7.6.401.g6a319
^ permalink raw reply related
* [PATCH 1/2] mac80211: fix remain_off_channel regression
From: Eliad Peller @ 2011-10-20 17:05 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
The offchannel code is currently broken - we should
remain_off_channel if the work was started, and
the work's channel and channel_type are the same
as local->tmp_channel and local->tmp_channel_type.
However, if wk->chan_type and local->tmp_channel_type
coexist (e.g. have the same channel type), we won't
remain_off_channel.
This behavior was introduced by commit da2fd1f
("mac80211: Allow work items to use existing
channel type.")
Tested-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
---
net/mac80211/work.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/work.c b/net/mac80211/work.c
index af374fa..b4de5dc 100644
--- a/net/mac80211/work.c
+++ b/net/mac80211/work.c
@@ -1084,8 +1084,8 @@ static void ieee80211_work_work(struct work_struct *work)
continue;
if (wk->chan != local->tmp_channel)
continue;
- if (ieee80211_work_ct_coexists(wk->chan_type,
- local->tmp_channel_type))
+ if (!ieee80211_work_ct_coexists(wk->chan_type,
+ local->tmp_channel_type))
continue;
remain_off_channel = true;
}
--
1.7.6.401.g6a319
^ permalink raw reply related
* Re: [PATCH 4/6] mac80211: allow frame aggregation for mesh
From: Thomas Pedersen @ 2011-10-20 16:48 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, anagar6, devel, johannes, linville
In-Reply-To: <201110201146.00505.chunkeey@googlemail.com>
On Thu, Oct 20, 2011 at 2:46 AM, Christian Lamparter
<chunkeey@googlemail.com> wrote:
> On Thursday, October 20, 2011 03:03:24 AM Thomas Pedersen wrote:
>> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
>> Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
>> ---
>> net/mac80211/agg-rx.c | 3 ++-
>> net/mac80211/agg-tx.c | 4 +++-
>> net/mac80211/ht.c | 3 ++-
>> net/mac80211/rx.c | 1 +
>> 4 files changed, 8 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
>> index 2ac0339..36c2836 100644
>> --- a/net/mac80211/agg-tx.c
>> +++ b/net/mac80211/agg-tx.c
>> @@ -378,6 +379,7 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
>> * by drivers or the standard.
>> */
>> if (sdata->vif.type != NL80211_IFTYPE_STATION &&
>> + sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
>> sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
>> sdata->vif.type != NL80211_IFTYPE_AP)
>> return -EINVAL;
>
> just a nitpick, but it looks like the comment in agg-tx.c
> seems to be a little out of date. Hence, would you mind
> removing it as well?
>
No problem :)
> /*
> * The aggregation code is not prepared to handle
> * anything but STA/AP due to the BSSID handling.
> * IBSS could work in the code but isn't supported
> * by drivers or the standard.
> */
> if (sdata->vif.type != NL80211_IFTYPE_STATION &&
> sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
> sdata->vif.type != NL80211_IFTYPE_AP)
> return -EINVAL;
>
> Regards,
> Chr
>
^ permalink raw reply
* Re: [RFC 1/2] mac80211: fix remain_off_channel regression
From: Eliad Peller @ 2011-10-20 16:47 UTC (permalink / raw)
To: Ben Greear; +Cc: Johannes Berg, linux-wireless, John W. Linville
In-Reply-To: <4E9F110A.5000608@candelatech.com>
hi Ben,
On Wed, Oct 19, 2011 at 8:03 PM, Ben Greear <greearb@candelatech.com> wrote:
> On 07/25/2011 08:29 AM, Eliad Peller wrote:
>>
>> i'm not familiar enough with the off_channel flow,
>> but this one looks completely broken - we should
>> remain_off_channel if the work was started, and
>> the work's channel and channel_type are the same
>> as local->tmp_channel and local->tmp_channel_type.
>>
>> however, if wk->chan_type and local->tmp_channel_type
>> coexist (e.g. have the same channel type), we won't
>> remain_off_channel.
>>
>> this behavior was introduced by commit da2fd1f
>> ("mac80211: Allow work items to use existing
>> channel type.")
>>
>> Signed-off-by: Eliad Peller<eliad@wizery.com>
>
> Both Johannes and I agreed with this patch shortly after it
> was posted, and I have just done a quick test with multiple
> stations and it appears to work fine.
>
> Eliad: Please re-send this patch w/out the RFC, and you
> can add:
>
> Tested-by: Ben Greear <greearb@candelatech.com>
>
it seems that i forgot to resubmit the RFCs as patches.
thanks for testing, i'll submit them shortly.
(John - i see there is some ongoing discussion regarding similar
patches, so feel free to take only some of them, according to the
conclusion)
Eliad.
^ permalink raw reply
* Re: [PATCH] mac80211: Fix off-channel problem in work task.
From: Ben Greear @ 2011-10-20 16:12 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Eliad Peller, Johannes Berg
In-Reply-To: <20111020160859.GC2293@redhat.com>
On 10/20/2011 09:09 AM, Stanislaw Gruszka wrote:
> On Thu, Oct 20, 2011 at 08:22:55AM -0700, Ben Greear wrote:
>> On 10/20/2011 07:58 AM, Stanislaw Gruszka wrote:
>>> On Wed, Oct 19, 2011 at 11:44:36AM -0700, greearb@candelatech.com wrote:
>>>> From: Ben Greear<greearb@candelatech.com>
>>>>
>>>> The ieee80211_cfg_on_oper_channel method compared the
>>>> current hardware config as well as the desired hardware
>>>> config. In most cases, this is proper, but when deciding
>>>> whether to go back on-channel, if the hardware is not
>>>> configured on-channel, but logically it *should* be
>>>> on-channel, then we must go on-channel.
>>>>
>>>> This patch adds a flag to the ieee80211_cfg_on_oper_channel
>>>> logic to disable comparing the actual hardware so we do not
>>>> have to create another tricky method with similar logic.
>>>>
>>>> Reported-by: Eliad Peller<eliad@wizery.com>
>>>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>>>
>>> I much more prefer previous one-line patch from Eliad
>>> http://news.gmane.org/find-root.php?message_id=%3c1311607763%2d12603%2d3%2dgit%2dsend%2demail%2deliad%40wizery.com%3e
>>>
>>> this one seems to provide unneeded code complexity, but
>>> behaviour i.e. number of channel switches in hardware
>>> is the same.
>>
>> I believe it's possible to set tmp_channel to NULL and not actually
>> change the on/off channel configuration, and my patch should allow us to
>> skip a hardware config in that case.
>>
>> However, this might only be possible if we are in this code while
>> scanning, and currently, I don't believe we can be in this work
>> code while scanning.
>
> So you want to optimize a case that is not even possible at present.
> Do you know that "premature optimization is the root of all evil" ? :-)
I was trying to clean out some of the sloppiness in the on/off channel
logic, but in this case, I don't think the extra parania helped much,
and my attempt at cleverness obviously introduced some bugs...
> I'm not quite against by that change, but I would like to have -stable
> fixes, since bug we are talking about not only annoys people by warning,
> but also disallow to associate to wireless network. I prefer that we
> apply Eliad patches and cc -stable and do possible further optimization
> on top of that (ideally if some measurement will be available that show
> optimization really works).
That is fine with me.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] mac80211: Fix off-channel problem in work task.
From: Stanislaw Gruszka @ 2011-10-20 16:09 UTC (permalink / raw)
To: Ben Greear; +Cc: linux-wireless, Eliad Peller, Johannes Berg
In-Reply-To: <4EA03CCF.6090604@candelatech.com>
On Thu, Oct 20, 2011 at 08:22:55AM -0700, Ben Greear wrote:
> On 10/20/2011 07:58 AM, Stanislaw Gruszka wrote:
> >On Wed, Oct 19, 2011 at 11:44:36AM -0700, greearb@candelatech.com wrote:
> >>From: Ben Greear<greearb@candelatech.com>
> >>
> >>The ieee80211_cfg_on_oper_channel method compared the
> >>current hardware config as well as the desired hardware
> >>config. In most cases, this is proper, but when deciding
> >>whether to go back on-channel, if the hardware is not
> >>configured on-channel, but logically it *should* be
> >>on-channel, then we must go on-channel.
> >>
> >>This patch adds a flag to the ieee80211_cfg_on_oper_channel
> >>logic to disable comparing the actual hardware so we do not
> >>have to create another tricky method with similar logic.
> >>
> >>Reported-by: Eliad Peller<eliad@wizery.com>
> >>Signed-off-by: Ben Greear<greearb@candelatech.com>
> >
> >I much more prefer previous one-line patch from Eliad
> >http://news.gmane.org/find-root.php?message_id=%3c1311607763%2d12603%2d3%2dgit%2dsend%2demail%2deliad%40wizery.com%3e
> >
> >this one seems to provide unneeded code complexity, but
> >behaviour i.e. number of channel switches in hardware
> >is the same.
>
> I believe it's possible to set tmp_channel to NULL and not actually
> change the on/off channel configuration, and my patch should allow us to
> skip a hardware config in that case.
>
> However, this might only be possible if we are in this code while
> scanning, and currently, I don't believe we can be in this work
> code while scanning.
So you want to optimize a case that is not even possible at present.
Do you know that "premature optimization is the root of all evil" ? :-)
I'm not quite against by that change, but I would like to have -stable
fixes, since bug we are talking about not only annoys people by warning,
but also disallow to associate to wireless network. I prefer that we
apply Eliad patches and cc -stable and do possible further optimization
on top of that (ideally if some measurement will be available that show
optimization really works).
Thanks
Stanislaw
^ permalink raw reply
* Re: [PATCH] mac80211: Fix off-channel problem in work task.
From: Ben Greear @ 2011-10-20 15:22 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Eliad Peller, Johannes Berg
In-Reply-To: <20111020145852.GB2293@redhat.com>
On 10/20/2011 07:58 AM, Stanislaw Gruszka wrote:
> On Wed, Oct 19, 2011 at 11:44:36AM -0700, greearb@candelatech.com wrote:
>> From: Ben Greear<greearb@candelatech.com>
>>
>> The ieee80211_cfg_on_oper_channel method compared the
>> current hardware config as well as the desired hardware
>> config. In most cases, this is proper, but when deciding
>> whether to go back on-channel, if the hardware is not
>> configured on-channel, but logically it *should* be
>> on-channel, then we must go on-channel.
>>
>> This patch adds a flag to the ieee80211_cfg_on_oper_channel
>> logic to disable comparing the actual hardware so we do not
>> have to create another tricky method with similar logic.
>>
>> Reported-by: Eliad Peller<eliad@wizery.com>
>> Signed-off-by: Ben Greear<greearb@candelatech.com>
>
> I much more prefer previous one-line patch from Eliad
> http://news.gmane.org/find-root.php?message_id=%3c1311607763%2d12603%2d3%2dgit%2dsend%2demail%2deliad%40wizery.com%3e
>
> this one seems to provide unneeded code complexity, but
> behaviour i.e. number of channel switches in hardware
> is the same.
I believe it's possible to set tmp_channel to NULL and not actually
change the on/off channel configuration, and my patch should allow us to
skip a hardware config in that case.
However, this might only be possible if we are in this code while
scanning, and currently, I don't believe we can be in this work
code while scanning.
So, his patch is probably good enough for now, and if the scanning change
ever happens, we can do something more like what I have.
Thanks,
Ben
>
> Stanislaw
>
>> ---
>>
>> NOTE: This is tricky stuff, please do not apply until at
>> least Johannes gets time to review this.
>>
>> :100644 100644 4c3d1f5... 40ca484... M net/mac80211/ieee80211_i.h
>> :100644 100644 d4ee6d2... 3ead637... M net/mac80211/main.c
>> :100644 100644 397343a... d1b6b29... M net/mac80211/scan.c
>> :100644 100644 bf5be22... 62a3357... M net/mac80211/work.c
>> net/mac80211/ieee80211_i.h | 3 ++-
>> net/mac80211/main.c | 13 ++++++++-----
>> net/mac80211/scan.c | 10 +++++-----
>> net/mac80211/work.c | 11 +++++++----
>> 4 files changed, 22 insertions(+), 15 deletions(-)
>>
>> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
>> index 4c3d1f5..40ca484 100644
>> --- a/net/mac80211/ieee80211_i.h
>> +++ b/net/mac80211/ieee80211_i.h
>> @@ -1139,7 +1139,8 @@ int ieee80211_request_sched_scan_stop(struct ieee80211_sub_if_data *sdata);
>> void ieee80211_sched_scan_stopped_work(struct work_struct *work);
>>
>> /* off-channel helpers */
>> -bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local);
>> +bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local,
>> + bool check_current_hw_cfg);
>> void ieee80211_offchannel_enable_all_ps(struct ieee80211_local *local,
>> bool tell_ap);
>> void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
>> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
>> index d4ee6d2..3ead637 100644
>> --- a/net/mac80211/main.c
>> +++ b/net/mac80211/main.c
>> @@ -94,11 +94,13 @@ static void ieee80211_reconfig_filter(struct work_struct *work)
>>
>> /*
>> * Returns true if we are logically configured to be on
>> - * the operating channel AND the hardware-conf is currently
>> - * configured on the operating channel. Compares channel-type
>> + * the operating channel and channel-type.
>> + * If the check_current_hw_cfg argument is TRUE,
>> + * the currently configured hardware value is checked
>> * as well.
>> */
>> -bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
>> +bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local,
>> + bool check_current_hw_cfg)
>> {
>> struct ieee80211_channel *chan, *scan_chan;
>> enum nl80211_channel_type channel_type;
>> @@ -126,8 +128,9 @@ bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
>> return false;
>>
>> /* Check current hardware-config against oper_channel. */
>> - if ((local->oper_channel != local->hw.conf.channel) ||
>> - (local->_oper_channel_type != local->hw.conf.channel_type))
>> + if (check_current_hw_cfg&&
>> + ((local->oper_channel != local->hw.conf.channel) ||
>> + (local->_oper_channel_type != local->hw.conf.channel_type)))
>> return false;
>>
>> return true;
>> diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
>> index 397343a..d1b6b29 100644
>> --- a/net/mac80211/scan.c
>> +++ b/net/mac80211/scan.c
>> @@ -216,7 +216,7 @@ ieee80211_scan_rx(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
>> * current channel, pass the pkt on up the stack so that
>> * the rest of the stack can make use of it.
>> */
>> - if (ieee80211_cfg_on_oper_channel(sdata->local)
>> + if (ieee80211_cfg_on_oper_channel(sdata->local, true)
>> && (channel == sdata->local->oper_channel))
>> return RX_CONTINUE;
>>
>> @@ -297,7 +297,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted,
>> local->scanning = 0;
>> local->scan_channel = NULL;
>>
>> - on_oper_chan = ieee80211_cfg_on_oper_channel(local);
>> + on_oper_chan = ieee80211_cfg_on_oper_channel(local, true);
>>
>> if (was_hw_scan || !on_oper_chan)
>> ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>> @@ -309,7 +309,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted,
>> bool on_oper_chan2;
>> ieee80211_configure_filter(local);
>> drv_sw_scan_complete(local);
>> - on_oper_chan2 = ieee80211_cfg_on_oper_channel(local);
>> + on_oper_chan2 = ieee80211_cfg_on_oper_channel(local, true);
>> /* We should always be on-channel at this point. */
>> WARN_ON(!on_oper_chan2);
>> if (on_oper_chan2&& (on_oper_chan != on_oper_chan2))
>> @@ -509,7 +509,7 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
>>
>> next_chan = local->scan_req->channels[local->scan_channel_idx];
>>
>> - if (ieee80211_cfg_on_oper_channel(local)) {
>> + if (ieee80211_cfg_on_oper_channel(local, true)) {
>> /* We're currently on operating channel. */
>> if (next_chan == local->oper_channel)
>> /* We don't need to move off of operating channel. */
>> @@ -587,7 +587,7 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
>> {
>> /* switch back to the operating channel */
>> local->scan_channel = NULL;
>> - if (!ieee80211_cfg_on_oper_channel(local))
>> + if (!ieee80211_cfg_on_oper_channel(local, true))
>> ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>>
>> /*
>> diff --git a/net/mac80211/work.c b/net/mac80211/work.c
>> index bf5be22..62a3357 100644
>> --- a/net/mac80211/work.c
>> +++ b/net/mac80211/work.c
>> @@ -973,7 +973,8 @@ static void ieee80211_work_work(struct work_struct *work)
>> bool tmp_chan_changed = false;
>> bool on_oper_chan2;
>> enum nl80211_channel_type wk_ct;
>> - on_oper_chan = ieee80211_cfg_on_oper_channel(local);
>> + on_oper_chan = ieee80211_cfg_on_oper_channel(local,
>> + true);
>>
>> /* Work with existing channel type if possible. */
>> wk_ct = wk->chan_type;
>> @@ -993,7 +994,8 @@ static void ieee80211_work_work(struct work_struct *work)
>> * happen to be on the same channel as
>> * the requested channel.
>> */
>> - on_oper_chan2 = ieee80211_cfg_on_oper_channel(local);
>> + on_oper_chan2 = ieee80211_cfg_on_oper_channel(local,
>> + true);
>> if (on_oper_chan != on_oper_chan2) {
>> if (on_oper_chan2) {
>> /* going off oper channel, PS too */
>> @@ -1091,7 +1093,7 @@ static void ieee80211_work_work(struct work_struct *work)
>> }
>>
>> if (!remain_off_channel&& local->tmp_channel) {
>> - bool on_oper_chan = ieee80211_cfg_on_oper_channel(local);
>> + bool on_oper_chan = ieee80211_cfg_on_oper_channel(local, true);
>> local->tmp_channel = NULL;
>> /* If tmp_channel wasn't operating channel, then
>> * we need to go back on-channel.
>> @@ -1101,7 +1103,8 @@ static void ieee80211_work_work(struct work_struct *work)
>> * we still need to do a hardware config. Currently,
>> * we cannot be here while scanning, however.
>> */
>> - if (ieee80211_cfg_on_oper_channel(local)&& !on_oper_chan)
>> + if (ieee80211_cfg_on_oper_channel(local, false)&&
>> + !on_oper_chan)
>> ieee80211_hw_config(local, 0);
>>
>> /* At the least, we need to disable offchannel_ps,
>> --
>> 1.7.3.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] mac80211: Fix off-channel problem in work task.
From: Stanislaw Gruszka @ 2011-10-20 14:58 UTC (permalink / raw)
To: greearb; +Cc: linux-wireless, Eliad Peller, Johannes Berg
In-Reply-To: <1319049876-16243-1-git-send-email-greearb@candelatech.com>
On Wed, Oct 19, 2011 at 11:44:36AM -0700, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> The ieee80211_cfg_on_oper_channel method compared the
> current hardware config as well as the desired hardware
> config. In most cases, this is proper, but when deciding
> whether to go back on-channel, if the hardware is not
> configured on-channel, but logically it *should* be
> on-channel, then we must go on-channel.
>
> This patch adds a flag to the ieee80211_cfg_on_oper_channel
> logic to disable comparing the actual hardware so we do not
> have to create another tricky method with similar logic.
>
> Reported-by: Eliad Peller <eliad@wizery.com>
> Signed-off-by: Ben Greear <greearb@candelatech.com>
I much more prefer previous one-line patch from Eliad
http://news.gmane.org/find-root.php?message_id=%3c1311607763%2d12603%2d3%2dgit%2dsend%2demail%2deliad%40wizery.com%3e
this one seems to provide unneeded code complexity, but
behaviour i.e. number of channel switches in hardware
is the same.
Stanislaw
> ---
>
> NOTE: This is tricky stuff, please do not apply until at
> least Johannes gets time to review this.
>
> :100644 100644 4c3d1f5... 40ca484... M net/mac80211/ieee80211_i.h
> :100644 100644 d4ee6d2... 3ead637... M net/mac80211/main.c
> :100644 100644 397343a... d1b6b29... M net/mac80211/scan.c
> :100644 100644 bf5be22... 62a3357... M net/mac80211/work.c
> net/mac80211/ieee80211_i.h | 3 ++-
> net/mac80211/main.c | 13 ++++++++-----
> net/mac80211/scan.c | 10 +++++-----
> net/mac80211/work.c | 11 +++++++----
> 4 files changed, 22 insertions(+), 15 deletions(-)
>
> diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
> index 4c3d1f5..40ca484 100644
> --- a/net/mac80211/ieee80211_i.h
> +++ b/net/mac80211/ieee80211_i.h
> @@ -1139,7 +1139,8 @@ int ieee80211_request_sched_scan_stop(struct ieee80211_sub_if_data *sdata);
> void ieee80211_sched_scan_stopped_work(struct work_struct *work);
>
> /* off-channel helpers */
> -bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local);
> +bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local,
> + bool check_current_hw_cfg);
> void ieee80211_offchannel_enable_all_ps(struct ieee80211_local *local,
> bool tell_ap);
> void ieee80211_offchannel_stop_vifs(struct ieee80211_local *local,
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index d4ee6d2..3ead637 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -94,11 +94,13 @@ static void ieee80211_reconfig_filter(struct work_struct *work)
>
> /*
> * Returns true if we are logically configured to be on
> - * the operating channel AND the hardware-conf is currently
> - * configured on the operating channel. Compares channel-type
> + * the operating channel and channel-type.
> + * If the check_current_hw_cfg argument is TRUE,
> + * the currently configured hardware value is checked
> * as well.
> */
> -bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
> +bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local,
> + bool check_current_hw_cfg)
> {
> struct ieee80211_channel *chan, *scan_chan;
> enum nl80211_channel_type channel_type;
> @@ -126,8 +128,9 @@ bool ieee80211_cfg_on_oper_channel(struct ieee80211_local *local)
> return false;
>
> /* Check current hardware-config against oper_channel. */
> - if ((local->oper_channel != local->hw.conf.channel) ||
> - (local->_oper_channel_type != local->hw.conf.channel_type))
> + if (check_current_hw_cfg &&
> + ((local->oper_channel != local->hw.conf.channel) ||
> + (local->_oper_channel_type != local->hw.conf.channel_type)))
> return false;
>
> return true;
> diff --git a/net/mac80211/scan.c b/net/mac80211/scan.c
> index 397343a..d1b6b29 100644
> --- a/net/mac80211/scan.c
> +++ b/net/mac80211/scan.c
> @@ -216,7 +216,7 @@ ieee80211_scan_rx(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb)
> * current channel, pass the pkt on up the stack so that
> * the rest of the stack can make use of it.
> */
> - if (ieee80211_cfg_on_oper_channel(sdata->local)
> + if (ieee80211_cfg_on_oper_channel(sdata->local, true)
> && (channel == sdata->local->oper_channel))
> return RX_CONTINUE;
>
> @@ -297,7 +297,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted,
> local->scanning = 0;
> local->scan_channel = NULL;
>
> - on_oper_chan = ieee80211_cfg_on_oper_channel(local);
> + on_oper_chan = ieee80211_cfg_on_oper_channel(local, true);
>
> if (was_hw_scan || !on_oper_chan)
> ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
> @@ -309,7 +309,7 @@ static void __ieee80211_scan_completed(struct ieee80211_hw *hw, bool aborted,
> bool on_oper_chan2;
> ieee80211_configure_filter(local);
> drv_sw_scan_complete(local);
> - on_oper_chan2 = ieee80211_cfg_on_oper_channel(local);
> + on_oper_chan2 = ieee80211_cfg_on_oper_channel(local, true);
> /* We should always be on-channel at this point. */
> WARN_ON(!on_oper_chan2);
> if (on_oper_chan2 && (on_oper_chan != on_oper_chan2))
> @@ -509,7 +509,7 @@ static void ieee80211_scan_state_decision(struct ieee80211_local *local,
>
> next_chan = local->scan_req->channels[local->scan_channel_idx];
>
> - if (ieee80211_cfg_on_oper_channel(local)) {
> + if (ieee80211_cfg_on_oper_channel(local, true)) {
> /* We're currently on operating channel. */
> if (next_chan == local->oper_channel)
> /* We don't need to move off of operating channel. */
> @@ -587,7 +587,7 @@ static void ieee80211_scan_state_enter_oper_channel(struct ieee80211_local *loca
> {
> /* switch back to the operating channel */
> local->scan_channel = NULL;
> - if (!ieee80211_cfg_on_oper_channel(local))
> + if (!ieee80211_cfg_on_oper_channel(local, true))
> ieee80211_hw_config(local, IEEE80211_CONF_CHANGE_CHANNEL);
>
> /*
> diff --git a/net/mac80211/work.c b/net/mac80211/work.c
> index bf5be22..62a3357 100644
> --- a/net/mac80211/work.c
> +++ b/net/mac80211/work.c
> @@ -973,7 +973,8 @@ static void ieee80211_work_work(struct work_struct *work)
> bool tmp_chan_changed = false;
> bool on_oper_chan2;
> enum nl80211_channel_type wk_ct;
> - on_oper_chan = ieee80211_cfg_on_oper_channel(local);
> + on_oper_chan = ieee80211_cfg_on_oper_channel(local,
> + true);
>
> /* Work with existing channel type if possible. */
> wk_ct = wk->chan_type;
> @@ -993,7 +994,8 @@ static void ieee80211_work_work(struct work_struct *work)
> * happen to be on the same channel as
> * the requested channel.
> */
> - on_oper_chan2 = ieee80211_cfg_on_oper_channel(local);
> + on_oper_chan2 = ieee80211_cfg_on_oper_channel(local,
> + true);
> if (on_oper_chan != on_oper_chan2) {
> if (on_oper_chan2) {
> /* going off oper channel, PS too */
> @@ -1091,7 +1093,7 @@ static void ieee80211_work_work(struct work_struct *work)
> }
>
> if (!remain_off_channel && local->tmp_channel) {
> - bool on_oper_chan = ieee80211_cfg_on_oper_channel(local);
> + bool on_oper_chan = ieee80211_cfg_on_oper_channel(local, true);
> local->tmp_channel = NULL;
> /* If tmp_channel wasn't operating channel, then
> * we need to go back on-channel.
> @@ -1101,7 +1103,8 @@ static void ieee80211_work_work(struct work_struct *work)
> * we still need to do a hardware config. Currently,
> * we cannot be here while scanning, however.
> */
> - if (ieee80211_cfg_on_oper_channel(local) && !on_oper_chan)
> + if (ieee80211_cfg_on_oper_channel(local, false) &&
> + !on_oper_chan)
> ieee80211_hw_config(local, 0);
>
> /* At the least, we need to disable offchannel_ps,
> --
> 1.7.3.4
>
> --
> 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: ath5k: controlling powersave with iw or iwconfig fails
From: Bob Copeland @ 2011-10-20 14:29 UTC (permalink / raw)
To: Mohammed Shafi
Cc: sedat.dilek, Joerg Pommnitz, linux-wireless@vger.kernel.org,
ath5k-users@lists.ath5k.org
In-Reply-To: <CAD2nsn3zkAgCf=_Y1CUt0X1qw7py4oEJ5sqaod_KYJxo68G1nQ@mail.gmail.com>
On Thu, Oct 20, 2011 at 7:46 AM, Mohammed Shafi
<shafi.wireless@gmail.com> wrote:
> On Thu, Oct 20, 2011 at 5:03 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
>> Which iw version?
>
> looks like its ath5k does not supports station power save.
Yes, that is the reason.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [ath5k-devel] Support for Linux WiFi stack (+wpa_supplicant) in Android
From: Bob Copeland @ 2011-10-20 14:24 UTC (permalink / raw)
To: Dani Camps; +Cc: linux-wireless
In-Reply-To: <1319092629.45912.YahooMailNeo@web29720.mail.ird.yahoo.com>
[trimmed CC because none of the mailing lists are the proper place for
this query, and added l-w back]
On Thu, Oct 20, 2011 at 2:37 AM, Dani Camps <danicamps81@yahoo.com> wrote:
> Dear all,
> I would like to ask whether there is support for the Linux Wi-Fi stack (+
> wpa_supplicant) in Android. In http://bobcopeland.com/android_wifi.html it
> is mentioned that the first Android developer phone uses a driver from TI
> that is GPLd and included within mac80211 (wl12xx).
This is not what my (dated) webpage says -- it says that it is
possible to use wl12xx *instead* of the vendor driver with Android.
Have a look at the AOSP code to know for yourself which drivers
Android uses. Source for drivers is generally available but last time
I looked (and it was quite a while ago) the two main drivers, TI and
broadcom, used their own WEXT ioctls and not cfg80211 etc. Maybe this
has changed since, I don't know.
> PS: Apologies if this is not the best mailing list for this topic, but
> linux-wireless was returning my emails
Try disabling HTML email.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: wwguy @ 2011-10-20 14:10 UTC (permalink / raw)
To: Norbert Preining
Cc: David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <20111020045927.GB23044@gamma.logic.tuwien.ac.at>
Hi Norbert,
On Wed, 2011-10-19 at 21:59 -0700, Norbert Preining wrote:
> Hi Wey,
>
> so I am now at the university, and it seems your last patch
> did wonder. Here a log after waking up from suspend at university...
>
Great, this is just a test patch, we will figure out what is the correct
way to handle this and fix the issue for good :-)
Thanks
Wey
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-20 13:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319118625.3959.16.camel@jlt3.sipsolutions.net>
> Just "iw wlan0 scan" output or so. Basically I just want the BSSID/freq
> to see which APs are on which band.
Ok, no prob, do it Wed.
Bye
N
^ permalink raw reply
* Commanding sleep/awake from mac80211
From: Andrés García Saavedra @ 2011-10-20 13:52 UTC (permalink / raw)
To: linux-wireless
Hi all,
I am testing a custom algorithm whereby I'd like to adaptively command
a STA to sleep/awake. Of course I would like to do so in the higher
level possible (for simplicity). The following is a sort of a summary
of my conclusions on the "state-of-art" on the implementation of such
a thing. I would like to ask you whether i am totally misleaded here.
Thanks in advance!
* mac80211: I can see in mac80211 that the function
ap_sta_ps_start/end() is defined to notify drivers of such transitions
using drv_sta_notify(STA_NOTIFY_AWAKE/SLEEP) callback. This looked
promising but... reading ath5k/ath9k/b43 driver codes, the atheros
ones do not implement these notification handlers at all, and b43 does
not do anything important eventually with them.
So, my guess is that actually the drivers themselves are the ones in
commanding the powersaving mode transitions awake/sleep regardless of
what mac80211 "could say".
* ath5k: seems to not command HW to sleep ever. (Only implemented the
"hw on hold" which is not used within ath5k).
* ath9k: Indeed it schedules sleep/awake timers. This way, it is
ath9k decision regardless what mac80211 say.
* b43: seems to not command HW to sleep ever...
Again, I'd appreciate if someone would point me out whether my
conclusions are correct.
Thanks!
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Johannes Berg @ 2011-10-20 13:50 UTC (permalink / raw)
To: Norbert Preining
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <56FBBFB3-4DC9-4CB6-939A-8F0130EBCB9B@logic.at>
On Thu, 2011-10-20 at 22:45 +0900, Norbert Preining wrote:
> Hi Johannes,
>
> > did you have scan information for these APs?
>
> Unfortunately not, but I can get them when I am back on Wednesday, if you want.
>
> Just let me know what exactely.
Just "iw wlan0 scan" output or so. Basically I just want the BSSID/freq
to see which APs are on which band.
johannes
^ permalink raw reply
* Re: iwlagn is getting very shaky
From: Norbert Preining @ 2011-10-20 13:45 UTC (permalink / raw)
To: Johannes Berg
Cc: Guy, Wey-Yi, David Rientjes, linux-kernel@vger.kernel.org,
ipw3945-devel@lists.sourceforge.net, ilw@linux.intel.com,
linux-wireless@vger.kernel.org, Pekka Enberg
In-Reply-To: <1319096418.3959.1.camel@jlt3.sipsolutions.net>
Hi Johannes,
> did you have scan information for these APs?
Unfortunately not, but I can get them when I am back on Wednesday, if you want.
Just let me know what exactely.
Best wishes
Norbert
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: Larry Finger @ 2011-10-20 13:35 UTC (permalink / raw)
To: v4mp; +Cc: linux-wireless
In-Reply-To: <loom.20111020T114336-286@post.gmane.org>
On 10/20/2011 04:47 AM, v4mp wrote:
>
>
> i'm sorry but i don't know how to recompile kernel to apply this patch,
> i'm using the 3.1.oneric.rc9 for ubuntu precompiled
> can u recompile it with this patch,
> and then send me the compiled kernel to install?
I do not use Ubuntu, thus I cannot compile the kernel for you.
Larry
^ permalink raw reply
* Re: ath5k: controlling powersave with iw or iwconfig fails
From: Mohammed Shafi @ 2011-10-20 11:46 UTC (permalink / raw)
To: sedat.dilek
Cc: Joerg Pommnitz, linux-wireless@vger.kernel.org,
ath5k-users@lists.ath5k.org
In-Reply-To: <CA+icZUXyYSVUA-PTCQB7z167iLAnh83DEJxOGoYB4qxaFkTZog@mail.gmail.com>
On Thu, Oct 20, 2011 at 5:03 PM, Sedat Dilek <sedat.dilek@googlemail.com> wrote:
> Which iw version?
looks like its ath5k does not supports station power save.
>
> - Sedat -
>
> On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
>> Hello all,
>> trying to disable PS on ath5k (Linux 3.0) gives:
>>
>> iw dev wlan0 set power_save off
>> command failed: Operation not supported (-95)
>>
>>
>> Is there any special magic required to disable power saving?
>> It seems to interfere with our amplifier...
>>
>>
>> --
>> Regards
>> Joerg
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
shafi
^ permalink raw reply
* Re: ath5k: controlling powersave with iw or iwconfig fails
From: Joerg Pommnitz @ 2011-10-20 11:46 UTC (permalink / raw)
To: sedat.dilek@gmail.com
Cc: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
In-Reply-To: <CA+icZUXyYSVUA-PTCQB7z167iLAnh83DEJxOGoYB4qxaFkTZog@mail.gmail.com>
iw is 0.9.22, but I just found part of the answer myself. Controlling PS in
IBSS mode is not supported (I failed to mention the IBSS part in my previous
mail).
Question: Is any power saving going on in IBSS mode at all? I'm seeing lots
of Probe-Requests that I thought were related to PS.
--
Regards
Joerg
----- Ursprüngliche Message -----
> Von: Sedat Dilek <sedat.dilek@googlemail.com>
> An: Joerg Pommnitz <pommnitz@yahoo.com>
> Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>; "ath5k-users@lists.ath5k.org" <ath5k-users@lists.ath5k.org>
> Gesendet: 13:33 Donnerstag, 20.Oktober 2011
> Betreff: Re: ath5k: controlling powersave with iw or iwconfig fails
>
> Which iw version?
>
> - Sedat -
>
> On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com>
> wrote:
>> Hello all,
>> trying to disable PS on ath5k (Linux 3.0) gives:
>>
>> iw dev wlan0 set power_save off
>> command failed: Operation not supported (-95)
>>
>>
>> Is there any special magic required to disable power saving?
>> It seems to interfere with our amplifier...
>>
>>
>> --
>> Regards
>> Joerg
>>
>> --
>> 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: ath5k: controlling powersave with iw or iwconfig fails
From: Sedat Dilek @ 2011-10-20 11:33 UTC (permalink / raw)
To: Joerg Pommnitz
Cc: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
In-Reply-To: <1319109568.26974.YahooMailNeo@web161206.mail.bf1.yahoo.com>
Which iw version?
- Sedat -
On Thu, Oct 20, 2011 at 1:19 PM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
> Hello all,
> trying to disable PS on ath5k (Linux 3.0) gives:
>
> iw dev wlan0 set power_save off
> command failed: Operation not supported (-95)
>
>
> Is there any special magic required to disable power saving?
> It seems to interfere with our amplifier...
>
>
> --
> Regards
> Joerg
>
> --
> 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
* ath5k: controlling powersave with iw or iwconfig fails
From: Joerg Pommnitz @ 2011-10-20 11:19 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org, ath5k-users@lists.ath5k.org
Hello all,
trying to disable PS on ath5k (Linux 3.0) gives:
iw dev wlan0 set power_save off
command failed: Operation not supported (-95)
Is there any special magic required to disable power saving?
It seems to interfere with our amplifier...
--
Regards
Joerg
^ permalink raw reply
* Re: Available nl80211 multicast groups
From: Johannes Berg @ 2011-10-20 11:22 UTC (permalink / raw)
To: André Prata; +Cc: linux-wireless
In-Reply-To: <CAGEq-jBnU4gmb+A7ox3O0vwSr0HFkccEqBydH5cqNChZ_hTkDQ@mail.gmail.com>
On Wed, 2011-10-19 at 20:30 +0100, André Prata wrote:
> Hi!
>
> I saw on your code that you resolve the multicas id of several groups
> for the nl80211 family /online/, like "scan" and "mlme". I'd like to
> know if there are defined constants for those IDs (i'm guessing
> they're not).
There's no list it seems -- you'll have to look at nl80211.c.
> Also I wanted to know what other groups exist and what messages I
> should expect from them (no docs, or my bad search skills?).
> Is there a multicast group to get reports on link quality changes, or
> similar, or is that only available through polling?
You can subscribe to such changes though I think only one application
can do that right now and wpa_s will do it.
johannes
^ permalink raw reply
* Re: [PATCH 5/6] mac80211: add WMM IE to mesh frames
From: Johannes Berg @ 2011-10-20 11:16 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, anagar6, devel, linville
In-Reply-To: <1319072606-28291-6-git-send-email-thomas@cozybit.com>
On Wed, 2011-10-19 at 18:03 -0700, Thomas Pedersen wrote:
> Include the WMM IE in mesh peering and beacon frames. This is needed
> tell any potential peers what our WMM / EDCA parameters are.
The goal seems fine but why bother building the WMM IE out of the actual
TX queue configuration? Shouldn't it normally be the other way around?
But I have no idea how QoS is supposed to work in a mesh...
johannes
^ permalink raw reply
* Re: [PATCH 2/3] mac80211: find correct IE offset in mesh beacons
From: Johannes Berg @ 2011-10-20 11:13 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, linville
In-Reply-To: <1319070203-22097-2-git-send-email-thomas@cozybit.com>
> - baselen = (u8 *) mgmt->u.probe_resp.variable - (u8 *) mgmt;
> + switch (stype) {
> + case IEEE80211_STYPE_PROBE_RESP:
> + ies = (u8 *) mgmt->u.probe_resp.variable;
> + break;
> + case IEEE80211_STYPE_BEACON:
> + ies = (u8 *) mgmt->u.beacon.variable;
> + break;
> + default:
> + return;
> + }
> +
Does that really make sense? the offset is the same anyway and we don't
get here with other frames.
johannes
^ permalink raw reply
* Re: Alfa AWUS036NHR with RTL8188RU chipset
From: v4mp @ 2011-10-20 9:47 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4E9F97B4.5010304@lwfinger.net>
i'm sorry but i don't know how to recompile kernel to apply this patch,
i'm using the 3.1.oneric.rc9 for ubuntu precompiled
can u recompile it with this patch,
and then send me the compiled kernel to install?
^ permalink raw reply
* Re: [PATCH 4/6] mac80211: allow frame aggregation for mesh
From: Christian Lamparter @ 2011-10-20 9:46 UTC (permalink / raw)
To: Thomas Pedersen; +Cc: linux-wireless, anagar6, devel, johannes, linville
In-Reply-To: <1319072606-28291-5-git-send-email-thomas@cozybit.com>
On Thursday, October 20, 2011 03:03:24 AM Thomas Pedersen wrote:
> Signed-off-by: Thomas Pedersen <thomas@cozybit.com>
> Signed-off-by: Ashok Nagarajan <anagar6@uic.edu>
> ---
> net/mac80211/agg-rx.c | 3 ++-
> net/mac80211/agg-tx.c | 4 +++-
> net/mac80211/ht.c | 3 ++-
> net/mac80211/rx.c | 1 +
> 4 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c
> index 2ac0339..36c2836 100644
> --- a/net/mac80211/agg-tx.c
> +++ b/net/mac80211/agg-tx.c
> @@ -378,6 +379,7 @@ int ieee80211_start_tx_ba_session(struct ieee80211_sta *pubsta, u16 tid,
> * by drivers or the standard.
> */
> if (sdata->vif.type != NL80211_IFTYPE_STATION &&
> + sdata->vif.type != NL80211_IFTYPE_MESH_POINT &&
> sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
> sdata->vif.type != NL80211_IFTYPE_AP)
> return -EINVAL;
just a nitpick, but it looks like the comment in agg-tx.c
seems to be a little out of date. Hence, would you mind
removing it as well?
/*
* The aggregation code is not prepared to handle
* anything but STA/AP due to the BSSID handling.
* IBSS could work in the code but isn't supported
* by drivers or the standard.
*/
if (sdata->vif.type != NL80211_IFTYPE_STATION &&
sdata->vif.type != NL80211_IFTYPE_AP_VLAN &&
sdata->vif.type != NL80211_IFTYPE_AP)
return -EINVAL;
Regards,
Chr
^ 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