* [PATCH] mwifiex: populate rates in probe request using cfg80211_scan_request
From: Bing Zhao @ 2013-07-31 0:18 UTC (permalink / raw)
To: linux-wireless
Cc: John W. Linville, Avinash Patil, Amitkumar Karwar,
Nishant Sarmukadam, Frank Huang, Bing Zhao
From: Avinash Patil <patila@marvell.com>
Whenever available, use cfg80211_scan_request to populates rates
in outgoing probe request. This will help to advertise band specific
rates and fix an issue where 11b rates were advertised in probe
request going out on 11a band.
This will also ensure that we do not advertise 11b rates while P2P
scan is going on.
Signed-off-by: Avinash Patil <patila@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
drivers/net/wireless/mwifiex/cfp.c | 42 ++++++++++++++++++++++---
drivers/net/wireless/mwifiex/main.h | 2 ++
drivers/net/wireless/mwifiex/scan.c | 63 +++++++++++++++++++++++++++----------
3 files changed, 85 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/mwifiex/cfp.c b/drivers/net/wireless/mwifiex/cfp.c
index 5178c46..9eefacb 100644
--- a/drivers/net/wireless/mwifiex/cfp.c
+++ b/drivers/net/wireless/mwifiex/cfp.c
@@ -404,11 +404,43 @@ mwifiex_is_rate_auto(struct mwifiex_private *priv)
return false;
}
-/*
- * This function gets the supported data rates.
- *
- * The function works in both Ad-Hoc and infra mode by printing the
- * band and returning the data rates.
+/* This function gets the supported data rates from bitmask inside
+ * cfg80211_scan_request.
+ */
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type)
+{
+ struct wiphy *wiphy = priv->adapter->wiphy;
+ struct cfg80211_scan_request *request = priv->scan_request;
+ u32 num_rates, rate_mask;
+ struct ieee80211_supported_band *sband;
+ int i;
+
+ if (radio_type) {
+ sband = wiphy->bands[IEEE80211_BAND_5GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_5GHZ];
+ } else {
+ sband = wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (WARN_ON_ONCE(!sband))
+ return 0;
+ rate_mask = request->rates[IEEE80211_BAND_2GHZ];
+ }
+
+ num_rates = 0;
+ for (i = 0; i < sband->n_bitrates; i++) {
+ if ((BIT(i) & rate_mask) == 0)
+ continue; /* skip rate */
+ rates[num_rates++] = (u8)(sband->bitrates[i].bitrate / 5);
+ }
+
+ return num_rates;
+}
+
+/* This function gets the supported data rates. The function works in
+ * both Ad-Hoc and infra mode by printing the band and returning the
+ * data rates.
*/
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates)
{
diff --git a/drivers/net/wireless/mwifiex/main.h b/drivers/net/wireless/mwifiex/main.h
index 48685e7..cf961d9 100644
--- a/drivers/net/wireless/mwifiex/main.h
+++ b/drivers/net/wireless/mwifiex/main.h
@@ -903,6 +903,8 @@ int mwifiex_cmd_append_vsie_tlv(struct mwifiex_private *priv, u16 vsie_mask,
u32 mwifiex_get_active_data_rates(struct mwifiex_private *priv,
u8 *rates);
u32 mwifiex_get_supported_rates(struct mwifiex_private *priv, u8 *rates);
+u32 mwifiex_get_rates_from_cfg80211(struct mwifiex_private *priv,
+ u8 *rates, u8 radio_type);
u8 mwifiex_is_rate_auto(struct mwifiex_private *priv);
extern u16 region_code_index[MWIFIEX_MAX_REGION_CODE];
void mwifiex_save_curr_bcn(struct mwifiex_private *priv);
diff --git a/drivers/net/wireless/mwifiex/scan.c b/drivers/net/wireless/mwifiex/scan.c
index c447d9b..8cf7d50 100644
--- a/drivers/net/wireless/mwifiex/scan.c
+++ b/drivers/net/wireless/mwifiex/scan.c
@@ -543,6 +543,37 @@ mwifiex_scan_create_channel_list(struct mwifiex_private *priv,
return chan_idx;
}
+/* This function appends rate TLV to scan config command. */
+static int
+mwifiex_append_rate_tlv(struct mwifiex_private *priv,
+ struct mwifiex_scan_cmd_config *scan_cfg_out,
+ u8 radio)
+{
+ struct mwifiex_ie_types_rates_param_set *rates_tlv;
+ u8 rates[MWIFIEX_SUPPORTED_RATES], *tlv_pos;
+ u32 rates_size;
+
+ memset(rates, 0, sizeof(rates));
+
+ tlv_pos = (u8 *)scan_cfg_out->tlv_buf + scan_cfg_out->tlv_buf_len;
+
+ if (priv->scan_request)
+ rates_size = mwifiex_get_rates_from_cfg80211(priv, rates,
+ radio);
+ else
+ rates_size = mwifiex_get_supported_rates(priv, rates);
+
+ dev_dbg(priv->adapter->dev, "info: SCAN_CMD: Rates size = %d\n",
+ rates_size);
+ rates_tlv = (struct mwifiex_ie_types_rates_param_set *)tlv_pos;
+ rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
+ rates_tlv->header.len = cpu_to_le16((u16) rates_size);
+ memcpy(rates_tlv->rates, rates, rates_size);
+ scan_cfg_out->tlv_buf_len += sizeof(rates_tlv->header) + rates_size;
+
+ return rates_size;
+}
+
/*
* This function constructs and sends multiple scan config commands to
* the firmware.
@@ -564,9 +595,10 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
struct mwifiex_chan_scan_param_set *tmp_chan_list;
struct mwifiex_chan_scan_param_set *start_chan;
- u32 tlv_idx;
+ u32 tlv_idx, rates_size;
u32 total_scan_time;
u32 done_early;
+ u8 radio_type;
if (!scan_cfg_out || !chan_tlv_out || !scan_chan_list) {
dev_dbg(priv->adapter->dev,
@@ -591,6 +623,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
tlv_idx = 0;
total_scan_time = 0;
+ radio_type = 0;
chan_tlv_out->header.len = 0;
start_chan = tmp_chan_list;
done_early = false;
@@ -612,6 +645,7 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
continue;
}
+ radio_type = tmp_chan_list->radio_type;
dev_dbg(priv->adapter->dev,
"info: Scan: Chan(%3d), Radio(%d),"
" Mode(%d, %d), Dur(%d)\n",
@@ -692,6 +726,9 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
break;
}
+ rates_size = mwifiex_append_rate_tlv(priv, scan_cfg_out,
+ radio_type);
+
priv->adapter->scan_channels = start_chan;
/* Send the scan command to the firmware with the specified
@@ -699,6 +736,14 @@ mwifiex_scan_channel_list(struct mwifiex_private *priv,
ret = mwifiex_send_cmd_async(priv, HostCmd_CMD_802_11_SCAN,
HostCmd_ACT_GEN_SET, 0,
scan_cfg_out);
+
+ /* rate IE is updated per scan command but same starting
+ * pointer is used each time so that rate IE from earlier
+ * scan_cfg_out->buf is overwritten with new one.
+ */
+ scan_cfg_out->tlv_buf_len -=
+ sizeof(struct mwifiex_ie_types_header) + rates_size;
+
if (ret)
break;
}
@@ -741,7 +786,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
struct mwifiex_adapter *adapter = priv->adapter;
struct mwifiex_ie_types_num_probes *num_probes_tlv;
struct mwifiex_ie_types_wildcard_ssid_params *wildcard_ssid_tlv;
- struct mwifiex_ie_types_rates_param_set *rates_tlv;
u8 *tlv_pos;
u32 num_probes;
u32 ssid_len;
@@ -753,8 +797,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
u8 radio_type;
int i;
u8 ssid_filter;
- u8 rates[MWIFIEX_SUPPORTED_RATES];
- u32 rates_size;
struct mwifiex_ie_types_htcap *ht_cap;
/* The tlv_buf_len is calculated for each scan command. The TLVs added
@@ -889,19 +931,6 @@ mwifiex_config_scan(struct mwifiex_private *priv,
}
- /* Append rates tlv */
- memset(rates, 0, sizeof(rates));
-
- rates_size = mwifiex_get_supported_rates(priv, rates);
-
- rates_tlv = (struct mwifiex_ie_types_rates_param_set *) tlv_pos;
- rates_tlv->header.type = cpu_to_le16(WLAN_EID_SUPP_RATES);
- rates_tlv->header.len = cpu_to_le16((u16) rates_size);
- memcpy(rates_tlv->rates, rates, rates_size);
- tlv_pos += sizeof(rates_tlv->header) + rates_size;
-
- dev_dbg(adapter->dev, "info: SCAN_CMD: Rates size = %d\n", rates_size);
-
if (ISSUPP_11NENABLED(priv->adapter->fw_cap_info) &&
(priv->adapter->config_bands & BAND_GN ||
priv->adapter->config_bands & BAND_AN)) {
--
1.8.2.3
^ permalink raw reply related
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 0:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings
In-Reply-To: <20130730235508.GA25319@kroah.com>
On Tue, Jul 30, 2013 at 04:55:08PM -0700, Greg Kroah-Hartman wrote:
> On Tue, Jul 30, 2013 at 03:48:09PM -0700, Luis R. Rodriguez wrote:
> > > We are planning to take one extra step and split this into a
> > > mini-driver approach similar to what has been done for usbnet, but we
> > > are not there yet.
> >
> > Neat. Perhaps we need something that we can share with 802.11 or other
> > hardare I highly doubt we're the only ones patching ROM. Don't we even
> > patch up core CPUs? I'm wondering if firmware_class could be expanded to
> > support serialized ROM patching. The biggest hurdle I see with splititng
> > ROM patching from a single firmware is serializing that, addressing
> > revision dependencies and of course kernel dependencies.
>
> What does the firmware_class need to do here that it doesn't do today?
It will depend on the requirements for ROM patches and if or not
firmware can be split up into patches rather than getting a full
firmware.fw update for any single patch update. If ROM patches
get split up then how I can imagine driver code firmware getting
to become a pain in the ass to maintain and nasty. It'd seem
better to build relationships between these and possible patch
depdendencies on ROM and let firmware_class do the management
of that.
> > > However the ROM patching drivers need to be in the kernel since
> > > otherwise they will race with the core init sequence.
> >
> > Sure and depending on the architecture -- if this is kicked off to
> > userspace helpers or not then we may need to consider dbus in
> > kernel thing to help with speed / races, dependenecies / async
> > loading, -EPROBE_DEFER, etc.
>
> How would dbus in the kernel change anything here?
> The kernel directly loads firmware from the filesystem now, no userspace
> helpers are involved, so no need for udev, libusb, etc. And as such, no
> need for any "dbus" in the kernel to do this either.
> I don't understand how it could, please explain.
Yeah nevermind :D too much coffee today made my brain fart.
> Also note, for those not knowing, we have been working on dbus in the
> kernel (google "kdbus" for the github repo), but it is all
> outward-facing (i.e. userspace using the kdbus code to interact with
> other processes with a dbus-like protocol, not for in-kernel dbus
> things, although adding it wouldn't be that hard, just really strange.
Thanks!
Luis
^ permalink raw reply
* 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Luis R. Rodriguez @ 2013-07-31 0:53 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Greear, Paul Stewart, Felix Fietkau, Jouni Malinen
Folks,
Back in 2009 Intel had put out a wifi-test tree [0] but that seems
deprecated now. The git tree at least is gone. Can someone confirm if
that's dead? We later had Google present at the 2010 San Francisco
wireless summit [1] their test infrastructure using autotest. Last I
checked that stuff was not merged back upstream to autotest. Can
someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
internal testing infrastructures that obviously are not open.
If we are to embark on a new journey towards an open testing
infrastructure what should be used? Ben, you have some stuff, and I
know you also report some interesting bugs with insane amount of
stations. Is any of it open?
AFAICT mac80211_hwism should and likely already is used for a slew of
core API changes / tests. Addressing testing using that shoud
hopefully address tons of testings and find a lot of issues. We'd then
just need vendors to replicate behaviour on top of their drivers. The
core test stuff though still needs to be available.
What do we have, anyone have any lofty plans?
[0] http://wireless.kernel.org/en/developers/Testing/wifi-test
[1] http://wireless.kernel.org/en/developers/Summits/SanFranciscoBayArea-2010
[2] http://wireless.kernel.org/en/users/Drivers/mac80211_hwsim
Luis
^ permalink raw reply
* [PATCH v2] Bluetooth: btmrvl: add calibration data download support
From: Bing Zhao @ 2013-07-31 1:05 UTC (permalink / raw)
To: linux-bluetooth
Cc: Marcel Holtmann, Gustavo Padovan, Johan Hedberg, linux-wireless,
Bing Zhao, Amitkumar Karwar
From: Amitkumar Karwar <akarwar@marvell.com>
A text file containing calibration data in hex format can
be provided at following path:
/lib/firmware/mrvl/sd8797_caldata.conf
The data will be downloaded to firmware during initialization.
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
---
v2: Remove module parameter. The calibration data will be downloaded
only when the device speicific data file is provided.
(Marcel Holtmann)
drivers/bluetooth/btmrvl_drv.h | 10 ++-
drivers/bluetooth/btmrvl_main.c | 140 +++++++++++++++++++++++++++++++++++++++-
drivers/bluetooth/btmrvl_sdio.c | 9 ++-
drivers/bluetooth/btmrvl_sdio.h | 2 +
4 files changed, 157 insertions(+), 4 deletions(-)
diff --git a/drivers/bluetooth/btmrvl_drv.h b/drivers/bluetooth/btmrvl_drv.h
index 27068d1..5ef5e84 100644
--- a/drivers/bluetooth/btmrvl_drv.h
+++ b/drivers/bluetooth/btmrvl_drv.h
@@ -23,6 +23,8 @@
#include <linux/bitops.h>
#include <linux/slab.h>
#include <net/bluetooth/bluetooth.h>
+#include <linux/ctype.h>
+#include <linux/firmware.h>
#define BTM_HEADER_LEN 4
#define BTM_UPLD_SIZE 2312
@@ -41,6 +43,8 @@ struct btmrvl_thread {
struct btmrvl_device {
void *card;
struct hci_dev *hcidev;
+ struct device *dev;
+ const char *cal_data;
u8 dev_type;
@@ -91,6 +95,7 @@ struct btmrvl_private {
#define BT_CMD_HOST_SLEEP_CONFIG 0x59
#define BT_CMD_HOST_SLEEP_ENABLE 0x5A
#define BT_CMD_MODULE_CFG_REQ 0x5B
+#define BT_CMD_LOAD_CONFIG_DATA 0x61
/* Sub-commands: Module Bringup/Shutdown Request/Response */
#define MODULE_BRINGUP_REQ 0xF1
@@ -116,10 +121,13 @@ struct btmrvl_private {
#define PS_SLEEP 0x01
#define PS_AWAKE 0x00
+#define BT_CMD_DATA_SIZE 32
+#define BT_CAL_DATA_SIZE 28
+
struct btmrvl_cmd {
__le16 ocf_ogf;
u8 length;
- u8 data[4];
+ u8 data[BT_CMD_DATA_SIZE];
} __packed;
struct btmrvl_event {
diff --git a/drivers/bluetooth/btmrvl_main.c b/drivers/bluetooth/btmrvl_main.c
index 9a9f518..9487684 100644
--- a/drivers/bluetooth/btmrvl_main.c
+++ b/drivers/bluetooth/btmrvl_main.c
@@ -57,8 +57,9 @@ bool btmrvl_check_evtpkt(struct btmrvl_private *priv, struct sk_buff *skb)
ocf = hci_opcode_ocf(opcode);
ogf = hci_opcode_ogf(opcode);
- if (ocf == BT_CMD_MODULE_CFG_REQ &&
- priv->btmrvl_dev.sendcmdflag) {
+ if ((ocf == BT_CMD_MODULE_CFG_REQ ||
+ ocf == BT_CMD_LOAD_CONFIG_DATA) &&
+ priv->btmrvl_dev.sendcmdflag) {
priv->btmrvl_dev.sendcmdflag = false;
priv->adapter->cmd_complete = true;
wake_up_interruptible(&priv->adapter->cmd_wait_q);
@@ -552,6 +553,132 @@ static int btmrvl_service_main_thread(void *data)
return 0;
}
+static int btmrvl_parse_cal_cfg(const u8 *src, u32 len, u8 *dst, u32 dst_size)
+{
+ const u8 *s = src;
+ u8 *d = dst;
+ int ret;
+ u8 tmp[3];
+
+ while ((s - src) < len) {
+ if (*s && (isspace(*s) || *s == '\t')) {
+ s++;
+ continue;
+ }
+
+ if (isxdigit(*s)) {
+ if ((d - dst) >= dst_size) {
+ BT_ERR("calibration data file too big!!!");
+ return -EINVAL;
+ }
+
+ memcpy(tmp, s, 2);
+ tmp[2] = '\0';
+
+ ret = kstrtol(tmp, 16, (long *)d++);
+ if (ret < 0)
+ return ret;
+
+ s += 2;
+ } else {
+ s++;
+ }
+ }
+ if (d == dst)
+ return -EINVAL;
+
+ return 0;
+}
+
+static int btmrvl_load_cal_data(struct btmrvl_private *priv,
+ u8 *config_data)
+{
+ struct sk_buff *skb;
+ struct btmrvl_cmd *cmd;
+ int i;
+
+ skb = bt_skb_alloc(sizeof(*cmd), GFP_ATOMIC);
+ if (!skb)
+ return -ENOMEM;
+
+ cmd = (struct btmrvl_cmd *)skb->data;
+ cmd->ocf_ogf =
+ cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA));
+ cmd->length = BT_CMD_DATA_SIZE;
+ cmd->data[0] = 0x00;
+ cmd->data[1] = 0x00;
+ cmd->data[2] = 0x00;
+ cmd->data[3] = BT_CMD_DATA_SIZE - 4;
+
+ /* swap cal-data bytes */
+ for (i = 4; i < BT_CMD_DATA_SIZE; i++)
+ cmd->data[i] = config_data[(i/4)*8 - 1 - i];
+
+ bt_cb(skb)->pkt_type = MRVL_VENDOR_PKT;
+ skb_put(skb, sizeof(*cmd));
+ skb->dev = (void *)priv->btmrvl_dev.hcidev;
+ skb_queue_head(&priv->adapter->tx_queue, skb);
+ priv->btmrvl_dev.sendcmdflag = true;
+ priv->adapter->cmd_complete = false;
+
+ print_hex_dump_bytes("Calibration data: ",
+ DUMP_PREFIX_OFFSET, cmd->data, BT_CMD_DATA_SIZE);
+
+ wake_up_interruptible(&priv->main_thread.wait_q);
+ if (!wait_event_interruptible_timeout(priv->adapter->cmd_wait_q,
+ priv->adapter->cmd_complete,
+ msecs_to_jiffies(WAIT_UNTIL_CMD_RESP))) {
+ BT_ERR("Timeout while loading calibration data");
+ return -ETIMEDOUT;
+ }
+
+ return 0;
+}
+
+static int
+btmrvl_process_cal_cfg(struct btmrvl_private *priv, u8 *data, u32 size)
+{
+ u8 cal_data[BT_CAL_DATA_SIZE];
+ int ret;
+
+ ret = btmrvl_parse_cal_cfg(data, size, cal_data, sizeof(cal_data));
+ if (ret)
+ return ret;
+
+ ret = btmrvl_load_cal_data(priv, cal_data);
+ if (ret) {
+ BT_ERR("Fail to load calibrate data");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int btmrvl_cal_data_config(struct btmrvl_private *priv)
+{
+ const struct firmware *cfg;
+ int ret;
+ const char *cal_data = priv->btmrvl_dev.cal_data;
+
+ if (!cal_data)
+ return 0;
+
+ ret = request_firmware(&cfg, cal_data, priv->btmrvl_dev.dev);
+ if (ret < 0) {
+ BT_DBG("Failed to get %s file, skipping cal data download",
+ cal_data);
+ ret = 0;
+ goto done;
+ }
+
+ ret = btmrvl_process_cal_cfg(priv, (u8 *)cfg->data, cfg->size);
+done:
+ if (cfg)
+ release_firmware(cfg);
+
+ return ret;
+}
+
int btmrvl_register_hdev(struct btmrvl_private *priv)
{
struct hci_dev *hdev = NULL;
@@ -583,12 +710,21 @@ int btmrvl_register_hdev(struct btmrvl_private *priv)
goto err_hci_register_dev;
}
+ ret = btmrvl_cal_data_config(priv);
+ if (ret) {
+ BT_ERR("Set cal data failed");
+ goto err_cal_data_config;
+ }
+
#ifdef CONFIG_DEBUG_FS
btmrvl_debugfs_init(hdev);
#endif
return 0;
+err_cal_data_config:
+ hci_unregister_dev(hdev);
+
err_hci_register_dev:
hci_free_dev(hdev);
diff --git a/drivers/bluetooth/btmrvl_sdio.c b/drivers/bluetooth/btmrvl_sdio.c
index 75c2626..292fd92 100644
--- a/drivers/bluetooth/btmrvl_sdio.c
+++ b/drivers/bluetooth/btmrvl_sdio.c
@@ -18,7 +18,6 @@
* this warranty disclaimer.
**/
-#include <linux/firmware.h>
#include <linux/slab.h>
#include <linux/mmc/sdio_ids.h>
@@ -102,6 +101,7 @@ static const struct btmrvl_sdio_card_reg btmrvl_reg_88xx = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
.helper = "mrvl/sd8688_helper.bin",
.firmware = "mrvl/sd8688.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_8688,
.sd_blksz_fw_dl = 64,
};
@@ -109,6 +109,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8688 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
.helper = NULL,
.firmware = "mrvl/sd8787_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -116,6 +117,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8787 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
.helper = NULL,
.firmware = "mrvl/sd8797_uapsta.bin",
+ .cal_data = "mrvl/sd8797_caldata.conf",
.reg = &btmrvl_reg_87xx,
.sd_blksz_fw_dl = 256,
};
@@ -123,6 +125,7 @@ static const struct btmrvl_sdio_device btmrvl_sdio_sd8797 = {
static const struct btmrvl_sdio_device btmrvl_sdio_sd8897 = {
.helper = NULL,
.firmware = "mrvl/sd8897_uapsta.bin",
+ .cal_data = NULL,
.reg = &btmrvl_reg_88xx,
.sd_blksz_fw_dl = 256,
};
@@ -1006,6 +1009,7 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
struct btmrvl_sdio_device *data = (void *) id->driver_data;
card->helper = data->helper;
card->firmware = data->firmware;
+ card->cal_data = data->cal_data;
card->reg = data->reg;
card->sd_blksz_fw_dl = data->sd_blksz_fw_dl;
}
@@ -1034,6 +1038,8 @@ static int btmrvl_sdio_probe(struct sdio_func *func,
}
card->priv = priv;
+ priv->btmrvl_dev.dev = &card->func->dev;
+ priv->btmrvl_dev.cal_data = card->cal_data;
/* Initialize the interface specific function pointers */
priv->hw_host_to_card = btmrvl_sdio_host_to_card;
@@ -1222,4 +1228,5 @@ MODULE_FIRMWARE("mrvl/sd8688_helper.bin");
MODULE_FIRMWARE("mrvl/sd8688.bin");
MODULE_FIRMWARE("mrvl/sd8787_uapsta.bin");
MODULE_FIRMWARE("mrvl/sd8797_uapsta.bin");
+MODULE_FIRMWARE("mrvl/sd8797_caldata.conf");
MODULE_FIRMWARE("mrvl/sd8897_uapsta.bin");
diff --git a/drivers/bluetooth/btmrvl_sdio.h b/drivers/bluetooth/btmrvl_sdio.h
index 43d35a6..6872d9e 100644
--- a/drivers/bluetooth/btmrvl_sdio.h
+++ b/drivers/bluetooth/btmrvl_sdio.h
@@ -85,6 +85,7 @@ struct btmrvl_sdio_card {
u32 ioport;
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
u8 rx_unit;
@@ -94,6 +95,7 @@ struct btmrvl_sdio_card {
struct btmrvl_sdio_device {
const char *helper;
const char *firmware;
+ const char *cal_data;
const struct btmrvl_sdio_card_reg *reg;
u16 sd_blksz_fw_dl;
};
--
1.8.0
^ permalink raw reply related
* Re: [PATCH] MAINTAINERS: change email of TI WiLink drivers' maintainer
From: Luciano Coelho @ 2013-07-31 5:22 UTC (permalink / raw)
To: linville; +Cc: balbi, linux-wireless, luca
In-Reply-To: <1375206341-26211-1-git-send-email-coelho@ti.com>
Hi John,
Could you queue this for 3.11?
I don't currently have anything else for 3.11, so it would just be an
overhead to send you a pull request for this tiny change. ;)
--
Cheers,
Luca.
On Tue, 2013-07-30 at 20:45 +0300, Luciano Coelho wrote:
> Soon the coelho@ti.com email will not be valid anymore, so change it
> to my private one.
>
> Cc: Luciano Coelho <luca@coelho.fi>
> Signed-off-by: Luciano Coelho <coelho@ti.com>
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index c6dc128..77be3f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8278,7 +8278,7 @@ S: Maintained
> F: sound/soc/codecs/twl4030*
>
> TI WILINK WIRELESS DRIVERS
> -M: Luciano Coelho <coelho@ti.com>
> +M: Luciano Coelho <luca@coelho.fi>
> L: linux-wireless@vger.kernel.org
> W: http://wireless.kernel.org/en/users/Drivers/wl12xx
> W: http://wireless.kernel.org/en/users/Drivers/wl1251
^ permalink raw reply
* Re: [PATCH] ath10k: move irq setup
From: Michal Kazior @ 2013-07-31 5:50 UTC (permalink / raw)
To: Kalle Valo; +Cc: ath10k, linux-wireless
In-Reply-To: <87d2pzuc90.fsf@kamboji.qca.qualcomm.com>
On 30 July 2013 20:35, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> There was a slight race during PCI shutdown. Since
>> interrupts weren't really stopped (only Copy
>> Engine interrupts were disabled through device hw
>> registers) it was possible for a firmware
>> indication (crash) interrupt to come in after
>> tasklets were synced/killed. This would cause
>> memory corruption and a panic in most cases. It
>> was also possible for interrupt to come before CE
>> was initialized during device probing.
>>
>> Interrupts are required for BMI phase so they are enabled as soon as
>> power_up() is called but are freed upon both power_down() and stop()
>> so there's asymmetry here. As by design stop() cannot be followed by
>> start() it is okay. Both power_down() and stop() should be merged
>> later on to avoid confusion.
>
> Why are the interrupts freed both in power_down() and stop()? I don't
> get that.
>
> What if we call disable_irq() in power_down() instead?
power_down() must call free_irq(), because power_up() calls
request_irq() (if you want the symmetry). If anything, the stop()
should call disable_irq(), but wouldn't that mean start() should call
enable_irq()? But than, irqs are needed before start()..
I did think about disable_irq() but AFAIR you need to enable_irq()
later on (so either way you need to keep track of the irq state or
you'll get a ton of WARN_ONs from the system). I'll double check that
and report back later
>> Before this can be really properly fixed var/hw
>> init code split is necessary.
>>
>> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
>> ---
>>
>> Please note: this is based on my (still under
>> review at the time of posting) previous patchests:
>> device setup refactor and recovery.
>>
>> I'm posting this before those patchsets are merged
>> so anyone interested in testing this fix (I can't
>> reproduce the problem on my setup) can give it a
>> try.
>
> This was reported by Ben, right? So this sould have a Reported-by line
> attributing him.
Yes. I'll fix that, provided we get through the review with the patch :)
>> @@ -1783,16 +1792,24 @@ static int ath10k_pci_hif_power_up(struct ath10k *ar)
>> return 0;
>>
>> err_ce:
>> + /* XXX: Until var/hw init is split it's impossible to fix the ordering
>> + * here so we must call stop_intr() here too to prevent interrupts after
>> + * CE is teared down. It's okay to double call the stop_intr()
>> */
>
> "FIXME:"
Ok.
>> exit:
>> + ar_pci->intr_started = ret == 0;
>
> A bit too clever for the sake of readibility for my taste, but I guess
> it's ok.
>
>> --- a/drivers/net/wireless/ath/ath10k/pci.h
>> +++ b/drivers/net/wireless/ath/ath10k/pci.h
>> @@ -198,6 +198,7 @@ struct ath10k_pci {
>> * interrupts.
>> */
>> int num_msi_intrs;
>> + bool intr_started;
>
> Adding a new state variable makes me worried. I really would prefer a
> solution which would not require that.
I know that. That's why I mentioned in the commit log that it is more
of a workaround than a real fix. Me, I don't like this either but a
real fix requires a lot of rework from what I can tell.
This bug can be triggered more easily now apparently after recovery
patches went in. I'm not experiencing it but I get reports of rare
panics when a machine is left idle for a very long time with
interfaces brought down.
> Also if we call request_irq() in ath10k_pci_probe() we should also call
> free_irq() in ath10k_pci_remove() for symmetry. Just doing a temporary
> hack will most likely stay forever :)
With the patch interrupts are temporarily enabled&disabled for
probe_fw() during pci_probe() and are then not requested until
mac80211 start().
Pozdrawiam / Best regards,
Michał Kazior.
^ permalink raw reply
* Re: [PATCH] ath10k: improve tx throughput on slow machines
From: Kalle Valo @ 2013-07-31 6:06 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374495928-29514-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> It is more efficient to move just the 802.11
> header instead of the whole payload in most cases.
>
> This has no measurable effect on modern hardware.
> It should improve performance by a few percent on
> hardware such as an Access Point that have a slow
> CPU compared to a typical desktop CPU.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Applied, thanks.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] ath10k: detect the number of spatial streams supported by hw
From: Kalle Valo @ 2013-07-31 6:06 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1374662206-19198-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> Until now ath10k assumed 3 spatial streams.
> However some devices support only 2 spatial
> streams.
>
> This patch improves performance on devices that
> don't support 3 spatial streams.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Thanks, applied.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2] ath10k: implement get_survey()
From: Kalle Valo @ 2013-07-31 6:24 UTC (permalink / raw)
To: Michal Kazior; +Cc: ath10k, linux-wireless
In-Reply-To: <1375081712-9697-1-git-send-email-michal.kazior@tieto.com>
Michal Kazior <michal.kazior@tieto.com> writes:
> This implements a limited subset of what can be
> reported in the survey dump.
>
> This can be used for assessing approximate channel
> load, e.g. for automatic channel selection.
>
> Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
[...]
> @@ -374,6 +375,11 @@ struct ath10k {
>
> struct work_struct restart_work;
>
> + /* cycle count is reported twice for each visited channel during scan */
> + u32 survey_last_rx_clear_count;
> + u32 survey_last_cycle_count;
> + struct survey_info survey[ATH10K_NUM_CHANS];
Please document the locking. Apparently survey is protected with
data_lock?
[...]
> static void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb)
> {
> - ath10k_dbg(ATH10K_DBG_WMI, "WMI_CHAN_INFO_EVENTID\n");
> + struct wmi_chan_info_event *ev;
> + int idx;
> +
> + spin_lock_bh(&ar->data_lock);
> +
> + ev = (struct wmi_chan_info_event *)skb->data;
> + ath10k_dbg(ATH10K_DBG_WMI,
> + "chan info: err_code:%d freq:%d cmd_flags:%d noise_floor:%d rx_clear_count:%d cycle_count:%d\n",
> + __le32_to_cpu(ev->err_code),
> + __le32_to_cpu(ev->freq),
> + __le32_to_cpu(ev->cmd_flags),
> + __le32_to_cpu(ev->noise_floor),
> + __le32_to_cpu(ev->rx_clear_count),
> + __le32_to_cpu(ev->cycle_count));
"wmi event chan info err_code %d freq %d cmd_flags %d noise_floor %d rx_clear_count %d cycle_count %d\n"
> + if (!ar->scan.in_progress) {
> + ath10k_warn("chan info event without a scan request?\n");
> + goto exit;
> + }
> +
> + if (__le32_to_cpu(ev->cmd_flags) & WMI_CHAN_INFO_FLAG_COMPLETE) {
> + idx = freq_to_idx(ar, __le32_to_cpu(ev->freq));
> + if (idx >= ARRAY_SIZE(ar->survey)) {
> + ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
> + __le32_to_cpu(ev->freq), idx);
I think we should just bail out if this happens.
> + } else {
> + /* During scanning chan info is reported twice for each
> + * visited channel. The reported cycle count is global
> + * and per-channel cycle count must be calculated */
> +
> + ar->survey[idx].channel_time = WMI_CHAN_INFO_MSEC(
> + __le32_to_cpu(ev->cycle_count) -
> + ar->survey_last_cycle_count);
> + ar->survey[idx].channel_time_rx = WMI_CHAN_INFO_MSEC(
> + __le32_to_cpu(ev->rx_clear_count) -
> + ar->survey_last_rx_clear_count);
> + ar->survey[idx].noise = __le32_to_cpu(ev->noise_floor);
> + ar->survey[idx].filled = SURVEY_INFO_CHANNEL_TIME |
> + SURVEY_INFO_CHANNEL_TIME_RX |
> + SURVEY_INFO_NOISE_DBM;
> + }
...and then there's no reason to use else branch here. Also you can add
temporary variables time and time_rx to make clean up the indentation.
> + }
> +
> + ar->survey_last_rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
> + ar->survey_last_cycle_count = __le32_to_cpu(ev->cycle_count);
> +
> +exit:
> + spin_unlock_bh(&ar->data_lock);
> }
>
> static void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index da3b2bc..4acff47 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -2931,6 +2931,9 @@ struct wmi_chan_info_event {
> __le32 cycle_count;
> } __packed;
>
> +#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
> +#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595) /* XXX: empirically extrapolated */
Use "FIXME:" and comment on a separate line:
/* FIXME: empirically extrapolated */
#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595)
--
Kalle Valo
^ permalink raw reply
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Johannes Berg @ 2013-07-31 6:44 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau,
Jouni Malinen
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On Tue, 2013-07-30 at 17:53 -0700, Luis R. Rodriguez wrote:
> Folks,
>
> Back in 2009 Intel had put out a wifi-test tree [0] but that seems
> deprecated now. The git tree at least is gone. Can someone confirm if
> that's dead?
It is indeed dead.
> We later had Google present at the 2010 San Francisco
> wireless summit [1] their test infrastructure using autotest. Last I
> checked that stuff was not merged back upstream to autotest.
I don't think that's upstream, but it's certainly available as open
source from chromium.
> Can
> someone confirm ? Lastly we have mac80211_hwsim [2] and also a slew of
> internal testing infrastructures that obviously are not open.
hwsim is really orthogonal here - it's a test driver to allow testing in
e.g. virtual machine environments as opposed to a real
testbed/screenroom, but it obviously doesn't provide any test
infrastructure.
johannes
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Johannes Berg @ 2013-07-31 6:46 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, mcgrof, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <20130730224809.GN17130@pogo>
On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
> Neat. Perhaps we need something that we can share with 802.11 or other
> hardare I highly doubt we're the only ones patching ROM. Don't we even
> patch up core CPUs? I'm wondering if firmware_class could be expanded to
> support serialized ROM patching. The biggest hurdle I see with splititng
> ROM patching from a single firmware is serializing that, addressing
> revision dependencies and of course kernel dependencies.
I don't really see what you're trying to get it so I arbitrarily picked
this ...
I think "ROM patching" like in BT and 802.11 are two completely
different things. In BT at least you have a common transport to the
device, a more-or-less common command set (HCI) etc. None of that exists
for wireless (today) so trying to find common ground between firmware
(patches) for different 802.11 hardware seems completely futile?
johannes
^ permalink raw reply
* Re: [PATCH 15/30] iwlwifi: mvm: reprobe device on firmware error during restart
From: Johannes Berg @ 2013-07-31 6:47 UTC (permalink / raw)
To: Eliad Peller; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <CAB3XZEcZX8u5Fcsf7mbbso9O0krhLVgzdT9Ay8dxsv_T+_SOhQ@mail.gmail.com>
On Wed, 2013-07-31 at 00:56 +0300, Eliad Peller wrote:
> > + reprobe = kzalloc(sizeof(*reprobe), GFP_ATOMIC);
> > + if (!reprobe)
> > + return;
>
> missing module_put() :)
Doh, good catch. All the more reason to respin this pull request.
johannes
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-07-26
From: Johannes Berg @ 2013-07-31 6:48 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <1374827327-3464-1-git-send-email-johannes@sipsolutions.net>
On Fri, 2013-07-26 at 10:28 +0200, Johannes Berg wrote:
> John,
>
> First -next pull request for iwlwifi.
I'll respin this, Eliad noticed one bug and we also found one.
johannes
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2013-07-26
From: Sedat Dilek @ 2013-07-31 6:50 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1375253292.8289.6.camel@jlt4.sipsolutions.net>
On Wed, Jul 31, 2013 at 8:48 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2013-07-26 at 10:28 +0200, Johannes Berg wrote:
>> John,
>>
>> First -next pull request for iwlwifi.
>
> I'll respin this, Eliad noticed one bug and we also found one.
>
BTW, johill which kill-bug-spray do you prefer?
It seems to be very effective... if it kills also real (alive) bugs
it's double-good.
- Sedat -
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: FUSB200 xhci issue
From: Oleksij Rempel @ 2013-07-31 6:52 UTC (permalink / raw)
To: Christian Lamparter
Cc: Sarah Sharp, Seth Forshee, ath9k_htc_fw, USB list, linux-wireless
In-Reply-To: <6066029.JHY9cn8Gkh@blech>
Am 28.07.2013 22:41, schrieb Christian Lamparter:
> On Sunday, July 28, 2013 04:28:25 PM Oleksij Rempel wrote:
>> Am 28.07.2013 14:12, schrieb Oleksij Rempel:
>>> Am 28.07.2013 13:38, schrieb Christian Lamparter:
>>>
>>>>>>
>>>>>> Anyway, I tried the -next branch.
>>>>>>
>>>>>> commit dbbb809d592dde0b3c9ecb97b3b387ff8e40e799
>>>>>> Author: Oleksij Rempel <linux@rempel-privat.de>
>>>>>> Date: Wed Jul 24 10:26:18 2013 +0200
>>>>>>
>>>>>> k2_fw_usb_api: workaround for EP4 bug.
>>>>>>
>>>>>> but still, the device won't show up after autosuspend.
>>>>>
>>>>> Hm... firmware probably didn't rebooted before suspend. Did interface
>>>>> was up, before autosuspend? If no, you need latest wireles-testing -
>>>>> there are patches to handle this issue. Or just make "ifconfig wlan1 up"
>>>>> before rmmod.
>>>> Oh, I it was on the latest wireless-testing. (And the "ath9k_htc" module
>>>> had the patch "ath9k_htc: reboot firmwware if it was loaded").
>>>>
>>>> Furthermore, I did the same test with one of the ehci-only ports
>>>> and it worked. Both, devices (one had a AR7015, the other a AR9271)
>>>> came back after autosuspend there.
>>>
>>> Grrr... so it brings us back to xhci issue. Even EP4 workaround wont
>>> work here :( Suddenly i have no more ideas.
>>>
>>> Sarah, it's your turn now.
>>
>> Christian,
>> can you please provide some more info about your xhci controller. I'll
>> try to get me same.
>
> Well, it's a laptop (HP DV6-6003EG). I recon that getting 100% the
> same setup will be difficult. However, since the uPD720200 was/is
> very popular, it should be very easy to find one. [It's probably
> on all of these "10 euro usb-3.0 pcie-adapters". So as long as you
> got a free 1x-pcie port you should be good.]
>
> Here's the lspci summary:
>
> 19:00.0 USB controller [0c03]: NEC Corporation uPD720200 USB 3.0 Host Controller [1033:0194] (rev 04) (prog-if 30 [XHCI])
> Subsystem: Hewlett-Packard Company Device [103c:1657]
> Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
> Latency: 0, Cache Line Size: 64 bytes
> Interrupt: pin A routed to IRQ 19
> Region 0: Memory at d3400000 (64-bit, non-prefetchable) [size=8K]
> Capabilities: <access denied>
> Kernel driver in use: xhci_hcd
>
Thx... i purchased on random on ebay, will see what i get.
I know now why carl9170 don't triggering this bug. Carl uses EP4 as
Interrupt with packet size 64. ath9k-htc initially have EP4=Intr,
Interval=1, but will reconfigure it to Bulk, Interval=0.
It mean, before usb suspend EP4=Bulk, Interval=0 and after resume
EP4=Intr, Inter=?. May be xhci can't handle some thing like this? Or may
be interval stay 0, and xhci will overfill usb buffer on adapter - at
least it looks so.
--
Regards,
Oleksij
^ permalink raw reply
* AP changed bandwidth, new config is ... changed bandwidth in a way we can't support - disconnect - why? (intel advanced-n 6250)
From: Arkadiusz Miskiewicz @ 2013-07-31 6:55 UTC (permalink / raw)
To: linux-wireless; +Cc: ilw
Hi.
What could be going on with WRT160NL access point, stock firmware that
my linux (3.10.4) with Intel Corporation Centrino Advanced-N + WiMAX 6250 [Kilmer Peak] (rev 2c)
cannot even connect? The same happened with my earlier Intel 5350 wifi card.
It basically reports:
[79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
(note I have two wrt160nl here and problem happens with both)
Any hints on why "we can't support" configuration issued by this (common) AP?
[79474.704167] eth1: authenticate with 68:7f:74:06:b3:1b
[79474.708354] eth1: send auth to 68:7f:74:06:b3:1b (try 1/3)
[79474.710051] eth1: authenticated
[79474.712304] eth1: associate with 68:7f:74:06:b3:1b (try 1/3)
[79474.735808] eth1: RX AssocResp from 68:7f:74:06:b3:1b (capab=0x431 status=0 aid=1)
[79474.739952] eth1: associated
[79474.834786] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79474.834791] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
[79474.877910] cfg80211: Calling CRDA to update world regulatory domain
[79474.880204] cfg80211: World regulatory domain updated:
[79474.880208] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79474.880210] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880213] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880215] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[79474.880217] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880219] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79474.880581] cfg80211: Calling CRDA for country: PL
[79474.884514] cfg80211: Regulatory domain changed to country: PL
[79474.884517] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79474.884520] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884522] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884524] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79474.884526] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[79474.884528] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[79477.468073] eth1: authenticate with 68:7f:74:06:b3:1b
[79477.472240] eth1: send auth to 68:7f:74:06:b3:1b (try 1/3)
[79477.473923] eth1: authenticated
[79477.476176] eth1: associate with 68:7f:74:06:b3:1b (try 1/3)
[79477.480118] eth1: RX AssocResp from 68:7f:74:06:b3:1b (capab=0x431 status=0 aid=1)
[79477.484355] eth1: associated
[79477.496067] eth1: AP 68:7f:74:06:b3:1b changed bandwidth, new config is 2422 MHz, width 1 (2422/0 MHz)
[79477.496072] eth1: AP 68:7f:74:06:b3:1b changed bandwidth in a way we can't support - disconnect
[79477.506470] eth1: deauthenticating from 68:7f:74:06:b3:1b by local choice (reason=1)
[79477.506598] cfg80211: Calling CRDA to update world regulatory domain
[79477.512546] cfg80211: World regulatory domain updated:
[79477.512550] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79477.512553] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512556] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512558] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
[79477.512560] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512562] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
[79477.512884] cfg80211: Calling CRDA for country: PL
[79477.516800] cfg80211: Regulatory domain changed to country: PL
[79477.516803] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
[79477.516806] cfg80211: (2402000 KHz - 2482000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516808] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516810] cfg80211: (5250000 KHz - 5330000 KHz @ 40000 KHz), (N/A, 2000 mBm)
[79477.516812] cfg80211: (5490000 KHz - 5710000 KHz @ 40000 KHz), (N/A, 2700 mBm)
[79477.516814] cfg80211: (57240000 KHz - 65880000 KHz @ 2160000 KHz), (N/A, 4000 mBm)
[79480.234322] eth1: authenticate with 68:7f:74:06:b6:75
[79480.234333] eth1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[79480.238466] eth1: send auth to 68:7f:74:06:b6:75 (try 1/3)
[79480.304305] eth1: send auth to 68:7f:74:06:b6:75 (try 2/3)
[79480.325316] eth1: send auth to 68:7f:74:06:b6:75 (try 3/3)
[79480.352770] eth1: authentication with 68:7f:74:06:b6:75 timed out
[79483.409516] eth1: authenticate with 68:7f:74:06:b6:75
[79483.409527] eth1: capabilities/regulatory prevented using AP HT/VHT configuration, downgraded
[79483.411562] eth1: direct probe to 68:7f:74:06:b6:75 (try 1/3)
[79483.612029] eth1: direct probe to 68:7f:74:06:b6:75 (try 2/3)
[79483.816045] eth1: direct probe to 68:7f:74:06:b6:75 (try 3/3)
[79484.020039] eth1: authentication with 68:7f:74:06:b6:75 timed out
--
Arkadiusz Miśkiewicz, arekm / maven.pl
^ permalink raw reply
* [PATCH 1/2] rtlwifi: rtl8192cu: fix function declaration header
From: Mark Schulte @ 2013-07-31 7:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry.Finger, Mark Schulte
Move rtl92cu_update_hal_rate_tbl declartion to hw.h to correspond with function
definition in hw.c
Signed-off-by: Mark Schulte <schultetwin@gmail.com>
---
drivers/net/wireless/rtlwifi/rtl8192cu/hw.h | 3 +++
drivers/net/wireless/rtlwifi/rtl8192cu/sw.h | 3 ---
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
index 8e3ec1e..0f7812e 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/hw.h
@@ -109,5 +109,8 @@ void rtl92c_set_fw_joinbss_report_cmd(struct ieee80211_hw *hw, u8 mstatus);
void rtl92c_fill_h2c_cmd(struct ieee80211_hw *hw,
u8 element_id, u32 cmd_len, u8 *p_cmdbuffer);
bool rtl92cu_phy_mac_config(struct ieee80211_hw *hw);
+void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
+ struct ieee80211_sta *sta,
+ u8 rssi_level);
#endif
diff --git a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
index 262e1e4..a1310ab 100644
--- a/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
+++ b/drivers/net/wireless/rtlwifi/rtl8192cu/sw.h
@@ -49,8 +49,5 @@ bool rtl92cu_phy_set_rf_power_state(struct ieee80211_hw *hw,
u32 rtl92cu_phy_query_rf_reg(struct ieee80211_hw *hw,
enum radio_path rfpath, u32 regaddr, u32 bitmask);
void rtl92cu_phy_set_bw_mode_callback(struct ieee80211_hw *hw);
-void rtl92cu_update_hal_rate_tbl(struct ieee80211_hw *hw,
- struct ieee80211_sta *sta,
- u8 rssi_level);
#endif
--
1.8.3.3
^ permalink raw reply related
* [PATCH 2/2] rtlwifi: sparse warnings: cast to restricted type
From: Mark Schulte @ 2013-07-31 7:08 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Larry.Finger, Mark Schulte
In-Reply-To: <1375254507-26154-1-git-send-email-schultetwin@gmail.com>
Adding type casts to suppress sparse warnings:
* warning: cast to restricted __le32/__le16
Signed-off-by: Mark Schulte <schultetwin@gmail.com>
---
drivers/net/wireless/rtlwifi/ps.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/rtlwifi/ps.c b/drivers/net/wireless/rtlwifi/ps.c
index 298b615..f646b75 100644
--- a/drivers/net/wireless/rtlwifi/ps.c
+++ b/drivers/net/wireless/rtlwifi/ps.c
@@ -688,7 +688,7 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void *data,
find_p2p_ie = true;
/*to find noa ie*/
while (ie + 1 < end) {
- noa_len = READEF2BYTE(&ie[1]);
+ noa_len = READEF2BYTE((__le16 *)&ie[1]);
if (ie + 3 + ie[1] > end)
return;
@@ -717,13 +717,13 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void *data,
READEF1BYTE(ie+index);
index += 1;
p2pinfo->noa_duration[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_interval[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_start_time[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
}
@@ -780,7 +780,7 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw, void *data,
RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD, "action frame find P2P IE.\n");
/*to find noa ie*/
while (ie + 1 < end) {
- noa_len = READEF2BYTE(&ie[1]);
+ noa_len = READEF2BYTE((__le16 *)&ie[1]);
if (ie + 3 + ie[1] > end)
return;
@@ -809,13 +809,13 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw, void *data,
READEF1BYTE(ie+index);
index += 1;
p2pinfo->noa_duration[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_interval[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
p2pinfo->noa_start_time[i] =
- READEF4BYTE(ie+index);
+ READEF4BYTE((__le32 *)ie+index);
index += 4;
}
--
1.8.3.3
^ permalink raw reply related
* Re: 802.11 infrastructure for regression testing - upstream / mac80211 / cfg80211
From: Jouni Malinen @ 2013-07-31 7:25 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Ben Greear, Paul Stewart, Felix Fietkau
In-Reply-To: <CAB=NE6Vm18RcDYQn+QoEzSG202HezT0rqV_hwb_UOzyecstu5w@mail.gmail.com>
On Tue, Jul 30, 2013 at 05:53:31PM -0700, Luis R. Rodriguez wrote:
> AFAICT mac80211_hwism should and likely already is used for a slew of
> core API changes / tests. Addressing testing using that shoud
> hopefully address tons of testings and find a lot of issues. We'd then
> just need vendors to replicate behaviour on top of their drivers. The
> core test stuff though still needs to be available.
I have automated tests running mainly from wpa_supplicant/hostapd
regression testing view point on top of mac80211_hwsim. The test cases
are in hostap.git:
http://w1.fi/gitweb/gitweb.cgi?p=hostap.git;a=tree;f=tests/hwsim;hb=HEAD
These tests are run automatically on all hostap.git commits in a simple
Buildbot setup: http://buildbot.w1.fi:8010/
There's currently 51 test cases covering relatively large set of basic
functionality (and various corner cases, too). I'm hoping to extend this
to cover all common use cases and lot of protocol conformance testing
for that matter. In addition, I use this for development time testing,
so new tests show up at the same time with new functionality.
These tests are currently run on top of a single cfg80211/mac80211
version that I'm updating manually every now and then. I have found
regressions on those components, too, and not just
wpa_supplicant/hostapd, so it would sound useful to get this running
automatically on cfg80211/mac80211 snapshots, too, to get faster reports
on regressions. My buildbot.w1.fi server is a very low-end virtual
server, so it won't be able to do this, but if someone has a bit more
beefier server available, it would be straightforward to extend this
type of Buildbot setup to trigger both on hostap.git and
wireless-testing.git commits to run the tests. The server would need to
be able to run kvm and build kernel.
Obviously mac80211_hwsim tests won't cover everything, but so far, I've
been quite happy with the coverage it can give for testing
wpa_supplicant, hostapd, cfg80211, and mac80211.
--
Jouni Malinen PGP id EFC895FA
^ permalink raw reply
* Re: ROM Patching (was: [PATCH] bluetooth: remove wrong dependency for BT_ATH3K)
From: Luis R. Rodriguez @ 2013-07-31 7:48 UTC (permalink / raw)
To: Johannes Berg
Cc: Marcel Holtmann, Hector Palacios, linux-wireless,
linux-bluetooth@vger.kernel.org, gustavo@padovan.org,
johan.hedberg@gmail.com, linux-kernel@vger.kernel.org,
surajs@qca.qualcomm.com, jjohnson, Adrian Chadd, ddahlby,
Ben Hutchings, Greg Kroah-Hartman
In-Reply-To: <1375253182.8289.3.camel@jlt4.sipsolutions.net>
On Tue, Jul 30, 2013 at 11:46 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Tue, 2013-07-30 at 15:48 -0700, Luis R. Rodriguez wrote:
>
>> Neat. Perhaps we need something that we can share with 802.11 or other
>> hardare I highly doubt we're the only ones patching ROM. Don't we even
>> patch up core CPUs? I'm wondering if firmware_class could be expanded to
>> support serialized ROM patching. The biggest hurdle I see with splititng
>> ROM patching from a single firmware is serializing that, addressing
>> revision dependencies and of course kernel dependencies.
>
> I don't really see what you're trying to get it so I arbitrarily picked
> this ...
>
> I think "ROM patching" like in BT and 802.11 are two completely
> different things. In BT at least you have a common transport to the
> device, a more-or-less common command set (HCI) etc.
Sure.
> None of that exists
> for wireless (today) so trying to find common ground between firmware
> (patches) for different 802.11 hardware seems completely futile?
So long as we can gaurantee mobile drivers get fw updated as much as
is really needed in the industry great.
Luis
^ permalink raw reply
* Re: [PATCH 3.11] nl80211: fix another nl80211_fam.attrbuf race
From: Johannes Berg @ 2013-07-31 8:20 UTC (permalink / raw)
To: linux-wireless; +Cc: Ben Hutchings
In-Reply-To: <1375216722-31194-1-git-send-email-johannes@sipsolutions.net>
On Tue, 2013-07-30 at 22:38 +0200, Johannes Berg wrote:
> From: Johannes Berg <johannes.berg@intel.com>
>
> This is similar to the race Linus had reported, but in this case
> it's an older bug: nl80211_prepare_wdev_dump() uses the wiphy
> index in cb->args[0] as it is and thus parses the message over
> and over again instead of just once because 0 is the first valid
> wiphy index. Similar code in nl80211_testmode_dump() correctly
> offsets the wiphy_index by 1, do that here as well.
Applied.
johannes
^ permalink raw reply
* [PATCH 3.11] mac80211: don't wait for TX status forever
From: Johannes Berg @ 2013-07-31 8:22 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
TX status notification can get lost, or the frames could
get stuck on the queue, so don't wait for the callback
from the driver forever and instead time out after half
a second.
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/mac80211/mlme.c | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index fa19828..8a02018 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -31,10 +31,12 @@
#include "led.h"
#define IEEE80211_AUTH_TIMEOUT (HZ / 5)
+#define IEEE80211_AUTH_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_AUTH_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_AUTH_MAX_TRIES 3
#define IEEE80211_AUTH_WAIT_ASSOC (HZ * 5)
#define IEEE80211_ASSOC_TIMEOUT (HZ / 5)
+#define IEEE80211_ASSOC_TIMEOUT_LONG (HZ / 2)
#define IEEE80211_ASSOC_TIMEOUT_SHORT (HZ / 10)
#define IEEE80211_ASSOC_MAX_TRIES 3
@@ -3412,10 +3414,13 @@ static int ieee80211_probe_auth(struct ieee80211_sub_if_data *sdata)
if (tx_flags == 0) {
auth_data->timeout = jiffies + IEEE80211_AUTH_TIMEOUT;
- ifmgd->auth_data->timeout_started = true;
+ auth_data->timeout_started = true;
run_again(sdata, auth_data->timeout);
} else {
- auth_data->timeout_started = false;
+ auth_data->timeout =
+ round_jiffies_up(jiffies + IEEE80211_AUTH_TIMEOUT_LONG);
+ auth_data->timeout_started = true;
+ run_again(sdata, auth_data->timeout);
}
return 0;
@@ -3452,7 +3457,11 @@ static int ieee80211_do_assoc(struct ieee80211_sub_if_data *sdata)
assoc_data->timeout_started = true;
run_again(sdata, assoc_data->timeout);
} else {
- assoc_data->timeout_started = false;
+ assoc_data->timeout =
+ round_jiffies_up(jiffies +
+ IEEE80211_ASSOC_TIMEOUT_LONG);
+ assoc_data->timeout_started = true;
+ run_again(sdata, assoc_data->timeout);
}
return 0;
--
1.8.0
^ permalink raw reply related
* [PATCH v3] ath10k: implement get_survey()
From: Michal Kazior @ 2013-07-31 8:32 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
In-Reply-To: <1375081712-9697-1-git-send-email-michal.kazior@tieto.com>
This implements a limited subset of what can be
reported in the survey dump.
This can be used for assessing approximate channel
load, e.g. for automatic channel selection.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
---
v3:
* fix warning print format
* bail out on invalid frequency earlier
* use temp vars for improved readability
* document survey stats vars are protected by data_lock
* use FIXME: instead of XXX:
v2: Do not sum up channel time. Each time a
channel is visited stats for that channel are
overwritten. This makes the behaviour
more consistent with ath9k.
drivers/net/wireless/ath/ath10k/core.h | 7 +++
drivers/net/wireless/ath/ath10k/mac.c | 36 +++++++++++++++
drivers/net/wireless/ath/ath10k/wmi.c | 75 +++++++++++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi.h | 5 +++
4 files changed, 122 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.h b/drivers/net/wireless/ath/ath10k/core.h
index ff42bb7..e4bba56 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -38,6 +38,7 @@
#define ATH10K_SCAN_ID 0
#define WMI_READY_TIMEOUT (5 * HZ)
#define ATH10K_FLUSH_TIMEOUT_HZ (5*HZ)
+#define ATH10K_NUM_CHANS 38
/* Antenna noise floor */
#define ATH10K_DEFAULT_NOISE_FLOOR -95
@@ -375,6 +376,12 @@ struct ath10k {
struct work_struct restart_work;
+ /* cycle count is reported twice for each visited channel during scan.
+ * access protected by data_lock */
+ u32 survey_last_rx_clear_count;
+ u32 survey_last_cycle_count;
+ struct survey_info survey[ATH10K_NUM_CHANS];
+
#ifdef CONFIG_ATH10K_DEBUGFS
struct ath10k_debug debug;
#endif
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 344ad27..9598646 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2934,6 +2934,41 @@ static void ath10k_restart_complete(struct ieee80211_hw *hw)
mutex_unlock(&ar->conf_mutex);
}
+static int ath10k_get_survey(struct ieee80211_hw *hw, int idx,
+ struct survey_info *survey)
+{
+ struct ath10k *ar = hw->priv;
+ struct ieee80211_supported_band *sband;
+ struct survey_info *ar_survey = &ar->survey[idx];
+ int ret = 0;
+
+ mutex_lock(&ar->conf_mutex);
+
+ sband = hw->wiphy->bands[IEEE80211_BAND_2GHZ];
+ if (sband && idx >= sband->n_channels) {
+ idx -= sband->n_channels;
+ sband = NULL;
+ }
+
+ if (!sband)
+ sband = hw->wiphy->bands[IEEE80211_BAND_5GHZ];
+
+ if (!sband || idx >= sband->n_channels) {
+ ret = -ENOENT;
+ goto exit;
+ }
+
+ spin_lock_bh(&ar->data_lock);
+ memcpy(survey, ar_survey, sizeof(*survey));
+ spin_unlock_bh(&ar->data_lock);
+
+ survey->channel = &sband->channels[idx];
+
+exit:
+ mutex_unlock(&ar->conf_mutex);
+ return ret;
+}
+
static const struct ieee80211_ops ath10k_ops = {
.tx = ath10k_tx,
.start = ath10k_start,
@@ -2955,6 +2990,7 @@ static const struct ieee80211_ops ath10k_ops = {
.flush = ath10k_flush,
.tx_last_beacon = ath10k_tx_last_beacon,
.restart_complete = ath10k_restart_complete,
+ .get_survey = ath10k_get_survey,
#ifdef CONFIG_PM
.suspend = ath10k_suspend,
.resume = ath10k_resume,
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 1cbcb2e..55f90c7 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -390,9 +390,82 @@ static int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct sk_buff *skb)
return 0;
}
+static int freq_to_idx(struct ath10k *ar, int freq)
+{
+ struct ieee80211_supported_band *sband;
+ int band, ch, idx = 0;
+
+ for (band = IEEE80211_BAND_2GHZ; band < IEEE80211_NUM_BANDS; band++) {
+ sband = ar->hw->wiphy->bands[band];
+ if (!sband)
+ continue;
+
+ for (ch = 0; ch < sband->n_channels; ch++, idx++)
+ if (sband->channels[ch].center_freq == freq)
+ goto exit;
+ }
+
+exit:
+ return idx;
+}
+
static void ath10k_wmi_event_chan_info(struct ath10k *ar, struct sk_buff *skb)
{
- ath10k_dbg(ATH10K_DBG_WMI, "WMI_CHAN_INFO_EVENTID\n");
+ struct wmi_chan_info_event *ev;
+ struct survey_info *survey;
+ u32 err_code, freq, cmd_flags, noise_floor, rx_clear_count, cycle_count;
+ int idx;
+
+ ev = (struct wmi_chan_info_event *)skb->data;
+
+ err_code = __le32_to_cpu(ev->err_code);
+ freq = __le32_to_cpu(ev->freq);
+ cmd_flags = __le32_to_cpu(ev->cmd_flags);
+ noise_floor = __le32_to_cpu(ev->noise_floor);
+ rx_clear_count = __le32_to_cpu(ev->rx_clear_count);
+ cycle_count = __le32_to_cpu(ev->cycle_count);
+
+ ath10k_dbg(ATH10K_DBG_WMI,
+ "chan info err_code %d freq %d cmd_flags %d noise_floor %d rx_clear_count %d cycle_count %d\n",
+ err_code, freq, cmd_flags, noise_floor, rx_clear_count,
+ cycle_count);
+
+ spin_lock_bh(&ar->data_lock);
+
+ if (!ar->scan.in_progress) {
+ ath10k_warn("chan info event without a scan request?\n");
+ goto exit;
+ }
+
+ idx = freq_to_idx(ar, freq);
+ if (idx >= ARRAY_SIZE(ar->survey)) {
+ ath10k_warn("chan info: invalid frequency %d (idx %d out of bounds)\n",
+ freq, idx);
+ goto exit;
+ }
+
+ if (cmd_flags & WMI_CHAN_INFO_FLAG_COMPLETE) {
+ /* During scanning chan info is reported twice for each
+ * visited channel. The reported cycle count is global
+ * and per-channel cycle count must be calculated */
+
+ cycle_count -= ar->survey_last_cycle_count;
+ rx_clear_count -= ar->survey_last_rx_clear_count;
+
+ survey = &ar->survey[idx];
+ survey->channel_time = WMI_CHAN_INFO_MSEC(cycle_count);
+ survey->channel_time_rx = WMI_CHAN_INFO_MSEC(rx_clear_count);
+ survey->noise = noise_floor;
+ survey->filled = SURVEY_INFO_CHANNEL_TIME |
+ SURVEY_INFO_CHANNEL_TIME_RX |
+ SURVEY_INFO_NOISE_DBM;
+ }
+
+ ar->survey_last_rx_clear_count = rx_clear_count;
+ ar->survey_last_cycle_count = cycle_count;
+
+exit:
+ spin_unlock_bh(&ar->data_lock);
}
static void ath10k_wmi_event_echo(struct ath10k *ar, struct sk_buff *skb)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index da3b2bc..2c5a4f8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -2931,6 +2931,11 @@ struct wmi_chan_info_event {
__le32 cycle_count;
} __packed;
+#define WMI_CHAN_INFO_FLAG_COMPLETE BIT(0)
+
+/* FIXME: empirically extrapolated */
+#define WMI_CHAN_INFO_MSEC(x) ((x) / 76595)
+
/* Beacon filter wmi command info */
#define BCN_FLT_MAX_SUPPORTED_IES 256
#define BCN_FLT_MAX_ELEMS_IE_LIST (BCN_FLT_MAX_SUPPORTED_IES / 32)
--
1.7.9.5
^ permalink raw reply related
* Fwd: [Bug 989269] Connecting to WLAN causes kernel panic
From: Arend van Spriel @ 2013-07-31 8:39 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless, John W. Linville, John Greene
In-Reply-To: <bug-989269-351310-C5h8dsuOxB@bugzilla.redhat.com>
Hi Felix,
How are things in OpenWRT. I wanted to ask you something regarding a
defect I am looking at. Since kernel 3.9 several reports have been made
about a kernel panic in brcmsmac, ie. a divide-by-zero error.
Debugging the issue shows we end up with a rate with MCS index 110,
which is, well, impossible. As brcmsmac gets the rate info from
minstrel_ht I was wondering if we have an intergration issue here. I saw
around April patches about new API which may have been in the 3.9 time
frame and something subtly changed things for brcmsmac.
Regards,
Arend
-------- Original Message --------
Subject: [Bug 989269] Connecting to WLAN causes kernel panic
Date: Wed, 31 Jul 2013 08:11:41 +0000
From: <bugzilla@redhat.com>
To: <fedora-kernel-wireless-brcm80211@fedoraproject.org>
https://bugzilla.redhat.com/show_bug.cgi?id=989269
--- Comment #13 from Arend van Spriel <arend@broadcom.com> ---
(In reply to Chris from comment #12)
> Created attachment 780839 [details]
> dmesg | grep brcms when connecting to WLAN after patch 2
>
> During gathering this data I connected to the internet, was sitting for a
> while and then walked through a corridor in my university, so that the
> computer was connecting to different routers. Sat down there for
> significantly longer time. At the end I reconnected and disconnected.
> It seems to work stable, without any problems, but I haven't tried to use
> the connection for something heavier.
Thanks for the data. I observed two values that are invalid. ratespec
value 0
is invalid and the driver selects 1Mbps rate to do the calculation. The
other
value 134217838 is what triggers the divide-by-zero. The ratespec value is:
ratespec: 0x800006E
RATE 110 (rate value [unit: 500Kbps or MCS index])
MIMORATE 1 (RATE field represents MIMO MCS index)
This does not make sense, because MCS index can only go up to 32. I suspect
this should not be a mimo rate, but 54Mbps. Looking further how we end up in
this situation.
--
You are receiving this mail because:
You are the assignee for the bug.
^ permalink raw reply
* [PATCH 0/2] ath10k: implement checksum offloading
From: Michal Kazior @ 2013-07-31 8:47 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Michal Kazior
Hi,
This patchset adds tx and rx checksum offloading
to ath10k driver.
I don't have any hard numbers but I did observe a
consistently sligthly better performance on AP135
+ ath10k. Nothing ground breaking though.
Michal Kazior (2):
ath10k: implement rx checksum offloading
ath10k: implement tx checksum offloading
drivers/net/wireless/ath/ath10k/htt_rx.c | 40 ++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
drivers/net/wireless/ath/ath10k/mac.c | 2 ++
3 files changed, 44 insertions(+)
--
1.7.9.5
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox