* [PATCH v3 1/2] ath10k: Fix bug in max. VHT A-MPDU size
From: Michal Kazior @ 2013-10-08 2:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Sujith Manoharan, Michal Kazior
In-Reply-To: <1381200718-16271-1-git-send-email-michal.kazior@tieto.com>
From: Sujith Manoharan <c_manoha@qca.qualcomm.com>
For VHT peers, the maximum A-MPDU size has to be calculated
from the VHT capabilities element and not the HT-cap. The formula
is the same, but a higher value is used in VHT, allowing larger
aggregates to be transmitted.
The patch contains a workaround for some Netgear/Linksys APs that
report Rx A-MPDU factor incorrectly.
Tested-by: Kalle Valo <kvalo@qca.qualcomm.com>
Signed-off-by: Sujith Manoharan <c_manoha@qca.qualcomm.com>
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v3:
* fix lines over 80 chars (Kalle)
* fix max() cast warning (Kalle)
* add Tested-by
drivers/net/wireless/ath/ath10k/mac.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 4b7c949..049eca2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1033,14 +1033,27 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
struct wmi_peer_assoc_complete_arg *arg)
{
const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
+ u8 ampdu_factor;
if (!vht_cap->vht_supported)
return;
arg->peer_flags |= WMI_PEER_VHT;
-
arg->peer_vht_caps = vht_cap->cap;
+
+ ampdu_factor = (vht_cap->cap &
+ IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK) >>
+ IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_SHIFT;
+
+ /* Workaround: Some Netgear/Linksys 11ac APs set Rx A-MPDU factor to
+ * zero in VHT IE. Using it would result in degraded throughput.
+ * arg->peer_max_mpdu at this point contains HT max_mpdu so keep
+ * it if VHT max_mpdu is smaller. */
+ arg->peer_max_mpdu = max(arg->peer_max_mpdu,
+ (1U << (IEEE80211_HT_MAX_AMPDU_FACTOR +
+ ampdu_factor)) - 1);
+
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= WMI_PEER_80MHZ;
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH v3 2/2] ath10k: fix scheduling while atomic bug
From: Michal Kazior @ 2013-10-08 2:51 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1381200718-16271-1-git-send-email-michal.kazior@tieto.com>
Recent WMI/HTC changes made it possible for WMI
commands to sleep (if there's not enough HTC TX
credits to submit a command). TX path is in an
atomic context so calling WMI commands in it is
wrong.
This simply moves WEP key index update to a worker
and fixes the 'scheduling while atomic' bug.
This still leaves multiple WEP key handling laggy,
i.e. some frames may be TXed with an old/different
key (although recipient should still be able to RX
them).
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/core.h | 4 ++-
drivers/net/wireless/ath/ath10k/mac.c | 53 +++++++++++++++++++++++-----------
2 files changed, 39 insertions(+), 18 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index ce36daa..cef5455 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -215,8 +215,10 @@ struct ath10k_vif {
struct ath10k *ar;
struct ieee80211_vif *vif;
+ struct work_struct wep_key_work;
struct ieee80211_key_conf *wep_keys[WMI_MAX_KEY_INDEX + 1];
- u8 def_wep_key_index;
+ u8 def_wep_key_idx;
+ u8 def_wep_key_newidx;
u16 tx_seq_no;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 049eca2..498514e 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1239,7 +1239,7 @@ static void ath10k_bss_disassoc(struct ieee80211_hw *hw,
/* FIXME: why don't we print error if wmi call fails? */
ret = ath10k_wmi_vdev_down(ar, arvif->vdev_id);
- arvif->def_wep_key_index = 0;
+ arvif->def_wep_key_idx = 0;
}
static int ath10k_station_assoc(struct ath10k *ar, struct ath10k_vif *arvif,
@@ -1467,6 +1467,30 @@ static void ath10k_tx_h_qos_workaround(struct ieee80211_hw *hw,
skb_pull(skb, IEEE80211_QOS_CTL_LEN);
}
+static void ath10k_tx_wep_key_work(struct work_struct *work)
+{
+ struct ath10k_vif *arvif = container_of(work, struct ath10k_vif,
+ wep_key_work);
+ int ret, keyidx = arvif->def_wep_key_newidx;
+
+ if (arvif->def_wep_key_idx == keyidx)
+ return;
+
+ ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d set keyidx %d\n",
+ arvif->vdev_id, keyidx);
+
+ ret = ath10k_wmi_vdev_set_param(arvif->ar,
+ arvif->vdev_id,
+ arvif->ar->wmi.vdev_param->def_keyid,
+ keyidx);
+ if (ret) {
+ ath10k_warn("could not update wep keyidx (%d)\n", ret);
+ return;
+ }
+
+ arvif->def_wep_key_idx = keyidx;
+}
+
static void ath10k_tx_h_update_wep_key(struct sk_buff *skb)
{
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
@@ -1475,8 +1499,6 @@ static void ath10k_tx_h_update_wep_key(struct sk_buff *skb)
struct ath10k *ar = arvif->ar;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
struct ieee80211_key_conf *key = info->control.hw_key;
- u32 vdev_param;
- int ret;
if (!ieee80211_has_protected(hdr->frame_control))
return;
@@ -1488,21 +1510,14 @@ static void ath10k_tx_h_update_wep_key(struct sk_buff *skb)
key->cipher != WLAN_CIPHER_SUITE_WEP104)
return;
- if (key->keyidx == arvif->def_wep_key_index)
- return;
-
- ath10k_dbg(ATH10K_DBG_MAC, "mac vdev %d keyidx %d\n",
- arvif->vdev_id, key->keyidx);
-
- vdev_param = ar->wmi.vdev_param->def_keyid;
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
- key->keyidx);
- if (ret) {
- ath10k_warn("could not update wep keyidx (%d)\n", ret);
+ if (key->keyidx == arvif->def_wep_key_idx)
return;
- }
- arvif->def_wep_key_index = key->keyidx;
+ /* FIXME: Most likely a few frames will be TXed with an old key. Simply
+ * queueing frames until key index is updated is not an option because
+ * sk_buff may need more processing to be done, e.g. offchannel */
+ arvif->def_wep_key_newidx = key->keyidx;
+ ieee80211_queue_work(ar->hw, &arvif->wep_key_work);
}
static void ath10k_tx_h_add_p2p_noa_ie(struct ath10k *ar, struct sk_buff *skb)
@@ -2023,6 +2038,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
arvif->ar = ar;
arvif->vif = vif;
+ INIT_WORK(&arvif->wep_key_work, ath10k_tx_wep_key_work);
+
if ((vif->type == NL80211_IFTYPE_MONITOR) && ar->monitor_present) {
ath10k_warn("Only one monitor interface allowed\n");
ret = -EBUSY;
@@ -2078,7 +2095,7 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
vdev_param = ar->wmi.vdev_param->def_keyid;
ret = ath10k_wmi_vdev_set_param(ar, 0, vdev_param,
- arvif->def_wep_key_index);
+ arvif->def_wep_key_idx);
if (ret)
ath10k_warn("Failed to set default keyid: %d\n", ret);
@@ -2146,6 +2163,8 @@ static void ath10k_remove_interface(struct ieee80211_hw *hw,
mutex_lock(&ar->conf_mutex);
+ cancel_work_sync(&arvif->wep_key_work);
+
spin_lock_bh(&ar->data_lock);
if (arvif->beacon) {
dev_kfree_skb_any(arvif->beacon);
--
1.8.4.rc3
^ permalink raw reply related
* [PATCH] ath10k: fix RX performance when using AP 10.X FW
From: Michal Kazior @ 2013-10-08 3:00 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Due to oversight AP 10.X support was merged with
Ethernet RX decap mode.
Only Native Wifi RX decap mode guarantees IP
header is properly aligned and avoids sk_buff data
realignment (which is very expensive
performance-wise) in mac80211.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
drivers/net/wireless/ath/ath10k/hw.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/hw.h b/drivers/net/wireless/ath/ath10k/hw.h
index 3fd7b98..8aeb46d 100644
--- a/drivers/net/wireless/ath/ath10k/hw.h
+++ b/drivers/net/wireless/ath/ath10k/hw.h
@@ -123,7 +123,7 @@ enum ath10k_mcast2ucast_mode {
#define TARGET_10X_RX_CHAIN_MASK (BIT(0) | BIT(1) | BIT(2))
#define TARGET_10X_RX_TIMEOUT_LO_PRI 100
#define TARGET_10X_RX_TIMEOUT_HI_PRI 40
-#define TARGET_10X_RX_DECAP_MODE ATH10K_HW_TXRX_ETHERNET
+#define TARGET_10X_RX_DECAP_MODE ATH10K_HW_TXRX_NATIVE_WIFI
#define TARGET_10X_SCAN_MAX_PENDING_REQS 4
#define TARGET_10X_BMISS_OFFLOAD_MAX_VDEV 2
#define TARGET_10X_ROAM_OFFLOAD_MAX_VDEV 2
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH V2] memstick: Fix memory leak in memstick_check() error path
From: Larry Finger @ 2013-10-08 3:12 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linville, Alex Dubov, linux-wireless, linux-kernel, Kay Sievers
In-Reply-To: <20131008021304.GB32733@kroah.com>
On 10/07/2013 09:13 PM, Greg Kroah-Hartman wrote:
> On Sun, Oct 06, 2013 at 10:21:51PM -0500, Larry Finger wrote:
>> With kernel 3.12-rc3, kmemleak reports the following leak:
>>
>>> unreferenced object 0xffff8800ae85c190 (size 16):
>>> comm "kworker/u4:3", pid 685, jiffies 4294916336 (age 2831.760s)
>>> hex dump (first 16 bytes):
>>> 6d 65 6d 73 74 69 63 6b 30 00 00 00 00 00 00 00 memstick0.......
>>> backtrace:
>>> [<ffffffff8146a0d1>] kmemleak_alloc+0x21/0x50
>>> [<ffffffff81160720>] __kmalloc_track_caller+0x160/0x2f0
>>> [<ffffffff81237b9b>] kvasprintf+0x5b/0x90
>>> [<ffffffff8122c0c1>] kobject_set_name_vargs+0x21/0x60
>>> [<ffffffff812e7f5c>] dev_set_name+0x3c/0x40
>>> [<ffffffffa02bf918>] memstick_check+0xb8/0x340 [memstick]
>>> [<ffffffff81069862>] process_one_work+0x1d2/0x670
>>> [<ffffffff8106a88a>] worker_thread+0x11a/0x370
>>> [<ffffffff81072ea6>] kthread+0xd6/0xe0
>>> [<ffffffff81478bbc>] ret_from_fork+0x7c/0xb0
>>
>> This problem was introduced by commit 0252c3b "memstick: struct device -
>> replace bus_id with dev_name(), dev_set_name()" where the name is not freed
>> in the error path. The name is also leaked in memstick_free_card().
>>
>> Thanks to Catalin Marinas for suggesting the fix.
>>
>> Cc: Kay Sievers <kay.sievers@vrfy.org>
>> Cc: Alex Dubov <oakad@yahoo.com>
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
>> ---
>>
>> V2 fixes the typos in the commit message, and frees the name in
>> memstick_free_card() as well as the error path in memstick_check().
>
> Looking back at this, to try to figure out why the kmemleak report shows
> up, shows that this is a mess. Why would we be erroring out _before_ we
> try to register the struct device with the driver core, yet we had
> already initialized the struct device structure? Only set up the
> structure right before sending it to driver core, don't delay in
> allocation, only problems can happen (like here.)
>
> To fix this up, will take some major work, which I can't do, sorry, but
> this patch will not work either.
Thanks for the analysis. My interest is getting rid of memory leaks from other
sources so that the leaks from my drivers are more obvious.
Perhaps Alex will pick this up and do the rewrite.
Please drop both patches.
Larry
^ permalink raw reply
* RE: [Ilw] Driver for 7260-AC (Mint15)
From: Grumbach, Emmanuel @ 2013-10-08 5:27 UTC (permalink / raw)
To: Steve NJ, linux-wireless@vger.kernel.org; +Cc: ilw@linux.intel.com
In-Reply-To: <CAK6YWsnC=wLcHGOpcp01rpbEL2Ns=Ds0j=758WkheD0DOuhcQA@mail.gmail.com>
>Hello,
>Mint15 does not recognize the the new 7260-AC card outright. and the installation instruction are lackluster at http://wireless.kernel.org/en/users/Drivers/iwlwifi
>Could you give me a headups how to get it working.
>Thanx
>--S
Please contact your distro. This device is supported starting kernel 3.11. You can also opt for the backport solution: https://backports.wiki.kernel.org/index.php/Main_Page.
^ permalink raw reply
* ath10k: ath-next-test branch for testing patches
From: Kalle Valo @ 2013-10-08 5:56 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless
Hi,
I have noticed that Fengguan's build tests are really helpful, his build
bot has found quite a few issues. To make more use of the buildbot I
have been experimenting with ath-next-test branch for running various
tests. So I'm planning to change the ath10k patch flow to this:
1. patch gets posted to the mailing lists
2. patch is immediately applied to ath-next-test
3. waiting two business days for patch being under review (unless the patch
is urgent)
4. if no comments or warnings, the patch is applied to ath-next branch
5. ath-next is merged to master branch
6. ath-next pull requests are sent once a week (or so)
Thoughts?
--
Kalle Valo
^ permalink raw reply
* RE: [PATCH] mac80211: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
From: David Laight @ 2013-10-08 8:33 UTC (permalink / raw)
To: djduanjiong, Johannes Berg, John W. Linville, David S. Miller
Cc: linux-wireless, netdev, Duan Jiong
In-Reply-To: <1381190953-6362-1-git-send-email-duanj.fnst@cn.fujitsu.com>
> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
> ---
> net/mac80211/key.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/mac80211/key.c b/net/mac80211/key.c
> index 620677e..3e51dd7 100644
> --- a/net/mac80211/key.c
> +++ b/net/mac80211/key.c
> @@ -879,7 +879,7 @@ ieee80211_gtk_rekey_add(struct ieee80211_vif *vif,
> keyconf->keylen, keyconf->key,
> 0, NULL);
> if (IS_ERR(key))
> - return ERR_PTR(PTR_ERR(key));
> + return ERR_CAST(key);
I suspect the old code is a deliberate attempt to indicate that it
the error value that is being returned rather than the pointer.
Looking higher up that file there seems to be a fubar when setting
up the TKIP key.
It seems to put the same 6 bytes into every TID.
(I'm sure seq_len shouldn't be ignored either.0
David
^ permalink raw reply
* Re: [PATCH] mac80211: Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...))
From: Johannes Berg @ 2013-10-08 8:37 UTC (permalink / raw)
To: David Laight
Cc: djduanjiong, John W. Linville, David S. Miller, linux-wireless,
netdev, Duan Jiong
In-Reply-To: <AE90C24D6B3A694183C094C60CF0A2F6026B7379@saturn3.aculab.com>
On Tue, 2013-10-08 at 09:33 +0100, David Laight wrote:
> > if (IS_ERR(key))
> > - return ERR_PTR(PTR_ERR(key));
> > + return ERR_CAST(key);
>
> I suspect the old code is a deliberate attempt to indicate that it
> the error value that is being returned rather than the pointer.
I was under the impression that's what ERR_CAST means.
> Looking higher up that file there seems to be a fubar when setting
> up the TKIP key.
> It seems to put the same 6 bytes into every TID.
> (I'm sure seq_len shouldn't be ignored either.0
Both are fine.
johannes
^ permalink raw reply
* [PATCH] nl80211: vendor command support
From: Johannes Berg @ 2013-10-08 8:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
Add support for vendor-specific commands to nl80211. This is
intended to be used for really vendor-specific functionality
that can't be implemented in a generic fashion for any reason.
It's *NOT* intended to be used for any normal/generic feature
or any optimisations that could be implemented across drivers.
Currently, only vendor commands (with replies) are supported,
no dump operations or vendor-specific notifications.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 108 +++++++++++++++++++-
include/uapi/linux/nl80211.h | 41 ++++++++
net/wireless/core.h | 4 +-
net/wireless/nl80211.c | 235 ++++++++++++++++++++++++++++++-------------
4 files changed, 314 insertions(+), 74 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 45f6bf5..9297ca0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2664,6 +2664,26 @@ struct wiphy_coalesce_support {
};
/**
+ * enum wiphy_vendor_command_flags - validation flags for vendor commands
+ * @WIPHY_VENDOR_CMD_NEED_WDEV: vendor command requires wdev
+ * @WIPHY_VENDOR_CMD_NEED_NETDEV: vendor command requires netdev
+ * @WIPHY_VENDOR_CMD_NEED_RUNNING: interface/wdev must be up & running
+ * (must be combined with %_WDEV or %_NETDEV)
+ */
+enum wiphy_vendor_command_flags {
+ WIPHY_VENDOR_CMD_NEED_WDEV = BIT(0),
+ WIPHY_VENDOR_CMD_NEED_NETDEV = BIT(1),
+ WIPHY_VENDOR_CMD_NEED_RUNNING = BIT(2),
+};
+
+struct wiphy_vendor_command {
+ struct nl80211_vendor_cmd_info info;
+ u32 flags;
+ int (*doit)(struct wiphy *wiphy, struct wireless_dev *wdev,
+ void *data, int data_len);
+};
+
+/**
* struct wiphy - wireless hardware description
* @reg_notifier: the driver's regulatory notification callback,
* note that if your driver uses wiphy_apply_custom_regulatory()
@@ -2774,6 +2794,9 @@ struct wiphy_coalesce_support {
* @extended_capabilities_mask: mask of the valid values
* @extended_capabilities_len: length of the extended capabilities
* @coalesce: packet coalescing support information
+ *
+ * @vendor_commands: array of vendor commands supported by the hardware
+ * @n_vendor_commands: number of vendor commands
*/
struct wiphy {
/* assign these fields before you register the wiphy */
@@ -2885,6 +2908,9 @@ struct wiphy {
const struct wiphy_coalesce_support *coalesce;
+ const struct wiphy_vendor_command *vendor_commands;
+ int n_vendor_commands;
+
char priv[0] __aligned(NETDEV_ALIGN);
};
@@ -3815,6 +3841,75 @@ void wiphy_rfkill_start_polling(struct wiphy *wiphy);
*/
void wiphy_rfkill_stop_polling(struct wiphy *wiphy);
+/**
+ * DOC: Vendor commands
+ *
+ * Occasionally, there are special protocol or firmware features that
+ * can't be implemented very openly. For this and similar cases, the
+ * vendor command functionality allows implementing the features with
+ * (typically closed-source) userspace and firmware, using nl80211 as
+ * the configuration mechanism.
+ *
+ * A driver supporting vendor commands must register them as an array
+ * in struct wiphy, with handlers for each one, each command has an
+ * OUI and sub command ID to identify it.
+ *
+ * Note that this feature should not be (ab)used to implement protocol
+ * features that could openly be shared across drivers. In particular,
+ * it must never be required to use vendor commands to implement any
+ * "normal" functionality that higher-level userspace like connection
+ * managers etc. need.
+ */
+
+struct sk_buff *__cfg80211_alloc_reply_skb(struct wiphy *wiphy,
+ enum nl80211_commands cmd,
+ enum nl80211_attrs attr,
+ int approxlen);
+
+/**
+ * cfg80211_vendor_cmd_alloc_reply_skb - allocate vendor command reply
+ * @wiphy: the wiphy
+ * @approxlen: an upper bound of the length of the data that will
+ * be put into the skb
+ *
+ * This function allocates and pre-fills an skb for a reply to
+ * a vendor command. Since it is intended for a reply, calling
+ * it outside of a vendor command's doit() operation is invalid.
+ *
+ * The returned skb is pre-filled with some identifying data in
+ * a way that any data that is put into the skb (with skb_put(),
+ * nla_put() or similar) will end up being within the
+ * %NL80211_ATTR_VENDOR_DATA attribute, so all that needs to be done
+ * with the skb is adding data for the corresponding userspace tool
+ * which can then read that data out of the testdata attribute. You
+ * must not modify the skb in any other way.
+ *
+ * When done, call cfg80211_vendor_cmd_reply() with the skb and return
+ * its error code as the result of the doit() operation.
+ *
+ * Return: An allocated and pre-filled skb. %NULL if any errors happen.
+ */
+static inline struct sk_buff *
+cfg80211_vendor_cmd_alloc_reply_skb(struct wiphy *wiphy, int approxlen)
+{
+ return __cfg80211_alloc_reply_skb(wiphy, NL80211_CMD_TESTMODE,
+ NL80211_ATTR_TESTDATA, approxlen);
+}
+
+/**
+ * cfg80211_vendor_cmd_reply - send the reply skb
+ * @skb: The skb, must have been allocated with
+ * cfg80211_vendor_cmd_alloc_reply_skb()
+ *
+ * Since calling this function will usually be the last thing
+ * before returning from the vendor command doit() you should
+ * return the error code. Note that this function consumes the
+ * skb regardless of the return value.
+ *
+ * Return: An error code or 0 on success.
+ */
+int cfg80211_vendor_cmd_reply(struct sk_buff *skb);
+
#ifdef CONFIG_NL80211_TESTMODE
/**
* DOC: Test mode
@@ -3850,8 +3945,12 @@ void wiphy_rfkill_stop_polling(struct wiphy *wiphy);
*
* Return: An allocated and pre-filled skb. %NULL if any errors happen.
*/
-struct sk_buff *cfg80211_testmode_alloc_reply_skb(struct wiphy *wiphy,
- int approxlen);
+static inline struct sk_buff *
+cfg80211_testmode_alloc_reply_skb(struct wiphy *wiphy, int approxlen)
+{
+ return __cfg80211_alloc_reply_skb(wiphy, NL80211_CMD_TESTMODE,
+ NL80211_ATTR_TESTDATA, approxlen);
+}
/**
* cfg80211_testmode_reply - send the reply skb
@@ -3865,7 +3964,10 @@ struct sk_buff *cfg80211_testmode_alloc_reply_skb(struct wiphy *wiphy,
*
* Return: An error code or 0 on success.
*/
-int cfg80211_testmode_reply(struct sk_buff *skb);
+static inline int cfg80211_testmode_reply(struct sk_buff *skb)
+{
+ return cfg80211_vendor_cmd_reply(skb);
+}
/**
* cfg80211_testmode_alloc_event_skb - allocate testmode event
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index fde2c02..d0a479a 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -686,6 +686,15 @@
* other station that transmission must be blocked until the channel
* switch is complete.
*
+ * @NL80211_CMD_VENDOR: Vendor-specified command/event. The command is specified
+ * by the %NL80211_ATTR_VENDOR_ID attribute and a sub-command in
+ * %NL80211_ATTR_VENDOR_SUBCMD. Parameter(s) can be transported in
+ * %NL80211_ATTR_VENDOR_DATA.
+ * For feature advertisement, the %NL80211_ATTR_VENDOR_DATA attribute is
+ * used in the wiphy data as a nested attribute containing descriptions
+ * (&struct nl80211_vendor_cmd_info) of the supported vendor commands.
+ * This may also be sent as an event with the same attributes.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -853,6 +862,8 @@ enum nl80211_commands {
NL80211_CMD_CHANNEL_SWITCH,
+ NL80211_CMD_VENDOR,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -1496,6 +1507,12 @@ enum nl80211_commands {
* @NL80211_ATTR_RXMGMT_FLAGS: flags for nl80211_send_mgmt(), u32.
* As specified in the &enum nl80211_rxmgmt_flags.
*
+ * @NL80211_ATTR_VENDOR_ID: The vendor ID, either a 24-bit OUI or, if
+ * %NL80211_VENDOR_ID_IS_LINUX is set, a special Linux ID (not used yet)
+ * @NL80211_ATTR_VENDOR_SUBCMD: vendor sub-command
+ * @NL80211_ATTR_VENDOR_DATA: data for the vendor command, if any; this
+ * attribute is also used for vendor command feature advertisement
+ *
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
*/
@@ -1806,6 +1823,10 @@ enum nl80211_attrs {
NL80211_ATTR_RXMGMT_FLAGS,
+ NL80211_ATTR_VENDOR_ID,
+ NL80211_ATTR_VENDOR_SUBCMD,
+ NL80211_ATTR_VENDOR_DATA,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
@@ -3917,4 +3938,24 @@ enum nl80211_rxmgmt_flags {
NL80211_RXMGMT_FLAG_ANSWERED = 1 << 0,
};
+/*
+ * If this flag is unset, the lower 24 bits are an OUI, if set
+ * a Linux nl80211 vendor ID is used (no such IDs are allocated
+ * yet, so that's not valid so far)
+ */
+#define NL80211_VENDOR_ID_IS_LINUX 0x80000000
+
+/**
+ * struct nl80211_vendor_cmd_info - vendor command data
+ * @vendor_id: If the %NL80211_VENDOR_ID_IS_LINUX flag is clear, then the
+ * value is a 24-bit OUI; if it is set then a separately allocated ID
+ * may be used, but no such IDs are allocated yet. New IDs should be
+ * added to this file when needed.
+ * @subcmd: sub-command ID for the command
+ */
+struct nl80211_vendor_cmd_info {
+ u32 vendor_id;
+ u32 subcmd;
+};
+
#endif /* __LINUX_NL80211_H */
diff --git a/net/wireless/core.h b/net/wireless/core.h
index b43efac..296c101 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -67,9 +67,7 @@ struct cfg80211_registered_device {
struct work_struct scan_done_wk;
struct work_struct sched_scan_results_wk;
-#ifdef CONFIG_NL80211_TESTMODE
- struct genl_info *testmode_info;
-#endif
+ struct genl_info *cur_cmd_info;
struct work_struct conn_work;
struct work_struct event_work;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 2838206..92d34e4 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -354,6 +354,9 @@ 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_VENDOR_ID] = { .type = NLA_U32 },
+ [NL80211_ATTR_VENDOR_SUBCMD] = { .type = NLA_U32 },
+ [NL80211_ATTR_VENDOR_DATA] = { .type = NLA_BINARY },
};
/* policy for the key attributes */
@@ -1151,6 +1154,7 @@ struct nl80211_dump_wiphy_state {
s64 filter_wiphy;
long start;
long split_start, band_start, chan_start;
+ long vendor_start;
bool split;
};
@@ -1162,6 +1166,7 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *dev,
struct nlattr *nl_bands, *nl_band;
struct nlattr *nl_freqs, *nl_freq;
struct nlattr *nl_cmds;
+ struct nlattr *nl_vendor_cmds;
enum ieee80211_band band;
struct ieee80211_channel *chan;
int i;
@@ -1556,6 +1561,20 @@ static int nl80211_send_wiphy(struct cfg80211_registered_device *dev,
case 10:
if (nl80211_send_coalesce(msg, dev))
goto nla_put_failure;
+ state->split_start++;
+ break;
+ case 11:
+ nl_vendor_cmds = nla_nest_start(msg, NL80211_ATTR_VENDOR_DATA);
+ if (!nl_vendor_cmds)
+ goto nla_put_failure;
+
+ for (i = state->vendor_start;
+ i < dev->wiphy.n_vendor_commands; i++)
+ if (nla_put(msg, i + 1,
+ sizeof(struct nl80211_vendor_cmd_info),
+ &dev->wiphy.vendor_commands[i].info))
+ goto nla_put_failure;
+ nla_nest_end(msg, nl_vendor_cmds);
/* done */
state->split_start = 0;
@@ -6605,6 +6624,40 @@ static int nl80211_set_mcast_rate(struct sk_buff *skb, struct genl_info *info)
return err;
}
+static struct sk_buff *
+__cfg80211_alloc_vendor_skb(struct cfg80211_registered_device *rdev,
+ int approxlen, u32 portid, u32 seq,
+ enum nl80211_commands cmd,
+ enum nl80211_attrs attr, gfp_t gfp)
+{
+ struct sk_buff *skb;
+ void *hdr;
+ struct nlattr *data;
+
+ skb = nlmsg_new(approxlen + 100, gfp);
+ if (!skb)
+ return NULL;
+
+ hdr = nl80211hdr_put(skb, portid, seq, 0, cmd);
+ if (!hdr) {
+ kfree_skb(skb);
+ return NULL;
+ }
+
+ if (nla_put_u32(skb, NL80211_ATTR_WIPHY, rdev->wiphy_idx))
+ goto nla_put_failure;
+ data = nla_nest_start(skb, attr);
+
+ ((void **)skb->cb)[0] = rdev;
+ ((void **)skb->cb)[1] = hdr;
+ ((void **)skb->cb)[2] = data;
+
+ return skb;
+
+ nla_put_failure:
+ kfree_skb(skb);
+ return NULL;
+}
#ifdef CONFIG_NL80211_TESTMODE
static struct genl_multicast_group nl80211_testmode_mcgrp = {
@@ -6633,11 +6686,11 @@ static int nl80211_testmode_do(struct sk_buff *skb, struct genl_info *info)
if (!info->attrs[NL80211_ATTR_TESTDATA])
return -EINVAL;
- rdev->testmode_info = info;
+ rdev->cur_cmd_info = info;
err = rdev_testmode_cmd(rdev, wdev,
nla_data(info->attrs[NL80211_ATTR_TESTDATA]),
nla_len(info->attrs[NL80211_ATTR_TESTDATA]));
- rdev->testmode_info = NULL;
+ rdev->cur_cmd_info = NULL;
return err;
}
@@ -6737,77 +6790,14 @@ static int nl80211_testmode_dump(struct sk_buff *skb,
return err;
}
-static struct sk_buff *
-__cfg80211_testmode_alloc_skb(struct cfg80211_registered_device *rdev,
- int approxlen, u32 portid, u32 seq, gfp_t gfp)
-{
- struct sk_buff *skb;
- void *hdr;
- struct nlattr *data;
-
- skb = nlmsg_new(approxlen + 100, gfp);
- if (!skb)
- return NULL;
-
- hdr = nl80211hdr_put(skb, portid, seq, 0, NL80211_CMD_TESTMODE);
- if (!hdr) {
- kfree_skb(skb);
- return NULL;
- }
-
- if (nla_put_u32(skb, NL80211_ATTR_WIPHY, rdev->wiphy_idx))
- goto nla_put_failure;
- data = nla_nest_start(skb, NL80211_ATTR_TESTDATA);
-
- ((void **)skb->cb)[0] = rdev;
- ((void **)skb->cb)[1] = hdr;
- ((void **)skb->cb)[2] = data;
-
- return skb;
-
- nla_put_failure:
- kfree_skb(skb);
- return NULL;
-}
-
-struct sk_buff *cfg80211_testmode_alloc_reply_skb(struct wiphy *wiphy,
- int approxlen)
-{
- struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
-
- if (WARN_ON(!rdev->testmode_info))
- return NULL;
-
- return __cfg80211_testmode_alloc_skb(rdev, approxlen,
- rdev->testmode_info->snd_portid,
- rdev->testmode_info->snd_seq,
- GFP_KERNEL);
-}
-EXPORT_SYMBOL(cfg80211_testmode_alloc_reply_skb);
-
-int cfg80211_testmode_reply(struct sk_buff *skb)
-{
- struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
- void *hdr = ((void **)skb->cb)[1];
- struct nlattr *data = ((void **)skb->cb)[2];
-
- if (WARN_ON(!rdev->testmode_info)) {
- kfree_skb(skb);
- return -EINVAL;
- }
-
- nla_nest_end(skb, data);
- genlmsg_end(skb, hdr);
- return genlmsg_reply(skb, rdev->testmode_info);
-}
-EXPORT_SYMBOL(cfg80211_testmode_reply);
-
struct sk_buff *cfg80211_testmode_alloc_event_skb(struct wiphy *wiphy,
int approxlen, gfp_t gfp)
{
struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
- return __cfg80211_testmode_alloc_skb(rdev, approxlen, 0, 0, gfp);
+ return __cfg80211_alloc_vendor_skb(rdev, approxlen, 0, 0,
+ NL80211_CMD_TESTMODE,
+ NL80211_ATTR_TESTDATA, gfp);
}
EXPORT_SYMBOL(cfg80211_testmode_alloc_event_skb);
@@ -8791,6 +8781,108 @@ static int nl80211_crit_protocol_stop(struct sk_buff *skb,
return 0;
}
+static int nl80211_vendor_cmd(struct sk_buff *skb, struct genl_info *info)
+{
+ struct cfg80211_registered_device *rdev = info->user_ptr[0];
+ struct wireless_dev *wdev =
+ __cfg80211_wdev_from_attrs(genl_info_net(info), info->attrs);
+ int i, err;
+ u32 vid, subcmd;
+
+ if (!rdev->wiphy.vendor_commands)
+ return -EOPNOTSUPP;
+
+ if (IS_ERR(wdev)) {
+ err = PTR_ERR(wdev);
+ if (err != -EINVAL)
+ return err;
+ wdev = NULL;
+ } else if (wdev->wiphy != &rdev->wiphy) {
+ return -EINVAL;
+ }
+
+ if (!info->attrs[NL80211_ATTR_VENDOR_ID] ||
+ !info->attrs[NL80211_ATTR_VENDOR_SUBCMD])
+ return -EINVAL;
+
+ vid = nla_get_u32(info->attrs[NL80211_ATTR_VENDOR_ID]);
+ subcmd = nla_get_u32(info->attrs[NL80211_ATTR_VENDOR_SUBCMD]);
+ for (i = 0; i < rdev->wiphy.n_vendor_commands; i++) {
+ const struct wiphy_vendor_command *vcmd;
+ void *data = NULL;
+ int len = 0;
+
+ vcmd = &rdev->wiphy.vendor_commands[i];
+
+ if (vcmd->info.vendor_id != vid || vcmd->info.subcmd != subcmd)
+ continue;
+
+ if (vcmd->flags & (WIPHY_VENDOR_CMD_NEED_WDEV |
+ WIPHY_VENDOR_CMD_NEED_NETDEV)) {
+ if (!wdev)
+ return -EINVAL;
+ if (vcmd->flags & WIPHY_VENDOR_CMD_NEED_NETDEV &&
+ !wdev->netdev)
+ return -EINVAL;
+
+ if (vcmd->flags & WIPHY_VENDOR_CMD_NEED_RUNNING) {
+ if (wdev->netdev &&
+ !netif_running(wdev->netdev))
+ return -ENETDOWN;
+ else if (!wdev->p2p_started)
+ return -ENETDOWN;
+ }
+ } else {
+ wdev = NULL;
+ }
+
+ if (info->attrs[NL80211_ATTR_VENDOR_DATA]) {
+ data = nla_data(info->attrs[NL80211_ATTR_VENDOR_DATA]);
+ len = nla_len(info->attrs[NL80211_ATTR_VENDOR_DATA]);
+ }
+
+ return rdev->wiphy.vendor_commands[i].doit(&rdev->wiphy, wdev,
+ data, len);
+ }
+
+ return -EOPNOTSUPP;
+}
+
+struct sk_buff *__cfg80211_alloc_reply_skb(struct wiphy *wiphy,
+ enum nl80211_commands cmd,
+ enum nl80211_attrs attr,
+ int approxlen)
+{
+ struct cfg80211_registered_device *rdev = wiphy_to_dev(wiphy);
+
+ if (WARN_ON(!rdev->cur_cmd_info))
+ return NULL;
+
+ return __cfg80211_alloc_vendor_skb(rdev, approxlen,
+ rdev->cur_cmd_info->snd_portid,
+ rdev->cur_cmd_info->snd_seq,
+ cmd, attr, GFP_KERNEL);
+}
+EXPORT_SYMBOL(__cfg80211_alloc_reply_skb);
+
+int cfg80211_vendor_cmd_reply(struct sk_buff *skb)
+{
+ struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
+ void *hdr = ((void **)skb->cb)[1];
+ struct nlattr *data = ((void **)skb->cb)[2];
+
+ if (WARN_ON(!rdev->cur_cmd_info)) {
+ kfree_skb(skb);
+ return -EINVAL;
+ }
+
+ nla_nest_end(skb, data);
+ genlmsg_end(skb, hdr);
+ return genlmsg_reply(skb, rdev->cur_cmd_info);
+}
+EXPORT_SYMBOL(cfg80211_vendor_cmd_reply);
+
+
#define NL80211_FLAG_NEED_WIPHY 0x01
#define NL80211_FLAG_NEED_NETDEV 0x02
#define NL80211_FLAG_NEED_RTNL 0x04
@@ -9515,6 +9607,13 @@ static struct genl_ops nl80211_ops[] = {
.internal_flags = NL80211_FLAG_NEED_NETDEV_UP |
NL80211_FLAG_NEED_RTNL,
},
+ {
+ .cmd = NL80211_CMD_VENDOR,
+ .doit = nl80211_vendor_cmd,
+ .policy = nl80211_policy,
+ .flags = GENL_ADMIN_PERM,
+ .internal_flags = NL80211_FLAG_NEED_RTNL,
+ },
};
static struct genl_multicast_group nl80211_mlme_mcgrp = {
--
1.8.4.rc3
^ permalink raw reply related
* Re: [PATCH] cfg80211: fix nl80211.h documentation for DFS enum states
From: Johannes Berg @ 2013-10-08 8:54 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <1381188475-5195-1-git-send-email-mcgrof@do-not-panic.com>
On Mon, 2013-10-07 at 16:27 -0700, Luis R. Rodriguez wrote:
> The names are prefixed incorrectly on the documentation.
Applied, thanks.
johannes
^ permalink raw reply
* Re: [regression] [bisected] rt2800pci doesn't work after 9483f40d8d01918b399b4e24d0c1111db0afffeb
From: Stanislaw Gruszka @ 2013-10-08 9:35 UTC (permalink / raw)
To: Kirill Tkhai
Cc: linux-wireless@vger.kernel.org, linville@tuxdriver.com,
ivdoorn@gmail.com, gwingerde@gmail.com,
helmut.schaa@googlemail.com
In-Reply-To: <85301381147490@web10g.yandex.ru>
On Mon, Oct 07, 2013 at 04:04:50PM +0400, Kirill Tkhai wrote:
> If sometimes you need testing the driver on device with IDs like I wrote I'm ready
> to help with this.
If you would like to do early testing of rt2x00 patches you can subscribe to:
http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
Traffic on that mailing list isn't high and early detected regressions
are always welcome.
Stanislaw
^ permalink raw reply
* WIFI P2P ping doesn't work.
From: Matt Chen @ 2013-10-08 9:57 UTC (permalink / raw)
To: linux-wireless
Hi list,
I am running the v3.12-rc3 and using Atheros AR9485 with ath9k. My
wpa_supplicant is from git://w1.fi/srv/git/hostap.git in master branch
with most recent commit.
The my_p2p_supplicant.conf for my wpa_supplicant is :
=======================================
ctrl=/var/run/wpa_supplicant
update_config=1
device_name=HP GO
device_type=1-0050F204-2
p2p_go_ht40=1
=========================================
I run "wpa_supplicant -i wlan0 -f my_p2p_supplicant.conf -Dnl80211
-ddt -f /var/log/wpa_supplicant -B
I use wpa_cli to work on P2P. So here goes my case:
M#1
p2p_find
p2p_stop
p2p_peers
p2p_connect [M#2 MAC ADDRESS] pbc go_intent=7
M#2
p2p_find
p2p_stop
p2p_peers
p2p_connect [M#1 MAC ADDRESS] pbc
Then I can find the M#1 become the P0 GO mode and M#2 become station
mode. And each status is completed. But after that, I set each machine
with a static IP such as 192.168.5.10 and 192.168.5.11 manually. I am
not able to ping each IP.
Is there anything I am doing wrong ?
Thank you.
^ permalink raw reply
* Recommend a Wireless/WiFi chip, that best address bufferbloat
From: Jesper Dangaard Brouer @ 2013-10-08 9:57 UTC (permalink / raw)
To: Dave Taht, John Linville, bloat-devel
Cc: linux-wireless, Simon Barber, Anirudh Sivaraman
Hi All,
As Dave Taht repeats, we have not solved bufferbloat on Wifi, yet.
I've been approached by some embedded developers, who need to choose
some Wifi hardware for their device, and is concerned about bufferbloat.
What do we recommend of Wifi chips?
- Which ones are the least-bad regrading bufferbloat?
- Which ones do we hope to solve in the near-future?
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Sr. Network Kernel Developer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH] nl80211: vendor command support
From: Eliad Peller @ 2013-10-08 10:34 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org, Johannes Berg
In-Reply-To: <1381222401-21999-1-git-send-email-johannes@sipsolutions.net>
On Tue, Oct 8, 2013 at 11:53 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> Add support for vendor-specific commands to nl80211. This is
> intended to be used for really vendor-specific functionality
> that can't be implemented in a generic fashion for any reason.
> It's *NOT* intended to be used for any normal/generic feature
> or any optimisations that could be implemented across drivers.
>
> Currently, only vendor commands (with replies) are supported,
> no dump operations or vendor-specific notifications.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
[...]
>
> #ifdef CONFIG_NL80211_TESTMODE
> static struct genl_multicast_group nl80211_testmode_mcgrp = {
> @@ -6633,11 +6686,11 @@ static int nl80211_testmode_do(struct sk_buff *skb, struct genl_info *info)
> if (!info->attrs[NL80211_ATTR_TESTDATA])
> return -EINVAL;
>
> - rdev->testmode_info = info;
> + rdev->cur_cmd_info = info;
> err = rdev_testmode_cmd(rdev, wdev,
> nla_data(info->attrs[NL80211_ATTR_TESTDATA]),
> nla_len(info->attrs[NL80211_ATTR_TESTDATA]));
> - rdev->testmode_info = NULL;
> + rdev->cur_cmd_info = NULL;
>
> return err;
> }
[...]
> +
> +int cfg80211_vendor_cmd_reply(struct sk_buff *skb)
> +{
> + struct cfg80211_registered_device *rdev = ((void **)skb->cb)[0];
> + void *hdr = ((void **)skb->cb)[1];
> + struct nlattr *data = ((void **)skb->cb)[2];
> +
> + if (WARN_ON(!rdev->cur_cmd_info)) {
> + kfree_skb(skb);
> + return -EINVAL;
> + }
> +
> + nla_nest_end(skb, data);
> + genlmsg_end(skb, hdr);
> + return genlmsg_reply(skb, rdev->cur_cmd_info);
> +}
don't you miss the rdev->cur_cmd_info initialization in case of
vendor_cmd (like it's being done in testmode)?
Eliad.
^ permalink raw reply
* Re: [PATCH] nl80211: vendor command support
From: Johannes Berg @ 2013-10-08 10:41 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEe+vVezWHBkOt_M4pfqCu--c78EuyMEmGD2oqcpP9=c-w@mail.gmail.com>
On Tue, 2013-10-08 at 12:34 +0200, Eliad Peller wrote:
> don't you miss the rdev->cur_cmd_info initialization in case of
> vendor_cmd (like it's being done in testmode)?
Indeed, I missed that. Need to test it anyway :)
johannes
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Stanislaw Gruszka @ 2013-10-08 10:46 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <525269F0.5000802@kevlo.org>
On Mon, Oct 07, 2013 at 03:59:44PM +0800, Kevin Lo wrote:
> rt2800_rfcsr_read(rt2x00dev, 23, &rfcsr);
> rt2x00_set_field8(&rfcsr, RFCSR23_FREQ_OFFSET,
> rt2x00dev->freq_offset);
> rt2800_rfcsr_write(rt2x00dev, 23, rfcsr);
NACK, still malformed
^ permalink raw reply
* Re: [rt2x00-users] [PATCH v2] rt2x00: rt2800lib: no need to toggle RF R30 bit 7 twice
From: Stanislaw Gruszka @ 2013-10-08 10:47 UTC (permalink / raw)
To: Kevin Lo; +Cc: John Linville, linux-wireless, users
In-Reply-To: <20131007080201.GA18265@ns.kevlo.org>
On Mon, Oct 07, 2013 at 04:02:01PM +0800, Kevin Lo wrote:
> In rt2800_config_channel_rf3xxx(), there's no need to toggle
> RF R30 bit 7 twice.
>
> Signed-off-by: Kevin Lo <kevlo@kevlo.org>
This one is fine.
Acked-by: Stanislaw Gruszka <stf_xl@wp.pl>
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-10-07
From: Johannes Berg @ 2013-10-08 10:59 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless
In-Reply-To: <1381139793.13586.18.camel@jlt4.sipsolutions.net>
Please hold off on this,
> iwlwifi: mvm: Add device wide power command
This commit causes a regression in monitor mode.
johannes
^ permalink raw reply
* RE: [PATCH v3 0/6] Add Mesh Channel Switch Support
From: Jean-Pierre Tosoni @ 2013-10-08 7:49 UTC (permalink / raw)
To: devel, linux-wireless, yeohchunyeow
In-Reply-To: <1380760429-26100-1-git-send-email-yeohchunyeow@cozybit.com>
Hi, see some typos below.
Jean-Pierre
> -----Message d'origine-----
> De : devel-bounces@lists.open80211s.org [mailto:devel-
> bounces@lists.open80211s.org] De la part de Chun-Yeow Yeoh
> Envoyé : jeudi 3 octobre 2013 02:34
>
> Limitations:
> * Channel switch is only allow for the same band and also same channel
> width from the previous setting.
Allow -> allowed
settings
>
> These patches are reviewed and commented by Bob Copeland, Thomas
> Pedersen
> and Johannes Berg. Any further comments are welcomed.
>
> Add seperate patch for refactoring the ieee80211_parse_ch_switch_ie to
Seperate -> separate
> reduce the number of function paramaters.
Parameters
>
> Chun-Yeow Yeoh (6):
> mac80211: process the CSA frame for mesh accordingly
> {nl,cfg,mac}80211: enable the triggering of CSA frame in mesh
> mac80211: add the CSA and MCSP elements in mesh beaconing
> mac80211: refactor the parsing of chan switch ie
> {nl,cfg,mac}80211: finalizing mesh channel switching
> mac80211: process mesh channel switching using beacon
>
> include/linux/ieee80211.h | 20 +++
> net/mac80211/Kconfig | 11 ++
> net/mac80211/cfg.c | 24 ++++
> net/mac80211/debug.h | 10 ++
> net/mac80211/ibss.c | 67 ++--------
> net/mac80211/ieee80211_i.h | 29 ++++-
> net/mac80211/mesh.c | 293
> +++++++++++++++++++++++++++++++++++++++++++-
> net/mac80211/mlme.c | 32 +++--
> net/mac80211/rx.c | 5 +-
> net/mac80211/spectmgmt.c | 33 +++--
> net/mac80211/tx.c | 16 +++
> net/mac80211/util.c | 96 +++++++++++++++
> net/wireless/nl80211.c | 4 +-
> 13 files changed, 540 insertions(+), 100 deletions(-)
>
> --
> 1.7.9.5
>
> _______________________________________________
> Devel mailing list
> Devel@lists.open80211s.org
> http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel
^ permalink raw reply
* [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 11:31 UTC (permalink / raw)
To: linux-wireless, netdev; +Cc: patches, johannes, linville, Ard Biesheuvel
Use the generic CCM aead chaining mode driver rather than a local
implementation that sits right on top of the core AES cipher.
This allows the use of accelerated implementations of either
CCM as a whole or the CTR mode which it encapsulates.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
net/mac80211/Kconfig | 1 +
net/mac80211/aes_ccm.c | 165 +++++++++++++++++--------------------------------
net/mac80211/aes_ccm.h | 8 +--
net/mac80211/key.h | 2 +-
net/mac80211/wpa.c | 24 +++----
5 files changed, 71 insertions(+), 129 deletions(-)
diff --git a/net/mac80211/Kconfig b/net/mac80211/Kconfig
index 62535fe..dc31ec3 100644
--- a/net/mac80211/Kconfig
+++ b/net/mac80211/Kconfig
@@ -4,6 +4,7 @@ config MAC80211
select CRYPTO
select CRYPTO_ARC4
select CRYPTO_AES
+ select CRYPTO_CCM
select CRC32
select AVERAGE
---help---
diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index be7614b9..ef808d7 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -2,6 +2,8 @@
* Copyright 2003-2004, Instant802 Networks, Inc.
* Copyright 2005-2006, Devicescape Software, Inc.
*
+ * Rewrite: Copyright (C) 2013 Linaro Ltd <ard.biesheuvel@linaro.org>
+ *
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
@@ -17,134 +19,77 @@
#include "key.h"
#include "aes_ccm.h"
-static void aes_ccm_prepare(struct crypto_cipher *tfm, u8 *scratch, u8 *a)
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ u8 *data, size_t data_len, u8 *cdata, u8 *mic)
{
- int i;
- u8 *b_0, *aad, *b, *s_0;
+ struct scatterlist assoc, pt, ct[2];
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
- aad = scratch + 4 * AES_BLOCK_SIZE;
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
+ /* allocate the variable sized aead_request on the stack */
+ int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
+ sizeof(struct aead_request));
+ struct aead_request req[1 + l];
- crypto_cipher_encrypt_one(tfm, b, b_0);
+ memset(req, 0, sizeof(*req) + crypto_aead_reqsize(tfm));
- /* Extra Authenticate-only data (always two AES blocks) */
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- aad[i] ^= b[i];
- crypto_cipher_encrypt_one(tfm, b, aad);
+ sg_init_one(&pt, data, data_len);
+ sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
+ sg_init_table(ct, 2);
+ sg_set_buf(&ct[0], cdata, data_len);
+ sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
- aad += AES_BLOCK_SIZE;
+ aead_request_set_tfm(req, tfm);
+ aead_request_set_crypt(req, &pt, ct, data_len, b_0);
+ aead_request_set_assoc(req, &assoc, assoc.length);
- for (i = 0; i < AES_BLOCK_SIZE; i++)
- aad[i] ^= b[i];
- crypto_cipher_encrypt_one(tfm, a, aad);
+ crypto_aead_encrypt(req);
+}
- /* Mask out bits from auth-only-b_0 */
- b_0[0] &= 0x07;
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
+ u8 *cdata, size_t data_len, u8 *mic, u8 *data)
+{
+ struct scatterlist assoc, pt, ct[2];
- /* S_0 is used to encrypt T (= MIC) */
- b_0[14] = 0;
- b_0[15] = 0;
- crypto_cipher_encrypt_one(tfm, s_0, b_0);
-}
+ /* allocate the variable sized aead_request on the stack */
+ int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
+ sizeof(struct aead_request));
+ struct aead_request req[1 + l];
+ memset(req, 0, sizeof(*req) + crypto_aead_reqsize(tfm));
-void ieee80211_aes_ccm_encrypt(struct crypto_cipher *tfm, u8 *scratch,
- u8 *data, size_t data_len,
- u8 *cdata, u8 *mic)
-{
- int i, j, last_len, num_blocks;
- u8 *pos, *cpos, *b, *s_0, *e, *b_0;
-
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
- e = scratch + 2 * AES_BLOCK_SIZE;
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
-
- num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
- last_len = data_len % AES_BLOCK_SIZE;
- aes_ccm_prepare(tfm, scratch, b);
-
- /* Process payload blocks */
- pos = data;
- cpos = cdata;
- for (j = 1; j <= num_blocks; j++) {
- int blen = (j == num_blocks && last_len) ?
- last_len : AES_BLOCK_SIZE;
-
- /* Authentication followed by encryption */
- for (i = 0; i < blen; i++)
- b[i] ^= pos[i];
- crypto_cipher_encrypt_one(tfm, b, b);
-
- b_0[14] = (j >> 8) & 0xff;
- b_0[15] = j & 0xff;
- crypto_cipher_encrypt_one(tfm, e, b_0);
- for (i = 0; i < blen; i++)
- *cpos++ = *pos++ ^ e[i];
- }
-
- for (i = 0; i < IEEE80211_CCMP_MIC_LEN; i++)
- mic[i] = b[i] ^ s_0[i];
-}
+ sg_init_one(&pt, data, data_len);
+ sg_init_one(&assoc, &aad[2], be16_to_cpup((__be16 *)aad));
+ sg_init_table(ct, 2);
+ sg_set_buf(&ct[0], cdata, data_len);
+ sg_set_buf(&ct[1], mic, IEEE80211_CCMP_MIC_LEN);
+ aead_request_set_tfm(req, tfm);
+ aead_request_set_crypt(req, ct, &pt, data_len + IEEE80211_CCMP_MIC_LEN,
+ b_0);
+ aead_request_set_assoc(req, &assoc, assoc.length);
-int ieee80211_aes_ccm_decrypt(struct crypto_cipher *tfm, u8 *scratch,
- u8 *cdata, size_t data_len, u8 *mic, u8 *data)
-{
- int i, j, last_len, num_blocks;
- u8 *pos, *cpos, *b, *s_0, *a, *b_0;
-
- b = scratch;
- s_0 = scratch + AES_BLOCK_SIZE;
- a = scratch + 2 * AES_BLOCK_SIZE;
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
-
- num_blocks = DIV_ROUND_UP(data_len, AES_BLOCK_SIZE);
- last_len = data_len % AES_BLOCK_SIZE;
- aes_ccm_prepare(tfm, scratch, a);
-
- /* Process payload blocks */
- cpos = cdata;
- pos = data;
- for (j = 1; j <= num_blocks; j++) {
- int blen = (j == num_blocks && last_len) ?
- last_len : AES_BLOCK_SIZE;
-
- /* Decryption followed by authentication */
- b_0[14] = (j >> 8) & 0xff;
- b_0[15] = j & 0xff;
- crypto_cipher_encrypt_one(tfm, b, b_0);
- for (i = 0; i < blen; i++) {
- *pos = *cpos++ ^ b[i];
- a[i] ^= *pos++;
- }
- crypto_cipher_encrypt_one(tfm, a, a);
- }
-
- for (i = 0; i < IEEE80211_CCMP_MIC_LEN; i++) {
- if ((mic[i] ^ s_0[i]) != a[i])
- return -1;
- }
-
- return 0;
+ return crypto_aead_decrypt(req);
}
-
-struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[])
+struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[])
{
- struct crypto_cipher *tfm;
+ struct crypto_aead *tfm;
+ int err;
- tfm = crypto_alloc_cipher("aes", 0, CRYPTO_ALG_ASYNC);
- if (!IS_ERR(tfm))
- crypto_cipher_setkey(tfm, key, WLAN_KEY_LEN_CCMP);
+ tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR(tfm))
+ return tfm;
- return tfm;
-}
+ err = crypto_aead_setkey(tfm, key, WLAN_KEY_LEN_CCMP);
+ if (!err)
+ err = crypto_aead_setauthsize(tfm, IEEE80211_CCMP_MIC_LEN);
+ if (!err)
+ return tfm;
+ crypto_free_aead(tfm);
+ return ERR_PTR(err);
+}
-void ieee80211_aes_key_free(struct crypto_cipher *tfm)
+void ieee80211_aes_key_free(struct crypto_aead *tfm)
{
- crypto_free_cipher(tfm);
+ crypto_free_aead(tfm);
}
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index 5b7d744..52650b3 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -12,13 +12,13 @@
#include <linux/crypto.h>
-struct crypto_cipher *ieee80211_aes_key_setup_encrypt(const u8 key[]);
-void ieee80211_aes_ccm_encrypt(struct crypto_cipher *tfm, u8 *scratch,
+struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[]);
+void ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
u8 *data, size_t data_len,
u8 *cdata, u8 *mic);
-int ieee80211_aes_ccm_decrypt(struct crypto_cipher *tfm, u8 *scratch,
+int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
u8 *cdata, size_t data_len,
u8 *mic, u8 *data);
-void ieee80211_aes_key_free(struct crypto_cipher *tfm);
+void ieee80211_aes_key_free(struct crypto_aead *tfm);
#endif /* AES_CCM_H */
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 036d57e..aaae0ed 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -83,7 +83,7 @@ struct ieee80211_key {
* Management frames.
*/
u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
- struct crypto_cipher *tfm;
+ struct crypto_aead *tfm;
u32 replays; /* dot11RSNAStatsCCMPReplays */
} ccmp;
struct {
diff --git a/net/mac80211/wpa.c b/net/mac80211/wpa.c
index c9edfcb..c39ee61 100644
--- a/net/mac80211/wpa.c
+++ b/net/mac80211/wpa.c
@@ -301,22 +301,16 @@ ieee80211_crypto_tkip_decrypt(struct ieee80211_rx_data *rx)
}
-static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
+static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *b_0, u8 *aad,
int encrypted)
{
__le16 mask_fc;
int a4_included, mgmt;
u8 qos_tid;
- u8 *b_0, *aad;
u16 data_len, len_a;
unsigned int hdrlen;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
- memset(scratch, 0, 6 * AES_BLOCK_SIZE);
-
- b_0 = scratch + 3 * AES_BLOCK_SIZE;
- aad = scratch + 4 * AES_BLOCK_SIZE;
-
/*
* Mask FC: zero subtype b4 b5 b6 (if not mgmt)
* Retry, PwrMgt, MoreData; set Protected
@@ -343,7 +337,7 @@ static void ccmp_special_blocks(struct sk_buff *skb, u8 *pn, u8 *scratch,
data_len -= IEEE80211_CCMP_MIC_LEN;
/* First block, b_0 */
- b_0[0] = 0x59; /* flags: Adata: 1, M: 011, L: 001 */
+ b_0[0] = 0x1; /* set L := 1, M and Adata flags are implied */
/* Nonce: Nonce Flags | A2 | PN
* Nonce Flags: Priority (b0..b3) | Management (b4) | Reserved (b5..b7)
*/
@@ -407,7 +401,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
u8 *pos;
u8 pn[6];
u64 pn64;
- u8 scratch[6 * AES_BLOCK_SIZE];
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
if (info->control.hw_key &&
!(info->control.hw_key->flags & IEEE80211_KEY_FLAG_GENERATE_IV) &&
@@ -460,8 +455,8 @@ static int ccmp_encrypt_skb(struct ieee80211_tx_data *tx, struct sk_buff *skb)
return 0;
pos += IEEE80211_CCMP_HDR_LEN;
- ccmp_special_blocks(skb, pn, scratch, 0);
- ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, scratch, pos, len,
+ ccmp_special_blocks(skb, pn, b_0, aad, 0);
+ ieee80211_aes_ccm_encrypt(key->u.ccmp.tfm, b_0, aad, pos, len,
pos, skb_put(skb, IEEE80211_CCMP_MIC_LEN));
return 0;
@@ -525,12 +520,13 @@ ieee80211_crypto_ccmp_decrypt(struct ieee80211_rx_data *rx)
}
if (!(status->flag & RX_FLAG_DECRYPTED)) {
- u8 scratch[6 * AES_BLOCK_SIZE];
+ u8 aad[2 * AES_BLOCK_SIZE];
+ u8 b_0[AES_BLOCK_SIZE];
/* hardware didn't decrypt/verify MIC */
- ccmp_special_blocks(skb, pn, scratch, 1);
+ ccmp_special_blocks(skb, pn, b_0, aad, 1);
if (ieee80211_aes_ccm_decrypt(
- key->u.ccmp.tfm, scratch,
+ key->u.ccmp.tfm, b_0, aad,
skb->data + hdrlen + IEEE80211_CCMP_HDR_LEN,
data_len,
skb->data + skb->len - IEEE80211_CCMP_MIC_LEN,
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 11:52 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless, netdev, patches, linville
In-Reply-To: <1381231915-24232-1-git-send-email-ard.biesheuvel@linaro.org>
On Tue, 2013-10-08 at 13:31 +0200, Ard Biesheuvel wrote:
Hmm, thanks I guess. I'll need to review this in more detail, but I have
a question first:
> + /* allocate the variable sized aead_request on the stack */
> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
> + sizeof(struct aead_request));
> + struct aead_request req[1 + l];
This looks a bit odd, why round up first and then add one? Why even
bother using a struct array rather than some local struct like
struct {
struct aead_request req;
u8 data[crypto_aed_reqsize(tfm)];
} req_data;
or so?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 12:00 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <1381233152.13359.10.camel@jlt4.sipsolutions.net>
On 8 October 2013 13:52, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 13:31 +0200, Ard Biesheuvel wrote:
>
> Hmm, thanks I guess. I'll need to review this in more detail, but I have
> a question first:
>
>> + /* allocate the variable sized aead_request on the stack */
>> + int l = DIV_ROUND_UP(crypto_aead_reqsize(tfm),
>> + sizeof(struct aead_request));
>> + struct aead_request req[1 + l];
>
> This looks a bit odd, why round up first and then add one? Why even
> bother using a struct array rather than some local struct like
>
> struct {
> struct aead_request req;
> u8 data[crypto_aed_reqsize(tfm)];
> } req_data;
>
> or so?
>
Yes, that looks much better. I will put that in my v2, let me know if
you have more questions/comments.
BTW I should probably have mentioned that this is fully tested code:
my zd1211 works happily with it using pairwise CCMP with no
regressions in performance.
Cheers,
Ard.
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Johannes Berg @ 2013-10-08 12:16 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: linux-wireless, netdev, Patch Tracking, linville
In-Reply-To: <CAKv+Gu9-ddqyuGg=NDFoWzNko+0uMG_po6WnzTc7g3DAzx=_dQ@mail.gmail.com>
On Tue, 2013-10-08 at 14:00 +0200, Ard Biesheuvel wrote:
> BTW I should probably have mentioned that this is fully tested code:
> my zd1211 works happily with it using pairwise CCMP with no
> regressions in performance.
Good to know. Not that I think zd1211 is a good device for performance
tests (you'd have to measure CPU utilisation in some way), but
ultimately it doesn't really matter as all the high-performance devices
need hardware crypto anyway.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: port CCMP to cryptoapi's CCM driver
From: Ard Biesheuvel @ 2013-10-08 12:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, Patch Tracking, John Linville
In-Reply-To: <1381234564.13359.11.camel@jlt4.sipsolutions.net>
On 8 October 2013 14:16, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Tue, 2013-10-08 at 14:00 +0200, Ard Biesheuvel wrote:
>
>> BTW I should probably have mentioned that this is fully tested code:
>> my zd1211 works happily with it using pairwise CCMP with no
>> regressions in performance.
>
> Good to know. Not that I think zd1211 is a good device for performance
> tests (you'd have to measure CPU utilisation in some way), but
> ultimately it doesn't really matter as all the high-performance devices
> need hardware crypto anyway.
>
I agree. I am not saying the typical performance of a zd1211 is a
meaningful quantity, just that this particular device performs
identically before and after applying this patch, which suggests that
it is not creating lots of corrupted frames or messing up the
authentication.
Regards,
--
Ard.
^ permalink raw reply
* Re: [PATCH 0/2] ath10k: minor fixes
From: Kalle Valo @ 2013-10-08 12:23 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1380867200-19714-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> The patchset fixes a compilation warning and a
> memory leak in FW loading code.
>
> Michal Kazior (2):
> ath10k: fix printf format string
> ath10k: fix possible memory leak in new FW loading
Both appplied, thanks for fixing my bugs :)
--
Kalle Valo
^ 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