* Re: pull-request: mac80211 2013-05-27
From: John W. Linville @ 2013-05-28 17:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1369646928.8229.24.camel@jlt4.sipsolutions.net>
On Mon, May 27, 2013 at 11:28:48AM +0200, Johannes Berg wrote:
> Hi John,
>
> Another pull request for 3.10 with a number of fixes.
>
> This time I have a fix from Stanislaw for a stupid mistake I made in the
> auth/assoc timeout changes, a fix from Felix for 64-bit traffic counters
> and one from Helmut for address mask handling in mac80211. I also have a
> few fixes myself for four different crashes reported by a few people.
>
> Please let me know if there are any issues.
>
> johannes
>
>
> The following changes since commit e248ad30204eff6559b4d2d94d49d9d46c08185a:
>
> cfg80211: fix sending WoWLAN TCP wakeup settings (2013-05-16 22:38:09 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git for-john
>
> for you to fetch changes up to ac20976dcaeea3e77e40e9aac8f3799d2a22ea2b:
>
> mac80211: Allow single vif mac address change with addr_mask (2013-05-27 11:26:48 +0200)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull-request: iwlwifi-fixes 2013-05-27
From: John W. Linville @ 2013-05-28 17:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1369647404.8229.26.camel@jlt4.sipsolutions.net>
On Mon, May 27, 2013 at 11:36:44AM +0200, Johannes Berg wrote:
> John,
>
> And here's a pull request for iwlwifi-fixes ...
>
> This fixes a brown paper-bag bug that we really should've caught in
> review. More details in the changelog for the fix.
>
> johannes
>
>
> The following changes since commit e3d4bc8cc0230e8dc8033484666f03f87392a8c4:
>
> iwlwifi: mvm: fix aggregation drain flow (2013-05-16 22:39:07 +0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git for-john
>
> for you to fetch changes up to a87783699b23395c46bbeeb5d28f6db24897bf26:
>
> iwlwifi: dvm: fix zero LQ CMD sending avoidance (2013-05-27 11:33:57 +0200)
Pulling now...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] ath9k_hw: fix PA predistortion miscalibration
From: Dan Williams @ 2013-05-28 17:37 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, linville, mcgrof, felixb
In-Reply-To: <1369757084-50141-1-git-send-email-nbd@openwrt.org>
On Tue, 2013-05-28 at 18:04 +0200, Felix Fietkau wrote:
> If any bins from the training data are skipped (i != max_index), the
> calculated compensation curve gets distorted, and the signal will be
> wildly overamplified. This may be the cause of the reported hardware
> damage that was caused by PA predistortion (because of which PAPRD was
> disabled by default).
>
> When calculating the x_est, Y, theta values, the use of max_index and i
> was reversed. i points to the bin index whereas max_index refers to the
> index of the calculated arrays.
Maybe add a comment in the code about the meaning of max_index and i, if
there isn't one already?
Dan
> Note that PA predistortion is still disabled, it will be re-enabled
> after it has been properly validated.
>
> Signed-off-by: Felix Fietkau <nbd@openwrt.org>
> ---
> drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
> index 09c1f9d..6343cc9 100644
> --- a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
> +++ b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
> @@ -454,6 +454,8 @@ static bool create_pa_curve(u32 *data_L, u32 *data_U, u32 *pa_table, u16 *gain)
> if (accum_cnt <= thresh_accum_cnt)
> continue;
>
> + max_index++;
> +
> /* sum(tx amplitude) */
> accum_tx = ((data_L[i] >> 16) & 0xffff) |
> ((data_U[i] & 0x7ff) << 16);
> @@ -468,20 +470,21 @@ static bool create_pa_curve(u32 *data_L, u32 *data_U, u32 *pa_table, u16 *gain)
>
> accum_tx <<= scale_factor;
> accum_rx <<= scale_factor;
> - x_est[i + 1] = (((accum_tx + accum_cnt) / accum_cnt) + 32) >>
> - scale_factor;
> + x_est[max_index] =
> + (((accum_tx + accum_cnt) / accum_cnt) + 32) >>
> + scale_factor;
>
> - Y[i + 1] = ((((accum_rx + accum_cnt) / accum_cnt) + 32) >>
> + Y[max_index] =
> + ((((accum_rx + accum_cnt) / accum_cnt) + 32) >>
> scale_factor) +
> - (1 << scale_factor) * max_index + 16;
> + (1 << scale_factor) * i + 16;
>
> if (accum_ang >= (1 << 26))
> accum_ang -= 1 << 27;
>
> - theta[i + 1] = ((accum_ang * (1 << scale_factor)) + accum_cnt) /
> - accum_cnt;
> -
> - max_index++;
> + theta[max_index] =
> + ((accum_ang * (1 << scale_factor)) + accum_cnt) /
> + accum_cnt;
> }
>
> /*
^ permalink raw reply
* Re: [RFC 06/12] mac80211: notify bridge when leaving mesh
From: Thomas Pedersen @ 2013-05-28 17:01 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wirelss, Bob Copeland, open80211s
In-Reply-To: <1369427550.13623.3.camel@johannes>
On Fri, May 24, 2013 at 1:32 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2013-05-21 at 18:09 -0700, Thomas Pedersen wrote:
>> Hey, Sorry for the late response.
>
> Me too :)
>
>> >> netif_carrier_off(sdata->dev);
>> >> + if (sdata->dev->priv_flags & IFF_BRIDGE_PORT)
>> >> + /* stop bridge transmissions */
>> >> + call_netdevice_notifiers(NETDEV_CHANGE, sdata->dev);
>> >
>> > Err, this seems like a really bad hack? I don't really think drivers
>> > should call that?
>>
>> Why not? We're just notifying the bridge interface that this port has
>> gone down, to avoid dereferencing a null pointer (on bridge flood
>> traffic) after the mesh_bss has been removed.
>>
>> Is cfg80211_leave_mesh() an acceptable location for this fix?
>
> I'm not really convinced it's an acceptable fix in itself? Why should we
> ever have to call netdev notifiers, that seems odd to me. Also why would
> that prevent a crash? Wouldn't we just drop packets for the mesh if we
> aren't joined in a mesh any more? Or something like that Accessing the
> priv flags and then calling the netdev notifiers seems really strange to
> me. If this was necessary, then wouldn't netif_carrier_off() do it
> internally?
OK I'll take a look at this and figure out a cleaner solution then. Thanks.
--
Thomas
^ permalink raw reply
* RE: [PATCH v2 2/2] cfg80211/nl80211: Add packet coalesce support
From: Amitkumar Karwar @ 2013-05-28 16:24 UTC (permalink / raw)
To: 'Johannes Berg', Bing Zhao
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho
In-Reply-To: <1369426955.8290.34.camel@jlt4.sipsolutions.net>
Hi Johannes,
>
> Some smallish things.
>
> > In most cases, host that receives IPv4 and IPv6 multicast/broadcast
> > packets does not do anything with these packets. Therefore the
> > reception of these unwanted packets causes unnecessary processing
> > and power consumption.
>
> This is curious, you already discard those that you don't care about by
> way of multicast filtering, no? What's the added advantage here? Would
> you coalesce interrupts for those packets that pass the filter(s)?
Yes. we don't want to simply discard those packets, because few of them may be useful for the host.
The advantage here is instead of getting random per packet receive interrupts, host receives multiple buffered packets with a single receive interrupt.
> But
> those packets are packets that the host cares about, no?
The assumption is filters are designed in such a way that specified delay in packet processing is acceptable for those packets.
>
> > /**
> > + * struct cfg80211_coalesce_rules - Coalesce rule parameters
> > + *
> > + * This structure defines coalesce rule for the device.
> > + * @delay: maximum coalescing delay in msecs.
> > + * @condition: condition for packet coalescence.
> > + * i.e. pattern 'match' or 'no match'
> > + * @patterns: array of packet patterns
> > + * @n_patterns: number of patterns
> > + */
> > +struct cfg80211_coalesce_rules {
> > + int delay;
> > + u8 condition;
>
> seems like "condition" should be of some enum type? presumably an
> nl80211 enum type that userspace can use?
Sure. We will add an enum for "condition".
>
> > + struct cfg80211_pkt_pattern *patterns;
>
> const?
This can not be a const. It points to an array of patterns. Runtime while adding new rule, buffer is allocated based on number of patterns configured by user and information is filled.
>
> > +struct cfg80211_coalesce {
> > + struct cfg80211_coalesce_rules **rules;
> > + int n_rules;
> > +};
>
> I think you can pass these as two function arguments rather than a
> separate struct.
This is our global structure for coalesce configuration. We just save it's pointer in rdev structure. It is allocated when user adds first coalesce rule. rdev->coalesce is NULL when user clears the setting.
>
> > @@ -3027,7 +3063,6 @@ enum nl80211_cqm_rssi_threshold_event {
> > NL80211_CQM_RSSI_BEACON_LOSS_EVENT,
> > };
> >
> > -
> > /**
> > * enum nl80211_tx_power_setting - TX power adjustment
> > * @NL80211_TX_POWER_AUTOMATIC: automatically determine transmit power
>
> seems spurious :)
Ok. We will revert the change.
>
> > * This struct is carried in %NL80211_WOWLAN_TRIG_PKT_PATTERN when
> > - * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED in the
> > - * capability information given by the kernel to userspace.
> > + * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED or in
> > + * %NL80211_ATTR_COALESCE_RULE_PKT_PATTERN when that is part of
> > + * %NL80211_ATTR_COALESCE_RULE in the capability information given
> > + * by the kernel to userspace.
>
> Ah, I think here you're updating what I asked about before.
>
> > + * @NL80211_ATTR_COALESCE_RULE_CONDITION: condition for packet
> coalescence.
> > + * i.e. pattern 'match' or 'no match'
>
> I'm sure the condition attribute isn't a string, so this should say
> which enum to take the value from?
Sure. We will update the description using newly added enum for "condition".
>
> > + * @NL80211_FEATURE_PACKET_COALESCE: This driver support packet
> coalescing
> > + * feature. Packets are buffered in firmware based on configured rules
> > + * to reduce unwanted packet or interrupt to host.
>
> I don't think you need this, since you have this:
>
> > + struct wiphy_coalesce_support coalesce;
We will get rid of this flag.
>
> Actually, you should probably make that a pointer, then it can be NULL
> for drivers not supporting it, and static const for those that do. Means
> you should make it a const pointer, of course.
>
> Userspace can tell by checking if the support is advertised.
We will use following condition to check if driver is not supporting the feature. (wowlan code does the same thing)
"if (!dev->wiphy.coalesce.n_patterns || !dev->wiphy.coalesce.n_rules)"
>
>
> > +static inline void
> > +cfg80211_rdev_free_coalesce(struct cfg80211_registered_device *rdev)
>
> That's fairly big, would prefer not to inline it.
Ack, thanks.
>
> > +static int nl80211_set_coalesce(struct sk_buff *skb, struct genl_info
> *info)
> > +{
> > + struct cfg80211_registered_device *rdev = info->user_ptr[0];
> > + struct nlattr *tb[NUM_NL80211_ATTR_COALESCE_RULE];
> > + struct wiphy_coalesce_support *coalesce = &rdev->wiphy.coalesce;
> > + struct cfg80211_coalesce_rules new_rule = {};
> > + struct cfg80211_coalesce_rules *nrule;
> > + int err, i;
> > +
> > + if (!(rdev->wiphy.features & NL80211_FEATURE_PACKET_COALESCE))
> > + return -EOPNOTSUPP;
>
> Then this should check the coalesce pointer of course, which can then be
> NULL.
>
> > + if (!rdev->coalesce) {
> > + rdev->coalesce = kzalloc(sizeof(*rdev->coalesce), GFP_KERNEL);
> > + rdev->coalesce->rules = kcalloc(coalesce->n_rules,
> > + sizeof(void *), GFP_KERNEL);
> > + }
> > +
> > + if (rdev->coalesce->n_rules >= coalesce->n_rules)
> > + return -EOPNOTSUPP;
>
> This is bad. You leave rdev->coalesce assigned, but it's completely
> invalid data. IMHO you should use a temporary variable and only assign
> it when it's fully parsed, freeing it if not. That way, you also don't
> kill old values when new invalid values are parsed.
"iw coalesce add" command adds one coalesce rule at a time. "iw coalesce disable" command removes all configured rules.
"rdev->coalesce" will be created while adding first rule. "if (!rdev->coalesce)" condition will be false for further rules.
"if (rdev->coalesce->n_rules >= coalesce->n_rules)" condition becomes true when number of configured rules becomes equal to number of supported rules advertised by the driver. So we can't accommodate new rule in this case.
Therefore we don't leave rdev->coalesce assigned with invalid data.
We are already using 'new_rule' as a temporary variable for storing new rule information and freeing it in failure cases (similar to wowlan code).
>
> > + new_rule.delay = nla_get_u32(tb[NL80211_ATTR_COALESCE_RULE_DELAY]);
> > + new_rule.condition =
> > + nla_get_u8(tb[NL80211_ATTR_COALESCE_RULE_CONDITION]);
>
> Needs sanity checking, what if userspace passes the value 17? Does that
> mean anything? :)
Ack. We will add sanity check to allow only valid enum values.
>
> > + nla_for_each_nested(pat,
> > + tb[NL80211_ATTR_COALESCE_RULE_PKT_PATTERN],
> > + rem) {
> > + nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
> > + nla_len(pat), NULL);
> > + err = -EINVAL;
> > + if (!pat_tb[NL80211_PKTPAT_MASK] ||
> > + !pat_tb[NL80211_PKTPAT_PATTERN])
> > + goto error;
> > + pat_len = nla_len(pat_tb[NL80211_PKTPAT_PATTERN]);
> > + mask_len = DIV_ROUND_UP(pat_len, 8);
> > + if (nla_len(pat_tb[NL80211_PKTPAT_MASK]) !=
> > + mask_len)
> > + goto error;
> > + if (pat_len > coalesce->pattern_max_len ||
> > + pat_len < coalesce->pattern_min_len)
> > + goto error;
>
> I wonder if any of this could be refactored with WoWLAN? Not really sure
> though, maybe not.
Refactoring is little difficult here. We need to define new structure for pattern specific support variables (n_patterns, pattern_max_len, pattern_min_len, max_pkt_offset) which can be passed to a common routine created after refactoring. This will affect readability at many other places due to following replacements.
wiphy.wowlan.pattern_min_len -> wiphy.wowlan.pattern.pattern_min_len
wiphy.coalesce.pattern_min_len -> wiphy.coalesce.pattern.pattern_min_len
and so on.
>
> > + err = rdev->ops->set_coalesce(&rdev->wiphy, nrule);
> > + if (err)
> > + goto error;
> > +
> > + rdev->coalesce->rules[rdev->coalesce->n_rules++] = nrule;
>
> Wait ... you can't delete old rules, only add new ones? I think I'm
> confused, I thought the SET command was going to overwrite all old
> rules?
SET command either adds new coalesce rule or removes all existing rules.
Corresponding iw commands are 'add' and 'disable'
Please let me know if you want any specific modifications in the code/logic.
Thanks,
Amitkumar Karwar
>
> johannes
^ permalink raw reply
* RE: [PATCH v2 1/2] cfg80211/nl80211: rename packet pattern related structures and enums
From: Amitkumar Karwar @ 2013-05-28 16:21 UTC (permalink / raw)
To: 'Johannes Berg', Bing Zhao
Cc: linux-wireless@vger.kernel.org, Luis R. Rodriguez, Jouni Malinen,
Vasanthakumar Thiagarajan, Senthil Balasubramanian,
Luciano Coelho
In-Reply-To: <1369426217.8290.22.camel@jlt4.sipsolutions.net>
Hi Johannes,
Thanks for your comments.
>
> > -enum nl80211_wowlan_packet_pattern_attr {
>
> I think you missed a #define for this?
It's not used anywhere in iw or kernel code.
>
> > +/* only for backward compatibility */
> > +#define __NL80211_WOWLAN_PKTPAT_INVALID __NL80211_INVALID,
>
> that , at the end looks like a copy/paste error, but in fact shouldn't
> it be "__NL80211_PKTPAT_INVALID" anyway?
Thanks for pointing this out. We will correct it in updated version.
>
>
> > * that is part of %NL80211_ATTR_WOWLAN_TRIGGERS_SUPPORTED in the
> > * capability information given by the kernel to userspace.
>
> Should this be updated?
It has been updated after adding coalesce support in 2/2 patch.
Thanks,
Amitkumar Karwar
>
> johannes
^ permalink raw reply
* [PATCH] ath9k_hw: fix PA predistortion miscalibration
From: Felix Fietkau @ 2013-05-28 16:04 UTC (permalink / raw)
To: linux-wireless; +Cc: linville, mcgrof, felixb
If any bins from the training data are skipped (i != max_index), the
calculated compensation curve gets distorted, and the signal will be
wildly overamplified. This may be the cause of the reported hardware
damage that was caused by PA predistortion (because of which PAPRD was
disabled by default).
When calculating the x_est, Y, theta values, the use of max_index and i
was reversed. i points to the bin index whereas max_index refers to the
index of the calculated arrays.
Note that PA predistortion is still disabled, it will be re-enabled
after it has been properly validated.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_paprd.c | 19 +++++++++++--------
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
index 09c1f9d..6343cc9 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
+++ b/drivers/net/wireless/ath/ath9k/ar9003_paprd.c
@@ -454,6 +454,8 @@ static bool create_pa_curve(u32 *data_L, u32 *data_U, u32 *pa_table, u16 *gain)
if (accum_cnt <= thresh_accum_cnt)
continue;
+ max_index++;
+
/* sum(tx amplitude) */
accum_tx = ((data_L[i] >> 16) & 0xffff) |
((data_U[i] & 0x7ff) << 16);
@@ -468,20 +470,21 @@ static bool create_pa_curve(u32 *data_L, u32 *data_U, u32 *pa_table, u16 *gain)
accum_tx <<= scale_factor;
accum_rx <<= scale_factor;
- x_est[i + 1] = (((accum_tx + accum_cnt) / accum_cnt) + 32) >>
- scale_factor;
+ x_est[max_index] =
+ (((accum_tx + accum_cnt) / accum_cnt) + 32) >>
+ scale_factor;
- Y[i + 1] = ((((accum_rx + accum_cnt) / accum_cnt) + 32) >>
+ Y[max_index] =
+ ((((accum_rx + accum_cnt) / accum_cnt) + 32) >>
scale_factor) +
- (1 << scale_factor) * max_index + 16;
+ (1 << scale_factor) * i + 16;
if (accum_ang >= (1 << 26))
accum_ang -= 1 << 27;
- theta[i + 1] = ((accum_ang * (1 << scale_factor)) + accum_cnt) /
- accum_cnt;
-
- max_index++;
+ theta[max_index] =
+ ((accum_ang * (1 << scale_factor)) + accum_cnt) /
+ accum_cnt;
}
/*
--
1.8.0.2
^ permalink raw reply related
* ath6kl_sdio blocked by RFKILL
From: Ulf Samuelsson @ 2013-05-28 15:01 UTC (permalink / raw)
To: linux-wireless; +Cc: ath6kl-devel
Have built the ath6kl_sdio driver for an Cortex-A5 chip using the
linux-3.6.9 kernel
File system built using Yocto and Busybox RF-Kill.
Kernel Config contains:
CONFIG_RFKILL=m
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_RFKILL_GPIO is not set
When I do
# ifconfig wlan0 up.
I get the error message:
ifconfig: SIOCSIFFLAGS: Operation not possible due to RF-kill
If I run "rfkill list" I get
1: phy1: wlan
Soft blocked: yes
Hard blocked: no
If I try to unblock using "rfkill unblock all" or "wifi" or "wlan", the
soft block remains.
Any clues?
Looking through the Busybox rfkill code, this seems to generate an event.
What is supposed to react to this?
Could there be a rule, which is missing?
BR
Ulf Samuelsson
^ permalink raw reply
* Re: iwlwifi dmar errors in 3.9.2
From: Johannes Berg @ 2013-05-28 14:25 UTC (permalink / raw)
To: Ilia Mirkin; +Cc: linux-wireless
In-Reply-To: <CAKb7Uvj5rr1CBxpas3kVKk7zdKDFs7+iVRVT7Q+Ob_mue6-_pQ@mail.gmail.com>
On Tue, 2013-05-28 at 09:59 -0400, Ilia Mirkin wrote:
> On Tue, May 28, 2013 at 7:43 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Mon, 2013-05-20 at 17:12 -0400, Ilia Mirkin wrote:
> >> Hello,
> >>
> >> I recently upgraded to 3.9.2 from 3.7.10, and have begun to see some
> >> DMAR errors in my log. Here are a bunch of them:
> >> http://pastebin.com/wgq0JW0S
> >
> > Was there anything in the log _before_ this? Like the device already
> > getting an error, or so?
>
> Nothing that I felt was relevant, but you be the judge:
> http://pastebin.com/s3rV3UK9
Indeed, nothing that seems relevant, particularly no device error or so.
That seems almost like this _causes_ the device error ... hmm. I feel
this is going to be a tricky bug, probably should buy a laptop with
DMAR ... :)
johannes
^ permalink raw reply
* Re: iwlwifi dmar errors in 3.9.2
From: Ilia Mirkin @ 2013-05-28 13:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1369741393.8548.0.camel@jlt4.sipsolutions.net>
On Tue, May 28, 2013 at 7:43 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2013-05-20 at 17:12 -0400, Ilia Mirkin wrote:
>> Hello,
>>
>> I recently upgraded to 3.9.2 from 3.7.10, and have begun to see some
>> DMAR errors in my log. Here are a bunch of them:
>> http://pastebin.com/wgq0JW0S
>
> Was there anything in the log _before_ this? Like the device already
> getting an error, or so?
Nothing that I felt was relevant, but you be the judge:
http://pastebin.com/s3rV3UK9
-ilia
^ permalink raw reply
* [PATCH for 3.10] ath9k: use correct OTP register offsets for AR9550
From: Gabor Juhos @ 2013-05-28 12:52 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless, ath9k-devel, Gabor Juhos, stable, #, 3.6+
Accessing the OTP memory on AR9950 causes a data bus
like this:
Data bus error, epc == 801f7774, ra == 801f7774
Oops[#1]:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0-rc3 #592
task: 87c28000 ti: 87c22000 task.ti: 87c22000
$ 0 : 00000000 00000061 deadc0de 00000000
$ 4 : b8115f18 00015f18 00000007 00000004
$ 8 : 00000001 7c7c3c7c 7c7c7c7c 7c7c7c7c
$12 : 7c7c3c7c 80320a68 00000000 7c7c7c3c
$16 : 87cd8010 00015f18 00000007 00000000
$20 : 00000064 00000004 87c23c7c 8035210c
$24 : 00000000 801f3674
$28 : 87c22000 87c23b48 00000001 801f7774
Hi : 00000000
Lo : 00000064
epc : 801f7774 ath9k_hw_wait+0x58/0xb0
Not tainted
ra : 801f7774 ath9k_hw_wait+0x58/0xb0
Status: 1000cc03 KERNEL EXL IE
Cause : 4080801c
PrId : 00019750 (MIPS 74Kc)
Modules linked in:
Process swapper (pid: 1, threadinfo=87c22000, task=87c28000, ts=00000000)
Stack : 0000000f 00000061 00002710 8006240c 00000001 87cd8010 87c23bb0 87cd8010
00000000 00000004 00000003 80210c7c 000000b3 67fa8000 0000032a 000006fe
000003e8 00000002 00000028 87c23bf0 000003ff 80210d24 803e5630 80210e28
00000000 00000007 87cd8010 00007044 00000004 00000061 000003ff 000001ff
87c26000 87cd8010 00000220 87cd8bb8 80210000 8020fcf4 87c22000 87c23c08
...
Call Trace:
[<801f7774>] ath9k_hw_wait+0x58/0xb0
[<80210c7c>] ar9300_otp_read_word+0x80/0xd4
[<80210d24>] ar9300_read_otp+0x54/0xb0
[<8020fcf4>] ar9300_check_eeprom_header+0x1c/0x40
[<80210fe4>] ath9k_hw_ar9300_fill_eeprom+0x118/0x39c
[<80206650>] ath9k_hw_eeprom_init+0x74/0xb4
[<801f96d0>] ath9k_hw_init+0x7ec/0x96c
[<801e65ec>] ath9k_init_device+0x340/0x758
[<801f35d0>] ath_ahb_probe+0x21c/0x2c0
[<801c041c>] driver_probe_device+0xc0/0x1e4
[<801c05ac>] __driver_attach+0x6c/0xa4
[<801bea08>] bus_for_each_dev+0x64/0xa8
[<801bfa40>] bus_add_driver+0xcc/0x24c
[<801c0954>] driver_register+0xbc/0x17c
[<803f8fc0>] ath9k_init+0x5c/0x88
[<800608fc>] do_one_initcall+0xec/0x1a0
[<803e6a68>] kernel_init_freeable+0x13c/0x200
[<80309cdc>] kernel_init+0x1c/0xe4
[<80062450>] ret_from_kernel_thread+0x10/0x18
On the AR9550, the OTP registers are located at
the same address as on the AR9340. Use the correct
values to avoid the error.
Cc: stable@vger.kernel.org # 3.6+
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
---
drivers/net/wireless/ath/ath9k/ar9003_eeprom.h | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
index 54ba42f..874f657 100644
--- a/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/ar9003_eeprom.h
@@ -68,13 +68,16 @@
#define AR9300_BASE_ADDR 0x3ff
#define AR9300_BASE_ADDR_512 0x1ff
-#define AR9300_OTP_BASE (AR_SREV_9340(ah) ? 0x30000 : 0x14000)
-#define AR9300_OTP_STATUS (AR_SREV_9340(ah) ? 0x30018 : 0x15f18)
+#define AR9300_OTP_BASE \
+ ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x30000 : 0x14000)
+#define AR9300_OTP_STATUS \
+ ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x30018 : 0x15f18)
#define AR9300_OTP_STATUS_TYPE 0x7
#define AR9300_OTP_STATUS_VALID 0x4
#define AR9300_OTP_STATUS_ACCESS_BUSY 0x2
#define AR9300_OTP_STATUS_SM_BUSY 0x1
-#define AR9300_OTP_READ_DATA (AR_SREV_9340(ah) ? 0x3001c : 0x15f1c)
+#define AR9300_OTP_READ_DATA \
+ ((AR_SREV_9340(ah) || AR_SREV_9550(ah)) ? 0x3001c : 0x15f1c)
enum targetPowerHTRates {
HT_TARGET_RATE_0_8_16,
--
1.7.10
^ permalink raw reply related
* Re: [PATCH v2 1/3] cfg80211: support an active monitor interface flag
From: Johannes Berg @ 2013-05-28 12:38 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <51A4A044.3030109@openwrt.org>
On Tue, 2013-05-28 at 14:17 +0200, Felix Fietkau wrote:
> On 2013-05-28 1:50 PM, Johannes Berg wrote:
> > On Tue, 2013-05-28 at 13:01 +0200, Felix Fietkau wrote:
> >> An active monitor interface is one that is used for communication (via
> >> injection). It is expected to ACK incoming unicast packets. This is
> >> useful for running various 802.11 testing utilities that associate to an
> >> AP via injection and manage the state in user space.
> >
> > Applied 1 and 2.
> >
> > Allowing MAC address duplication seems a bit strange, but I guess it
> > simplifies things for users?
> It is allowed only for non-active monitor interfaces, which previously
> did not use ieee80211_verify_mac and ignores the configured MAC address
> anyway.
Oh, that makes sense, I misread the code then.
johannes
^ permalink raw reply
* Re: [PATCH 0/2] wil6210: fix for wdev->sme_state
From: Johannes Berg @ 2013-05-28 12:28 UTC (permalink / raw)
To: Vladimir Kondratiev; +Cc: John W . Linville, linux-wireless, Luis R . Rodriguez
In-Reply-To: <1369743473-7243-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
On Tue, 2013-05-28 at 15:17 +0300, Vladimir Kondratiev wrote:
> Here goes patch that Johannes asked for, where wil6210 stop using
> wdev->sme_state. Also, included is small patch fixing wrong channel
> when starting AP
Thanks!
Also a fix for a wil_status_dontscan status bit leak, if wmi_send()
fails :-)
johannes
^ permalink raw reply
* [PATCH 2/2] wil6210: Don't use wdev->sme_state
From: Vladimir Kondratiev @ 2013-05-28 12:17 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1369743473-7243-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
sme_state is private wdev's variable.
Track connection state internally
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/cfg80211.c | 4 ++++
drivers/net/wireless/ath/wil6210/main.c | 17 ++++++-----------
drivers/net/wireless/ath/wil6210/wil6210.h | 1 +
drivers/net/wireless/ath/wil6210/wmi.c | 3 ++-
4 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/wil6210/cfg80211.c b/drivers/net/wireless/ath/wil6210/cfg80211.c
index c5d4a87..4eb05d0 100644
--- a/drivers/net/wireless/ath/wil6210/cfg80211.c
+++ b/drivers/net/wireless/ath/wil6210/cfg80211.c
@@ -322,12 +322,16 @@ static int wil_cfg80211_connect(struct wiphy *wiphy,
* FW don't support scan after connection attempt
*/
set_bit(wil_status_dontscan, &wil->status);
+ set_bit(wil_status_fwconnecting, &wil->status);
rc = wmi_send(wil, WMI_CONNECT_CMDID, &conn, sizeof(conn));
if (rc == 0) {
/* Connect can take lots of time */
mod_timer(&wil->connect_timer,
jiffies + msecs_to_jiffies(2000));
+ } else {
+ clear_bit(wil_status_dontscan, &wil->status);
+ clear_bit(wil_status_fwconnecting, &wil->status);
}
out:
diff --git a/drivers/net/wireless/ath/wil6210/main.c b/drivers/net/wireless/ath/wil6210/main.c
index ea49c8a..1d99c0e 100644
--- a/drivers/net/wireless/ath/wil6210/main.c
+++ b/drivers/net/wireless/ath/wil6210/main.c
@@ -61,22 +61,17 @@ static void _wil6210_disconnect(struct wil6210_priv *wil, void *bssid)
wil_dbg_misc(wil, "%s()\n", __func__);
wil_link_off(wil);
- clear_bit(wil_status_fwconnected, &wil->status);
-
- switch (wdev->sme_state) {
- case CFG80211_SME_CONNECTED:
- cfg80211_disconnected(ndev, WLAN_STATUS_UNSPECIFIED_FAILURE,
+ if (test_bit(wil_status_fwconnected, &wil->status)) {
+ clear_bit(wil_status_fwconnected, &wil->status);
+ cfg80211_disconnected(ndev,
+ WLAN_STATUS_UNSPECIFIED_FAILURE,
NULL, 0, GFP_KERNEL);
- break;
- case CFG80211_SME_CONNECTING:
+ } else if (test_bit(wil_status_fwconnecting, &wil->status)) {
cfg80211_connect_result(ndev, bssid, NULL, 0, NULL, 0,
WLAN_STATUS_UNSPECIFIED_FAILURE,
GFP_KERNEL);
- break;
- default:
- break;
}
-
+ clear_bit(wil_status_fwconnecting, &wil->status);
for (i = 0; i < ARRAY_SIZE(wil->vring_tx); i++)
wil_vring_fini_tx(wil, i);
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 2e3c26e..373cf65 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -186,6 +186,7 @@ struct vring {
enum { /* for wil6210_priv.status */
wil_status_fwready = 0,
+ wil_status_fwconnecting,
wil_status_fwconnected,
wil_status_dontscan,
wil_status_reset_done,
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index a091eb1..527ffb5 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -409,7 +409,7 @@ static void wmi_evt_connect(struct wil6210_priv *wil, int id, void *d, int len)
if ((wdev->iftype == NL80211_IFTYPE_STATION) ||
(wdev->iftype == NL80211_IFTYPE_P2P_CLIENT)) {
- if (wdev->sme_state != CFG80211_SME_CONNECTING) {
+ if (!test_bit(wil_status_fwconnecting, &wil->status)) {
wil_err(wil, "Not in connecting state\n");
return;
}
@@ -433,6 +433,7 @@ static void wmi_evt_connect(struct wil6210_priv *wil, int id, void *d, int len)
cfg80211_new_sta(ndev, evt->bssid, &sinfo, GFP_KERNEL);
}
+ clear_bit(wil_status_fwconnecting, &wil->status);
set_bit(wil_status_fwconnected, &wil->status);
/* FIXME FW can transmit only ucast frames to peer */
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] wil6210: channel off by 1
From: Vladimir Kondratiev @ 2013-05-28 12:17 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
In-Reply-To: <1369743473-7243-1-git-send-email-qca_vkondrat@qca.qualcomm.com>
WMI commands wants channel index, that is channel - 1
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
---
drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index 5e01f4e..a091eb1 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -728,7 +728,7 @@ int wmi_pcp_start(struct wil6210_priv *wil, int bi, u8 wmi_nettype, u8 chan)
.bcon_interval = cpu_to_le16(bi),
.network_type = wmi_nettype,
.disable_sec_offload = 1,
- .channel = chan,
+ .channel = chan - 1,
};
struct {
struct wil6210_mbox_hdr_wmi wmi;
--
1.8.1.2
^ permalink raw reply related
* [PATCH 0/2] wil6210: fix for wdev->sme_state
From: Vladimir Kondratiev @ 2013-05-28 12:17 UTC (permalink / raw)
To: John W . Linville
Cc: Vladimir Kondratiev, Johannes Berg, linux-wireless,
Luis R . Rodriguez
Here goes patch that Johannes asked for, where wil6210 stop using
wdev->sme_state. Also, included is small patch fixing wrong channel
when starting AP
Vladimir Kondratiev (2):
wil6210: channel off by 1
wil6210: Don't use wdev->sme_state
drivers/net/wireless/ath/wil6210/cfg80211.c | 4 ++++
drivers/net/wireless/ath/wil6210/main.c | 17 ++++++-----------
drivers/net/wireless/ath/wil6210/wil6210.h | 1 +
drivers/net/wireless/ath/wil6210/wmi.c | 5 +++--
4 files changed, 14 insertions(+), 13 deletions(-)
--
1.8.1.2
^ permalink raw reply
* Re: [PATCH v2 1/3] cfg80211: support an active monitor interface flag
From: Felix Fietkau @ 2013-05-28 12:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1369741810.8548.1.camel@jlt4.sipsolutions.net>
On 2013-05-28 1:50 PM, Johannes Berg wrote:
> On Tue, 2013-05-28 at 13:01 +0200, Felix Fietkau wrote:
>> An active monitor interface is one that is used for communication (via
>> injection). It is expected to ACK incoming unicast packets. This is
>> useful for running various 802.11 testing utilities that associate to an
>> AP via injection and manage the state in user space.
>
> Applied 1 and 2.
>
> Allowing MAC address duplication seems a bit strange, but I guess it
> simplifies things for users?
It is allowed only for non-active monitor interfaces, which previously
did not use ieee80211_verify_mac and ignores the configured MAC address
anyway.
- Felix
^ permalink raw reply
* Re: [PATCH v2 1/3] cfg80211: support an active monitor interface flag
From: Johannes Berg @ 2013-05-28 11:50 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless
In-Reply-To: <1369738914-34367-1-git-send-email-nbd@openwrt.org>
On Tue, 2013-05-28 at 13:01 +0200, Felix Fietkau wrote:
> An active monitor interface is one that is used for communication (via
> injection). It is expected to ACK incoming unicast packets. This is
> useful for running various 802.11 testing utilities that associate to an
> AP via injection and manage the state in user space.
Applied 1 and 2.
Allowing MAC address duplication seems a bit strange, but I guess it
simplifies things for users?
johannes
^ permalink raw reply
* Re: iwlwifi dmar errors in 3.9.2
From: Johannes Berg @ 2013-05-28 11:43 UTC (permalink / raw)
To: Ilia Mirkin; +Cc: linux-wireless
In-Reply-To: <CAKb7UvhBS6G=1Burf6MfekEnT5vhiy8BKijJ27Fpd=9yBDy9Ng@mail.gmail.com>
On Mon, 2013-05-20 at 17:12 -0400, Ilia Mirkin wrote:
> Hello,
>
> I recently upgraded to 3.9.2 from 3.7.10, and have begun to see some
> DMAR errors in my log. Here are a bunch of them:
> http://pastebin.com/wgq0JW0S
Was there anything in the log _before_ this? Like the device already
getting an error, or so?
johannes
^ permalink raw reply
* [PATCH v2 2/3] mac80211: support active monitor interfaces
From: Felix Fietkau @ 2013-05-28 11:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
In-Reply-To: <1369738914-34367-1-git-send-email-nbd@openwrt.org>
Support them only if the driver advertises support for them via
IEEE80211_HW_SUPPORTS_ACTIVE_MONITOR. Unlike normal monitor interfaces,
they are added to the driver, along with their MAC address.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
net/mac80211/cfg.c | 11 +++++++----
net/mac80211/driver-ops.h | 3 ++-
net/mac80211/iface.c | 29 +++++++++++++++++++++++------
net/mac80211/util.c | 6 ++++++
4 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 1a89c80..7f73859 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -73,16 +73,19 @@ static int ieee80211_change_iface(struct wiphy *wiphy,
struct ieee80211_local *local = sdata->local;
if (ieee80211_sdata_running(sdata)) {
+ u32 mask = MONITOR_FLAG_COOK_FRAMES |
+ MONITOR_FLAG_ACTIVE;
+
/*
- * Prohibit MONITOR_FLAG_COOK_FRAMES to be
- * changed while the interface is up.
+ * Prohibit MONITOR_FLAG_COOK_FRAMES and
+ * MONITOR_FLAG_ACTIVE to be changed while the
+ * interface is up.
* Else we would need to add a lot of cruft
* to update everything:
* cooked_mntrs, monitor and all fif_* counters
* reconfigure hardware
*/
- if ((*flags & MONITOR_FLAG_COOK_FRAMES) !=
- (sdata->u.mntr_flags & MONITOR_FLAG_COOK_FRAMES))
+ if ((*flags & mask) != (sdata->u.mntr_flags & mask))
return -EBUSY;
ieee80211_adjust_monitor_flags(sdata, -1);
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 169664c..b931c96 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -146,7 +146,8 @@ static inline int drv_add_interface(struct ieee80211_local *local,
if (WARN_ON(sdata->vif.type == NL80211_IFTYPE_AP_VLAN ||
(sdata->vif.type == NL80211_IFTYPE_MONITOR &&
- !(local->hw.flags & IEEE80211_HW_WANT_MONITOR_VIF))))
+ !(local->hw.flags & IEEE80211_HW_WANT_MONITOR_VIF) &&
+ !(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))))
return -EINVAL;
trace_drv_add_interface(local, sdata);
diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index 60f1ce5..47e03e5 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -159,7 +159,8 @@ static int ieee80211_change_mtu(struct net_device *dev, int new_mtu)
return 0;
}
-static int ieee80211_verify_mac(struct ieee80211_local *local, u8 *addr)
+static int ieee80211_verify_mac(struct ieee80211_local *local, u8 *addr,
+ bool check_dup)
{
struct ieee80211_sub_if_data *sdata;
u64 new, mask, tmp;
@@ -179,10 +180,13 @@ static int ieee80211_verify_mac(struct ieee80211_local *local, u8 *addr)
((u64)m[2] << 3*8) | ((u64)m[3] << 2*8) |
((u64)m[4] << 1*8) | ((u64)m[5] << 0*8);
+ if (!check_dup)
+ return ret;
mutex_lock(&local->iflist_mtx);
list_for_each_entry(sdata, &local->interfaces, list) {
- if (sdata->vif.type == NL80211_IFTYPE_MONITOR)
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
+ !(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
continue;
m = sdata->vif.addr;
@@ -204,12 +208,17 @@ static int ieee80211_change_mac(struct net_device *dev, void *addr)
{
struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
struct sockaddr *sa = addr;
+ bool check_dup = true;
int ret;
if (ieee80211_sdata_running(sdata))
return -EBUSY;
- ret = ieee80211_verify_mac(sdata->local, sa->sa_data);
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
+ !(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ check_dup = false;
+
+ ret = ieee80211_verify_mac(sdata->local, sa->sa_data, check_dup);
if (ret)
return ret;
@@ -538,7 +547,11 @@ int ieee80211_do_open(struct wireless_dev *wdev, bool coming_up)
break;
}
- if (local->monitors == 0 && local->open_count == 0) {
+ if (sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE) {
+ res = drv_add_interface(local, sdata);
+ if (res)
+ goto err_stop;
+ } else if (local->monitors == 0 && local->open_count == 0) {
res = ieee80211_add_virtual_monitor(local);
if (res)
goto err_stop;
@@ -912,7 +925,11 @@ static void ieee80211_do_stop(struct ieee80211_sub_if_data *sdata,
mutex_lock(&local->mtx);
ieee80211_recalc_idle(local);
mutex_unlock(&local->mtx);
- break;
+
+ if (!(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ break;
+
+ /* fall through */
default:
if (going_down)
drv_remove_interface(local, sdata);
@@ -1061,7 +1078,7 @@ static const struct net_device_ops ieee80211_monitorif_ops = {
.ndo_start_xmit = ieee80211_monitor_start_xmit,
.ndo_set_rx_mode = ieee80211_set_multicast_list,
.ndo_change_mtu = ieee80211_change_mtu,
- .ndo_set_mac_address = eth_mac_addr,
+ .ndo_set_mac_address = ieee80211_change_mac,
.ndo_select_queue = ieee80211_monitor_select_queue,
};
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 27e0715..7cbe0db 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -560,6 +560,9 @@ void ieee80211_iterate_active_interfaces(
list_for_each_entry(sdata, &local->interfaces, list) {
switch (sdata->vif.type) {
case NL80211_IFTYPE_MONITOR:
+ if (!(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ continue;
+ break;
case NL80211_IFTYPE_AP_VLAN:
continue;
default:
@@ -598,6 +601,9 @@ void ieee80211_iterate_active_interfaces_atomic(
list_for_each_entry_rcu(sdata, &local->interfaces, list) {
switch (sdata->vif.type) {
case NL80211_IFTYPE_MONITOR:
+ if (!(sdata->u.mntr_flags & MONITOR_FLAG_ACTIVE))
+ continue;
+ break;
case NL80211_IFTYPE_AP_VLAN:
continue;
default:
--
1.8.0.2
^ permalink raw reply related
* [PATCH v2 1/3] cfg80211: support an active monitor interface flag
From: Felix Fietkau @ 2013-05-28 11:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
An active monitor interface is one that is used for communication (via
injection). It is expected to ACK incoming unicast packets. This is
useful for running various 802.11 testing utilities that associate to an
AP via injection and manage the state in user space.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/net/cfg80211.h | 1 +
include/uapi/linux/nl80211.h | 4 ++++
net/wireless/nl80211.c | 10 ++++++++++
3 files changed, 15 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 26b5b69..489821f 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -954,6 +954,7 @@ enum monitor_flags {
MONITOR_FLAG_CONTROL = 1<<NL80211_MNTR_FLAG_CONTROL,
MONITOR_FLAG_OTHER_BSS = 1<<NL80211_MNTR_FLAG_OTHER_BSS,
MONITOR_FLAG_COOK_FRAMES = 1<<NL80211_MNTR_FLAG_COOK_FRAMES,
+ MONITOR_FLAG_ACTIVE = 1<<NL80211_MNTR_FLAG_ACTIVE,
};
/**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index d1e48b5..7b4b101 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2413,6 +2413,8 @@ enum nl80211_survey_info {
* @NL80211_MNTR_FLAG_OTHER_BSS: disable BSSID filtering
* @NL80211_MNTR_FLAG_COOK_FRAMES: report frames after processing.
* overrides all other flags.
+ * @NL80211_MNTR_FLAG_ACTIVE: use the configured MAC address
+ * and ACK incoming unicast packets.
*
* @__NL80211_MNTR_FLAG_AFTER_LAST: internal use
* @NL80211_MNTR_FLAG_MAX: highest possible monitor flag
@@ -2424,6 +2426,7 @@ enum nl80211_mntr_flags {
NL80211_MNTR_FLAG_CONTROL,
NL80211_MNTR_FLAG_OTHER_BSS,
NL80211_MNTR_FLAG_COOK_FRAMES,
+ NL80211_MNTR_FLAG_ACTIVE,
/* keep last */
__NL80211_MNTR_FLAG_AFTER_LAST,
@@ -3575,6 +3578,7 @@ enum nl80211_feature_flags {
NL80211_FEATURE_ADVERTISE_CHAN_LIMITS = 1 << 14,
NL80211_FEATURE_FULL_AP_CLIENT_STATE = 1 << 15,
NL80211_FEATURE_USERSPACE_MPM = 1 << 16,
+ NL80211_FEATURE_ACTIVE_MONITOR = 1 << 17,
};
/**
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index dfdb5e6..27c9f5c 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -2279,6 +2279,7 @@ static const struct nla_policy mntr_flags_policy[NL80211_MNTR_FLAG_MAX + 1] = {
[NL80211_MNTR_FLAG_CONTROL] = { .type = NLA_FLAG },
[NL80211_MNTR_FLAG_OTHER_BSS] = { .type = NLA_FLAG },
[NL80211_MNTR_FLAG_COOK_FRAMES] = { .type = NLA_FLAG },
+ [NL80211_MNTR_FLAG_ACTIVE] = { .type = NLA_FLAG },
};
static int parse_monitor_flags(struct nlattr *nla, u32 *mntrflags)
@@ -2390,6 +2391,10 @@ static int nl80211_set_interface(struct sk_buff *skb, struct genl_info *info)
change = true;
}
+ if ((*flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ !(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
+ return -EOPNOTSUPP;
+
if (change)
err = cfg80211_change_iface(rdev, dev, ntype, flags, ¶ms);
else
@@ -2447,6 +2452,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info)
err = parse_monitor_flags(type == NL80211_IFTYPE_MONITOR ?
info->attrs[NL80211_ATTR_MNTR_FLAGS] : NULL,
&flags);
+
+ if (!err && (flags & NL80211_MNTR_FLAG_ACTIVE) &&
+ !(rdev->wiphy.features & NL80211_FEATURE_ACTIVE_MONITOR))
+ return -EOPNOTSUPP;
+
wdev = rdev_add_virtual_intf(rdev,
nla_data(info->attrs[NL80211_ATTR_IFNAME]),
type, err ? NULL : &flags, ¶ms);
--
1.8.0.2
^ permalink raw reply related
* [PATCH v2 3/3] ath9k: advertise support for active monitor interfaces
From: Felix Fietkau @ 2013-05-28 11:01 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
In-Reply-To: <1369738914-34367-1-git-send-email-nbd@openwrt.org>
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
drivers/net/wireless/ath/ath9k/init.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index c0aa4ff..f1d028a 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -772,6 +772,8 @@ void ath9k_set_hw_capab(struct ath_softc *sc, struct ieee80211_hw *hw)
if (AR_SREV_9160_10_OR_LATER(sc->sc_ah) || ath9k_modparam_nohwcrypt)
hw->flags |= IEEE80211_HW_MFP_CAPABLE;
+ hw->wiphy->features |= NL80211_FEATURE_ACTIVE_MONITOR;
+
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_P2P_GO) |
BIT(NL80211_IFTYPE_P2P_CLIENT) |
--
1.8.0.2
^ permalink raw reply related
* Re: [RFC 0/4] add master channel switch announcement support
From: Simon Wunderlich @ 2013-05-28 10:43 UTC (permalink / raw)
To: Simon Wunderlich
Cc: Johannes Berg, linux-wireless, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <20130514092734.GA16426@pandem0nium>
[-- Attachment #1: Type: text/plain, Size: 2339 bytes --]
Hey,
On Tue, May 14, 2013 at 11:27:34AM +0200, Simon Wunderlich wrote:
> > > [....]
> >
> > I don't really like your approach of building all the IEs in the kernel.
> > There are some things, like the country-after-switch in the CSA wrapper
> > (introduced in 11ac), that would be really awkward this way.
>
> Hmm ... OK. I have not checked 802.11ac yet (actually I don't have access to the
> drafts anyway). So what we have to expect is changing the country after the switch,
> or also other new things?
>
> > > * We already have NL80211_CMD_CH_SWITCH_NOTIFY which is only used for notification.
> > > Maybe we can rename that and re-use it instead of adding a new command
> > > NL80211_CMD_CHANNEL_SWITCH?
> >
> > Sure, I don't really care though.
> >
> OK, will try to merge that then. Seems cleaner than having multiple channel switch
> commands in the API.
>
> > > * could other drivers (next to ath9k) work with this API?
> >
> > Probably not easily. Any TI folks reading this?
>
> I was thinking about adding another callback function or option for that for drivers
> who do the channel switch internally. Then we would only need mac80211 to adapt.
>
> Would that help, or what would be problematic?
> >
> >
> > Anyway I think it'd be better to try to provide
> > (a) the "during-switch IEs", maybe with an offset to the counter so
> > mac80211,
> > driver or the device itself can count down
> > (b) the "after-switch beacon" IEs (and maybe probe response for
> o> offload)
>
> Yeah, that would be an alternative. I've been inspired by IEEE 802.11-2012/6.3.17
> (MLME-CHANNELSWITCH) originally. :)
> I think your suggestion is good for AP where we control the beacon. For IBSS it
> would be a little different: when a channel switch is triggered, userspace does
> not know the beacon (and will not set it). Therefore, we could only accept the
> change IEs and skip the "after-switch-beacon" IEs (these would be re-generated
> internally) in IBSS mode. I guess it would be similar for mesh.
>
> What do you think?
I'd like to bump this issue again - if we agree on that this solution could work
for IBSS and possibly other modes I'd like to prepare the patchset implementing that.
This is required for IBSS-DFS later after all ...
Thanks,
Simon
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCHv3 00/18] Add support for 5 and 10 MHz channels
From: Simon Wunderlich @ 2013-05-28 10:41 UTC (permalink / raw)
To: Simon Wunderlich
Cc: linux-wireless, Johannes Berg, Mathias Kretschmer,
Simon Wunderlich
In-Reply-To: <1368702045-27598-1-git-send-email-siwu@hrz.tu-chemnitz.de>
[-- Attachment #1: Type: text/plain, Size: 5089 bytes --]
Hey,
just to bump here - this patchset is idling around for quite some time now.
I can integrate Felix suggestions easily if not a maintainer would like to do
that. Any further comments/suggestions?
Thanks,
Simon
On Thu, May 16, 2013 at 01:00:27PM +0200, Simon Wunderlich wrote:
> This patchset adds support for 5 and 10 MHz in nl80211/cfg80211/mac80211
> and enables support in ath5k and ath9k, which already support this feature
> on the driver side. 5 and 10 MHz wide channels might be useful for:
>
> * long shot links, as the transmissions are more robust
> * future support for 802.11y which allows some 5 and 10 MHz channels in
> 3.6 GHz range
> * future support for 802.11p which uses 10 MHz in 5.9 GHz range
> * ... and more "special" applications.
>
> This patchset enables 5 and 10 MHz channels only for OFDM, and without
> HT/MIMO/aggregation (for now). Support may be added later.
>
> Changes to PATCHv2:
> * instead of introducing new bitrate tables, use bitrate flags which mark
> the bitrate with support for 5/10 MHz. All bitrates have then to be
> calculated manually.
> --> this saves a few changes where we only operate on indexes anyway,
> but requires some more checking at other parts where it is required
> to see if the rate is supported in 5/10 MHz. At least it is not
> that ugly and bloaty, and also saves a lot of code in drivers.
> * various DIV_ROUND_UP()s have been used instead of manual conversions
> --> this was squashed with the "big" bitrate adjustment patch (-1 patch)
> * found a bug in the rate mask matching code, which is fixed (+1 patch)
> * fixed a few bugs I introuced myself. :)
>
> As always, any comments are appreciated!
> Cheers,
> Simon
>
> Simon Wunderlich (18):
> nl80211/cfg80211: add 5 and 10 MHz defines and wiphy flag
> nl80211: add rate flags for 5/10 Mhz channels
> mac80211: Fix rate control mask matching call
> mac80211: fix various components for the new 5 and 10 MHz widths
> mac80211: fix timing for 5 MHz and 10 MHz channels
> mac80211: select and adjust bitrates according for channel mode
> mac80211: add radiotap flag and handling for 5/10 MHz
> cfg80211/mac80211: use reduced txpower for 5 and 10 MHz
> mac80211: change IBSS channel state to chandef
> nl80211: allow 5 and 10 MHz channels for IBSS
> ath9k: always use SIFS times from OFDM for 5/10 MHz
> ath9k: use chandef instead of channel_type
> ath9k: report 5/10 MHz channels
> ath9k: set 5/10 MHz supported channels and fix bitrate
> ath9k: announce that ath9k supports 5/10 MHz
> ath5k: report 5/10 MHz channels
> ath5k: set 5/10 MHz supported channels and fix duration
> ath5k: enable support for 5 MHz and 10 MHz channels
>
> drivers/net/wireless/ath/ath5k/ath5k.h | 1 +
> drivers/net/wireless/ath/ath5k/base.c | 59 ++++++++--
> drivers/net/wireless/ath/ath5k/base.h | 2 +-
> drivers/net/wireless/ath/ath5k/mac80211-ops.c | 2 +-
> drivers/net/wireless/ath/ath5k/pcu.c | 2 +
> drivers/net/wireless/ath/ath5k/qcu.c | 25 +++-
> drivers/net/wireless/ath/ath9k/common.c | 67 +++++++----
> drivers/net/wireless/ath/ath9k/common.h | 3 +-
> drivers/net/wireless/ath/ath9k/htc_drv_main.c | 5 +-
> drivers/net/wireless/ath/ath9k/hw.c | 5 +-
> drivers/net/wireless/ath/ath9k/init.c | 29 +++--
> drivers/net/wireless/ath/ath9k/main.c | 8 +-
> drivers/net/wireless/ath/ath9k/rc.c | 10 +-
> drivers/net/wireless/ath/ath9k/recv.c | 11 ++
> include/net/cfg80211.h | 55 +++++++++
> include/net/ieee80211_radiotap.h | 4 +
> include/net/mac80211.h | 5 +-
> include/uapi/linux/nl80211.h | 4 +
> net/mac80211/cfg.c | 36 +++++-
> net/mac80211/ibss.c | 101 +++++++++++-----
> net/mac80211/ieee80211_i.h | 45 ++++++-
> net/mac80211/iface.c | 2 +-
> net/mac80211/main.c | 2 +-
> net/mac80211/mesh.c | 4 +-
> net/mac80211/mesh_plink.c | 8 +-
> net/mac80211/mlme.c | 99 ++++++++++++----
> net/mac80211/rate.c | 60 +++++-----
> net/mac80211/rc80211_minstrel.c | 29 ++++-
> net/mac80211/rc80211_minstrel_ht.c | 11 +-
> net/mac80211/rx.c | 28 +++--
> net/mac80211/status.c | 17 ++-
> net/mac80211/tx.c | 16 ++-
> net/mac80211/util.c | 157 +++++++++++++++++++------
> net/wireless/chan.c | 57 +++++++--
> net/wireless/nl80211.c | 23 +++-
> 35 files changed, 761 insertions(+), 231 deletions(-)
>
> --
> 1.7.10.4
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH 1/2] mac80211: constify ieee802_11_parse_elems() argument
From: Johannes Berg @ 2013-05-28 8:59 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
It only returns pointers into the data, so there's no
reason not to mark the input data const.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/ieee80211_i.h | 5 +++--
net/mac80211/util.c | 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 9eed6f1..923e177 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1512,10 +1512,11 @@ static inline void ieee80211_tx_skb(struct ieee80211_sub_if_data *sdata,
ieee80211_tx_skb_tid(sdata, skb, 7);
}
-u32 ieee802_11_parse_elems_crc(u8 *start, size_t len, bool action,
+u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
struct ieee802_11_elems *elems,
u64 filter, u32 crc);
-static inline void ieee802_11_parse_elems(u8 *start, size_t len, bool action,
+static inline void ieee802_11_parse_elems(const u8 *start, size_t len,
+ bool action,
struct ieee802_11_elems *elems)
{
ieee802_11_parse_elems_crc(start, len, action, elems, 0, 0);
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 2a8d759..efc06d2 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -661,12 +661,12 @@ void ieee80211_queue_delayed_work(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_queue_delayed_work);
-u32 ieee802_11_parse_elems_crc(u8 *start, size_t len, bool action,
+u32 ieee802_11_parse_elems_crc(const u8 *start, size_t len, bool action,
struct ieee802_11_elems *elems,
u64 filter, u32 crc)
{
size_t left = len;
- u8 *pos = start;
+ const u8 *pos = start;
bool calc_crc = filter != 0;
DECLARE_BITMAP(seen_elems, 256);
const u8 *ie;
--
1.8.0
^ permalink raw reply related
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