* Re: WARNING with ath9k_htc on TL-WN721N
From: Oleksij Rempel @ 2013-09-05 14:32 UTC (permalink / raw)
To: Antonio Quartulli; +Cc: ath9k-devel, linux-wireless
In-Reply-To: <20130905142122.GE1570@ritirata.org>
Am 05.09.2013 16:21, schrieb Antonio Quartulli:
> On Thu, Sep 05, 2013 at 04:09:04PM +0200, Oleksij Rempel wrote:
>> Forgot attachment.
>>
>>
>> Am 05.09.2013 16:07, schrieb Oleksij Rempel:
>>> Hi,
>>>
>>> thank you.
>>>
>>> please do some tests for me.
>>>
>>> 1. run wireless adapter without other devices on this bus.
>>>
>
> Ok Oleksij, I'll try to do these tests soonish. You think the problem is
> triggered by a scan operation?
>
> If so, I'll try to reproduce it by scanning. Till now I had no clue about the
> cause.
Probably no only scan. Normally if you use network manager, it will scan
each 160 seconds or so. In this case you will get this warning lot more
often. Probably it comes together: hight network traffic + channel scan
+ usb traffic of other devices on same bus.
--
Regards,
Oleksij
^ permalink raw reply
* Re: Linux Wireless Mini-Summit in New Orleans -- 19-20 September (6 weeks from today!)
From: Dan Williams @ 2013-09-05 16:04 UTC (permalink / raw)
To: John W. Linville
Cc: linux-wireless, johannes, marcel, Samuel Ortiz, Gustavo Padovan,
linux-bluetooth, linux-nfc
In-Reply-To: <20130905133907.GE1947@tuxdriver.com>
On Thu, 2013-09-05 at 09:39 -0400, John W. Linville wrote:
> On Thu, Aug 08, 2013 at 03:04:29PM -0400, John W. Linville wrote:
> > Sorry, forgot to copy linux-bluetooth and linux-nfc...
> >
> > On Thu, Aug 08, 2013 at 02:54:11PM -0400, John W. Linville wrote:
> > > Greetings!
> > >
> > > This is a reminder that we will have a Linux Wireless Mini-Summit in
> > > New Orleans this year on 19-20 September. This will immediately follow
> > > LinuxCon and will run concurrently with Linux Plumber's Conference.
> > > This event includes Linux developers for wireless LAN (802.11),
> > > Bluetooth, and NFC technologies. Both kernel and userland developers
> > > are welcomed and heartily encouraged to attend!
> > >
> > > http://wireless.kernel.org/en/developers/Summits/New-Orleans-2013
> > >
> > > The link above is a Wiki. We are using it to collect discussion
> > > topics and to negotiate agenda/scheduling options for the event.
> > > Please go there to record your intent to attend the event and to
> > > propopse topics for discussion.
> > >
> > > Please be aware that in order to attend the event above one must
> > > register for either LinuxCon or for Linux Plumbers Conference.
> > > Act now, before those events fill-up and close their registrations!
> > >
> > > We are allotted one "large" room (up to ~80 people "theater style"), and
> > > two "small" rooms (up to ~25 people) for this event. Based on history
> > > and the numbers of contributors, the larger room will primarily be
> > > for the 802.11 discussions and any "plenary" topics while the smaller
> > > rooms will be for Bluetooth, NFC, and any "breakout" topics.
> > >
> > > So...thoughts? Topics to discuss?
>
> Ping? We're now just 2 weeks away!
>
> Is our topic list complete? It looks a bit light...
>
> Anyone have any input on scheduling the topics? Are there any
> overlapping LPC sessions that it would make sense to work around?
I'm attending though I haven't put my name on the wiki yet.
Random thoughts; it doesn't look like any of these are covered in the
regular LinuxConf or LPC sessions.
1) State of the Union (maybe by multiple people in the same session per
their expertise), since perhaps not everyone doing eg 802.11 stuff knows
what's happening in BT or NFC land, or not everyone working on a
specific driver may know what new stuff their driver might need to be
fixed up for. Maybe 5 minutes or less for things like:
* what's under the most active development right now?
* upcoming new driver, hardware, and new capabilities
* new 802.11 standards
* and what's coming up in the next year from the standards orgs
* what people will start working on soon
* what will 3.13 or 3.14 look like from a wireless perspective?
* 11s mesh status?
* anything interesting in wpa_supplicant land?
* anything new/interesting on the Android front?
2) Bluetooth - update about what's new and what's coming up in Bluez
land, and interaction with kernel 802.11 if any,
3) NFC - update about what's new and what's coming up in NFC land, where
it's getting used, what the stack looks like
4) What are users having the most problems with and how these problems
be fixed better/more quickly? Are they driver bugs? Are they stack
bugs? Supplicant bugs? NM/GUI/etc bugs? Is there anything in our
development processes that's not working as smoothly as it could be?
Dan
^ permalink raw reply
* Specifying priority for management frames?
From: Ben Greear @ 2013-09-05 18:17 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
While debugging a problem with group-rekeys, we noticed that the sniffer (on external machine)
reported management packets are sent in the best-effort QoS queue.
It seems to me that these should be in the VO queue instead, or at least
we should be able to specify the queue in supplicant when sending the frames?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Specifying priority for management frames?
From: Ben Greear @ 2013-09-05 18:28 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <5228CAB6.5060308@candelatech.com>
On 09/05/2013 11:17 AM, Ben Greear wrote:
> While debugging a problem with group-rekeys, we noticed that the sniffer (on external machine)
> reported management packets are sent in the best-effort QoS queue.
>
> It seems to me that these should be in the VO queue instead, or at least
> we should be able to specify the queue in supplicant when sending the frames?
Hrmm, actually it appears the mac80211 layer tries to send on VO. Maybe
some of my hackings are messing this up...I'll go dig deeper.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH v2] mac80211: fix the setting of extended supported rate IE
From: Chun-Yeow Yeoh @ 2013-09-05 19:14 UTC (permalink / raw)
To: linux-wireless
Cc: johannes, linville, devel, distro11s, Chun-Yeow Yeoh,
Colleen Twitty
The patch "mac80211: select and adjust bitrates according to
channel mode" causes regression and breaks the extended supported rate
IE setting. Since "i" is starting with 8, so this is not necessary
to introduce "skip" here.
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
Signed-off-by: Colleen Twitty <colleen@cozybit.com>
Reviewed-by: Jason Abele <jason@cozybit.com>
---
v2: remove skip (Jason)
net/mac80211/util.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 3c8283b..4bb639f 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -2128,14 +2128,11 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
pos = skb_put(skb, exrates + 2);
*pos++ = WLAN_EID_EXT_SUPP_RATES;
*pos++ = exrates;
- skip = 0;
for (i = 8; i < sband->n_bitrates; i++) {
u8 basic = 0;
if ((rate_flags & sband->bitrates[i].flags)
!= rate_flags)
continue;
- if (skip++ < 8)
- continue;
if (need_basic && basic_rates & BIT(i))
basic = 0x80;
rate = DIV_ROUND_UP(sband->bitrates[i].bitrate,
--
1.7.9.5
^ permalink raw reply related
* Re: bcma problem on x86_64
From: Rafał Miłecki @ 2013-09-06 8:05 UTC (permalink / raw)
To: Arend van Spriel; +Cc: linux-wireless
In-Reply-To: <522879D0.2030107@broadcom.com>
Hi,
2013/9/5 Arend van Spriel <arend@broadcom.com>:
> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached log). I
> thought I misconfigured my setup, but just upgraded to 3.11 and I am still
> seeing the same issue. Did you have any reports like this?
Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
try over the weekend.
--
Rafał
^ permalink raw reply
* Re: bcma problem on x86_64
From: Arend van Spriel @ 2013-09-06 9:05 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless
In-Reply-To: <CACna6ryc0_9xcQonuJbK6aB0-ak_izLTi_LNGHB=Lsx0Q5t-Zw@mail.gmail.com>
On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
> Hi,
>
> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached log). I
>> thought I misconfigured my setup, but just upgraded to 3.11 and I am still
>> seeing the same issue. Did you have any reports like this?
>
> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
> try over the weekend.
>
I am bisecting. Will let you know when I find something.
Gr. AvS
^ permalink raw reply
* beginner build question
From: Brian O'Connor @ 2013-09-06 9:27 UTC (permalink / raw)
To: linux-wireless
I am trying to compile rtl8192su in Ubuntu 13.04 and I get the
following error when I "make all":
make -C /lib/modules/3.10.10-031010-generic/build
M=/home/media/rtl8192su/r92su CONFIG_R92SU=m CONFIG_R92SU_DEBUGFS=y
CONFIG_R92SU_WPC=y all EXTRA_CFLAGS="-DDEBUG -DCONFIG_R92SU=m
-DCONFIG_R92SU_DEBUGFS=y -DCONFIG_R92SU_WPC=y"
make[1]: Entering directory `/usr/src/linux-headers-3.10.10-031010-generic'
make[1]: *** No rule to make target `vmlinux', needed by `all'. Stop.
make[1]: Leaving directory `/usr/src/linux-headers-3.10.10-031010-generic'
make: *** [all] Error 2
Any suggestions?
Thanks in advance,
Brian
^ permalink raw reply
* Re: [PATCH] Add missing braces to ath10k_pci_tx_pipe_cleanup
From: Kalle Valo @ 2013-09-06 9:32 UTC (permalink / raw)
To: Dave Jones; +Cc: netdev, linux-wireless, linville, ath10k
In-Reply-To: <20130905035128.GA15824@redhat.com>
Dave Jones <davej@redhat.com> writes:
> The indentation here implies this was meant to be a multi-statement
> if, but it lacks the braces.
>
> Signed-off-by: Dave Jones <davej@fedoraproject.org>
Thanks, applied.
I added "ath10k:" to the patch title.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 0/3] ath10k: HTT stats
From: Kalle Valo @ 2013-09-06 9:43 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
In-Reply-To: <20130903084302.26199.3538.stgit@localhost6.localdomain6>
Kalle Valo <kvalo@qca.qualcomm.com> writes:
> Adds trace events and a debugfs interface to enable HTT stats
> from firmware.
>
> ---
>
> Kalle Valo (3):
> ath10k: add trace event ath10k_htt_stats
> ath10k: implement ath10k_debug_start/stop()
> ath10k: add htt_stats_enable debugfs file
All three applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v4 2/2] ath10k: implement per-VDEV FW statistics
From: Kalle Valo @ 2013-09-06 9:48 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1378196481-13983-3-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> The WMI_REQUEST_PEER_STAT command with latst (1.0.0.716) FW
> can return per-VDEV statistics. Using debugfs we can fetch this info now.
>
> This is a backward compatible change. In case of older FW the VDEV
> statistics are simply not returned.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
> ---
[...]
> for (i = 0; i < num_peer_stats; i++) {
> - peer_stats = (struct wmi_peer_stats *)tmp;
> + peer_stats = (struct wmi_peer_stats_common *)tmp;
You still have the evil cast here :)
(Evil here meaning that that you make the implicit assumption that _v1
and _v2 start with the _common struct.)
Let me send v5 and you can review that before I commit.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: set the UART baud rate to 19200
From: Kalle Valo @ 2013-09-06 9:52 UTC (permalink / raw)
To: Bartosz Markowski; +Cc: ath10k, linux-wireless
In-Reply-To: <1378211043-20299-1-git-send-email-bartosz.markowski@tieto.com>
Bartosz Markowski <bartosz.markowski@tieto.com> writes:
> When configuring the host_interests over BMI, set the UART
> baud rate to 19200. This is valid for QCA988X_2.0 devices.
>
> Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
Thanks, both patches applied.
To first patch I added this:
kvalo: found during code review, there should not be any functionality
changes
--
Kalle Valo
^ permalink raw reply
* Re: beginner build question
From: Christian Lamparter @ 2013-09-06 10:21 UTC (permalink / raw)
To: Brian O'Connor; +Cc: linux-wireless
In-Reply-To: <CAHhaCVjomgED0WW1fyUQbePNS0DnPEfKb5uE-+rEMhx6zgO1ZA@mail.gmail.com>
Hello,
On Friday, September 06, 2013 02:27:26 AM Brian O'Connor wrote:
> I am trying to compile rtl8192su in Ubuntu 13.04 and I get the
> following error when I "make all":
>
> make -C /lib/modules/3.10.10-031010-generic/build
> M=/home/media/rtl8192su/r92su CONFIG_R92SU=m CONFIG_R92SU_DEBUGFS=y
> CONFIG_R92SU_WPC=y all EXTRA_CFLAGS="-DDEBUG -DCONFIG_R92SU=m
^^^
> -DCONFIG_R92SU_DEBUGFS=y -DCONFIG_R92SU_WPC=y"
> make[1]: Entering directory `/usr/src/linux-headers-3.10.10-031010-generic'
> make[1]: *** No rule to make target `vmlinux', needed by `all'. Stop.
> make[1]: Leaving directory `/usr/src/linux-headers-3.10.10-031010-generic'
> make: *** [all] Error 2
>
> Any suggestions?
Thanks for reporting this. I fixed the project's readme.
<https://github.com/chunkeey/rtl8192su/commit/d1934e155840ccd273a429d85f1f2aa407ba49b7>
Just run "make" instead of "make all".
Regards
Chr
^ permalink raw reply
* [PATCH 2/2] mac80211: implement support for configuring antenna gain
From: Felix Fietkau @ 2013-09-06 13:06 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
In-Reply-To: <1378472763-36062-1-git-send-email-nbd@openwrt.org>
Report the maximum allowable extra antenna gain to the driver to allow
it to reduce the tx power even further based on internal data
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/net/mac80211.h | 2 ++
net/mac80211/cfg.c | 14 ++++++++++++++
net/mac80211/ieee80211_i.h | 1 +
net/mac80211/main.c | 18 ++++++++++++++++--
4 files changed, 33 insertions(+), 2 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 4be8785..c7272fe 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1019,6 +1019,7 @@ enum ieee80211_smps_mode {
*
* @power_level: requested transmit power (in dBm), backward compatibility
* value only that is set to the minimum of all interfaces
+ * @max_antenna_gain: maximum antenna gain adjusted by user config (in dBi)
*
* @chandef: the channel definition to tune to
* @radar_enabled: whether radar detection is enabled
@@ -1040,6 +1041,7 @@ struct ieee80211_conf {
u32 flags;
int power_level, dynamic_ps_timeout;
int max_sleep_period;
+ int max_antenna_gain;
u16 listen_interval;
u8 ps_dtim_period;
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 2e7855a..4d75e73 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -2284,6 +2284,19 @@ static int ieee80211_get_tx_power(struct wiphy *wiphy,
return 0;
}
+static int ieee80211_set_antenna_gain(struct wiphy *wiphy, int dbi)
+{
+ struct ieee80211_local *local = wiphy_priv(wiphy);
+
+ if (dbi < 0)
+ return -EINVAL;
+
+ local->user_antenna_gain = dbi;
+ ieee80211_hw_config(local, 0);
+
+ return 0;
+}
+
static int ieee80211_set_wds_peer(struct wiphy *wiphy, struct net_device *dev,
const u8 *addr)
{
@@ -3658,6 +3671,7 @@ struct cfg80211_ops mac80211_config_ops = {
.set_wiphy_params = ieee80211_set_wiphy_params,
.set_tx_power = ieee80211_set_tx_power,
.get_tx_power = ieee80211_get_tx_power,
+ .set_antenna_gain = ieee80211_set_antenna_gain,
.set_wds_peer = ieee80211_set_wds_peer,
.rfkill_poll = ieee80211_rfkill_poll,
CFG80211_TESTMODE_CMD(ieee80211_testmode_cmd)
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index b618651..c303b18 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -1155,6 +1155,7 @@ struct ieee80211_local {
int dynamic_ps_forced_timeout;
int user_power_level; /* in dBm, for all interfaces */
+ int user_antenna_gain; /* in dBi */
enum ieee80211_smps_mode smps_mode;
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 21d5d44..47312d6 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -97,7 +97,7 @@ static u32 ieee80211_hw_conf_chan(struct ieee80211_local *local)
struct ieee80211_sub_if_data *sdata;
struct cfg80211_chan_def chandef = {};
u32 changed = 0;
- int power;
+ int power, ant_gain, max_power;
u32 offchannel_flag;
offchannel_flag = local->hw.conf.flags & IEEE80211_CONF_OFFCHANNEL;
@@ -152,8 +152,21 @@ static u32 ieee80211_hw_conf_chan(struct ieee80211_local *local)
}
rcu_read_unlock();
- if (local->hw.conf.power_level != power) {
+ max_power = chandef.chan->max_reg_power;
+ ant_gain = chandef.chan->max_antenna_gain;
+ if (local->user_antenna_gain > 0) {
+ if (local->user_antenna_gain > ant_gain) {
+ max_power -= local->user_antenna_gain - ant_gain;
+ ant_gain = 0;
+ } else
+ ant_gain -= local->user_antenna_gain;
+ power = min(power, max_power);
+ }
+
+ if (local->hw.conf.power_level != power ||
+ local->hw.conf.max_antenna_gain != ant_gain) {
changed |= IEEE80211_CONF_CHANGE_POWER;
+ local->hw.conf.max_antenna_gain = ant_gain;
local->hw.conf.power_level = power;
}
@@ -583,6 +596,7 @@ struct ieee80211_hw *ieee80211_alloc_hw(size_t priv_data_len,
IEEE80211_RADIOTAP_MCS_HAVE_BW;
local->hw.radiotap_vht_details = IEEE80211_RADIOTAP_VHT_KNOWN_GI |
IEEE80211_RADIOTAP_VHT_KNOWN_BANDWIDTH;
+ local->user_antenna_gain = 0;
local->hw.uapsd_queues = IEEE80211_DEFAULT_UAPSD_QUEUES;
local->hw.uapsd_max_sp_len = IEEE80211_DEFAULT_MAX_SP_LEN;
local->user_power_level = IEEE80211_UNSET_POWER_LEVEL;
--
1.8.0.2
^ permalink raw reply related
* [PATCH 1/2] cfg80211: add support for configuring antenna gain
From: Felix Fietkau @ 2013-09-06 13:06 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes
When using high-gain antennas, transmit power needs to be reduced to
stay within legal EIRP limits.
This option only reduces transmit power as much as is necessary to
stay within the limit.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
---
include/net/cfg80211.h | 2 ++
include/uapi/linux/nl80211.h | 5 +++++
net/wireless/nl80211.c | 17 +++++++++++++++++
3 files changed, 24 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d530c54..6b73781 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2061,6 +2061,7 @@ struct cfg80211_update_ft_ies_params {
* (as advertised by the nl80211 feature flag.)
* @get_tx_power: store the current TX power into the dbm variable;
* return 0 if successful
+ * @set_antenna_gain: set antenna gain to reduce maximum tx power if necessary
*
* @set_wds_peer: set the WDS peer for a WDS interface
*
@@ -2283,6 +2284,7 @@ struct cfg80211_ops {
enum nl80211_tx_power_setting type, int mbm);
int (*get_tx_power)(struct wiphy *wiphy, struct wireless_dev *wdev,
int *dbm);
+ int (*set_antenna_gain)(struct wiphy *wiphy, int dbi);
int (*set_wds_peer)(struct wiphy *wiphy, struct net_device *dev,
const u8 *addr);
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index fde2c02..14b8d50 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1496,6 +1496,9 @@ enum nl80211_commands {
* @NL80211_ATTR_RXMGMT_FLAGS: flags for nl80211_send_mgmt(), u32.
* As specified in the &enum nl80211_rxmgmt_flags.
*
+ * @NL80211_ATTR_WIPHY_ANTENNA_GAIN: Configured antenna gain. Used to reduce
+ * transmit power to stay within regulatory limits. u32, dBi.
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1806,6 +1809,8 @@ enum nl80211_attrs {
NL80211_ATTR_RXMGMT_FLAGS,
+ NL80211_ATTR_WIPHY_ANTENNA_GAIN,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index af8d84a..a29ab58 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -354,6 +354,7 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
[NL80211_ATTR_CSA_IES] = { .type = NLA_NESTED },
[NL80211_ATTR_CSA_C_OFF_BEACON] = { .type = NLA_U16 },
[NL80211_ATTR_CSA_C_OFF_PRESP] = { .type = NLA_U16 },
+ [NL80211_ATTR_WIPHY_ANTENNA_GAIN] = { .type = NLA_U32 },
};
/* policy for the key attributes */
@@ -2033,6 +2034,22 @@ static int nl80211_set_wiphy(struct sk_buff *skb, struct genl_info *info)
goto bad_res;
}
+ if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_GAIN]) {
+ int idx, dbi = 0;
+
+ if (!rdev->ops->set_antenna_gain) {
+ result = -EOPNOTSUPP;
+ goto bad_res;
+ }
+
+ idx = NL80211_ATTR_WIPHY_ANTENNA_GAIN;
+ dbi = nla_get_u32(info->attrs[idx]);
+
+ result = rdev->ops->set_antenna_gain(&rdev->wiphy, dbi);
+ if (result)
+ goto bad_res;
+ }
+
if (info->attrs[NL80211_ATTR_WIPHY_ANTENNA_TX] &&
info->attrs[NL80211_ATTR_WIPHY_ANTENNA_RX]) {
u32 tx_ant, rx_ant;
--
1.8.0.2
^ permalink raw reply related
* Build warnings in b43 and b43legacy
From: Larry Finger @ 2013-09-06 15:13 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: LKML, linux-wireless
Geert,
In http://lkml.indiana.edu/hypermail/linux/kernel/1309.0/00918.html and earlier
postings of the build regressions in 3.11-rcX, I notice the following entries:
+ /scratch/kisskb/src/drivers/net/wireless/b43/b43.h: warning: 'packed'
attribute ignored for field of type 'union <anonymous>' [-Wattributes]: => 641:2
+ /scratch/kisskb/src/drivers/net/wireless/b43/xmit.h: warning: 'packed'
attribute ignored for field of type 'struct <anonymous>' [-Wattributes]: =>
64:3, 88:3, 290:3, 283:3, 77:3
+ /scratch/kisskb/src/drivers/net/wireless/b43legacy/b43legacy.h: warning:
'packed' attribute ignored for field of type 'union <anonymous>' [-Wattributes]:
=> 381:2
From the indicated source lines, and some research on the topic of packed
attributes of anonymous entities, I think I know what it would take to fix
these; however, I am reluctant to touch this code. Firstly, my compiler does not
show the warning, and secondly, blindly reworking those critical structures
could cause severe regressions.
What compiler version and options does it take to get these warnings to appear?
Thanks,
Larry
^ permalink raw reply
* Re: Build warnings in b43 and b43legacy
From: Geert Uytterhoeven @ 2013-09-06 15:19 UTC (permalink / raw)
To: Larry Finger; +Cc: LKML, linux-wireless
In-Reply-To: <5229F10A.7000503@lwfinger.net>
On Fri, Sep 6, 2013 at 5:13 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> In http://lkml.indiana.edu/hypermail/linux/kernel/1309.0/00918.html and
> earlier postings of the build regressions in 3.11-rcX, I notice the
> following entries:
>
> + /scratch/kisskb/src/drivers/net/wireless/b43/b43.h: warning: 'packed'
> attribute ignored for field of type 'union <anonymous>' [-Wattributes]: =>
> 641:2
> + /scratch/kisskb/src/drivers/net/wireless/b43/xmit.h: warning: 'packed'
> attribute ignored for field of type 'struct <anonymous>' [-Wattributes]: =>
> 64:3, 88:3, 290:3, 283:3, 77:3
> + /scratch/kisskb/src/drivers/net/wireless/b43legacy/b43legacy.h: warning:
> 'packed' attribute ignored for field of type 'union <anonymous>'
> [-Wattributes]: => 381:2
>
> From the indicated source lines, and some research on the topic of packed
> attributes of anonymous entities, I think I know what it would take to fix
> these; however, I am reluctant to touch this code. Firstly, my compiler does
> not show the warning, and secondly, blindly reworking those critical
> structures could cause severe regressions.
>
> What compiler version and options does it take to get these warnings to
> appear?
All logs I analyze are from the linux-next build service at
http://kisskb.ellerman.id.au/kisskb/matrix/.
I think you can reproduce moft the warnings using the most recent toolchains at
https://www.kernel.org/pub/tools/crosstool/files/bin/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: bcma problem on x86_64
From: Arend van Spriel @ 2013-09-06 15:25 UTC (permalink / raw)
To: Rafał Miłecki; +Cc: linux-wireless, Hauke Mehrtens
In-Reply-To: <52299AC3.5010809@broadcom.com>
On 09/06/2013 11:05 AM, Arend van Spriel wrote:
> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>> Hi,
>>
>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>> log). I
>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>> still
>>> seeing the same issue. Did you have any reports like this?
>>
>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>> try over the weekend.
>>
>
> I am bisecting. Will let you know when I find something.
Bisect points to:
fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Mon Jul 15 13:15:08 2013 +0200
bcma: fix handling of big addrl
The return value of bcma_erom_get_addr_desc() is a unsigned value
and it
could wrap around in the two complement writing. This happens for one
core in the BCM4708 SoC.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
It is probably caused by using IS_ERR_VALUE() macro which does a
unsigned long cast, which gives different results on 64-bit platform.
This patch was submitted upstream yesterday by Dave for 3.12-rc1.
Regards,
Arend
> Gr. AvS
>
> --
> 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
* [PATCH] Don't get iw version from git if there is no .git/
From: Florian Schmaus @ 2013-09-06 15:41 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Florian Schmaus
The version.sh script should only try to get the version from git if the
source actually resides in a git repository, i.e. .git/ exists. Doing
otherwise in a non-git source repo results in git ascending until it
finds a .git directory, which will cause problems in some source-based
distributions ( https://bugs.gentoo.org/show_bug.cgi?id=482334 ).
---
version.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/version.sh b/version.sh
index 80e55ab..0f1aa1d 100755
--- a/version.sh
+++ b/version.sh
@@ -3,7 +3,7 @@
VERSION="3.11"
OUT="$1"
-if head=`git rev-parse --verify HEAD 2>/dev/null`; then
+if [ -d .git ] && head=`git rev-parse --verify HEAD 2>/dev/null`; then
git update-index --refresh --unmerged > /dev/null
descr=$(git describe)
--
1.8.1.5
^ permalink raw reply related
* Re: bcma problem on x86_64
From: Hauke Mehrtens @ 2013-09-06 16:37 UTC (permalink / raw)
To: Arend van Spriel; +Cc: Rafał Miłecki, linux-wireless
In-Reply-To: <5229F3D1.9000200@broadcom.com>
[-- Attachment #1: Type: text/plain, Size: 1604 bytes --]
On 09/06/2013 05:25 PM, Arend van Spriel wrote:
> On 09/06/2013 11:05 AM, Arend van Spriel wrote:
>> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>>> Hi,
>>>
>>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>>> log). I
>>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>>> still
>>>> seeing the same issue. Did you have any reports like this?
>>>
>>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>>> try over the weekend.
>>>
>>
>> I am bisecting. Will let you know when I find something.
>
> Bisect points to:
>
> fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
> commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
> Author: Hauke Mehrtens <hauke@hauke-m.de>
> Date: Mon Jul 15 13:15:08 2013 +0200
>
> bcma: fix handling of big addrl
>
> The return value of bcma_erom_get_addr_desc() is a unsigned value
> and it
> could wrap around in the two complement writing. This happens for one
> core in the BCM4708 SoC.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>
> It is probably caused by using IS_ERR_VALUE() macro which does a
> unsigned long cast, which gives different results on 64-bit platform.
>
> This patch was submitted upstream yesterday by Dave for 3.12-rc1.
>
> Regards,
> Arend
>
Hi Arend,
Thanks for spotting this. This commit is not in final 3.11, otherwise
I would have suspected it before.
Could you please try the attached patch.
Hauke
[-- Attachment #2: 0001-bcma-fix-error-handling.patch --]
[-- Type: text/x-patch, Size: 2529 bytes --]
>From 4a6337b38369977b94d6e752c57b09e7f4539830 Mon Sep 17 00:00:00 2001
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Fri, 6 Sep 2013 18:32:41 +0200
Subject: [PATCH] bcma: fix error handling
---
drivers/bcma/scan.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index cd6b20f..b7906d5 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -269,6 +269,8 @@ static struct bcma_device *bcma_find_core_reverse(struct bcma_bus *bus, u16 core
return NULL;
}
+#define IS_ERR_VALUE_U32 unlikely((x) >= (u32)-MAX_ERRNO)
+
static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
@@ -351,11 +353,11 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
* the main register space for the core
*/
tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
/* Try again to see if it is a bridge */
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_BRIDGE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
return -EILSEQ;
} else {
bcma_info(bus, "Bridge found\n");
@@ -369,7 +371,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SLAVE, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: slave port %d "
* "has %d descriptors\n", i, j); */
@@ -386,7 +388,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_MWRAP, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* "has %d descriptors\n", i, j); */
@@ -404,7 +406,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SWRAP, i + hack);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* has %d descriptors\n", i, j); */
--
1.7.10.4
^ permalink raw reply related
* Re: bcma problem on x86_64
From: Arend van Spriel @ 2013-09-06 16:50 UTC (permalink / raw)
To: Hauke Mehrtens; +Cc: Rafał Miłecki, linux-wireless
In-Reply-To: <522A04B4.3050708@hauke-m.de>
On 09/06/2013 06:37 PM, Hauke Mehrtens wrote:
> On 09/06/2013 05:25 PM, Arend van Spriel wrote:
>> On 09/06/2013 11:05 AM, Arend van Spriel wrote:
>>> On 09/06/2013 10:05 AM, Rafał Miłecki wrote:
>>>> Hi,
>>>>
>>>> 2013/9/5 Arend van Spriel <arend@broadcom.com>:
>>>>> Since 3.11-rc4 I am seeing a problem with bcma on x64 (see attached
>>>>> log). I
>>>>> thought I misconfigured my setup, but just upgraded to 3.11 and I am
>>>>> still
>>>>> seeing the same issue. Did you have any reports like this?
>>>>
>>>> Unfortunately I wasn't testing final 3.11 with x86_64, I'll give it a
>>>> try over the weekend.
>>>>
>>>
>>> I am bisecting. Will let you know when I find something.
>>
>> Bisect points to:
>>
>> fd4edf197544bae1c77d84bad354aa7ce1d08ce1 is the first bad commit
>> commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
>> Author: Hauke Mehrtens <hauke@hauke-m.de>
>> Date: Mon Jul 15 13:15:08 2013 +0200
>>
>> bcma: fix handling of big addrl
>>
>> The return value of bcma_erom_get_addr_desc() is a unsigned value
>> and it
>> could wrap around in the two complement writing. This happens for one
>> core in the BCM4708 SoC.
>>
>> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
>> Signed-off-by: John W. Linville <linville@tuxdriver.com>
>>
>> It is probably caused by using IS_ERR_VALUE() macro which does a
>> unsigned long cast, which gives different results on 64-bit platform.
>>
>> This patch was submitted upstream yesterday by Dave for 3.12-rc1.
>>
>> Regards,
>> Arend
>>
> Hi Arend,
>
> Thanks for spotting this. This commit is not in final 3.11, otherwise
> I would have suspected it before.
Yeah. It will need to be fixed for 3.12 after the merge window.
> Could you please try the attached patch.
Just tried my own patch, which essentially does the same (not using a
macro).
So you may add
Acked-by: or Tested-by: Arend van Spriel <arend@broadcom.com>
Whatever you think is most appropriate.
Regards,
Arend
^ permalink raw reply
* Re: Specifying priority for management frames?
From: Ben Greear @ 2013-09-06 21:22 UTC (permalink / raw)
To: linux-wireless@vger.kernel.org
In-Reply-To: <5228CD6B.5010209@candelatech.com>
On 09/05/2013 11:28 AM, Ben Greear wrote:
> On 09/05/2013 11:17 AM, Ben Greear wrote:
>> While debugging a problem with group-rekeys, we noticed that the sniffer (on external machine)
>> reported management packets are sent in the best-effort QoS queue.
>>
>> It seems to me that these should be in the VO queue instead, or at least
>> we should be able to specify the queue in supplicant when sending the frames?
>
>
> Hrmm, actually it appears the mac80211 layer tries to send on VO. Maybe
> some of my hackings are messing this up...I'll go dig deeper.
I've dug a bit deeper, but not all the way I guess.
When I sniff on a separate machine, the EAP packets still
show QoS being 'Best Effort' in wireshark.
UDP data packets sent with proper IP TOS show up in
VI or VO as specified.
So, I think this means that either the EAP packets are not actually
going out the VO queue, or they are somehow missing some wifi QoS config
in their header.
I just tested this with the latest wireless-testing tree, totally un-modified.
The sniffer is running my standard set of patches, but I doubt that matters
since it does properly show QoS on UDP packets.
I'll go look to see if I can figure out where the wifi frame TOS bits
are configured..but if someone has suggestions, let me know!
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* [PATCH 3.12] bcma: fix error code handling on 64 Bit systems
From: Hauke Mehrtens @ 2013-09-07 15:02 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, zajec5, arend, Hauke Mehrtens
On most 64 Bit systems unsigned long is 64 bit long and then -MAX_ERRNO
is out of the range of a u32 used to store the error code in.
This patch casts the -MAX_ERRNO to a u32 instead.
This fixes a regression introduced in:
commit fd4edf197544bae1c77d84bad354aa7ce1d08ce1
Author: Hauke Mehrtens <hauke@hauke-m.de>
Date: Mon Jul 15 13:15:08 2013 +0200
bcma: fix handling of big addrl
Reported-by: Arend van Spriel <arend@broadcom.com>
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Tested-by: Arend van Spriel <arend@broadcom.com>
---
drivers/bcma/scan.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/bcma/scan.c b/drivers/bcma/scan.c
index cd6b20f..3776840 100644
--- a/drivers/bcma/scan.c
+++ b/drivers/bcma/scan.c
@@ -269,6 +269,8 @@ static struct bcma_device *bcma_find_core_reverse(struct bcma_bus *bus, u16 core
return NULL;
}
+#define IS_ERR_VALUE_U32(x) ((x) >= (u32)-MAX_ERRNO)
+
static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
struct bcma_device_id *match, int core_num,
struct bcma_device *core)
@@ -351,11 +353,11 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
* the main register space for the core
*/
tmp = bcma_erom_get_addr_desc(bus, eromptr, SCAN_ADDR_TYPE_SLAVE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
/* Try again to see if it is a bridge */
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_BRIDGE, 0);
- if (tmp == 0 || IS_ERR_VALUE(tmp)) {
+ if (tmp == 0 || IS_ERR_VALUE_U32(tmp)) {
return -EILSEQ;
} else {
bcma_info(bus, "Bridge found\n");
@@ -369,7 +371,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SLAVE, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: slave port %d "
* "has %d descriptors\n", i, j); */
@@ -386,7 +388,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_MWRAP, i);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* "has %d descriptors\n", i, j); */
@@ -404,7 +406,7 @@ static int bcma_get_next_core(struct bcma_bus *bus, u32 __iomem **eromptr,
for (j = 0; ; j++) {
tmp = bcma_erom_get_addr_desc(bus, eromptr,
SCAN_ADDR_TYPE_SWRAP, i + hack);
- if (IS_ERR_VALUE(tmp)) {
+ if (IS_ERR_VALUE_U32(tmp)) {
/* no more entries for port _i_ */
/* pr_debug("erom: master wrapper %d "
* has %d descriptors\n", i, j); */
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH v2] mac80211: fix the setting of extended supported rate IE
From: Thomas Pedersen @ 2013-09-08 6:20 UTC (permalink / raw)
To: Chun-Yeow Yeoh
Cc: linux-wireless, Johannes Berg, John Linville, open11s,
distro11s@cozybit.com, Colleen Twitty
In-Reply-To: <1378408479-1025-1-git-send-email-yeohchunyeow@cozybit.com>
On Thu, Sep 5, 2013 at 12:14 PM, Chun-Yeow Yeoh
<yeohchunyeow@cozybit.com> wrote:
> The patch "mac80211: select and adjust bitrates according to
> channel mode" causes regression and breaks the extended supported rate
> IE setting. Since "i" is starting with 8, so this is not necessary
> to introduce "skip" here.
>
> Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com>
> Signed-off-by: Colleen Twitty <colleen@cozybit.com>
> Reviewed-by: Jason Abele <jason@cozybit.com>
> ---
> v2: remove skip (Jason)
>
> net/mac80211/util.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/net/mac80211/util.c b/net/mac80211/util.c
> index 3c8283b..4bb639f 100644
> --- a/net/mac80211/util.c
> +++ b/net/mac80211/util.c
> @@ -2128,14 +2128,11 @@ int ieee80211_add_ext_srates_ie(struct ieee80211_sub_if_data *sdata,
> pos = skb_put(skb, exrates + 2);
> *pos++ = WLAN_EID_EXT_SUPP_RATES;
> *pos++ = exrates;
> - skip = 0;
You could also remove the declaration then?
--
Thomas
^ permalink raw reply
* Re: [PATCH] cfg80211: Pass station supported channel and oper class info to kernel
From: Sunil Dutt @ 2013-09-08 6:32 UTC (permalink / raw)
To: Sunil Dutt; +Cc: Johannes Berg, linux-wireless, j, Deepak (QCA), Ashwani
In-Reply-To: <1377582278-3768-1-git-send-email-c_duttus@qti.qualcomm.com>
Hi Johannes,
Can you please help in reviewing the patch and upstream the same.
Regards,
Sunil
On Tue, Aug 27, 2013 at 11:14 AM, Sunil Dutt <c_duttus@qti.qualcomm.com> wrote:
> The information of the peer's supported channels and supported operating
> classes are required for the driver to perform TDLS off channel
> operations. This commit enhances the function nl80211_(new)set_station
> to pass this information of the peer to the driver.
>
> Signed-off-by: Sunil Dutt <c_duttus@qti.qualcomm.com>
> ---
> include/net/cfg80211.h | 8 ++++++++
> include/uapi/linux/nl80211.h | 9 +++++++++
> net/wireless/nl80211.c | 30 ++++++++++++++++++++++++++++++
> 3 files changed, 47 insertions(+)
>
> diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> index 9ab7a06..81889ca 100644
> --- a/include/net/cfg80211.h
> +++ b/include/net/cfg80211.h
> @@ -735,6 +735,10 @@ enum station_parameters_apply_mask {
> * @capability: station capability
> * @ext_capab: extended capabilities of the station
> * @ext_capab_len: number of extended capabilities
> + * @supported_channels: supported channels in IEEE 802.11 format
> + * @supported_channels_len: number of supported channels
> + * @supported_oper_classes: supported oper classes in IEEE 802.11 format
> + * @supported_oper_classes_len: number of supported operating classes
> */
> struct station_parameters {
> const u8 *supported_rates;
> @@ -754,6 +758,10 @@ struct station_parameters {
> u16 capability;
> const u8 *ext_capab;
> u8 ext_capab_len;
> + const u8 *supported_channels;
> + u8 supported_channels_len;
> + const u8 *supported_oper_classes;
> + u8 supported_oper_classes_len;
> };
>
> /**
> diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
> index 1f42bc3..61a21a4 100644
> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -1493,6 +1493,11 @@ enum nl80211_commands {
> * @NL80211_ATTR_CSA_C_OFF_PRESP: Offset of the channel switch counter
> * field in the probe response (%NL80211_ATTR_PROBE_RESP).
> *
> + * @NL80211_ATTR_STA_SUPPORTED_CHANNELS: array of supported channels.
> + *
> + * @NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES: array of supported
> + * supported operating classes.
> + *
> * @NL80211_ATTR_MAX: highest attribute number currently defined
> * @__NL80211_ATTR_AFTER_LAST: internal use
> */
> @@ -1801,6 +1806,10 @@ enum nl80211_attrs {
> NL80211_ATTR_CSA_C_OFF_BEACON,
> NL80211_ATTR_CSA_C_OFF_PRESP,
>
> + NL80211_ATTR_STA_SUPPORTED_CHANNELS,
> +
> + NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES,
> +
> /* add attributes here, update the policy in nl80211.c */
>
> __NL80211_ATTR_AFTER_LAST,
> diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
> index 741368c..0765b9a 100644
> --- a/net/wireless/nl80211.c
> +++ b/net/wireless/nl80211.c
> @@ -354,6 +354,8 @@ static const struct nla_policy nl80211_policy[NL80211_ATTR_MAX+1] = {
> [NL80211_ATTR_CSA_IES] = { .type = NLA_NESTED },
> [NL80211_ATTR_CSA_C_OFF_BEACON] = { .type = NLA_U16 },
> [NL80211_ATTR_CSA_C_OFF_PRESP] = { .type = NLA_U16 },
> + [NL80211_ATTR_STA_SUPPORTED_CHANNELS] = { .type = NLA_BINARY },
> + [NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES] = { .type = NLA_BINARY },
> };
>
> /* policy for the key attributes */
> @@ -3909,6 +3911,20 @@ static int nl80211_set_station_tdls(struct genl_info *info,
> params->vht_capa =
> nla_data(info->attrs[NL80211_ATTR_VHT_CAPABILITY]);
>
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]) {
> + params->supported_channels =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
> + params->supported_channels_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
> + }
> +
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]) {
> + params->supported_oper_classes =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
> + params->supported_oper_classes_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
> + }
> +
> return nl80211_parse_sta_wme(info, params);
> }
>
> @@ -4089,6 +4105,20 @@ static int nl80211_new_station(struct sk_buff *skb, struct genl_info *info)
> return -EINVAL;
> }
>
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]) {
> + params->supported_channels =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
> + params->supported_channels_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_CHANNELS]);
> + }
> +
> + if (info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]) {
> + params->supported_oper_classes =
> + nla_data(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
> + params->supported_oper_classes_len =
> + nla_len(info->attrs[NL80211_ATTR_STA_SUPPORTED_OPER_CLASSES]);
> + }
> +
> err = nl80211_parse_sta_wme(info, ¶ms);
> if (err)
> return err;
> --
> 1.8.2.1
>
> --
> 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
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