Re: [PATCH 1/2] cfg80211: Allow NL80211_ATTR_IFINDEX to be added to vendor events
> This means that this kernel change can't be pulled in without > corresponding driver changes to call cfg80211_vendor_event_alloc() > with a NULL for wdev. Please confirm if this is acceptable; otherwise, > we would need to use the new wrapper defined above. This is fine to me, there are very few such users anyway (make sure to update in a single patch.) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
Hi,
Sorry about the late reply! I'm getting back to merging now and taking a
closer look at this issue.
> +++ b/net/wireless/nl80211.c
> @@ -5261,7 +5261,7 @@ do {
> \
> FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshAwakeWindowDuration,
> 0, 65535, mask,
> NL80211_MESHCONF_AWAKE_WINDOW, nla_get_u16);
> - FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 1, 0x,
> + FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0x,
> mask, NL80211_MESHCONF_PLINK_TIMEOUT,
I think you should document this new behaviour also in nl80211.h.
Additionally - what's the plan on how to discover this? Should userspace
just try to set with 0 value and then drop back to some big number if it
gets an error?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: fix error handling in tx_frame_nl
On Thu, 2015-02-05 at 08:45 -0500, Bob Copeland wrote: > Correct two problems with the error handling when using the netlink > forwarding API: first, the netlink skb is never freed if nla_put() > fails; and second, genlmsg_unicast() can fail if the netlink socket > is full. In the latter case, the corresponding data skb is not counted > as a drop and userspace programs like wmediumd will see TCP stalls > due to lost packets. Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: clear sdata->radar_required
On Sun, 2015-02-08 at 12:36 +0200, Eliad Peller wrote: > If ieee80211_vif_use_channel() fails, we have to clear > sdata->radar_required (which we might have just set). > > Failing to do it results in stale radar_required field > which prevents starting new scan requests. Applied, but I fixed it to use = false instead of = 0. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: use loop index as type for net detect frequency results
On Mon, 2015-02-09 at 21:29 +0200, Luca Coelho wrote: > From: Samuel Tan > > We currently add nested members of the NL80211_ATTR_SCAN_FREQUENCIES > as NLA_U32 attributes of type NL80211_ATTR_WIPHY_FREQ in > cfg80211_net_detect_results. However, since there can be an arbitrary number > of > frequency results, we should use the loop index of the loop used to add the > frequency results to NL80211_ATTR_SCAN_FREQUENCIES as the type (i.e. nla_type) > for each result attribute, rather than a fixed type. > > This change is in line with how nested members are added to > NL80211_ATTR_SCAN_FREQUENCIES in the functions nl80211_send_wowlan_nd and > nl80211_add_scan_req. Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: Add minimal capability for vendor command/event testing
On Mon, 2015-02-09 at 18:19 +0200, Jouni Malinen wrote: > This allows wpa_supplicant/hostapd to send a vendor command and verify > response to that command and event. I'm going to drop this since you're working on the wdev thing. That might even help you with the first patch since you don't need to update this then. Please resubmit all these three patches (probably just two then) together. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] nl80211: Fix possible leak in nl80211_new_interface on MONITOR_FLAG_ACTIVE
On Sat, 2015-02-14 at 20:52 +0100, Christian Engelmayer wrote: > In case of NL80211_IFTYPE_MONITOR and flag MONITOR_FLAG_ACTIVE, the already > allocated sk_buff 'msg' is not freed, when the function exits in case the > feature is not supported. Detected by Coverity CID 1269116. > > Signed-off-by: Christian Engelmayer > --- > Compile tested only. Applies against linux-next. Thanks for the report. I've fixed this in a different way. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: fix n_reg_rules to match world_regdom
On Tue, 2015-02-17 at 16:10 -0800, Jason Abele wrote: > From: Jason Abele > > There are currently 8 rules in the world_regdom, but only the first 6 > are applied due to an incorrect value for n_reg_rules. This causes > channels 149-165 and 60GHz to be disabled. Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver
The device can be enumerated using ACPI using the id INT339A.
The 1st GPIO is the IRQ and the 2nd is the RESET pin.
I can be also enumerated using platform init.
Signed-off-by: Robert Dolca
---
drivers/nfc/Kconfig | 1 +
drivers/nfc/fdp/Kconfig | 22 ++
drivers/nfc/fdp/Makefile | 10 +
drivers/nfc/fdp/cmd.c | 196 +++
drivers/nfc/fdp/core.c| 503 ++
drivers/nfc/fdp/fdp.h | 115 +
drivers/nfc/fdp/i2c.c | 454 ++
drivers/nfc/fdp/ntf.c | 68 ++
drivers/nfc/fdp/rsp.c | 117 +
include/linux/platform_data/fdp.h | 33 +++
10 files changed, 1519 insertions(+)
create mode 100644 drivers/nfc/fdp/Kconfig
create mode 100644 drivers/nfc/fdp/Makefile
create mode 100644 drivers/nfc/fdp/cmd.c
create mode 100644 drivers/nfc/fdp/core.c
create mode 100644 drivers/nfc/fdp/fdp.h
create mode 100644 drivers/nfc/fdp/i2c.c
create mode 100644 drivers/nfc/fdp/ntf.c
create mode 100644 drivers/nfc/fdp/rsp.c
create mode 100644 include/linux/platform_data/fdp.h
diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 6ee2e8d..302fe59 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -68,6 +68,7 @@ config NFC_PORT100
If unsure, say N.
+source "drivers/nfc/fdp/Kconfig"
source "drivers/nfc/pn544/Kconfig"
source "drivers/nfc/microread/Kconfig"
source "drivers/nfc/nfcmrvl/Kconfig"
diff --git a/drivers/nfc/fdp/Kconfig b/drivers/nfc/fdp/Kconfig
new file mode 100644
index 000..130a235
--- /dev/null
+++ b/drivers/nfc/fdp/Kconfig
@@ -0,0 +1,22 @@
+config NFC_FDP
+ tristate "Intel FDP NFC driver"
+ depends on NFC_NCI
+ select CRC_CCITT
+ default n
+ ---help---
+ Intel FDP core driver.
+ This is a driver based on the NCI NFC kernel layers.
+
+ To compile this driver as a module, choose m here. The module will
+ be called pn547.
+ Say N if unsure.
+
+config NFC_FDP_I2C
+ tristate "NFC FDP i2c support"
+ depends on NFC_FDP && I2C
+ ---help---
+ This module adds support for the Intel FDP i2c interface.
+ Select this if your platform is using the i2c bus.
+
+ If you choose to build a module, it'll be called fdp_i2c.
+ Say N if unsure.
diff --git a/drivers/nfc/fdp/Makefile b/drivers/nfc/fdp/Makefile
new file mode 100644
index 000..caad636
--- /dev/null
+++ b/drivers/nfc/fdp/Makefile
@@ -0,0 +1,10 @@
+#
+# Makefile for FDP NCI based NFC driver
+#
+
+obj-$(CONFIG_NFC_FDP) += fdp.o
+obj-$(CONFIG_NFC_FDP_I2C) += fdp_i2c.o
+
+fdp-objs = core.o cmd.o ntf.o rsp.o
+fdp_i2c-objs = i2c.o
+
diff --git a/drivers/nfc/fdp/cmd.c b/drivers/nfc/fdp/cmd.c
new file mode 100644
index 000..1b78602
--- /dev/null
+++ b/drivers/nfc/fdp/cmd.c
@@ -0,0 +1,196 @@
+/* -
+ * Copyright (C) 2014-2016, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ * - */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "fdp.h"
+
+#define NCI_OP_PROP_PATCH_CMD nci_opcode_pack(NCI_GID_PROP, 0x08)
+#define NCI_OP_PROP_SET_PRODUCTION_DATA_CMD nci_opcode_pack(NCI_GID_PROP,
0x23)
+#define NCI_OP_CORE_GET_CONFIG_CMD nci_opcode_pack(NCI_GID_CORE,
0x03)
+static u8 nci_core_get_config_otp_ram_version[5] = {
+ 0x04,
+ NCI_PARAM_ID_FW_RAM_VERSION,
+ NCI_PARAM_ID_FW_OTP_VERSION,
+ NCI_PARAM_ID_OTP_LIMITED_VERSION,
+ NCI_PARAM_ID_KEY_INDEX_ID
+};
+
+#define NCI_GET_VERSION_TIMEOUT8000
+#define NCI_PATCH_REQUEST_TIMEOUT 8000
+
+struct production_data {
+ u8 len;
+ char *data;
+};
+
+static void fdp_nci_get_version_req(struct nci_dev *ndev, unsigned long opt)
+{
+ fdp_nci_send_cmd(ndev, NCI_OP_CORE_GET_CONFIG_CMD,
+sizeof(nci_core_get_config_otp_ram_version),
+&nci_core_get_config_otp_ram_version);
+}
+
+static void fdp_nci_set_production_data_req(struct nci_dev *ndev,
+ unsigned long opt)
+{
+ struct production_data *pd = (struct production_data *)opt;
+
+ fdp_nci_send_cmd(ndev, NCI_OP_PROP_SET_PRODUCTION_DATA_CMD,
+pd->len, pd->data);
+}
+
+static void fdp_nci_patc
[PATCH 6/8] NFC: NCI: Add function to get max packet size for conn
FDP driver needs to send the firmware as regular packets
(not fragmented). That's whay the driver should have a way to
get the max packet size for a given connection.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 1 +
net/nfc/nci/data.c | 12
2 files changed, 13 insertions(+)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 42ec342..d79f90e 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -321,6 +321,7 @@ void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff
*skb);
void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload);
int nci_send_data(struct nci_dev *ndev, __u8 conn_id, struct sk_buff *skb);
+__u8 nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id);
void nci_data_exchange_complete(struct nci_dev *ndev, struct sk_buff *skb,
__u8 conn_id, int err);
void nci_hci_data_received_cb(void *context, struct sk_buff *skb, int err);
diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c
index 83acd18..056f841 100644
--- a/net/nfc/nci/data.c
+++ b/net/nfc/nci/data.c
@@ -90,6 +90,18 @@ static inline void nci_push_data_hdr(struct nci_dev *ndev,
nci_pbf_set((__u8 *)hdr, pbf);
}
+__u8 nci_conn_max_data_pkt_payload_size(struct nci_dev *ndev, __u8 conn_id)
+{
+ struct nci_conn_info *conn_info;
+
+ conn_info = nci_get_conn_info_by_conn_id(ndev, conn_id);
+ if (!conn_info)
+ return 0;
+
+ return conn_info->max_pkt_payload_len;
+}
+EXPORT_SYMBOL(nci_conn_max_data_pkt_payload_size);
+
static int nci_queue_tx_data_frags(struct nci_dev *ndev,
__u8 conn_id,
struct sk_buff *skb) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [PATCH v4] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
I will re-send this message to ML because of delivery error.
-- Forwarded message --
From: Masashi Honma
Date: 2015-02-24 19:00 GMT+09:00
Subject: Re: [PATCH v4] mac80211: Allow 0 for
NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
To: Johannes Berg
Cc: "linux-wireless@vger.kernel.org" ,
Bob Copeland
2015-02-24 18:46 GMT+09:00 Johannes Berg :
>
> Hi,
>
> Sorry about the late reply! I'm getting back to merging now and taking a
> closer look at this issue.
Thank you for your review.
>
>
> > +++ b/net/wireless/nl80211.c
> > @@ -5261,7 +5261,7 @@ do {
> > \
> > FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshAwakeWindowDuration,
> > 0, 65535, mask,
> > NL80211_MESHCONF_AWAKE_WINDOW, nla_get_u16);
> > - FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 1, 0x,
> > + FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0x,
> > mask, NL80211_MESHCONF_PLINK_TIMEOUT,
>
> I think you should document this new behaviour also in nl80211.h.
Yes. I will modify and re-send this patch.
>
>
> Additionally - what's the plan on how to discover this? Should userspace
> just try to set with 0 value and then drop back to some big number if it
> gets an error?
I already modified wpa_supplicant by commit
0cb5f8d94536e097af7a11273f79239001a602d6.
The way is same as you. It tries to set with 0, if failed it re-try
with 60sec future of wpa_supplicant timeout value.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] NFC: NCI: Adds a way to get the new connection ID
nci_core_conn_create not has a new parameter so it can return
the ID of the new connection. Also not you can't call nci_core_conn_create
without waiting the answer for the previous call.
Signed-off-by: Robert Dolca
---
drivers/nfc/st21nfcb/st21nfcb_se.c | 2 +-
include/net/nfc/nci_core.h | 11 ---
net/nfc/nci/core.c | 13 ++---
net/nfc/nci/rsp.c | 6 ++
4 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/nfc/st21nfcb/st21nfcb_se.c
b/drivers/nfc/st21nfcb/st21nfcb_se.c
index 7c82e9d..8694675 100644
--- a/drivers/nfc/st21nfcb/st21nfcb_se.c
+++ b/drivers/nfc/st21nfcb/st21nfcb_se.c
@@ -515,7 +515,7 @@ static int st21nfcb_hci_network_init(struct nci_dev *ndev)
r = nci_core_conn_create(ndev, NCI_DESTINATION_NFCEE, 1,
sizeof(struct
core_conn_create_dest_spec_params) +
sizeof(struct dest_spec_params),
-dest_params);
+dest_params, NULL);
if (r != NCI_STATUS_OK)
goto free_dest_params;
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index d79f90e..a331755 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -240,6 +240,11 @@ struct nci_dev {
/* Save RF Discovery ID or NFCEE ID under conn_create */
__u8cur_id;
+ /* Pointer to the address where the next connection ID
+* will be stored */
+ __u8*next_conn_id;
+ __u8conn_busy;
+
/* stored during nci_data_exchange */
struct sk_buff *rx_data_reassembly;
@@ -266,9 +271,9 @@ int nci_set_config(struct nci_dev *ndev, __u8 id, size_t
len, __u8 *val);
int nci_nfcee_discover(struct nci_dev *ndev, u8 action);
int nci_nfcee_mode_set(struct nci_dev *ndev, u8 nfcee_id, u8 nfcee_mode);
int nci_core_conn_create(struct nci_dev *ndev, u8 destination_type,
-u8 number_destination_params,
-size_t params_len,
-struct core_conn_create_dest_spec_params *params);
+u8 number_destination_params, size_t params_len,
+struct core_conn_create_dest_spec_params *params,
+u8 *conn_id);
int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id);
struct nci_hci_dev *nci_hci_allocate(struct nci_dev *ndev);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index d2e7adf..aaa56f1 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -554,14 +554,19 @@ static void nci_core_conn_create_req(struct nci_dev
*ndev, unsigned long opt)
}
int nci_core_conn_create(struct nci_dev *ndev, u8 destination_type,
-u8 number_destination_params,
-size_t params_len,
-struct core_conn_create_dest_spec_params *params)
+u8 number_destination_params, size_t params_len,
+struct core_conn_create_dest_spec_params *params,
+u8 *conn_id)
{
int r;
struct nci_core_conn_create_cmd *cmd;
struct core_conn_create_data data;
+ if (ndev->conn_busy)
+ return -EBUSY;
+
+ ndev->conn_busy = 1;
+
data.length = params_len + sizeof(struct nci_core_conn_create_cmd);
cmd = kzalloc(data.length, GFP_KERNEL);
if (!cmd)
@@ -573,11 +578,13 @@ int nci_core_conn_create(struct nci_dev *ndev, u8
destination_type,
data.cmd = cmd;
ndev->cur_id = params->value[DEST_SPEC_PARAMS_ID_INDEX];
+ ndev->next_conn_id = conn_id;
r = __nci_request(ndev, nci_core_conn_create_req,
(unsigned long)&data,
msecs_to_jiffies(NCI_CMD_TIMEOUT));
kfree(cmd);
+ ndev->conn_busy = 0;
return r;
}
EXPORT_SYMBOL(nci_core_conn_create);
diff --git a/net/nfc/nci/rsp.c b/net/nfc/nci/rsp.c
index 02486bc..9aa9de2 100644
--- a/net/nfc/nci/rsp.c
+++ b/net/nfc/nci/rsp.c
@@ -244,6 +244,12 @@ static void nci_core_conn_create_rsp_packet(struct nci_dev
*ndev,
conn_info->id = ndev->cur_id;
conn_info->conn_id = rsp->conn_id;
+ /* Set the conn ID to the address provided by the caller */
+ if (ndev->next_conn_id) {
+ *ndev->next_conn_id = rsp->conn_id;
+ ndev->next_conn_id = NULL;
+ }
+
/* Note: data_exchange_cb and data_exchange_cb_context need to
* be specify out of nci_core_conn_create_rsp_packet
*/
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] NFC: NCI: Add a special nci_request for driver
This patch adds nci_request_driver and nci_req_complete_driver
as a wrapper for __nci_request. When nci_req_complete_driver is
called it also sets cmd_cnt to 1. This is done because the response is not
sent to the NFC subsystem so cmd_cnt is not decremented there.
nci_send_cmd was previously exported in order to send commands to
the device from the driver. It shouldn't be used without
nci_req_complete_driver because cmd_cnt will have the wrong value.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 4
net/nfc/nci/core.c | 19 +++
2 files changed, 23 insertions(+)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 4358d0a..42ec342 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -333,6 +333,10 @@ void nci_clear_target_list(struct nci_dev *ndev);
#define NCI_REQ_CANCELED 2
void nci_req_complete(struct nci_dev *ndev, int result);
+int nci_request_driver(struct nci_dev *ndev,
+ void (*req)(struct nci_dev *ndev, unsigned long opt),
+ unsigned long opt, __u32 timeout);
+void nci_req_complete_driver(struct nci_dev *ndev, int result);
struct nci_conn_info *nci_get_conn_info_by_conn_id(struct nci_dev *ndev,
int conn_id);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 317b94b..1a449ac 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -74,6 +74,17 @@ void nci_req_complete(struct nci_dev *ndev, int result)
}
}
+void nci_req_complete_driver(struct nci_dev *ndev, int result)
+{
+ nci_req_complete(ndev, result);
+
+ /* trigger the next cmd */
+ atomic_set(&ndev->cmd_cnt, 1);
+ if (!skb_queue_empty(&ndev->cmd_q))
+ queue_work(ndev->cmd_wq, &ndev->cmd_work);
+}
+EXPORT_SYMBOL(nci_req_complete_driver);
+
static void nci_req_cancel(struct nci_dev *ndev, int err)
{
if (ndev->req_status == NCI_REQ_PEND) {
@@ -127,6 +138,14 @@ static int __nci_request(struct nci_dev *ndev,
return rc;
}
+int nci_request_driver(struct nci_dev *ndev,
+ void (*req)(struct nci_dev *ndev, unsigned long opt),
+ unsigned long opt, __u32 timeout)
+{
+ return __nci_request(ndev, req, opt, timeout);
+}
+EXPORT_SYMBOL(nci_request_driver);
+
inline int nci_request(struct nci_dev *ndev,
void (*req)(struct nci_dev *ndev,
unsigned long opt),
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/8] NFC: NCI: Don't call setup if previous NCI request failed
If the previous nci_request (NCI reset) failed the setup function
was being called anyway. It shouldn't be called if the reset failed.
The result of the setup function is taken into consideration. If it
fails the init should fail.
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 1a449ac..d2e7adf 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -365,8 +365,8 @@ static int nci_open_device(struct nci_dev *ndev)
rc = __nci_request(ndev, nci_reset_req, 0,
msecs_to_jiffies(NCI_RESET_TIMEOUT));
- if (ndev->ops->setup)
- ndev->ops->setup(ndev);
+ if (!rc && ndev->ops->setup)
+ rc = ndev->ops->setup(ndev);
if (!rc) {
rc = __nci_request(ndev, nci_init_req, 0,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] NFC: NCI: Adds NCI init and reset API for drivers
In order to communicate with the device during the setup
phase, the driver may need to initialize the device. After
the setup is done the driver should reset the device to leave
it in the same state that it was before the setup function
call.
Signed-off-by: Robert Dolca
---
include/net/nfc/nci_core.h | 2 ++
net/nfc/nci/core.c | 14 ++
2 files changed, 16 insertions(+)
diff --git a/include/net/nfc/nci_core.h b/include/net/nfc/nci_core.h
index 34a6e09..4358d0a 100644
--- a/include/net/nfc/nci_core.h
+++ b/include/net/nfc/nci_core.h
@@ -314,6 +314,8 @@ static inline void *nci_get_drvdata(struct nci_dev *ndev)
return ndev->driver_data;
}
+int nci_init(struct nci_dev *ndev);
+int nci_reset(struct nci_dev *ndev);
void nci_rsp_packet(struct nci_dev *ndev, struct sk_buff *skb);
void nci_ntf_packet(struct nci_dev *ndev, struct sk_buff *skb);
void nci_rx_data_packet(struct nci_dev *ndev, struct sk_buff *skb);
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 9605b9c..317b94b 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -458,6 +458,20 @@ static int nci_dev_down(struct nfc_dev *nfc_dev)
return nci_close_device(ndev);
}
+int nci_init(struct nci_dev *ndev)
+{
+ return __nci_request(ndev, nci_init_req, 0,
+ msecs_to_jiffies(NCI_INIT_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_init);
+
+int nci_reset(struct nci_dev *ndev)
+{
+ return __nci_request(ndev, nci_reset_req, 0,
+msecs_to_jiffies(NCI_RESET_TIMEOUT));
+}
+EXPORT_SYMBOL(nci_reset);
+
int nci_set_config(struct nci_dev *ndev, __u8 id, size_t len, __u8 *val)
{
struct nci_set_config_param param;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] NFC: NCI: Allow connection close with dev down
By calling __nci_request instead of nci_request allows the driver to use
the function while initializing the device (setup stage)
Signed-off-by: Robert Dolca
---
net/nfc/nci/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c
index 9575a18..c4dd5d8 100644
--- a/net/nfc/nci/core.c
+++ b/net/nfc/nci/core.c
@@ -558,7 +558,7 @@ static void nci_core_conn_close_req(struct nci_dev *ndev,
unsigned long opt)
int nci_core_conn_close(struct nci_dev *ndev, u8 conn_id)
{
- return nci_request(ndev, nci_core_conn_close_req, conn_id,
+ return __nci_request(ndev, nci_core_conn_close_req, conn_id,
msecs_to_jiffies(NCI_CMD_TIMEOUT));
}
EXPORT_SYMBOL(nci_core_conn_close);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] NFC: NCI: Exporting NFC command and data send API
nci_send_cmd was exported in order to send commands to the device from the driver. For the firmware update the driver may use nci_send_data. Signed-off-by: Robert Dolca --- net/nfc/nci/core.c | 1 + net/nfc/nci/data.c | 1 + 2 files changed, 2 insertions(+) diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c index c4dd5d8..9605b9c 100644 --- a/net/nfc/nci/core.c +++ b/net/nfc/nci/core.c @@ -1153,6 +1153,7 @@ int nci_send_cmd(struct nci_dev *ndev, __u16 opcode, __u8 plen, void *payload) return 0; } +EXPORT_SYMBOL(nci_send_cmd); /* NCI TX Data worker thread */ diff --git a/net/nfc/nci/data.c b/net/nfc/nci/data.c index 566466d..83acd18 100644 --- a/net/nfc/nci/data.c +++ b/net/nfc/nci/data.c @@ -203,6 +203,7 @@ free_exit: exit: return rc; } +EXPORT_SYMBOL(nci_send_data); /* - NCI RX Data - */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] Adds Intel FieldsPeak NFC solution driver
This patch adds support for Intel's FieldsPeak NFC solution. The device is enumerated with ACPI and platform init. In order to implement the driver the nci_core_conn_create was modified in order to report the ID of the newly created connection. Fixed a bug that prevented to close a connection from the driver while the dev was down. The max packet size of a connection can be retrieved by the driver. The init, reset NCI functions can be called from the driver. The driver can also send command to the device using the NFC subsystem using the request - response blocking method. Robert Dolca (8): NFC: NCI: Allow connection close with dev down NFC: NCI: Exporting NFC command and data send API NFC: NCI: Adds NCI init and reset API for drivers NFC: NCI: Add a special nci_request for driver NFC: NCI: Don't call setup if previous NCI request failed NFC: NCI: Add function to get max packet size for conn NFC: NCI: Adds a way to get the new connection ID NFC: Add Intel FieldsPeak NFC solution driver drivers/nfc/Kconfig| 1 + drivers/nfc/fdp/Kconfig| 22 ++ drivers/nfc/fdp/Makefile | 10 + drivers/nfc/fdp/cmd.c | 196 +++ drivers/nfc/fdp/core.c | 503 + drivers/nfc/fdp/fdp.h | 115 + drivers/nfc/fdp/i2c.c | 454 + drivers/nfc/fdp/ntf.c | 68 + drivers/nfc/fdp/rsp.c | 117 + drivers/nfc/st21nfcb/st21nfcb_se.c | 2 +- include/linux/platform_data/fdp.h | 33 +++ include/net/nfc/nci_core.h | 18 +- net/nfc/nci/core.c | 53 +++- net/nfc/nci/data.c | 13 + net/nfc/nci/rsp.c | 6 + 15 files changed, 1601 insertions(+), 10 deletions(-) create mode 100644 drivers/nfc/fdp/Kconfig create mode 100644 drivers/nfc/fdp/Makefile create mode 100644 drivers/nfc/fdp/cmd.c create mode 100644 drivers/nfc/fdp/core.c create mode 100644 drivers/nfc/fdp/fdp.h create mode 100644 drivers/nfc/fdp/i2c.c create mode 100644 drivers/nfc/fdp/ntf.c create mode 100644 drivers/nfc/fdp/rsp.c create mode 100644 include/linux/platform_data/fdp.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, 2015-02-20 at 01:00 +0530, Krishna Chaitanya wrote: > Hi Johannes, > > The BW tracking feature in mac80211 is causing connection problems and > operating mode/bw problems when switching b/w modes and bw's in AP. > > For Eg. Initially if AP is operating in VHT-80MHz, and then we changed > in to HT-40MHz, mac80211 cannot handle it because the VHT capability > is mismatched b/w stored info (ifmgd->flags). How are you doing such a change? I was assuming that the BSS would cease to exist if it was reconfigured in such a way. > I have tried your DISABLE_BW_TRACK patch, that helps making the > connection but it doesn't update the chipset causing issues. Well, that was clearly going to happen. > Ideally we should be able to handle all the config changes right? Not sure. How does this config change work? I'd have expected the AP to stop beaconing and kick everyone out if you actually reconfigured it to no longer have VHT since then it can't do VHT rates any more either according to the new config? What exactly are you doing, and how does the AP behave, and what do you expect to happen? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote: > Before that i have a basic question? Should we reset our tracking after > the connection is lost, in my case above the connection was lost (Config > change in A triggers a reboot), still mac80211 is tracking the BW changes? Huh?? So the AP does restart, but mac80211 tries to stay connected to it? That seems pretty unlikely. The tracking *shouldn't* have any knowledge of what happened before the association, but there could be bugs in the flags assignment I guess. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211_hwsim: notify user-space about channel change.
On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote: > > This seems a bit strange - don't we already tag packets with the > > frequency? Why would you need the channel change separately? What does > > that even mean? Depending on how you use this it could entirely break > > off-channel operation, for example. > > I was thinking about passive scans. In that case, we would not always get a > packet transmitted > when the channel changes? Ah, well, ok. However, hwsim doesn't actually really have a concept of the 'current channel', for example in the offchannel code it just temporarily listens on two channels ... so that's not very good for a more realistic implementation :) > I was thinking user-space would mimic a real radio that can only listen on > one channel at once (can any real radios actually listen on two channels at > once?) No, real radios cannot do that (not really anyway - I guess if it was VHT80 it's really already listening on 4 channels but ...) > So, if we are off-channel, and pkt arrives for the 'main' channel, then > a real radio should drop it, right? Yes. > Of course, if user-space does not care, then it can simply ignore the > channel-change > logic so I think this would be backwards compat with existing hwsim > user-space apps. Sure. But given the murky concept of channel change, and not going to PS for off-channel in hwsim etc. I think this would need a bit more design rather than just exposing the mac80211 channel change. Additionally, with chanctx support that won't even be invoked for example. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On Mon, 2015-02-23 at 09:38 -0800, Ben Greear wrote: > > This doesn't really seem right - essentially it means that whatever you > > just gave to userspace is now completely useless? > > > > It seems skb_orphan() could/should be put here. > > I don't understand your complaint, why is what I gave to user-space useless? userspace is supposed to give back the SKB pointer as a cookie when it reports whether or not it was transmitted correctly, and then we will free the SKB afterwards. Note that I also just merged a patch from Bob in this area. > If we just orphan them, does that clean up the skb memory properly? No, of course not, but it removes it from socket accounting. This may be what you want, although I'm not really sure it's the right thing to do since it would make this behave differently than other drivers which also don't orphan the SKB (and shouldn't - you can consider the SKB on this queue as being on the HW DMA queue where it should still be accounted for correctly) I think perhaps you just want Bob's patch to fix the case of too slow userspace. > If not, what eventually frees the skb? The tx status path does. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211_hwsim: support any address in userspace
On Mon, 2015-02-23 at 10:33 -0500, Bob Copeland wrote: > Due to the checks in get_hwsim_data_ref_from_addr, wmediumd > was only able to use the second mac address (those starting with > 0x42). This is confusing and needlessly limiting, so allow any > configured address. > > While at it, use ether_addr_equal since data->addresses and the > address from the netlink payload are aligned(2). As I mentioned on IRC, I think you should iterate the interfaces to identify the currently live MAC addresses instead of the fake "hw addresses" we assign to each hwsim radio. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote: > > Good point. I was actually thinking about it. I can try cooking a > > patch unless you want to do it yourself :-) > > I've taken a look into this. The most obvious place to add the > timestamp for each packet would be ieee80211_tx_info (i.e. the > skb->cb[48]). The problem is it's very tight there. Even squeezing 2 > bytes (allowing up to 64ms of tx completion delay which I'm worried > won't be enough) will be troublesome. Some drivers already use every > last byte of their allowance on 64bit archs (e.g. ar5523 uses entire > 40 bytes of driver_data). Couldn't we just repurpose the existing skb->tstamp field for this, as long as the skb is fully contained within the wireless layer? Actually, it looks like we can't, since I guess timestamping options can be turned on on any socket. > I wonder if it's okay to bump skb->cb to 56 bytes to avoid the cascade > of changes required to implement the tx completion delay accounting? I have no doubt that would be rejected :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AR9462 problems connecting again..
On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote: > Over the weekend I found a bug in minstrel-ht that might well be > implicated here. > > The last retransmit rate is meant to be a 'get the packet there > reliably' rate; minstrel-ht doesn't do that right, and can pick a > fairly flaky rate instead. > > Can't generate a proper patch right now, so this diff might not apply > cleanly, but the fix is simply to change 75 to 99 in the two places > below: While this may indeed be helpful, I don't think it is sufficient for this EAPOL frame related issue. What I would like to see is minstrel_ht using a basic rate (something non-HT) at the end of the retry series for EAPOL frames. The current behavior looks very suspicious to me. The early EAPOL frames after association are being used to probe for higher rates. This results in the total number of retry attempts actually getting smaller than any other frame, i.e., minstrel_ht seems to be using significantly _less_ robust choices for the EAPOL frames than following "normal" data frames! This should really be the other way around.. As an example, I'm seeing this on 5 GHz band (with the 75 to 99 change in place, but behavior was more or less identical without it): - the first EAPOL frame (msg 2/4) getting one attempt at MCS 3, 2 attempts at MCS 0, 2 attempts at MCS 0 (yes, identical to the previous one) with total maximum of 5 attempts - the second EAPOL frame (msg 4/4) getting one attempt at MCS 9, 2 attempts at MCS 0, 2 attempts at MCS 0 with total maximum of 5 attempts - another data frame after this: 5 attempts at MCS 9, 5 attempts at MCS 3, 5 attempts at MCS 3 with total maximum of 15 attempts(!!) This cannot be the best approach here.. For the IEEE80211_TX_CTRL_PORT_CTRL_PROTO cases, there are identified issues where failing to deliver the frame results is significant issues either in getting connected in the first place or getting disconnected if rekeying fails. I'm not sure how this would be implemented cleanly in minstrel_ht or whether that is even the best place (i.e., rate.c could do this instead), but I'd like that third attempt for control port cases to be dropped to use a (lowish) basic rate and non-MCS at that since there may be some interop issues with HT MCS early during association. Alternatively with drivers like ath9k that support 4 rate values, it would also be fine to add this basic rate attempt (or well, I'd have multiple, say 4, such attempts) as an additional 4th entry which does not currently seem to get used with minstrel at all. The "(lowish) basic rate" here could be defined as 6 Mbps OFDM for 5 GHz band and either that or maybe even 2 Mbps or 5.5 Mbps on 2.4 GHz (if included by the AP in basic rate set). -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 3:39 PM, Johannes Berg wrote: > On Fri, 2015-02-20 at 02:58 +0530, Krishna Chaitanya wrote: > >> Before that i have a basic question? Should we reset our tracking after >> the connection is lost, in my case above the connection was lost (Config >> change in A triggers a reboot), still mac80211 is tracking the BW changes? > > Huh?? > > So the AP does restart, but mac80211 tries to stay connected to it? That > seems pretty unlikely. The tracking *shouldn't* have any knowledge of > what happened before the association, but there could be bugs in the > flags assignment I guess. Let me explain the sequences. STA (mac80211) connects to AP in VHT-80. AP is reconfigured to 11n40 (stops beaconing for about 30secs and then starts again). STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. STA see's AP again and tries to connect, but due to BW tracking in mac80211 it doesn't connect. So i guess we are not resetting the tracking after losing connection. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote: > On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote: > > > > Good point. I was actually thinking about it. I can try cooking a > > > patch unless you want to do it yourself :-) > > > > I've taken a look into this. The most obvious place to add the > > timestamp for each packet would be ieee80211_tx_info (i.e. the > > skb->cb[48]). The problem is it's very tight there. Even squeezing 2 > > bytes (allowing up to 64ms of tx completion delay which I'm worried > > won't be enough) will be troublesome. Some drivers already use every > > last byte of their allowance on 64bit archs (e.g. ar5523 uses entire > > 40 bytes of driver_data). > > Couldn't we just repurpose the existing skb->tstamp field for this, as > long as the skb is fully contained within the wireless layer? > > Actually, it looks like we can't, since I guess timestamping options can > be turned on on any socket. Actually, that creates a clone or a new skb? Hmm. Anyway, I think we should just move the vif and hw_key pointers out of the tx_info and into ieee80211_tx_control. That will give us plenty of space, and they can't really be used long-term anyway? Although ... both might be somewhat problematic for mac80211 itself? Hmm. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver
I have no idea about NFC, but > +config NFC_FDP > + tristate "Intel FDP NFC driver" > + depends on NFC_NCI > + select CRC_CCITT > + default n > + ---help--- > + Intel FDP core driver. > + This is a driver based on the NCI NFC kernel layers. > + > + To compile this driver as a module, choose m here. The module will > + be called pn547. this seems like a copy/paste error? Certainly it's called fdp? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: > STA (mac80211) connects to AP in VHT-80. > AP is reconfigured to 11n40 (stops beaconing for about 30secs and then > starts again). > STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. > STA see's AP again and tries to connect, But this goes through the supplicant, right? You actually get a full connection loss (which I certainly would expect after 30 seconds) > but due to BW tracking in > mac80211 it doesn't connect. > > So i guess we are not resetting the tracking after losing connection. Right, some flag is not getting reset correctly I suppose. I thought we had pretty robust code for this, but I guess not. Easiest might be to print the flags and other state for during all connection attempts, and then compare * VHT connection * subsequent HT connection * HT connection after reloading the driver johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 8/8] NFC: Add Intel FieldsPeak NFC solution driver
On Tue, Feb 24, 2015 at 11:33:10AM +0100, Johannes Berg wrote: > > +config NFC_FDP > > + tristate "Intel FDP NFC driver" > > + depends on NFC_NCI > > + select CRC_CCITT > > + default n > > + ---help--- > > + Intel FDP core driver. > > + This is a driver based on the NCI NFC kernel layers. > > + > > + To compile this driver as a module, choose m here. The module will > > + be called pn547. > > this seems like a copy/paste error? Certainly it's called fdp? You are right. It should be FDP instead of pn547. I will also rename the menu entry name from "Intel FDP NFC driver" to "Intel FieldsPeak (FDP) NFC driver" to be more clear what FDP means. Thanks, Robert -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: calls nl80211_exit on error
On Wed, 2015-01-28 at 10:03 +0800, Junjie Mao wrote: > nl80211_exit should be called in cfg80211_init if cfg80211_init succeeds but > regulatory_init or create_singlethread_workqueue fails. Applied, thanks. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Throughput regression with `tcp: refine TSO autosizing`
On Tue, 2015-02-24 at 11:30 +0100, Johannes Berg wrote: > On Tue, 2015-02-24 at 11:24 +0100, Johannes Berg wrote: > > On Thu, 2015-02-12 at 08:48 +0100, Michal Kazior wrote: > > > > > > Good point. I was actually thinking about it. I can try cooking a > > > > patch unless you want to do it yourself :-) > > > > > > I've taken a look into this. The most obvious place to add the > > > timestamp for each packet would be ieee80211_tx_info (i.e. the > > > skb->cb[48]). The problem is it's very tight there. Even squeezing 2 > > > bytes (allowing up to 64ms of tx completion delay which I'm worried > > > won't be enough) will be troublesome. Some drivers already use every > > > last byte of their allowance on 64bit archs (e.g. ar5523 uses entire > > > 40 bytes of driver_data). > > > > Couldn't we just repurpose the existing skb->tstamp field for this, as > > long as the skb is fully contained within the wireless layer? > > > > Actually, it looks like we can't, since I guess timestamping options can > > be turned on on any socket. > > Actually, that creates a clone or a new skb? Hmm. Ah and then it puts it on the error queue right away, so I think we can reuse it. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg wrote: > On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: > >> STA (mac80211) connects to AP in VHT-80. >> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then >> starts again). >> STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. >> STA see's AP again and tries to connect, > > But this goes through the supplicant, right? You actually get a full > connection loss (which I certainly would expect after 30 seconds) Our HW N/W lost event timeout is 5secs. >> but due to BW tracking in >> mac80211 it doesn't connect. >> >> So i guess we are not resetting the tracking after losing connection. > > Right, some flag is not getting reset correctly I suppose. I thought we > had pretty robust code for this, but I guess not. > > Easiest might be to print the flags and other state for during all > connection attempts, and then compare > * VHT connection > * subsequent HT connection > * HT connection after reloading the driver Sure Johannes, will share the info. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
iw set fixed bitrate doesn't commit at 802.11n mode
Hello all. I'm working on 5 GHz band, Microtik R52n-M card and when forcing bitrate, it doesn't work for .11n mode executing the following comands: - iw dev wlan0 set noack_map 0x0009 - iw dev wlan0 set bitrates ht-mcs-5 10 No error is thrown but PHY bitrate remains at 6.0 Mbit/s. After that, I execute comand - iw dev wlan0 set bitrates legacy-5 54 and bitrate goes up to 54 Mbit/s (iperf UDP goes from 5.5 Mbit/s to 31.5Mbit/s) Doing "iw dev wlan0 set bitrates mcs-5 10" bitrate falls back to 6 Mbit/s. Tested on Ubuntu version 14.04.02 LTS x64, AP-STA mode. Thanks. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] mac80211_hwsim: support any address in userspace
Due to the checks in get_hwsim_data_ref_from_addr, wmediumd
was only able to use the second mac address (those starting with
0x42). This is confusing and needlessly limiting, so allow any
configured address.
Signed-off-by: Bob Copeland
---
v2: use mac80211_hwsim_addr_match instead which checks active
interface addresses instead of pre-configured 'hardware'
addresses (Johannes)
drivers/net/wireless/mac80211_hwsim.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c
b/drivers/net/wireless/mac80211_hwsim.c
index 1204853..3555251 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -907,8 +907,7 @@ static void mac80211_hwsim_tx_frame_nl(struct ieee80211_hw
*hw,
goto nla_put_failure;
}
- if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER,
- ETH_ALEN, data->addresses[1].addr))
+ if (nla_put(skb, HWSIM_ATTR_ADDR_TRANSMITTER, ETH_ALEN, hdr->addr2))
goto nla_put_failure;
/* We get the skb->data */
@@ -2611,7 +2610,7 @@ static struct mac80211_hwsim_data
*get_hwsim_data_ref_from_addr(const u8 *addr)
spin_lock_bh(&hwsim_radio_lock);
list_for_each_entry(data, &hwsim_radios, list) {
- if (memcmp(data->addresses[1].addr, addr, ETH_ALEN) == 0) {
+ if (mac80211_hwsim_addr_match(data, addr)) {
_found = true;
break;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
Both wpa_supplicant and mac80211 has inactivity timer. By default
wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30 minutes.
If wpa_supplicant uses more long timer than mac80211, wpa_supplicant will get
unexpected disconnection by mac80211. This patch adds functionality of disabling
mac80211 inactivity timer to avoid to prevent wpa_supplicant inactivity timer.
I have thought setting 0x to NL80211_MESHCONF_PLINK_TIMEOUT will solve
this problem without this patch. But the approach does not work on 32 bit
system. To explain the reason, I will show STA expiration rule in kernel. This
is the expression.
(current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250)
On 32bit system, right side could be over flow and be unexpected small value if
NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large. STA expiration occurs by
this reason. So I made this patch.
Signed-off-by: Masashi Honma
---
include/uapi/linux/nl80211.h | 3 ++-
net/mac80211/mesh.c | 3 ++-
net/wireless/nl80211.c | 2 +-
3 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 1cbc3aa..0c71180 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -3092,7 +3092,8 @@ enum nl80211_mesh_power_mode {
*
* @NL80211_MESHCONF_PLINK_TIMEOUT: If no tx activity is seen from a STA we've
* established peering with for longer than this time (in seconds), then
- * remove it from the STA's list of peers. Default is 30 minutes.
+ * remove it from the STA's list of peers. You may set this to 0 to disable
+ * the removal of the STA. Default is 30 minutes.
*
* @__NL80211_MESHCONF_ATTR_AFTER_LAST: internal use
*/
diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c
index 0c8b2a7..acf441f 100644
--- a/net/mac80211/mesh.c
+++ b/net/mac80211/mesh.c
@@ -574,7 +574,8 @@ static void ieee80211_mesh_housekeeping(struct
ieee80211_sub_if_data *sdata)
struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh;
u32 changed;
- ieee80211_sta_expire(sdata, ifmsh->mshcfg.plink_timeout * HZ);
+ if (ifmsh->mshcfg.plink_timeout > 0)
+ ieee80211_sta_expire(sdata, ifmsh->mshcfg.plink_timeout * HZ);
mesh_path_expire(sdata);
changed = mesh_accept_plinks_update(sdata);
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e9ad9d9..bef52af 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -5261,7 +5261,7 @@ do {
\
FILL_IN_MESH_PARAM_IF_SET(tb, cfg, dot11MeshAwakeWindowDuration,
0, 65535, mask,
NL80211_MESHCONF_AWAKE_WINDOW, nla_get_u16);
- FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 1, 0x,
+ FILL_IN_MESH_PARAM_IF_SET(tb, cfg, plink_timeout, 0, 0x,
mask, NL80211_MESHCONF_PLINK_TIMEOUT,
nla_get_u32);
if (mask_out)
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On 02/24/2015 02:14 AM, Johannes Berg wrote: On Mon, 2015-02-23 at 09:38 -0800, Ben Greear wrote: This doesn't really seem right - essentially it means that whatever you just gave to userspace is now completely useless? It seems skb_orphan() could/should be put here. I don't understand your complaint, why is what I gave to user-space useless? userspace is supposed to give back the SKB pointer as a cookie when it reports whether or not it was transmitted correctly, and then we will free the SKB afterwards. If there is no status to return, then why would user-space call back at all? Should user-space *always* return a status even when not requested to? Thanks, Ben Note that I also just merged a patch from Bob in this area. If we just orphan them, does that clean up the skb memory properly? No, of course not, but it removes it from socket accounting. This may be what you want, although I'm not really sure it's the right thing to do since it would make this behave differently than other drivers which also don't orphan the SKB (and shouldn't - you can consider the SKB on this queue as being on the HW DMA queue where it should still be accounted for correctly) I think perhaps you just want Bob's patch to fix the case of too slow userspace. If not, what eventually frees the skb? The tx status path does. johannes -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On Tue, 2015-02-24 at 06:28 -0800, Ben Greear wrote: > If there is no status to return, then why would user-space call back at all? > > Should user-space *always* return a status even when not requested to? I'd certainly expect so from hwsim. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211_hwsim: notify user-space about channel change.
On 02/24/2015 02:11 AM, Johannes Berg wrote: On Mon, 2015-02-23 at 09:43 -0800, Ben Greear wrote: This seems a bit strange - don't we already tag packets with the frequency? Why would you need the channel change separately? What does that even mean? Depending on how you use this it could entirely break off-channel operation, for example. I was thinking about passive scans. In that case, we would not always get a packet transmitted when the channel changes? Ah, well, ok. However, hwsim doesn't actually really have a concept of the 'current channel', for example in the offchannel code it just temporarily listens on two channels ... so that's not very good for a more realistic implementation :) I was thinking user-space would mimic a real radio that can only listen on one channel at once (can any real radios actually listen on two channels at once?) No, real radios cannot do that (not really anyway - I guess if it was VHT80 it's really already listening on 4 channels but ...) So, if we are off-channel, and pkt arrives for the 'main' channel, then a real radio should drop it, right? Yes. Of course, if user-space does not care, then it can simply ignore the channel-change logic so I think this would be backwards compat with existing hwsim user-space apps. Sure. But given the murky concept of channel change, and not going to PS for off-channel in hwsim etc. I think this would need a bit more design rather than just exposing the mac80211 channel change. Additionally, with chanctx support that won't even be invoked for example. We could push more and more of this to user-space and let it decide whether and how to forward or accept frames for particular radios. But, to do that, we need the low-level settings sent to user-space (such as current channel). Encryption keys could be a future enhancement here, so that we can do 'hardware' encryption in hwsim (and handle encrypt/decrypt logic however we want in user-space). For in-kernel testing (ie, no user-space hwsim tool), then other methods can be used, or we can just ignore the trickier details. My interest is primarily in user-space hwsim tool at the moment. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211-hwsim: Don't enqueue pkts that do not want txstatus.
On 02/24/2015 06:34 AM, Johannes Berg wrote: On Tue, 2015-02-24 at 06:28 -0800, Ben Greear wrote: If there is no status to return, then why would user-space call back at all? Should user-space *always* return a status even when not requested to? I'd certainly expect so from hwsim. I expected just the opposite. But, I can change my user-space code easily enough. Thanks, Ben johannes -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] mac80211_hwsim: notify user-space about channel change.
On Tue, 2015-02-24 at 06:36 -0800, Ben Greear wrote: > We could push more and more of this to user-space and let it decide whether > and > how to forward or accept frames for particular radios. Sure, no objection to that. However, just arbitrarily adding a "change channel" call, without thinking about the realities of the code already supporting multi-channel concurrency, remain-on-channel and hw-scan operations won't get us very far and just lead to issues with the API. > But, to do that, we need the low-level settings sent to user-space > (such as current channel). Encryption keys could be a future enhancement > here, so that we can do 'hardware' encryption in hwsim (and handle > encrypt/decrypt > logic however we want in user-space). Sure. I'd just like to ask that the API is actually useful in more than the default single-channel support BSS-only case :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rtlwifi: Improve handling of IPv6 packets
Routine rtl_is_special_data() is supposed to identify packets that need to
use a low bit rate so that the probability of successful transmission is
high. The current version has a bug that causes all IPv6 packets to be
labelled as special, with a corresponding low rate of transmission. A
complete fix will be quite intrusive, but until that is available, all
IPv6 packets are identified as regular.
This patch also removes a magic number.
Reported-and-tested-by: Alan Fisher
Signed-off-by: Larry Finger
Cc: Stable [3.18+]
Cc: Alan Fisher
---
drivers/net/wireless/rtlwifi/base.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/base.c
b/drivers/net/wireless/rtlwifi/base.c
index 1d46774..074f716 100644
--- a/drivers/net/wireless/rtlwifi/base.c
+++ b/drivers/net/wireless/rtlwifi/base.c
@@ -1386,8 +1386,11 @@ u8 rtl_is_special_data(struct ieee80211_hw *hw, struct
sk_buff *skb, u8 is_tx)
}
return true;
- } else if (0x86DD == ether_type) {
- return true;
+ } else if (ETH_P_IPV6 == ether_type) {
+ /* TODO: Handle any IPv6 cases that need special handling.
+* For now, always return false
+*/
+ goto end;
}
end:
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Adds Intel FieldsPeak NFC solution driver
I'm excited - what's NFC? - Greg On Tue, Feb 24, 2015 at 2:01 AM, Robert Dolca wrote: > This patch adds support for Intel's FieldsPeak NFC solution. > The device is enumerated with ACPI and platform init. > > In order to implement the driver the nci_core_conn_create was > modified in order to report the ID of the newly created connection. > Fixed a bug that prevented to close a connection from the driver while > the dev was down. > > The max packet size of a connection can be retrieved by the driver. > > The init, reset NCI functions can be called from the driver. The driver > can also send command to the device using the NFC subsystem using the > request - response blocking method. > > Robert Dolca (8): > NFC: NCI: Allow connection close with dev down > NFC: NCI: Exporting NFC command and data send API > NFC: NCI: Adds NCI init and reset API for drivers > NFC: NCI: Add a special nci_request for driver > NFC: NCI: Don't call setup if previous NCI request failed > NFC: NCI: Add function to get max packet size for conn > NFC: NCI: Adds a way to get the new connection ID > NFC: Add Intel FieldsPeak NFC solution driver > > drivers/nfc/Kconfig| 1 + > drivers/nfc/fdp/Kconfig| 22 ++ > drivers/nfc/fdp/Makefile | 10 + > drivers/nfc/fdp/cmd.c | 196 +++ > drivers/nfc/fdp/core.c | 503 > + > drivers/nfc/fdp/fdp.h | 115 + > drivers/nfc/fdp/i2c.c | 454 + > drivers/nfc/fdp/ntf.c | 68 + > drivers/nfc/fdp/rsp.c | 117 + > drivers/nfc/st21nfcb/st21nfcb_se.c | 2 +- > include/linux/platform_data/fdp.h | 33 +++ > include/net/nfc/nci_core.h | 18 +- > net/nfc/nci/core.c | 53 +++- > net/nfc/nci/data.c | 13 + > net/nfc/nci/rsp.c | 6 + > 15 files changed, 1601 insertions(+), 10 deletions(-) > create mode 100644 drivers/nfc/fdp/Kconfig > create mode 100644 drivers/nfc/fdp/Makefile > create mode 100644 drivers/nfc/fdp/cmd.c > create mode 100644 drivers/nfc/fdp/core.c > create mode 100644 drivers/nfc/fdp/fdp.h > create mode 100644 drivers/nfc/fdp/i2c.c > create mode 100644 drivers/nfc/fdp/ntf.c > create mode 100644 drivers/nfc/fdp/rsp.c > create mode 100644 include/linux/platform_data/fdp.h > > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe netdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Adds Intel FieldsPeak NFC solution driver
On Tue, Feb 24, 2015 at 6:14 PM, Greg Rose wrote: > I'm excited - what's NFC? Please don't do top posting. Other than that: http://en.wikipedia.org/wiki/Near_field_communication Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Adds Intel FieldsPeak NFC solution driver
On Tue, Feb 24, 2015 at 8:25 AM, Daniel Baluta wrote: > On Tue, Feb 24, 2015 at 6:14 PM, Greg Rose wrote: >> I'm excited - what's NFC? > > > Please don't do top posting. My apologies - my smartphone interface rather sucks sometimes. > > Other than that: > > http://en.wikipedia.org/wiki/Near_field_communication > > Daniel. Thanks! - Greg -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
On Tue, Feb 24, 2015 at 2:26 AM, Jouni Malinen wrote: > On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote: >> Over the weekend I found a bug in minstrel-ht that might well be >> implicated here. >> >> The last retransmit rate is meant to be a 'get the packet there >> reliably' rate; minstrel-ht doesn't do that right, and can pick a >> fairly flaky rate instead. >> >> Can't generate a proper patch right now, so this diff might not apply >> cleanly, but the fix is simply to change 75 to 99 in the two places >> below: > > While this may indeed be helpful, I don't think it is sufficient for > this EAPOL frame related issue. What I would like to see is minstrel_ht > using a basic rate (something non-HT) at the end of the retry series for > EAPOL frames. > > The current behavior looks very suspicious to me. The early EAPOL frames > after association are being used to probe for higher rates. This results > in the total number of retry attempts actually getting smaller than any > other frame, i.e., minstrel_ht seems to be using significantly _less_ > robust choices for the EAPOL frames than following "normal" data frames! > This should really be the other way around.. > > As an example, I'm seeing this on 5 GHz band (with the 75 to 99 change > in place, but behavior was more or less identical without it): > - the first EAPOL frame (msg 2/4) getting one attempt at MCS 3, 2 > attempts at MCS 0, 2 attempts at MCS 0 (yes, identical to the previous > one) with total maximum of 5 attempts > - the second EAPOL frame (msg 4/4) getting one attempt at MCS 9, 2 > attempts at MCS 0, 2 attempts at MCS 0 with total maximum of 5 > attempts > - another data frame after this: 5 attempts at MCS 9, 5 attempts at MCS > 3, 5 attempts at MCS 3 with total maximum of 15 attempts(!!) I would in general prefer that the excessive retries in the present driver layers in wifi be dramatically reduced, the packet dropped and the problem punted to higher layers. > This cannot be the best approach here.. Falling back faster to the lowest possible rate with minimum retries, and then giving up sooner would be better. 15 attempts? jeeze > For the > IEEE80211_TX_CTRL_PORT_CTRL_PROTO cases, there are identified issues > where failing to deliver the frame results is significant issues either > in getting connected in the first place or getting disconnected if > rekeying fails. > > I'm not sure how this would be implemented cleanly in minstrel_ht or > whether that is even the best place (i.e., rate.c could do this > instead), but I'd like that third attempt for control port cases to be > dropped to use a (lowish) basic rate and non-MCS at that since there may > be some interop issues with HT MCS early during association. > Alternatively with drivers like ath9k that support 4 rate values, it > would also be fine to add this basic rate attempt (or well, I'd have > multiple, say 4, such attempts) as an additional 4th entry which does > not currently seem to get used with minstrel at all. > > The "(lowish) basic rate" here could be defined as 6 Mbps OFDM for 5 GHz > band and either that or maybe even 2 Mbps or 5.5 Mbps on 2.4 GHz (if > included by the AP in basic rate set). > > -- > Jouni MalinenPGP id EFC895FA > ___ > ath9k-devel mailing list > ath9k-de...@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: new firmware for Intel wireless Intel 3160 / 7260 / 7265 / 7265D devices
On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote: > On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote: > > On Tue, Feb 03, 2015 at 09:39:28PM +, Grumbach, Emmanuel wrote: > > > Hi, > > > > > > This is a pull request for new firmwares for the Intel wireless devices > > > mentioned in the subject. > > > > > > I replace -10.ucode with new ones (that includes bug fixes). > > > I add the brand new -12.ucode. > > > > > > Please pull. > > > > > > The following changes since commit > > > 38e5405c96d10bb42b629b45210c46166461fc21: > > > > > > > oh, heh, only 1 commit, not 3. ;-) > > > > Well - actually 2 commits. You missed the one that updates the -10.ucode > from 23.11.10.0 23.12.10.0. > Ah, oops, I've pulled this in now. --Kyle -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] brcm: drop executable from brcmfmac43143-sdio.bin
On Mon, Feb 16, 2015 at 11:09:47PM +0100, Rafał Miłecki wrote: > It isn't supposed to be run on host obviously. > > Signed-off-by: Rafał Miłecki Ah, I was working backwards and Marcel sent a patch more recently which fixed this and a few other files. Sorry about that -- Kyle > --- > brcm/brcmfmac43143-sdio.bin | Bin > 1 file changed, 0 insertions(+), 0 deletions(-) > mode change 100755 => 100644 brcm/brcmfmac43143-sdio.bin > > diff --git a/brcm/brcmfmac43143-sdio.bin b/brcm/brcmfmac43143-sdio.bin > old mode 100755 > new mode 100644 > -- > 1.8.4.5 > > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
Hi Jouni, Currently Minstrel_HT just skips EAPOL packets for its rate sampling on non-mrr chips by testing: (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO) On mrr hardware it uses them for probing. But the general MRR-chain should look like this for ath5k and ath9k chips that support 4 mrr chains: mrr[0]:= max_tp_rate[0] mrr[1]:= max_tp_rate[1] mrr[2]:= max_prob_rate mrr[3]:= basic_rate So for Minstrel Sampling Packets as well as for data packets, the 4th mrr stage should use the slowest rate in case all other 3 mrr stages failed with their retry attempts. I do see two possible options for control frames like EAPOL to be send out in a more robust fashion: - exclude those frames from AMPDU aggragates - change their mrr setup to be more conservative What do you think about this ? Greetings Thomas > Am 24.02.2015 um 11:26 schrieb Jouni Malinen : > > On Tue, Feb 24, 2015 at 01:29:27PM +1100, Andrew McGregor wrote: >> Over the weekend I found a bug in minstrel-ht that might well be >> implicated here. >> >> The last retransmit rate is meant to be a 'get the packet there >> reliably' rate; minstrel-ht doesn't do that right, and can pick a >> fairly flaky rate instead. >> >> Can't generate a proper patch right now, so this diff might not apply >> cleanly, but the fix is simply to change 75 to 99 in the two places >> below: > > While this may indeed be helpful, I don't think it is sufficient for > this EAPOL frame related issue. What I would like to see is minstrel_ht > using a basic rate (something non-HT) at the end of the retry series for > EAPOL frames. > > The current behavior looks very suspicious to me. The early EAPOL frames > after association are being used to probe for higher rates. This results > in the total number of retry attempts actually getting smaller than any > other frame, i.e., minstrel_ht seems to be using significantly _less_ > robust choices for the EAPOL frames than following "normal" data frames! > This should really be the other way around.. > > As an example, I'm seeing this on 5 GHz band (with the 75 to 99 change > in place, but behavior was more or less identical without it): > - the first EAPOL frame (msg 2/4) getting one attempt at MCS 3, 2 > attempts at MCS 0, 2 attempts at MCS 0 (yes, identical to the previous > one) with total maximum of 5 attempts > - the second EAPOL frame (msg 4/4) getting one attempt at MCS 9, 2 > attempts at MCS 0, 2 attempts at MCS 0 with total maximum of 5 > attempts > - another data frame after this: 5 attempts at MCS 9, 5 attempts at MCS > 3, 5 attempts at MCS 3 with total maximum of 15 attempts(!!) > > This cannot be the best approach here.. For the > IEEE80211_TX_CTRL_PORT_CTRL_PROTO cases, there are identified issues > where failing to deliver the frame results is significant issues either > in getting connected in the first place or getting disconnected if > rekeying fails. > > I'm not sure how this would be implemented cleanly in minstrel_ht or > whether that is even the best place (i.e., rate.c could do this > instead), but I'd like that third attempt for control port cases to be > dropped to use a (lowish) basic rate and non-MCS at that since there may > be some interop issues with HT MCS early during association. > Alternatively with drivers like ath9k that support 4 rate values, it > would also be fine to add this basic rate attempt (or well, I'd have > multiple, say 4, such attempts) as an additional 4th entry which does > not currently seem to get used with minstrel at all. > > The "(lowish) basic rate" here could be defined as 6 Mbps OFDM for 5 GHz > band and either that or maybe even 2 Mbps or 5.5 Mbps on 2.4 GHz (if > included by the AP in basic rate set). > > -- > Jouni MalinenPGP id EFC895FA > ___ > ath9k-devel mailing list > ath9k-de...@lists.ath9k.org > https://lists.ath9k.org/mailman/listinfo/ath9k-devel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] brcm: drop executable from brcmfmac43143-sdio.bin
On 24 February 2015 at 18:53, Kyle McMartin wrote: > On Mon, Feb 16, 2015 at 11:09:47PM +0100, Rafał Miłecki wrote: >> It isn't supposed to be run on host obviously. >> >> Signed-off-by: Rafał Miłecki > > Ah, I was working backwards and Marcel sent a patch more recently which > fixed this and a few other files. > > Sorry about that -- Kyle I don't mind (AKA care so much), no prob :) Thanks for handling this. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote: > Currently Minstrel_HT just skips EAPOL packets for its rate sampling on > non-mrr chips by testing: (info->control.flags & > IEEE80211_TX_CTRL_PORT_CTRL_PROTO) Yeah, I noticed that when going through the implementation, but it was indeed only for cases other than ath9k-like drivers. > On mrr hardware it uses them for probing. > But the general MRR-chain should look like this for ath5k and ath9k chips > that support 4 mrr chains: > > mrr[0]:= max_tp_rate[0] > mrr[1]:= max_tp_rate[1] > mrr[2]:= max_prob_rate > mrr[3]:= basic_rate Where is that mrr[3] part implemented? I did not find it when reviewing the design (hw->max_rates >= 3 is used, but not >= 4) and this does not match my experiments either when printing out all four values from ath9k. In every single case I observed, the last entry was unused (idx = -1) and only MCS values were used (i.e., not even a single case of basic rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific case with the AP that I used in the tests). > So for Minstrel Sampling Packets as well as for data packets, the 4th mrr > stage should use the slowest rate in case all other 3 mrr stages failed with > their retry attempts. > > I do see two possible options for control frames like EAPOL to be send out in > a more robust fashion: > - exclude those frames from AMPDU aggragates ath9k does that for IEEE80211_TX_CTL_RATE_CTRL_PROBE which seemed to get set for the initial EAPOL frames. I guess this could be done more generically for all EAPOL frames. > - change their mrr setup to be more conservative That mrr[3]:= basic_rate is the part I was really asking for as far as EAPOL frames are concerned. -- Jouni MalinenPGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3] wext: Return -E2BIG when the buffer is too small for the full scan results, including IEs.
When using the wext compatibility code in cfg80211, part of the IEs
can be truncated if the passed user buffer is large enough for the
BSS but not large enough for all of the IEs. This can cause an EAP
network to show up as a PSK network.
These changes allow the scan to always return -E2BIG in that case.
Signed-off-by: James Minor
---
net/wireless/scan.c | 86 ++---
1 file changed, 76 insertions(+), 10 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index 25e1e1f..dffeaca 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -1239,15 +1239,25 @@ int cfg80211_wext_siwscan(struct net_device *dev,
}
EXPORT_WEXT_HANDLER(cfg80211_wext_siwscan);
-static void ieee80211_scan_add_ies(struct iw_request_info *info,
- const struct cfg80211_bss_ies *ies,
- char **current_ev, char *end_buf)
+static inline void cfg80211_buf_full(char *prev_ev,
+char *current_ev,
+int *err)
+{
+ if (unlikely(prev_ev == current_ev))
+ *err = -E2BIG;
+}
+
+static int ieee80211_scan_add_ies(struct iw_request_info *info,
+ const struct cfg80211_bss_ies *ies,
+ char **current_ev, char *end_buf)
{
const u8 *pos, *end, *next;
struct iw_event iwe;
+ char *prev_ev;
+ int err = 0;
if (!ies)
- return;
+ return err;
/*
* If needed, fragment the IEs buffer (at IE boundaries) into short
@@ -1264,10 +1274,11 @@ static void ieee80211_scan_add_ies(struct
iw_request_info *info,
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVGENIE;
iwe.u.data.length = next - pos;
+ prev_ev = *current_ev;
*current_ev = iwe_stream_add_point(info, *current_ev,
end_buf, &iwe,
(void *)pos);
-
+ cfg80211_buf_full(prev_ev, *current_ev, &err);
pos = next;
}
@@ -1275,10 +1286,13 @@ static void ieee80211_scan_add_ies(struct
iw_request_info *info,
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = IWEVGENIE;
iwe.u.data.length = end - pos;
+ prev_ev = *current_ev;
*current_ev = iwe_stream_add_point(info, *current_ev,
end_buf, &iwe,
(void *)pos);
+ cfg80211_buf_full(prev_ev, *current_ev, &err);
}
+ return err;
}
static char *
@@ -1292,27 +1306,36 @@ ieee80211_bss(struct wiphy *wiphy, struct
iw_request_info *info,
u8 *buf, *cfg, *p;
int rem, i, sig;
bool ismesh = false;
+ char *prev_ev;
+ char *orig_ev = current_ev;
+ int err = 0;
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWAP;
iwe.u.ap_addr.sa_family = ARPHRD_ETHER;
memcpy(iwe.u.ap_addr.sa_data, bss->pub.bssid, ETH_ALEN);
+ prev_ev = current_ev;
current_ev = iwe_stream_add_event(info, current_ev, end_buf, &iwe,
IW_EV_ADDR_LEN);
+ cfg80211_buf_full(prev_ev, current_ev, &err);
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
iwe.u.freq.m =
ieee80211_frequency_to_channel(bss->pub.channel->center_freq);
iwe.u.freq.e = 0;
+ prev_ev = current_ev;
current_ev = iwe_stream_add_event(info, current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);
+ cfg80211_buf_full(prev_ev, current_ev, &err);
memset(&iwe, 0, sizeof(iwe));
iwe.cmd = SIOCGIWFREQ;
iwe.u.freq.m = bss->pub.channel->center_freq;
iwe.u.freq.e = 6;
+ prev_ev = current_ev;
current_ev = iwe_stream_add_event(info, current_ev, end_buf, &iwe,
IW_EV_FREQ_LEN);
+ cfg80211_buf_full(prev_ev, current_ev, &err);
if (wiphy->signal_type != CFG80211_SIGNAL_TYPE_NONE) {
memset(&iwe, 0, sizeof(iwe));
@@ -1341,8 +1364,10 @@ ieee80211_bss(struct wiphy *wiphy, struct
iw_request_info *info,
/* not reached */
break;
}
+ prev_ev = current_ev;
current_ev = iwe_stream_add_event(info, current_ev, end_buf,
&iwe, IW_EV_QUAL_LEN);
+ cfg80211_buf_full(prev_ev, current_ev, &err);
}
memset(&iwe, 0, sizeof(iwe));
@@ -1352,8 +1377,10 @@ ieee80211_bss(struct wiphy *wiphy, struct
iw_request_info *info,
else
iwe.u.data.flags = IW_ENCODE_DISABLED;
iwe.u.data.length = 0;
+
Re: pull request: new firmware for Intel wireless Intel 3160 / 7260 / 7265 / 7265D devices
On Tue, 2015-02-24 at 12:49 -0500, Kyle McMartin wrote: > On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote: > > On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote: > > > On Tue, Feb 03, 2015 at 09:39:28PM +, Grumbach, Emmanuel wrote: > > > > Hi, > > > > > > > > This is a pull request for new firmwares for the Intel wireless devices > > > > mentioned in the subject. > > > > > > > > I replace -10.ucode with new ones (that includes bug fixes). > > > > I add the brand new -12.ucode. > > > > > > > > Please pull. > > > > > > > > The following changes since commit > > > > 38e5405c96d10bb42b629b45210c46166461fc21: > > > > > > > > > > oh, heh, only 1 commit, not 3. ;-) > > > > > > > Well - actually 2 commits. You missed the one that updates the -10.ucode > > from 23.11.10.0 23.12.10.0. > > > > Ah, oops, I've pulled this in now. Thing is that the firmware team keeps finding new bugs :( So I'll have another version tomorrow... Will free to remove the commit and I'll send 23.15.10.0 tomorrow. Sorry
Re: [PATCH v2] mac80211_hwsim: support any address in userspace
On Tue, 2015-02-24 at 08:39 -0500, Bob Copeland wrote: > Due to the checks in get_hwsim_data_ref_from_addr, wmediumd > was only able to use the second mac address (those starting with > 0x42). This is confusing and needlessly limiting, so allow any > configured address. Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] nl80211: add NL80211_CMD_GET_TSF
On Mon, 2015-02-23 at 23:38 +0800, Rohan Joyce wrote: > Hi, > > The motivation for this patch is to assist using a WiiU Gamepad with Linux. > The WiiU Gamepad is an input device that also contains an LCD touchscreen, > speakers and a variety of sensors. The Gamepad connects to an access > point (usually the WiiU console itself, but it can be coerced to connect > to a properly configured hostap). The Gamepad provides five services over > UDP. Two of the services that are provided (audio and video streaming to > the device) use the TSF as a timestamp in the application layer. The > firmware on the Gamepad checks to make sure that incoming packets for > these services have timestamps within 1000us of its own internal clock, > which is synced to the TSF of the access point. Oh, right, I remember now. > At the moment, users who want to use this device have to manually apply > a kernel patch similar to that which was first posted to this list a year > ago. This patch is my attempt to implement the functionality using a more > conventional API and make it easier for end users. > > Should I include protocol implementation details specific to this device in > the documentation of the NL80211_CMD_GET_TSF command? Not necessarily, but some information about why this is needed would be good. I guess since this has no way of using something like 11v this really is the only chance. Note that you'll need to add a feature capability flag for this - many drivers, even ones based on mac80211, will not be able to implement this properly so relying only on the presence of the callback will not work properly. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
On Tue, 2015-02-24 at 22:42 +0900, Masashi Honma wrote: > Both wpa_supplicant and mac80211 has inactivity timer. By default > wpa_supplicant will be timed out in 5 minutes and mac80211's it is 30 minutes. > If wpa_supplicant uses more long timer than mac80211, wpa_supplicant will get > unexpected disconnection by mac80211. This patch adds functionality of > disabling > mac80211 inactivity timer to avoid to prevent wpa_supplicant inactivity timer. > > I have thought setting 0x to NL80211_MESHCONF_PLINK_TIMEOUT will solve > this problem without this patch. But the approach does not work on 32 bit > system. To explain the reason, I will show STA expiration rule in kernel. This > is the expression. > > (current jiffies) > (frame Rx jiffies + NL80211_MESHCONF_PLINK_TIMEOUT * 250) > > On 32bit system, right side could be over flow and be unexpected small value > if > NL80211_MESHCONF_PLINK_TIMEOUT is sufficiently large. STA expiration occurs by > this reason. So I made this patch. Applied, I've reworded and rewrapped the commit log - in the future please send commit logs with at most 72 characters per line. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] mac80211/minstrel: fix !x!=0 confusion
-linux-kernel, +linux-wireless. Look sane, applied. Please send to linux-wireless in the future so patches don't get lost. There's even a script for that ... :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Tue, Feb 24, 2015 at 4:59 PM, Krishna Chaitanya wrote: > On Tue, Feb 24, 2015 at 4:05 PM, Johannes Berg > wrote: >> On Tue, 2015-02-24 at 15:58 +0530, Krishna Chaitanya wrote: >> >>> STA (mac80211) connects to AP in VHT-80. >>> AP is reconfigured to 11n40 (stops beaconing for about 30secs and then >>> starts again). >>> STA loses connection (HW_CONN_TRACK), iee80211_connection_loss is called. >>> STA see's AP again and tries to connect, >> >> But this goes through the supplicant, right? You actually get a full >> connection loss (which I certainly would expect after 30 seconds) > > Our HW N/W lost event timeout is 5secs. > >>> but due to BW tracking in >>> mac80211 it doesn't connect. >>> >>> So i guess we are not resetting the tracking after losing connection. >> >> Right, some flag is not getting reset correctly I suppose. I thought we >> had pretty robust code for this, but I guess not. >> >> Easiest might be to print the flags and other state for during all >> connection attempts, and then compare >> * VHT connection >> * subsequent HT connection >> * HT connection after reloading the driver > Sure Johannes, will share the info. Before you spend time on this, my tests are based on older kernel 3.10.36 but the code in this ares looks pretty much same (At least the parts i am working on :-) ). If time permits, i will try the same with latest kernel as well. Usecase1: When changing from VHT80-HT40. STA disconnect but sometimes unable to reconnect. I have digged in to this issue further, and observed that whenever issue happens the bss_list in the scan list is having old information even though we are doing a new scan as BSS info is not found (even without new scan it should have been flushed). Sometimes "iw wlan0 scan dump" shows empty/VHT info (which is old). So while doing assoc, cfg80211 gets the bss information from bss_list (get_ie(VHT)) and passes to mac80211, which has VHT but AP's beacon/probe resp/assoc resp is HT only causing the issue. Event multiple connection attempts doesn't resolve this, but if i do repeated scan's i am able to connect. Use case2: When changing from HT40-VHT80, the connection goes through but it still connected as HT40 (vht_ie from cfg80211 is returned null). Can you think of any reason why the bss_list is not updated cfg80211? Note: iwconfig and wpa_supplicant both show same behavior. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: > Use case2: When changing from HT40-VHT80, the connection goes through > but it still connected as HT40 (vht_ie from cfg80211 is returned > null). > > Can you think of any reason why the bss_list is not updated cfg80211? > Note: iwconfig and wpa_supplicant both show same behavior. Well, there's no flushing, only overwriting by new results - but if you previuosly got both beacons and probe responses each one will stick around until you get them again. This sounds synthetic - just run your test scripts with "iw wlan0 scan flush". johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Connection issues with BW Tracking in mac80211
On Wed, Feb 25, 2015 at 2:17 AM, Johannes Berg wrote: > On Wed, 2015-02-25 at 02:03 +0530, Krishna Chaitanya wrote: > >> Use case2: When changing from HT40-VHT80, the connection goes through >> but it still connected as HT40 (vht_ie from cfg80211 is returned >> null). >> >> Can you think of any reason why the bss_list is not updated cfg80211? >> Note: iwconfig and wpa_supplicant both show same behavior. > > Well, there's no flushing, only overwriting by new results - but if you > previuosly got both beacons and probe responses each one will stick > around until you get them again. We do have the scan results expiry time of 30secs, that will flush the results from bss_list right? Even the get_bss checks for aging? > > This sounds synthetic - just run your test scripts with "iw wlan0 scan > flush". Sure, will give it a shot. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: new firmware for Intel wireless Intel 3160 / 7260 / 7265 / 7265D devices
On Tue, Feb 24, 2015 at 07:49:37PM +, Grumbach, Emmanuel wrote: > On Tue, 2015-02-24 at 12:49 -0500, Kyle McMartin wrote: > > On Fri, Feb 06, 2015 at 09:31:52AM +, Grumbach, Emmanuel wrote: > > > On Fri, 2015-02-06 at 04:15 -0500, Kyle McMartin wrote: > > > > On Tue, Feb 03, 2015 at 09:39:28PM +, Grumbach, Emmanuel wrote: > > > > > Hi, > > > > > > > > > > This is a pull request for new firmwares for the Intel wireless > > > > > devices > > > > > mentioned in the subject. > > > > > > > > > > I replace -10.ucode with new ones (that includes bug fixes). > > > > > I add the brand new -12.ucode. > > > > > > > > > > Please pull. > > > > > > > > > > The following changes since commit > > > > > 38e5405c96d10bb42b629b45210c46166461fc21: > > > > > > > > > > > > > oh, heh, only 1 commit, not 3. ;-) > > > > > > > > > > Well - actually 2 commits. You missed the one that updates the -10.ucode > > > from 23.11.10.0 23.12.10.0. > > > > > > > Ah, oops, I've pulled this in now. > > Thing is that the firmware team keeps finding new bugs :( > So I'll have another version tomorrow... Will free to remove the commit > and I'll send 23.15.10.0 tomorrow. > > Sorry > Happens :-) I'll make sure to check this mbox tomorrow afternoon and push out an update quickly. regards, Kyle -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
Hi Jouni, > Where is that mrr[3] part implemented? I did not find it when reviewing > the design (hw->max_rates >= 3 is used, but not >= 4) and this does not > match my experiments either when printing out all four values from > ath9k. In every single case I observed, the last entry was unused (idx = > -1) and only MCS values were used (i.e., not even a single case of basic > rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific > case with the AP that I used in the tests). Minstrel_HT does only set mrr[0..2] and does not touch the fourth mrr[3], assumed chips with 4 mrr stages. In function minstrel_ht_update_rates() the rate table struct ieee80211_sta_rates is set for the first 3 out of 4 rates and the fouth rate (mrr[3]) is „-1“. In case of ath9k, the driver in xmit.c allocates in function ath_tx_fill_desc() a struct ath_tx_info info by memset(&info, 0, sizeof(info)) .. so all info->rates[xy].Rate == 0. Than function ath_buf_set_rate() sets all info->rates[xy].Rate to those values specified in the rate table (struct ieee8021_sta_rate) IF (!rates[i].count || (rates[i].idx < 0)) … … so info->rates[3].Rate is untouched and still „0“. I just added a printk() to xmit.c in function ath_tx_fill_desc() just before ath9k_hw_set_txdesc() is called. >From the log I get, e.g.: [ 169.543554] mrr setup: mrr[0]:133 mrr[1]:132 mrr[2]:134 mrr[3]:0 I have not check yet if info->rates[3].Rate == 0 is the lowest possible rate… but I would guess so. Greetings Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
Hi, I thought about doing this for rate probing with FreeBSD's sample rate algorithm, but after actually having to use the damned thing in noisy environments I realised that it just wasn't worth the effort to optimise rate control selection whilst doing EAPOL frames. If we did more useful software retransmission at lower rates then sure, one could just be much more conservative about the rates and retry a few times at a lower rate. However, since that isn't the case and we only get three or so attempts at EAPOL exchange - once a second - before an AP decides we're no good, I figured I'd just skip anything other than the lowest basic rates for the frame exchange and make it associate quicker. I had the same problem with DHCP - initial DHCP leases were failing because the rate control code started high/medium and didn't degrade quickly enough before the next round of DHCP attempts. DHCP backs off even more aggressively, so failing that initial DHCP was quite expensive. -adrian -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] mac80211: Allow 0 for NL80211_MESHCONF_PLINK_TIMEOUT to disable STA expiration
2015-02-25 5:08 GMT+09:00 Johannes Berg : > Applied, I've reworded and rewrapped the commit log - in the future > please send commit logs with at most 72 characters per line. Thanks. I will remember 72 characters rule. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: MediaTek WiFi hardware support in upstream kernel
On 6 February 2015 at 18:29, Jakub Kiciński wrote: > Hello everyone! > > I put together a mac80211 driver for Mediatek MT7601U. It's partially > based on Felix's mt76, but I'm not sure if it will make sense to merge > the two together. MT7601U is a pretty old 1x1 bgn chip for USB dongles > and mt76 now only supports the latest and greatest ac APs. > > I'm testing STA functionality right now and it seems to be working ok. > The code is very much a work in progress but if anyone is interested you > can get it here: > > https://github.com/kuba-moo/mt7601u Hi, Jakub! I happen to have 7601 dongle, so I tested you driver. There were some problems, see "dmesg | grep mt7" output: [3.174960] mt7601u 3-5:1.0: ASIC revision: 76010001 MAC revision: 76010500 [3.181705] mt7601u 3-5:1.0: Firmware Version: 0.1.00 Build: 7640 Build time: 201302052146 [3.573018] mt7601u 3-5:1.0: Warning: unsupported EEPROM version 0d [3.574853] mt7601u 3-5:1.0: EEPROM ver:0d fae:00 [3.816647] usbcore: registered new interface driver mt7601u [ 10.461251] mt7601u_add_interface idx:0 [ 10.463193] mt7601u_bss_info_changed 000e [ 10.469748] mt7601u_conf_tx 03 <- [ 10.473738] mt7601u_conf_tx 02 <- 0001 [ 10.477856] mt7601u_conf_tx 01 <- 0002 [ 10.481980] mt7601u_conf_tx 00 <- 0003 [ 10.486849] mt7601u_bss_info_changed 2000 [ 10.488671] mt7601u_config ch:1 [ 10.504305] mt76_configure_filter changed:0 total:8000 [ 10.508327] mt76_configure_filter changed:0 total:8000 [ 10.550671] mt76_configure_filter changed:0 total:8000 [ 10.616870] mt7601u_config 0100 ch:1 [ 10.619449] mt76_configure_filter changed:10 total:8010 [ 10.621541] mt7601u_config 0040 ch:1 [ 10.692407] mt7601u_config 0040 ch:2 [ 10.992113] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying [ 11.291819] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying [ 11.591524] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying [ 11.891230] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying [ 12.190936] mt7601u 3-5:1.0: Warning: mt7601u_mcu_wait_resp retrying [ 12.192790] mt7601u 3-5:1.0: Error: mt7601u_mcu_wait_resp timed out [ 12.194491] mt7601u_config 0040 ch:3 [ 12.694660] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 12.696360] mt7601u_config 0040 ch:4 [ 13.194210] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 13.195873] mt7601u_config 0040 ch:5 [ 13.693674] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 13.695283] mt7601u_config 0040 ch:6 [ 14.193225] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 14.194808] mt7601u_config 0040 ch:7 [ 14.692677] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 14.694374] mt7601u_config 0040 ch:8 [ 15.192232] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 15.193766] mt7601u_config 0040 ch:9 [ 15.691688] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 15.693268] mt7601u_config 0040 ch:10 [ 16.191318] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 16.192891] mt7601u_config 0040 ch:11 [ 16.690710] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 16.692282] mt7601u_config 0040 ch:12 [ 17.190270] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 17.191771] mt7601u_config 0040 ch:13 [ 17.689713] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 17.691243] mt7601u_config 0040 ch:14 [ 18.189290] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 18.190810] mt7601u_config 0040 ch:1 [ 18.688839] mt7601u 3-5:1.0: Error: send MCU cmd failed:-110 [ 18.690304] mt76_configure_filter changed:0 total:8000 [ 18.692461] mt7601u_config 0100 ch:1 Is it because of "unsupported EEPROM version 0d"? -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ath9k-devel] AR9462 problems connecting again..
On 2015-02-25 07:14, Jouni Malinen wrote: > On Tue, Feb 24, 2015 at 06:54:47PM +0100, Thomas Hühn wrote: >> Currently Minstrel_HT just skips EAPOL packets for its rate sampling on >> non-mrr chips by testing: (info->control.flags & >> IEEE80211_TX_CTRL_PORT_CTRL_PROTO) > > Yeah, I noticed that when going through the implementation, but it was > indeed only for cases other than ath9k-like drivers. > >> On mrr hardware it uses them for probing. >> But the general MRR-chain should look like this for ath5k and ath9k chips >> that support 4 mrr chains: >> >> mrr[0]:= max_tp_rate[0] >> mrr[1]:= max_tp_rate[1] >> mrr[2]:= max_prob_rate >> mrr[3]:= basic_rate > > Where is that mrr[3] part implemented? I did not find it when reviewing > the design (hw->max_rates >= 3 is used, but not >= 4) and this does not > match my experiments either when printing out all four values from > ath9k. In every single case I observed, the last entry was unused (idx = > -1) and only MCS values were used (i.e., not even a single case of basic > rate visible; basic rates being 6, 12, 24 Mbps OFDM in this specific > case with the AP that I used in the tests). Minstrel_ht does *NOT* use mrr[3], nor should it. For normal data packets, a little packet loss under tough conditions is good, otherwise we risk lots of wasted airtime and bufferbloat. >> So for Minstrel Sampling Packets as well as for data packets, the 4th mrr >> stage should use the slowest rate in case all other 3 mrr stages failed with >> their retry attempts. >> >> I do see two possible options for control frames like EAPOL to be send out >> in a more robust fashion: >> - exclude those frames from AMPDU aggragates > > ath9k does that for IEEE80211_TX_CTL_RATE_CTRL_PROBE which seemed to > get set for the initial EAPOL frames. I guess this could be done more > generically for all EAPOL frames. I agree. >> - change their mrr setup to be more conservative > > That mrr[3]:= basic_rate is the part I was really asking for as far as > EAPOL frames are concerned. I don't think we need that. If we just exclude EAPOL from both probing and aggregation, it should be safe. While it's connecting, that leaves in low rates in the retry chain anyway. If it still fails often enough to be noticeable under normal conditions, there must be something seriously wrong outside of rate control, and we should not paper over it with a crude band-aid workaround. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] zero-copy AMSDU processing
On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote: > If the SKB has pages (rather than being linear, as > ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would > probably be the best approach, although it could be possible that would > mess up truesize accounting and lead to lower performance. Certainly > you'd want to do it only for suitably large packets (at least bigger > than 128 bytes or so) Why is it important whether it has pages? Looks like I can play with pointers to the linear part as well. I am thinking about the following scenario: in DMG (60G), max. MSDU size is 7920, so one have to account for this when establishing BACK. Then, I foresee it will be popular that MTU will be configured to 1500 (Ethernet bridging, just laziness etc.), so actual aggregations on the air would be 5x smaller that it could be. Then, I'd like to aggregate 5 packets 1500 bytes each into A-MSDU prior to aggregating it to A_MPDU. Then, I'll have good A-MPDU size. But, having more then 2Gbps throughput, I need effective way to de-aggregate A-MSDU on Rx side. Thanks, Vladimir -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] zero-copy AMSDU processing
On Wed, 2015-02-25 at 09:07 +0200, Vladimir Kondratiev wrote: > On Monday, February 23, 2015 09:35:39 AM Johannes Berg wrote: > > If the SKB has pages (rather than being linear, as > > ieee80211_amsdu_to_8023s() assumes) then what Emmanuel said would > > probably be the best approach, although it could be possible that would > > mess up truesize accounting and lead to lower performance. Certainly > > you'd want to do it only for suitably large packets (at least bigger > > than 128 bytes or so) > > Why is it important whether it has pages? Looks like I can play with > pointers to the linear part as well. I don't think that will work - it would crash later trying to free that page, no? Oh - you mean just skb_pull() and friends? That might actually work, yeah. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] ath10k: add basic tdls support
This patchset introduces tdls funtionality without tdls peer uapsd and tdls channel switching. Tdls is supported by qca6174 hardware what is indicated by firmware through supported services. Tdls station when authorized requires some parameters that are filled in by rate control initialization. Because of that this patches contains one patch for mac80211 which moves rate control initialization before calling drivers station state with transition to authorized state. v2: -introduce tdls peer counter -minor changes after review Marek Puzyniak (3): ath10k: make peer type configurable mac80211: initialize rate control earlier for tdls station ath10k: introduce basic tdls functionality Michal Kazior (1): ath10k: unify tx mode and dispatch drivers/net/wireless/ath/ath10k/core.h| 3 + drivers/net/wireless/ath/ath10k/htt_rx.c | 8 - drivers/net/wireless/ath/ath10k/htt_tx.c | 30 ++- drivers/net/wireless/ath/ath10k/mac.c | 307 +- drivers/net/wireless/ath/ath10k/mac.h | 8 + drivers/net/wireless/ath/ath10k/wmi-ops.h | 50 - drivers/net/wireless/ath/ath10k/wmi-tlv.c | 157 ++- drivers/net/wireless/ath/ath10k/wmi-tlv.h | 52 + drivers/net/wireless/ath/ath10k/wmi.c | 3 +- drivers/net/wireless/ath/ath10k/wmi.h | 43 + net/mac80211/cfg.c| 20 +- 11 files changed, 597 insertions(+), 84 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] ath10k: unify tx mode and dispatch
From: Michal Kazior
There are a few different tx paths depending on
firmware and frame itself.
Creating a uniform decision will make it possible
to switch between different txmode easier, both
for testing and for future features as well.
Signed-off-by: Michal Kazior
Signed-off-by: Marek Puzyniak
---
drivers/net/wireless/ath/ath10k/core.h | 2 +
drivers/net/wireless/ath/ath10k/htt_rx.c | 8 --
drivers/net/wireless/ath/ath10k/htt_tx.c | 30 +++---
drivers/net/wireless/ath/ath10k/mac.c| 155 ---
drivers/net/wireless/ath/ath10k/mac.h| 8 ++
5 files changed, 144 insertions(+), 59 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index d60e46f..94a8788 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -82,6 +82,8 @@ struct ath10k_skb_cb {
dma_addr_t paddr;
u8 eid;
u8 vdev_id;
+ enum ath10k_hw_txrx_mode txmode;
+ bool is_protected;
struct {
u8 tid;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index c1da44f..6d4bb5e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -637,14 +637,6 @@ static int ath10k_htt_rx_crypto_tail_len(struct ath10k *ar,
return 0;
}
-struct rfc1042_hdr {
- u8 llc_dsap;
- u8 llc_ssap;
- u8 llc_ctrl;
- u8 snap_oui[3];
- __be16 snap_type;
-} __packed;
-
struct amsdu_subframe_hdr {
u8 dst[ETH_ALEN];
u8 src[ETH_ALEN];
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c
b/drivers/net/wireless/ath/ath10k/htt_tx.c
index cbd2bc9..5b2c61b 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -420,9 +420,8 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
int res;
u8 flags0 = 0;
u16 msdu_id, flags1 = 0;
- dma_addr_t paddr;
- u32 frags_paddr;
- bool use_frags;
+ dma_addr_t paddr = 0;
+ u32 frags_paddr = 0;
res = ath10k_htt_tx_inc_pending(htt);
if (res)
@@ -440,12 +439,6 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
prefetch_len = min(htt->prefetch_len, msdu->len);
prefetch_len = roundup(prefetch_len, 4);
- /* Since HTT 3.0 there is no separate mgmt tx command. However in case
-* of mgmt tx using TX_FRM there is not tx fragment list. Instead of tx
-* fragment list host driver specifies directly frame pointer. */
- use_frags = htt->target_version_major < 3 ||
- !ieee80211_is_mgmt(hdr->frame_control);
-
skb_cb->htt.txbuf = dma_pool_alloc(htt->tx_pool, GFP_ATOMIC,
&paddr);
if (!skb_cb->htt.txbuf) {
@@ -466,7 +459,12 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
if (res)
goto err_free_txbuf;
- if (likely(use_frags)) {
+ switch (skb_cb->txmode) {
+ case ATH10K_HW_TXRX_RAW:
+ case ATH10K_HW_TXRX_NATIVE_WIFI:
+ flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
+ /* pass through */
+ case ATH10K_HW_TXRX_ETHERNET:
frags = skb_cb->htt.txbuf->frags;
frags[0].paddr = __cpu_to_le32(skb_cb->paddr);
@@ -474,15 +472,17 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
frags[1].paddr = 0;
frags[1].len = 0;
- flags0 |= SM(ATH10K_HW_TXRX_NATIVE_WIFI,
-HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+ flags0 |= SM(skb_cb->txmode, HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
frags_paddr = skb_cb->htt.txbuf_paddr;
- } else {
+ break;
+ case ATH10K_HW_TXRX_MGMT:
flags0 |= SM(ATH10K_HW_TXRX_MGMT,
HTT_DATA_TX_DESC_FLAGS0_PKT_TYPE);
+ flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
frags_paddr = skb_cb->paddr;
+ break;
}
/* Normally all commands go through HTC which manages tx credits for
@@ -508,11 +508,9 @@ int ath10k_htt_tx(struct ath10k_htt *htt, struct sk_buff
*msdu)
prefetch_len);
skb_cb->htt.txbuf->htc_hdr.flags = 0;
- if (!ieee80211_has_protected(hdr->frame_control))
+ if (!skb_cb->is_protected)
flags0 |= HTT_DATA_TX_DESC_FLAGS0_NO_ENCRYPT;
- flags0 |= HTT_DATA_TX_DESC_FLAGS0_MAC_HDR_PRESENT;
-
flags1 |= SM((u16)vdev_id, HTT_DATA_TX_DESC_FLAGS1_VDEV_ID);
flags1 |= SM((u16)tid, HTT_DATA_TX_DESC_FLAGS1_EXT_TID);
if (msdu->ip_summed == CHECKSUM_PARTIAL) {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index d6d2f0f..6d126d0 100644
--- a/drivers/net/wire
[PATCH v2 3/4] mac80211: initialize rate control earlier for tdls station
Currently when TDLS station in driver goes from assoc
to authorized state it can not use rate control parameters
because rate control is not initialized yet. Some drivers
require parameters already initialized by rate control when
entering authorized state. It can be done by initializing
rate control after station transition to authorized state
but before notifying driver about that.
Signed-off-by: Marek Puzyniak
---
net/mac80211/cfg.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index dd4ff36..ae24ed3 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -983,12 +983,21 @@ static int sta_apply_auth_flags(struct ieee80211_local
*local,
}
if (mask & BIT(NL80211_STA_FLAG_AUTHORIZED)) {
- if (set & BIT(NL80211_STA_FLAG_AUTHORIZED))
+ if (set & BIT(NL80211_STA_FLAG_AUTHORIZED)) {
+ /*
+* When peer becomes authorized, init rate control as
+* well. Some drivers require rate control initialized
+* before drv_sta_state() is called.
+*/
+ if (test_sta_flag(sta, WLAN_STA_TDLS_PEER))
+ rate_control_rate_init(sta);
+
ret = sta_info_move_state(sta,
IEEE80211_STA_AUTHORIZED);
- else if (test_sta_flag(sta, WLAN_STA_AUTHORIZED))
+ } else if (test_sta_flag(sta, WLAN_STA_AUTHORIZED)) {
ret = sta_info_move_state(sta, IEEE80211_STA_ASSOC);
- else
+ } else {
ret = 0;
+ }
if (ret)
return ret;
}
@@ -1377,11 +1386,6 @@ static int ieee80211_change_station(struct wiphy *wiphy,
if (err)
goto out_err;
- /* When peer becomes authorized, init rate control as well */
- if (test_sta_flag(sta, WLAN_STA_TDLS_PEER) &&
- test_sta_flag(sta, WLAN_STA_AUTHORIZED))
- rate_control_rate_init(sta);
-
mutex_unlock(&local->sta_mtx);
if ((sdata->vif.type == NL80211_IFTYPE_AP ||
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] ath10k: make peer type configurable
Peer type was hardcoded to default value.
For future implementation it is required
to make is configurable.
Signed-off-by: Marek Puzyniak
Signed-off-by: Marek Kwaczynski
---
drivers/net/wireless/ath/ath10k/mac.c | 17 +++--
drivers/net/wireless/ath/ath10k/wmi-ops.h | 8 +---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 5 +++--
drivers/net/wireless/ath/ath10k/wmi.c | 3 ++-
drivers/net/wireless/ath/ath10k/wmi.h | 6 ++
5 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 6d126d0..7378656 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -364,7 +364,8 @@ static u8 ath10k_parse_mpdudensity(u8 mpdudensity)
}
}
-static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr)
+static int ath10k_peer_create(struct ath10k *ar, u32 vdev_id, const u8 *addr,
+ enum wmi_peer_type peer_type)
{
int ret;
@@ -373,7 +374,7 @@ static int ath10k_peer_create(struct ath10k *ar, u32
vdev_id, const u8 *addr)
if (ar->num_peers >= ar->max_num_peers)
return -ENOBUFS;
- ret = ath10k_wmi_peer_create(ar, vdev_id, addr);
+ ret = ath10k_wmi_peer_create(ar, vdev_id, addr, peer_type);
if (ret) {
ath10k_warn(ar, "failed to create wmi peer %pM on vdev %i:
%i\n",
addr, vdev_id, ret);
@@ -1187,7 +1188,8 @@ static void ath10k_control_ibss(struct ath10k_vif *arvif,
return;
}
- ret = ath10k_peer_create(arvif->ar, arvif->vdev_id, self_peer);
+ ret = ath10k_peer_create(arvif->ar, arvif->vdev_id, self_peer,
+WMI_PEER_TYPE_DEFAULT);
if (ret) {
ath10k_warn(ar, "failed to create IBSS self peer %pM for vdev
%d: %d\n",
self_peer, arvif->vdev_id, ret);
@@ -2417,7 +2419,8 @@ void ath10k_offchan_tx_work(struct work_struct *work)
peer_addr, vdev_id);
if (!peer) {
- ret = ath10k_peer_create(ar, vdev_id, peer_addr);
+ ret = ath10k_peer_create(ar, vdev_id, peer_addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret)
ath10k_warn(ar, "failed to create peer %pM on
vdev %d: %d\n",
peer_addr, vdev_id, ret);
@@ -3300,7 +3303,8 @@ static int ath10k_add_interface(struct ieee80211_hw *hw,
}
if (arvif->vdev_type == WMI_VDEV_TYPE_AP) {
- ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr);
+ ret = ath10k_peer_create(ar, arvif->vdev_id, vif->addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret) {
ath10k_warn(ar, "failed to create vdev %i peer for AP:
%d\n",
arvif->vdev_id, ret);
@@ -4023,7 +4027,8 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
goto exit;
}
- ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr);
+ ret = ath10k_peer_create(ar, arvif->vdev_id, sta->addr,
+WMI_PEER_TYPE_DEFAULT);
if (ret) {
ath10k_warn(ar, "failed to add peer %pM for vdev %d
when adding a new sta: %i\n",
sta->addr, arvif->vdev_id, ret);
diff --git a/drivers/net/wireless/ath/ath10k/wmi-ops.h
b/drivers/net/wireless/ath/ath10k/wmi-ops.h
index 04dc4b9..a2cded8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-ops.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-ops.h
@@ -81,7 +81,8 @@ struct wmi_ops {
struct sk_buff *(*gen_vdev_wmm_conf)(struct ath10k *ar, u32 vdev_id,
const struct
wmi_wmm_params_all_arg *arg);
struct sk_buff *(*gen_peer_create)(struct ath10k *ar, u32 vdev_id,
- const u8 peer_addr[ETH_ALEN]);
+ const u8 peer_addr[ETH_ALEN],
+ enum wmi_peer_type peer_type);
struct sk_buff *(*gen_peer_delete)(struct ath10k *ar, u32 vdev_id,
const u8 peer_addr[ETH_ALEN]);
struct sk_buff *(*gen_peer_flush)(struct ath10k *ar, u32 vdev_id,
@@ -625,14 +626,15 @@ ath10k_wmi_vdev_wmm_conf(struct ath10k *ar, u32 vdev_id,
static inline int
ath10k_wmi_peer_create(struct ath10k *ar, u32 vdev_id,
- const u8 peer_addr[ETH_ALEN])
+ const u8 peer_addr[ETH_ALEN],
+ enum wmi_peer_type peer_type)
{
struct sk_buff *skb;
if (!ar->wmi.ops->gen_peer_create)
re
[PATCH v2 4/4] ath10k: introduce basic tdls functionality
This patch adds functions to enable/disable tdls
and to configure tdls peer station for tlv based firmware.
Tdls peer uapsd and tdls channel switching are not supported.
Transmitting tdls data frames works only for ethernet
type frames, that's why data addressed to tdls sta
is in ethernet format.
Tdls functionality for ath10k requires changes in mac80211
provided in patch:
mac80211: initialize rate control earlier for tdls station
Signed-off-by: Michal Kazior
Signed-off-by: Marek Kwaczynski
Signed-off-by: Marek Puzyniak
---
drivers/net/wireless/ath/ath10k/core.h| 1 +
drivers/net/wireless/ath/ath10k/mac.c | 141 +--
drivers/net/wireless/ath/ath10k/wmi-ops.h | 42 +
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 152 ++
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 52 ++
drivers/net/wireless/ath/ath10k/wmi.h | 37
6 files changed, 417 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h
b/drivers/net/wireless/ath/ath10k/core.h
index 94a8788..14b99c8 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -604,6 +604,7 @@ struct ath10k {
/* protected by conf_mutex */
int num_peers;
int num_stations;
+ int tdls_peers;
int max_num_peers;
int max_num_stations;
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 7378656..21720b8 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -518,6 +518,73 @@ static void ath10k_peer_cleanup_all(struct ath10k *ar)
ar->num_stations = 0;
}
+static int ath10k_mac_enable_tdls(struct ath10k *ar, u32 vdev_id, bool enable)
+{
+ int ret = 0;
+ bool changed = false;
+ enum wmi_tdls_state state = WMI_TDLS_DISABLE;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ if (enable) {
+ state = WMI_TDLS_ENABLE_ACTIVE;
+ if (!ar->tdls_peers)
+ changed = true;
+ ar->tdls_peers++;
+ } else {
+ if (ar->tdls_peers > 0) {
+ ar->tdls_peers--;
+ if (ar->tdls_peers == 0)
+ changed = true;
+ }
+ }
+
+ if (!changed)
+ return 0;
+
+ ret = ath10k_wmi_update_fw_tdls_state(ar, vdev_id, state);
+
+ if (ret) {
+ ath10k_warn(ar, "failed to update fw tdls state on vdev %i:
%i\n",
+ vdev_id, ret);
+ return ret;
+ }
+ return 0;
+}
+
+static int ath10k_mac_tdls_peer_update(struct ath10k *ar, u32 vdev_id,
+ struct ieee80211_sta *sta,
+ enum wmi_tdls_peer_state state)
+{
+ int ret;
+ struct wmi_tdls_peer_update_cmd_arg arg;
+ struct wmi_tdls_peer_capab_arg cap = {};
+ struct wmi_channel_arg chan_arg = {};
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ arg.vdev_id = vdev_id;
+ arg.peer_state = state;
+ ether_addr_copy(arg.addr, sta->addr);
+
+ cap.peer_max_sp = sta->max_sp;
+ cap.peer_uapsd_queues = sta->uapsd_queues;
+
+ if (state == WMI_TDLS_PEER_STATE_CONNECTED) {
+ if (!sta->tdls_initiator)
+ cap.is_peer_responder = 1;
+ }
+
+ ret = ath10k_wmi_tdls_peer_update(ar, &arg, &cap, &chan_arg);
+ if (ret) {
+ ath10k_warn(ar, "failed to update tdls peer %pM on vdev %i:
%i\n",
+ arg.addr, vdev_id, ret);
+ return ret;
+ }
+
+ return 0;
+}
+
//
/* Interface management */
//
@@ -2186,7 +2253,7 @@ static u8 ath10k_tx_h_get_vdev_id(struct ath10k *ar,
struct ieee80211_vif *vif)
static enum ath10k_hw_txrx_mode
ath10k_tx_h_get_txmode(struct ath10k *ar, struct ieee80211_vif *vif,
- struct sk_buff *skb)
+ struct ieee80211_sta *sta, struct sk_buff *skb)
{
const struct ieee80211_hdr *hdr = (void *)skb->data;
__le16 fc = hdr->frame_control;
@@ -2218,6 +2285,15 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
ieee80211_vif *vif,
!test_bit(ATH10K_FW_FEATURE_HAS_WMI_MGMT_TX, ar->fw_features))
return ATH10K_HW_TXRX_MGMT;
+ /* Workaround:
+*
+* Some wmi-tlv firmwares for qca6174 have broken Tx key selection for
+* NativeWifi txmode - it selects AP key instead of peer key. It seems
+* to work with Ethernet txmode so use it.
+*/
+ if (ieee80211_is_data_present(fc) && sta && sta->tdls)
+ return ATH10K_HW_TXRX_ETHERNET;
+
return ATH10K_HW_TXRX_NATIVE_WIFI;
}
@@ -2644,6 +2720,7 @@ static void ath10k_tx(struct ieee80211_hw *hw,
struct ath10k *ar =
