AMPDU stalls with brcmfmac4366b-pcie.bin triggering WARNINGs

[Rafał Miłecki]

Hi,

Even with the most recent brcmfmac code ppl keep seeing WARNINGs from
brcmf_netdev_wait_pend8021x [0].

Hante suggested using CONSOLE for debugging some firmware crash so I
decided to see I it could also help understanding WARNINGs. I believe it
did.

First of all, I can't reproduce these problems reliably. One evening I
got WARNINGs one by one and I could work on my debugging patch easily.
Yesterday when I got my patch complete, it took me 10+ hours to get a
single WARNING.

Anyway, it seems to me that sometimes AMPDU stalls in the firmware. It
seems firmware has some AMPDU watchdog that notices the problem and
kicks in. It prints some debugging info and starts cleaning up process.

If brcmf_netdev_wait_pend8021x gets called shortly after that (I set
wpa_group_rekey=30 in hostapd to get brcmf_cfg80211_add_key called more
often) it results in a WARNING.

For better debugging I wrote brcmfmac patch that:
1) Keeps track of every 802.1x skb submitted to the device
2) During WARNING it prints skbs and marks them as timedout
3) It informs when timedout skb gets finally reported as sent

Enough talking, please take a look at my debugging log. Does it give you
enough hint? Could you review/debug firmware's code responsible for
AMPDU? FWIW Merlin users (so no brcmfmac invovled) also saw this [1].

[  913.569121] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] 
ifp:c7369480 brcmf_ifname(ifp):wlan1
[  913.579521] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] 
ifp:c70cd480 brcmf_ifname(ifp):wlan0
[  913.627346] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] 
ifp:c71a1480 brcmf_ifname(ifp):wlan1-1
[  913.839833] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] 
ifp:c6464c80 brcmf_ifname(ifp):wlan0-1
[  914.179775] brcmfmac: [brcmf_cfg80211_add_key -> __send_key_to_dongle] 
ifp:c64cac80 brcmf_ifname(ifp):wlan0-2
[  914.191129] brcmfmac: CONSOLE: 027644.261 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.198474] brcmfmac: CONSOLE: 027644.266 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.206020] brcmfmac: CONSOLE: 027644.273 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.215243] brcmfmac: CONSOLE: 027644.284 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.224521] brcmfmac: CONSOLE: 027644.294 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.231878] brcmfmac: CONSOLE: 027644.298 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.239425] brcmfmac: CONSOLE: 027644.307 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.248444] brcmfmac: CONSOLE: 027644.318 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.257163] brcmfmac: CONSOLE: 027644.326 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.266616] brcmfmac: CONSOLE: 027644.336 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.274072] brcmfmac: CONSOLE: 027644.341 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.284716] brcmfmac: CONSOLE: 027644.354 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.291962] brcmfmac: CONSOLE: 027644.359 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.299172] brcmfmac: CONSOLE: 027644.364 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.306646] brcmfmac: CONSOLE: 027644.371 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.314058] brcmfmac: CONSOLE: 027644.380 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.323193] brcmfmac: CONSOLE: 027644.393 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.330640] brcmfmac: CONSOLE: 027644.400 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.340886] brcmfmac: CONSOLE: 027644.410 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.352975] brcmfmac: CONSOLE: 027644.422 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.365365] brcmfmac: CONSOLE: 027644.434 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.372790] brcmfmac: CONSOLE: 027644.440 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.384982] brcmfmac: CONSOLE: 027644.454 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.395488] brcmfmac: CONSOLE: 027644.465 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.402977] brcmfmac: CONSOLE: 027644.471 wl0.3: wlc_send_bar: seq 0x3 tid 0
[  914.701404] brcmfmac: CONSOLE: 027644.771 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.710513] brcmfmac: CONSOLE: 027644.780 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.717731] brcmfmac: CONSOLE: 027644.787 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.728099] brcmfmac: CONSOLE: 027644.798 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.737616] brcmfmac: CONSOLE: 027644.807 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.745320] brcmfmac: CONSOLE: 027644.815 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.757985] brcmfmac: CONSOLE: 027644.827 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.765457] brcmfmac: CONSOLE: 027644.833 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.772729] brcmfmac: CONSOLE: 027644.841 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.781407] brcmfmac: CONSOLE: 027644.851 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.789268] brcmfmac: CONSOLE: 027644.859 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.796754] brcmfmac: CONSOLE: 027644.866 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.808174] brcmfmac: CONSOLE: 027644.878 wl0.3: wlc_send_bar: seq 0x4 tid 0
[  914.818975] brcmfmac: CONSOLE: 027644.888 wl0.3: wlc_send_bar: seq 0x4 

[PATCH 2/5] wlcore: sdio: Populate config firmware data

[Tony Lindgren]

Configure the config firmware names and make it available
in platform data.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/sdio.c | 76 ++-
 1 file changed, 47 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/sdio.c 
b/drivers/net/wireless/ti/wlcore/sdio.c
index 5839acb..a6e94b1 100644
--- a/drivers/net/wireless/ti/wlcore/sdio.c
+++ b/drivers/net/wireless/ti/wlcore/sdio.c
@@ -216,17 +216,33 @@ static struct wl1271_if_operations sdio_ops = {
 };
 
 #ifdef CONFIG_OF
+
+static const struct wilink_family_data wl127x_data = {
+   .name = "wl127x",
+   .nvs_name = "ti-connectivity/wl127x-nvs.bin",
+};
+
+static const struct wilink_family_data wl128x_data = {
+   .name = "wl128x",
+   .nvs_name = "ti-connectivity/wl128x-nvs.bin",
+};
+
+static const struct wilink_family_data wl18xx_data = {
+   .name = "wl18xx",
+   .cfg_name = "ti-connectivity/wl18xx-conf.bin",
+};
+
 static const struct of_device_id wlcore_sdio_of_match_table[] = {
-   { .compatible = "ti,wl1271" },
-   { .compatible = "ti,wl1273" },
-   { .compatible = "ti,wl1281" },
-   { .compatible = "ti,wl1283" },
-   { .compatible = "ti,wl1801" },
-   { .compatible = "ti,wl1805" },
-   { .compatible = "ti,wl1807" },
-   { .compatible = "ti,wl1831" },
-   { .compatible = "ti,wl1835" },
-   { .compatible = "ti,wl1837" },
+   { .compatible = "ti,wl1271", .data = _data },
+   { .compatible = "ti,wl1273", .data = _data },
+   { .compatible = "ti,wl1281", .data = _data },
+   { .compatible = "ti,wl1283", .data = _data },
+   { .compatible = "ti,wl1801", .data = _data },
+   { .compatible = "ti,wl1805", .data = _data },
+   { .compatible = "ti,wl1807", .data = _data },
+   { .compatible = "ti,wl1831", .data = _data },
+   { .compatible = "ti,wl1835", .data = _data },
+   { .compatible = "ti,wl1837", .data = _data },
{ }
 };
 
@@ -234,9 +250,13 @@ static int wlcore_probe_of(struct device *dev, int *irq,
   struct wlcore_platdev_data *pdev_data)
 {
struct device_node *np = dev->of_node;
+   const struct of_device_id *of_id;
+
+   of_id = of_match_node(wlcore_sdio_of_match_table, np);
+   if (!of_id)
+   return -ENODEV;
 
-   if (!np || !of_match_node(wlcore_sdio_of_match_table, np))
-   return -ENODATA;
+   pdev_data->family = of_id->data;
 
*irq = irq_of_parse_and_map(np, 0);
if (!*irq) {
@@ -263,7 +283,7 @@ static int wlcore_probe_of(struct device *dev, int *irq,
 static int wl1271_probe(struct sdio_func *func,
  const struct sdio_device_id *id)
 {
-   struct wlcore_platdev_data pdev_data;
+   struct wlcore_platdev_data *pdev_data;
struct wl12xx_sdio_glue *glue;
struct resource res[1];
mmc_pm_flag_t mmcflags;
@@ -275,14 +295,15 @@ static int wl1271_probe(struct sdio_func *func,
if (func->num != 0x02)
return -ENODEV;
 
-   memset(_data, 0x00, sizeof(pdev_data));
-   pdev_data.if_ops = _ops;
+   pdev_data = devm_kzalloc(>dev, sizeof(*pdev_data), GFP_KERNEL);
+   if (!pdev_data)
+   return -ENOMEM;
 
-   glue = kzalloc(sizeof(*glue), GFP_KERNEL);
-   if (!glue) {
-   dev_err(>dev, "can't allocate glue\n");
-   goto out;
-   }
+   pdev_data->if_ops = _ops;
+
+   glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
+   if (!glue)
+   return -ENOMEM;
 
glue->dev = >dev;
 
@@ -292,16 +313,16 @@ static int wl1271_probe(struct sdio_func *func,
/* Use block mode for transferring over one block size of data */
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
-   ret = wlcore_probe_of(>dev, , _data);
+   ret = wlcore_probe_of(>dev, , pdev_data);
if (ret)
-   goto out_free_glue;
+   goto out;
 
/* if sdio can keep power while host is suspended, enable wow */
mmcflags = sdio_get_host_pm_caps(func);
dev_dbg(glue->dev, "sdio PM caps = 0x%x\n", mmcflags);
 
if (mmcflags & MMC_PM_KEEP_POWER)
-   pdev_data.pwr_in_suspend = true;
+   pdev_data->pwr_in_suspend = true;
 
sdio_set_drvdata(func, glue);
 
@@ -323,7 +344,7 @@ static int wl1271_probe(struct sdio_func *func,
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device");
ret = -ENOMEM;
-   goto out_free_glue;
+   goto out;
}
 
glue->core->dev.parent = >dev;
@@ -341,8 +362,8 @@ static int wl1271_probe(struct sdio_func *func,
goto out_dev_put;
}
 
-   ret = platform_device_add_data(glue->core, _data,
-  sizeof(pdev_data));
+   ret = platform_device_add_data(glue->core, 

[PATCH 3/5] wlcore: sdio: Populate config firmware data

[Tony Lindgren]

Configure the config firmware names and make it available
in platform data.

Let's also fix the order of the struct wilink_family_data
while at it.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/spi.c | 42 
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index a336493..f949ad2b 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -79,15 +79,19 @@
 #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
+static const struct wilink_family_data wl127x_data = {
+   .name = "wl127x",
+   .nvs_name = "ti-connectivity/wl127x-nvs.bin",
+};
 
-static const struct wilink_family_data *wilink_data;
+static const struct wilink_family_data wl128x_data = {
+   .name = "wl128x",
+   .nvs_name = "ti-connectivity/wl128x-nvs.bin",
+};
 
 static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
-};
-
-static const struct wilink_family_data wl12xx_data = {
-   .name = "wl12xx",
+   .cfg_name = "ti-connectivity/wl18xx-conf.bin",
 };
 
 struct wl12xx_spi_glue {
@@ -425,10 +429,10 @@ static struct wl1271_if_operations spi_ops = {
 };
 
 static const struct of_device_id wlcore_spi_of_match_table[] = {
-   { .compatible = "ti,wl1271", .data = _data},
-   { .compatible = "ti,wl1273", .data = _data},
-   { .compatible = "ti,wl1281", .data = _data},
-   { .compatible = "ti,wl1283", .data = _data},
+   { .compatible = "ti,wl1271", .data = _data},
+   { .compatible = "ti,wl1273", .data = _data},
+   { .compatible = "ti,wl1281", .data = _data},
+   { .compatible = "ti,wl1283", .data = _data},
{ .compatible = "ti,wl1801", .data = _data},
{ .compatible = "ti,wl1805", .data = _data},
{ .compatible = "ti,wl1807", .data = _data},
@@ -456,9 +460,9 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
if (!of_id)
return -ENODEV;
 
-   wilink_data = of_id->data;
+   pdev_data->family = of_id->data;
dev_info(>dev, "selected chip family is %s\n",
-wilink_data->name);
+pdev_data->family->name);
 
if (of_find_property(dt_node, "clock-xtal", NULL))
pdev_data->ref_clock_xtal = true;
@@ -475,13 +479,15 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
 static int wl1271_probe(struct spi_device *spi)
 {
struct wl12xx_spi_glue *glue;
-   struct wlcore_platdev_data pdev_data;
+   struct wlcore_platdev_data *pdev_data;
struct resource res[1];
int ret;
 
-   memset(_data, 0x00, sizeof(pdev_data));
+   pdev_data = devm_kzalloc(>dev, sizeof(*pdev_data), GFP_KERNEL);
+   if (!pdev_data)
+   return -ENOMEM;
 
-   pdev_data.if_ops = _ops;
+   pdev_data->if_ops = _ops;
 
glue = devm_kzalloc(>dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -505,7 +511,7 @@ static int wl1271_probe(struct spi_device *spi)
return PTR_ERR(glue->reg);
}
 
-   ret = wlcore_probe_of(spi, glue, _data);
+   ret = wlcore_probe_of(spi, glue, pdev_data);
if (ret) {
dev_err(glue->dev,
"can't get device tree parameters (%d)\n", ret);
@@ -518,7 +524,7 @@ static int wl1271_probe(struct spi_device *spi)
return ret;
}
 
-   glue->core = platform_device_alloc(wilink_data->name,
+   glue->core = platform_device_alloc(pdev_data->family->name,
   PLATFORM_DEVID_AUTO);
if (!glue->core) {
dev_err(glue->dev, "can't allocate platform_device\n");
@@ -539,8 +545,8 @@ static int wl1271_probe(struct spi_device *spi)
goto out_dev_put;
}
 
-   ret = platform_device_add_data(glue->core, _data,
-  sizeof(pdev_data));
+   ret = platform_device_add_data(glue->core, pdev_data,
+  sizeof(*pdev_data));
if (ret) {
dev_err(glue->dev, "can't add platform data\n");
goto out_dev_put;
-- 
2.9.3

[PATCH 4/5] wlcore: Fix config firmware loading issues

[Tony Lindgren]

Booting multiple wl12xx and wl18xx devices using the same rootfs is
a pain. You currently have to symlink the right nvs file depending
on the wl12xx type.

For example, with wl1271-nvs.bin being a symlink to wl127x-nvs.bin
by default and trying to bring up a wl128x based device:

wlcore: ERROR nvs size is not as expected: 1113 != 912
wlcore: ERROR NVS file is needed during boot
wlcore: ERROR NVS file is needed during boot
wlcore: ERROR firmware boot failed despite 3 retries

Note that wl18xx uses a separate config firmware wl18xx-conf.bin
that can be generated with tools using the following two git repos:

git.ti.com/wilink8-wlan/18xx-ti-utils
git.ti.com/wilink8-wlan/wl18xx_fw

So let's not configure the nvs file for wl18xx as it's not needed
AFAIK. If it turns out that we also need the nvs file for wl18xx,
we can just add it to the config firmware data for wl18xx.

Let's fix the issue by using the chip specific config firmware
data, and make sure we produce understandable warnings if something
is missing.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/boot.c | 15 ++
 drivers/net/wireless/ti/wlcore/main.c | 34 +--
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  7 ---
 3 files changed, 34 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/boot.c 
b/drivers/net/wireless/ti/wlcore/boot.c
index f75d304..f00509e 100644
--- a/drivers/net/wireless/ti/wlcore/boot.c
+++ b/drivers/net/wireless/ti/wlcore/boot.c
@@ -282,6 +282,9 @@ EXPORT_SYMBOL_GPL(wlcore_boot_upload_firmware);
 
 int wlcore_boot_upload_nvs(struct wl1271 *wl)
 {
+   struct platform_device *pdev = wl->pdev;
+   struct wlcore_platdev_data *pdev_data = dev_get_platdata(>dev);
+   const char *nvs_name = "unknown";
size_t nvs_len, burst_len;
int i;
u32 dest_addr, val;
@@ -293,6 +296,9 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
return -ENODEV;
}
 
+   if (pdev_data && pdev_data->family)
+   nvs_name = pdev_data->family->nvs_name;
+
if (wl->quirks & WLCORE_QUIRK_LEGACY_NVS) {
struct wl1271_nvs_file *nvs =
(struct wl1271_nvs_file *)wl->nvs;
@@ -310,8 +316,9 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
if (wl->nvs_len != sizeof(struct wl1271_nvs_file) &&
(wl->nvs_len != WL1271_INI_LEGACY_NVS_FILE_SIZE ||
 wl->enable_11a)) {
-   wl1271_error("nvs size is not as expected: %zu != %zu",
-   wl->nvs_len, sizeof(struct wl1271_nvs_file));
+   wl1271_error("%s size is not as expected: %zu != %zu",
+nvs_name, wl->nvs_len,
+sizeof(struct wl1271_nvs_file));
kfree(wl->nvs);
wl->nvs = NULL;
wl->nvs_len = 0;
@@ -328,8 +335,8 @@ int wlcore_boot_upload_nvs(struct wl1271 *wl)
if (nvs->general_params.dual_mode_select)
wl->enable_11a = true;
} else {
-   wl1271_error("nvs size is not as expected: %zu != %zu",
-wl->nvs_len,
+   wl1271_error("%s size is not as expected: %zu != %zu",
+nvs_name, wl->nvs_len,
 sizeof(struct wl128x_nvs_file));
kfree(wl->nvs);
wl->nvs = NULL;
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index ef6c15b..7f26299 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6413,9 +6413,12 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
void *context)
goto out;
}
wl->nvs_len = fw->size;
-   } else {
+   } else if (pdev_data->family->nvs_name) {
wl1271_debug(DEBUG_BOOT, "Could not get nvs file %s",
-WL12XX_NVS_NAME);
+pdev_data->family->nvs_name);
+   wl->nvs = NULL;
+   wl->nvs_len = 0;
+   } else {
wl->nvs = NULL;
wl->nvs_len = 0;
}
@@ -6510,21 +6513,29 @@ static void wlcore_nvs_cb(const struct firmware *fw, 
void *context)
 
 int wlcore_probe(struct wl1271 *wl, struct platform_device *pdev)
 {
+   struct wlcore_platdev_data *pdev_data = dev_get_platdata(>dev);
+   const char *nvs_name;
int ret;
 
-   if (!wl->ops || !wl->ptable)
+   if (!wl->ops || !wl->ptable || !pdev_data)
return -EINVAL;
 
wl->dev = >dev;
wl->pdev = pdev;
platform_set_drvdata(pdev, wl);
 
-   ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
-   

[PATCH 1/5] wlcore: Prepare family to fix nvs file handling

[Tony Lindgren]

Move struct wilink_family_data to be available for all TI WLAN
variants. And fix familiy typo, it should be just family.

Looks like wl12xx use two different nvs.bin files and wl18xx
uses a different conf.bin file.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wlcore/spi.c  | 12 
 drivers/net/wireless/ti/wlcore/wlcore_i.h |  7 +++
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index 0ed526e..a336493 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -80,17 +80,13 @@
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)
 
 
-struct wilink_familiy_data {
-   char name[8];
-};
-
-static const struct wilink_familiy_data *wilink_data;
+static const struct wilink_family_data *wilink_data;
 
-static const struct wilink_familiy_data wl18xx_data = {
+static const struct wilink_family_data wl18xx_data = {
.name = "wl18xx",
 };
 
-static const struct wilink_familiy_data wl12xx_data = {
+static const struct wilink_family_data wl12xx_data = {
.name = "wl12xx",
 };
 
@@ -461,7 +457,7 @@ static int wlcore_probe_of(struct spi_device *spi, struct 
wl12xx_spi_glue *glue,
return -ENODEV;
 
wilink_data = of_id->data;
-   dev_info(>dev, "selected chip familiy is %s\n",
+   dev_info(>dev, "selected chip family is %s\n",
 wilink_data->name);
 
if (of_find_property(dt_node, "clock-xtal", NULL))
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h 
b/drivers/net/wireless/ti/wlcore/wlcore_i.h
index 0277ae5..f68280d 100644
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -42,6 +42,12 @@
  */
 #define WL12XX_NVS_NAME "ti-connectivity/wl1271-nvs.bin"
 
+struct wilink_family_data {
+   const char *name;
+   const char *nvs_name;   /* wl12xx nvs file */
+   const char *cfg_name;   /* wl18xx cfg file */
+};
+
 #define WL1271_TX_SECURITY_LO16(s) ((u16)((s) & 0x))
 #define WL1271_TX_SECURITY_HI32(s) ((u32)(((s) >> 16) & 0x))
 #define WL1271_TX_SQN_POST_RECOVERY_PADDING 0xff
@@ -208,6 +214,7 @@ struct wl1271_if_operations {
 
 struct wlcore_platdev_data {
struct wl1271_if_operations *if_ops;
+   const struct wilink_family_data *family;
 
bool ref_clock_xtal;/* specify whether the clock is XTAL or not */
u32 ref_clock_freq; /* in Hertz */
-- 
2.9.3

[PATCH 5/5] wlcore: wl18xx: Use chip specific configuration firmware

[Tony Lindgren]

Use the wl18xx specific config firmware we now have available.

Signed-off-by: Tony Lindgren 
---
 drivers/net/wireless/ti/wl18xx/main.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/wireless/ti/wl18xx/main.c 
b/drivers/net/wireless/ti/wl18xx/main.c
index 00a04df..06d6943 100644
--- a/drivers/net/wireless/ti/wl18xx/main.c
+++ b/drivers/net/wireless/ti/wl18xx/main.c
@@ -1397,25 +1397,24 @@ static int wl18xx_get_pg_ver(struct wl1271 *wl, s8 *ver)
return ret;
 }
 
-#define WL18XX_CONF_FILE_NAME "ti-connectivity/wl18xx-conf.bin"
-
 static int wl18xx_load_conf_file(struct device *dev, struct wlcore_conf *conf,
-struct wl18xx_priv_conf *priv_conf)
+struct wl18xx_priv_conf *priv_conf,
+const char *file)
 {
struct wlcore_conf_file *conf_file;
const struct firmware *fw;
int ret;
 
-   ret = request_firmware(, WL18XX_CONF_FILE_NAME, dev);
+   ret = request_firmware(, file, dev);
if (ret < 0) {
wl1271_error("could not get configuration binary %s: %d",
-WL18XX_CONF_FILE_NAME, ret);
+file, ret);
return ret;
}
 
if (fw->size != WL18XX_CONF_SIZE) {
-   wl1271_error("configuration binary file size is wrong, expected 
%zu got %zu",
-WL18XX_CONF_SIZE, fw->size);
+   wl1271_error("%s configuration binary size is wrong, expected 
%zu got %zu",
+file, WL18XX_CONF_SIZE, fw->size);
ret = -EINVAL;
goto out_release;
}
@@ -1448,9 +1447,12 @@ static int wl18xx_load_conf_file(struct device *dev, 
struct wlcore_conf *conf,
 
 static int wl18xx_conf_init(struct wl1271 *wl, struct device *dev)
 {
+   struct platform_device *pdev = wl->pdev;
+   struct wlcore_platdev_data *pdata = dev_get_platdata(>dev);
struct wl18xx_priv *priv = wl->priv;
 
-   if (wl18xx_load_conf_file(dev, >conf, >conf) < 0) {
+   if (wl18xx_load_conf_file(dev, >conf, >conf,
+ pdata->family->cfg_name) < 0) {
wl1271_warning("falling back to default config");
 
/* apply driver default configuration */
@@ -2141,4 +2143,3 @@ MODULE_PARM_DESC(num_rx_desc_param,
 MODULE_LICENSE("GPL v2");
 MODULE_AUTHOR("Luciano Coelho ");
 MODULE_FIRMWARE(WL18XX_FW_NAME);
-MODULE_FIRMWARE(WL18XX_CONF_FILE_NAME);
-- 
2.9.3

[PATCH 0/5] Fix wlcore config firwmare annoyances

[Tony Lindgren]

Hi all,

Here are some patches to fix the firmware loading for wl12xx/wl18xx
when the same rootfs is used on multiple WLAN chip variants.

Regards,

Tony

Tony Lindgren (5):
  wlcore: Prepare family to fix nvs file handling
  wlcore: sdio: Populate config firmware data
  wlcore: sdio: Populate config firmware data
  wlcore: Fix config firmware loading issues
  wlcore: wl18xx: Use chip specific configuration firmware

 drivers/net/wireless/ti/wl18xx/main.c | 19 
 drivers/net/wireless/ti/wlcore/boot.c | 15 --
 drivers/net/wireless/ti/wlcore/main.c | 34 +-
 drivers/net/wireless/ti/wlcore/sdio.c | 76 +++
 drivers/net/wireless/ti/wlcore/spi.c  | 48 +--
 drivers/net/wireless/ti/wlcore/wlcore_i.h | 12 ++---
 6 files changed, 122 insertions(+), 82 deletions(-)

-- 
2.9.3

[PATCH] ath10k: cache calibration data when the core is stopped.

[Marty Faltesek]

Caching calibration data allows it to be accessed when the
device is not active.

Signed-off-by: Marty Faltesek 
---
 drivers/net/wireless/ath/ath10k/core.c  | 47 ++
 drivers/net/wireless/ath/ath10k/core.h  |  2 ++
 drivers/net/wireless/ath/ath10k/debug.c | 51 +
 drivers/net/wireless/ath/ath10k/debug.h |  1 +
 drivers/net/wireless/ath/ath10k/mac.c   |  1 +
 5 files changed, 65 insertions(+), 37 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.c 
b/drivers/net/wireless/ath/ath10k/core.c
index c0b9797..c99ad9e 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -1227,6 +1227,42 @@ success:
return 0;
 }
 
+int
+ath10k_cal_data_alloc(struct ath10k *ar, void **buf)
+{
+   u32 hi_addr;
+   __le32 addr;
+   int ret;
+
+   vfree(*buf);
+   *buf = vmalloc(QCA988X_CAL_DATA_LEN);
+   if (!*buf) {
+   return -EAGAIN;
+   }
+
+   hi_addr = host_interest_item_address(HI_ITEM(hi_board_data));
+
+   ret = ath10k_hif_diag_read(ar, hi_addr, , sizeof(addr));
+
+   if (ret) {
+   ath10k_warn(ar, "failed to read hi_board_data address: %d\n", 
ret);
+   } else {
+   ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), *buf,
+  QCA988X_CAL_DATA_LEN);
+   if (ret) {
+   ath10k_warn(ar, "failed to read calibration data: 
%d\n", ret);
+   }
+   }
+
+   if (ret) {
+   vfree(*buf);
+   *buf = NULL;
+   }
+
+   return ret;
+}
+
+
 static int ath10k_download_cal_data(struct ath10k *ar)
 {
int ret;
@@ -1714,6 +1750,12 @@ int ath10k_core_start(struct ath10k *ar, enum 
ath10k_firmware_mode mode)
 
INIT_LIST_HEAD(>arvifs);
 
+   /*
+* We are up now, so no need to cache calibration data.
+*/
+   vfree(ar->cal_data);
+ar->cal_data = NULL;
+
return 0;
 
 err_hif_stop:
@@ -1757,6 +1799,11 @@ void ath10k_core_stop(struct ath10k *ar)
lockdep_assert_held(>conf_mutex);
ath10k_debug_stop(ar);
 
+   /*
+* Cache caclibration data while stopped.
+*/
+   ath10k_cal_data_alloc(ar, >cal_data);
+
/* try to suspend target */
if (ar->state != ATH10K_STATE_RESTARTING &&
ar->state != ATH10K_STATE_UTF)
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index 4d3f002..cce61c1 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -635,6 +635,8 @@ struct ath10k {
struct ath10k_htc htc;
struct ath10k_htt htt;
 
+   void *cal_data;
+
struct ath10k_hw_params {
u32 id;
u16 dev_id;
diff --git a/drivers/net/wireless/ath/ath10k/debug.c 
b/drivers/net/wireless/ath/ath10k/debug.c
index 8b01e3e..7de0eb4 100644
--- a/drivers/net/wireless/ath/ath10k/debug.c
+++ b/drivers/net/wireless/ath/ath10k/debug.c
@@ -1427,53 +1427,26 @@ static const struct file_operations fops_fw_dbglog = {
 static int ath10k_debug_cal_data_open(struct inode *inode, struct file *file)
 {
struct ath10k *ar = inode->i_private;
-   void *buf;
-   u32 hi_addr;
-   __le32 addr;
int ret;
 
mutex_lock(>conf_mutex);
 
if (ar->state != ATH10K_STATE_ON &&
-   ar->state != ATH10K_STATE_UTF) {
-   ret = -ENETDOWN;
-   goto err;
-   }
-
-   buf = vmalloc(QCA988X_CAL_DATA_LEN);
-   if (!buf) {
-   ret = -ENOMEM;
-   goto err;
+   ar->state != ATH10K_STATE_UTF && ! ar->cal_data) {
+   mutex_unlock(>conf_mutex);
+   return (-ENETDOWN);
}
 
-   hi_addr = host_interest_item_address(HI_ITEM(hi_board_data));
-
-   ret = ath10k_hif_diag_read(ar, hi_addr, , sizeof(addr));
-   if (ret) {
-   ath10k_warn(ar, "failed to read hi_board_data address: %d\n", 
ret);
-   goto err_vfree;
-   }
-
-   ret = ath10k_hif_diag_read(ar, le32_to_cpu(addr), buf,
-  QCA988X_CAL_DATA_LEN);
-   if (ret) {
-   ath10k_warn(ar, "failed to read calibration data: %d\n", ret);
-   goto err_vfree;
+   if (ar->cal_data) {
+   file->private_data = ar->cal_data;
+   mutex_unlock(>conf_mutex);
+   return 0;
}
 
-   file->private_data = buf;
-
-   mutex_unlock(>conf_mutex);
-
-   return 0;
-
-err_vfree:
-   vfree(buf);
-
-err:
+   ret = ath10k_cal_data_alloc(ar, >private_data);
mutex_unlock(>conf_mutex);
 
-   return ret;
+   return (ret);
 }
 
 static ssize_t ath10k_debug_cal_data_read(struct file *file,
@@ -1489,7 +1462,11 @@ static ssize_t ath10k_debug_cal_data_read(struct file 
*file,
 static int 

pull-request: mac80211 2016-09-13

[Johannes Berg]

Hi Dave,

We found a few more issues, I'm sending you small fixes here. The diffstat
would be even shorter, but one of Felix's patches has to move about 30 lines
of code, which makes it seem much bigger than it really is.

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit 15543692a010192b4264ade0d45390e8bb3dc639:

  Merge tag 'mac80211-for-davem-2016-08-30' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 (2016-08-30 
21:34:48 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2016-09-13

for you to fetch changes up to ad5987b47e96a0fb6d13fea250e936aed93c:

  nl80211: validate number of probe response CSA counters (2016-09-13 20:19:27 
+0200)


A few more fixes:
 * better mesh path fixing, from Thomas
 * fix TIM IE recalculation after sending frames
   to a sleeping station, from Felix
 * fix sequence number assignment while sending
   frames to a sleeping station, also from Felix
 * validate number of probe response CSA counter
   offsets, fixing a copy/paste bug (from myself)


Felix Fietkau (2):
  mac80211: fix tim recalculation after PS response
  mac80211: fix sequence number assignment for PS response frames

Johannes Berg (1):
  nl80211: validate number of probe response CSA counters

Pedersen, Thomas (1):
  mac80211: make mpath path fixing more robust

 net/mac80211/mesh_hwmp.c|  3 ++-
 net/mac80211/mesh_pathtbl.c |  2 +-
 net/mac80211/sta_info.c |  4 +--
 net/mac80211/tx.c   | 65 +++--
 net/wireless/nl80211.c  |  2 +-
 5 files changed, 39 insertions(+), 37 deletions(-)

[PATCH 0/1] Fix problem with rtl8192eu firmware reload

[Jes . Sorensen]

From: Jes Sorensen 

Hi,

This one goes on top of my previous patches, albeit it probably
applies out of order.

It resolves the issue where firmware wouldn't load correctly if
reloading the driver module.

Cheers,
Jes


Jes Sorensen (1):
  rtl8xxxu: Implment 8192e specific power down sequence

 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 -
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |   1 +
 2 files changed, 144 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH 1/1] rtl8xxxu: Implement 8192e specific power down sequence

[Jes . Sorensen]

From: Jes Sorensen 

This powers down the 8192e correctly, or at least to the point where
the firmware will load again, when reloading the driver module.

Signed-off-by: Jes Sorensen 
---
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c | 144 -
 .../net/wireless/realtek/rtl8xxxu/rtl8xxxu_regs.h  |   1 +
 2 files changed, 144 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c 
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
index 841522e..df54d27 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8192e.c
@@ -1396,6 +1396,114 @@ exit:
return ret;
 }
 
+static int rtl8192eu_active_to_lps(struct rtl8xxxu_priv *priv)
+{
+   struct device *dev = >udev->dev;
+   u8 val8;
+   u16 val16;
+   u32 val32;
+   int retry, retval;
+
+   rtl8xxxu_write8(priv, REG_TXPAUSE, 0xff);
+
+   retry = 100;
+   retval = -EBUSY;
+   /*
+* Poll 32 bit wide 0x05f8 for 0x to ensure no TX is pending.
+*/
+   do {
+   val32 = rtl8xxxu_read32(priv, REG_SCH_TX_CMD);
+   if (!val32) {
+   retval = 0;
+   break;
+   }
+   } while (retry--);
+
+   if (!retry) {
+   dev_warn(dev, "Failed to flush TX queue\n");
+   retval = -EBUSY;
+   goto out;
+   }
+
+   /* Disable CCK and OFDM, clock gated */
+   val8 = rtl8xxxu_read8(priv, REG_SYS_FUNC);
+   val8 &= ~SYS_FUNC_BBRSTB;
+   rtl8xxxu_write8(priv, REG_SYS_FUNC, val8);
+
+   udelay(2);
+
+   /* Reset whole BB */
+   val8 = rtl8xxxu_read8(priv, REG_SYS_FUNC);
+   val8 &= ~SYS_FUNC_BB_GLB_RSTN;
+   rtl8xxxu_write8(priv, REG_SYS_FUNC, val8);
+
+   /* Reset MAC TRX */
+   val16 = rtl8xxxu_read16(priv, REG_CR);
+   val16 &= 0xff00;
+   val16 |= (CR_HCI_TXDMA_ENABLE | CR_HCI_RXDMA_ENABLE);
+   rtl8xxxu_write16(priv, REG_CR, val16);
+
+   val16 = rtl8xxxu_read16(priv, REG_CR);
+   val16 &= ~CR_SECURITY_ENABLE;
+   rtl8xxxu_write16(priv, REG_CR, val16);
+
+   val8 = rtl8xxxu_read8(priv, REG_DUAL_TSF_RST);
+   val8 |= DUAL_TSF_TX_OK;
+   rtl8xxxu_write8(priv, REG_DUAL_TSF_RST, val8);
+
+out:
+   return retval;
+}
+
+static int rtl8192eu_active_to_emu(struct rtl8xxxu_priv *priv)
+{
+   u8 val8;
+   int count, ret = 0;
+
+   /* Turn off RF */
+   rtl8xxxu_write8(priv, REG_RF_CTRL, 0);
+
+   /* Switch DPDT_SEL_P output from register 0x65[2] */
+   val8 = rtl8xxxu_read8(priv, REG_LEDCFG2);
+   val8 &= ~LEDCFG2_DPDT_SELECT;
+   rtl8xxxu_write8(priv, REG_LEDCFG2, val8);
+
+   /* 0x0005[1] = 1 turn off MAC by HW state machine*/
+   val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+   val8 |= BIT(1);
+   rtl8xxxu_write8(priv, REG_APS_FSMCO + 1, val8);
+
+   for (count = RTL8XXXU_MAX_REG_POLL; count; count--) {
+   val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+   if ((val8 & BIT(1)) == 0)
+   break;
+   udelay(10);
+   }
+
+   if (!count) {
+   dev_warn(>udev->dev, "%s: Disabling MAC timed out\n",
+__func__);
+   ret = -EBUSY;
+   goto exit;
+   }
+
+exit:
+   return ret;
+}
+
+static int rtl8192eu_emu_to_disabled(struct rtl8xxxu_priv *priv)
+{
+   u8 val8;
+
+   /* 0x04[12:11] = 01 enable WL suspend */
+   val8 = rtl8xxxu_read8(priv, REG_APS_FSMCO + 1);
+   val8 &= ~(BIT(3) | BIT(4));
+   val8 |= BIT(3);
+   rtl8xxxu_write8(priv, REG_APS_FSMCO + 1, val8);
+
+   return 0;
+}
+
 static int rtl8192eu_power_on(struct rtl8xxxu_priv *priv)
 {
u16 val16;
@@ -1446,6 +1554,40 @@ exit:
return ret;
 }
 
+void rtl8192eu_power_off(struct rtl8xxxu_priv *priv)
+{
+   u8 val8;
+   u16 val16;
+
+   rtl8xxxu_flush_fifo(priv);
+
+   val8 = rtl8xxxu_read8(priv, REG_TX_REPORT_CTRL);
+   val8 &= ~TX_REPORT_CTRL_TIMER_ENABLE;
+   rtl8xxxu_write8(priv, REG_TX_REPORT_CTRL, val8);
+
+   /* Turn off RF */
+   rtl8xxxu_write8(priv, REG_RF_CTRL, 0x00);
+
+   rtl8192eu_active_to_lps(priv);
+
+   /* Reset Firmware if running in RAM */
+   if (rtl8xxxu_read8(priv, REG_MCU_FW_DL) & MCU_FW_RAM_SEL)
+   rtl8xxxu_firmware_self_reset(priv);
+
+   /* Reset MCU */
+   val16 = rtl8xxxu_read16(priv, REG_SYS_FUNC);
+   val16 &= ~SYS_FUNC_CPU_ENABLE;
+   rtl8xxxu_write16(priv, REG_SYS_FUNC, val16);
+
+   /* Reset MCU ready status */
+   rtl8xxxu_write8(priv, REG_MCU_FW_DL, 0x00);
+
+   rtl8xxxu_reset_8051(priv);
+
+   rtl8192eu_active_to_emu(priv);
+   rtl8192eu_emu_to_disabled(priv);
+}
+
 static void rtl8192e_enable_rf(struct rtl8xxxu_priv *priv)
 {
u32 

Re: ath10k mesh + ap + encryption?

[Martin Blumenstingl]

Hi Simon,

On Tue, Sep 13, 2016 at 1:13 PM, Simon Wunderlich  
wrote:
> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich  writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> >
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> >
>> > We also tested version 10.2.4.97 (from codeaurora), which is now default
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> >
>> > So here are my questions:
>> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
>> >  time?
>> >  * Do you have any pointers how we could fix this? Could it be fixable in
>> >  the>
>> > driver (i.e. not in firmware)?
>> >
>> >  * Does anyone have an idea if 11s will be supported in future versions? I
>> >
>> > didn't find any changelogs, but having 11s mode no longer in the service
>> > map does not make me optimistic.
>>
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
Thanks for clarifying this.

> This was introduced in December 25th, 2015 after some firmware-related
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
> 10.2.4/firmware-5.bin_10.2.4.97-1
I initially updated to version 10.2.4.70.13-2, but we decided to
update to the "latest" firmware back then (see the thread at [0])
With the explanation from Kalle it makes sense to only use the
firmware binaries distributed in his repo (to ensure that the firmware
is tested by QCA's internal team).

> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
> numbers.
That looks strange to me as well

as a side-note: I am currently preparing and testing a patch to update
the ath10k-firmware in LEDE to 10.2.4.70.52


Regards,
Martin


[0] https://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg35623.html

Re: [PATCH v4] cfg80211: Add support to configure a beacon data rate

[Johannes Berg]

Hi,

Thanks for the new version. I was going to apply it but while changing
something small - see below - found what I think is another issue?

> +static int validate_beacon_tx_rate(struct cfg80211_ap_settings
> *params)
> +{
> + u32 rate, count_ht, count_vht, i;
> + enum nl80211_band band;
> +
> + band = params->chandef.chan->band;
> + rate = params->beacon_rate.control[band].legacy;
> +
> + /* Allow only one rate */
> + if (rate && (rate & (rate - 1)))
> + return -EINVAL;

I was going to change that to just
if (hweight32(rate) > 1)
return -EINVAL;

I realize that your code is equivalent, but I doubt that we need to be
really efficient here, and IMHO hweight32() is easier to understand.

> + count_ht = 0;
> + for (i = 0; i < IEEE80211_HT_MCS_MASK_LEN; i++) {
> + if (params->beacon_rate.control[band].ht_mcs[i]) {
> + count_ht++;
> + if (count_ht > 1)
> + return -EINVAL;
> + }
> + }

But this is where I got confused - this seems wrong, you should be
checking the hweight8() of each of the ht_mcs[i] values?

Similarly, the VHT one, but with hweight16() of course, no?

I was going to move a "if (rate) return -EINVAL;" check into this and
the VHT loop, so that we only need the count_ht && count_vht and the
"all empty" portion of this:

> + if ((rate && count_ht) ||
> + (rate && count_vht) ||
> + (count_ht && count_vht) ||
> + (!rate && !count_ht && !count_vht))
> + return -EINVAL;
> +
> + return 0;
> +}


johannes

[PATCH] cfg80211: allow connect keys only with default (TX) key

[Johannes Berg]

From: Johannes Berg 

There's no point in allowing connect keys when one of them
isn't also configured as the TX key, it would just confuse
drivers and probably cause them to pick something for TX.
Disallow this confusing and erroneous configuration.

Signed-off-by: Johannes Berg 
---
 net/wireless/ibss.c | 5 -
 net/wireless/nl80211.c  | 5 +
 net/wireless/sme.c  | 3 +++
 net/wireless/wext-sme.c | 2 +-
 4 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 896cbb20b6e1..eafdfa5798ae 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -114,6 +114,9 @@ static int __cfg80211_join_ibss(struct 
cfg80211_registered_device *rdev,
}
}
 
+   if (WARN_ON(connkeys && connkeys->def < 0))
+   return -EINVAL;
+
if (WARN_ON(wdev->connect_keys))
kzfree(wdev->connect_keys);
wdev->connect_keys = connkeys;
@@ -289,7 +292,7 @@ int cfg80211_ibss_wext_join(struct 
cfg80211_registered_device *rdev,
 
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
 
-   if (wdev->wext.keys) {
+   if (wdev->wext.keys && wdev->wext.keys->def != -1) {
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8c6cbaac7d89..2036a47915d1 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -895,6 +895,11 @@ nl80211_parse_connkeys(struct cfg80211_registered_device 
*rdev,
*no_ht = true;
}
 
+   if (result->def < 0) {
+   err = -EINVAL;
+   goto error;
+   }
+
return result;
  error:
kfree(result);
diff --git a/net/wireless/sme.c b/net/wireless/sme.c
index add6824c44fd..c08a3b57dca1 100644
--- a/net/wireless/sme.c
+++ b/net/wireless/sme.c
@@ -1043,6 +1043,9 @@ int cfg80211_connect(struct cfg80211_registered_device 
*rdev,
connect->crypto.ciphers_pairwise[0] = cipher;
}
}
+   } else {
+   if (WARN_ON(connkeys))
+   return -EINVAL;
}
 
wdev->connect_keys = connkeys;
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index f6523a4387cc..88f1f6931ab8 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -42,7 +42,7 @@ int cfg80211_mgd_wext_connect(struct 
cfg80211_registered_device *rdev,
if (!wdev->wext.connect.ssid_len)
return 0;
 
-   if (wdev->wext.keys) {
+   if (wdev->wext.keys && wdev->wext.keys->def != -1) {
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
-- 
2.8.1

Re: brcmfmac43430-sdio.bin in linux-firmware

[Fabio Estevam]

Hi Arend,

On Wed, Aug 24, 2016 at 4:22 PM, Arend Van Spriel
 wrote:

> I could, but this is handled by Cypress now. I have asked for firmware
> release tag so I can release it.

Have you had a chance to release brcmfmac43430-sdio.bin?

Thanks!

Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8

[Johannes Berg]

> Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9)
> results in lower effective bitrate than just using MCS 8 (unless
> you're using 3 spatial streams).

Ah. I took a - very brief - look at why this one is invalid and
couldn't figure it out.

>  Sounds like a rate control or reporting bug then.
> Please drop this.
> 
Ok, thanks.

johannes

Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8

[Pedersen, Thomas]

On Mon, 2016-09-12 at 08:43 +0200, Johannes Berg wrote:
> On Wed, 2016-09-07 at 18:20 +, Pedersen, Thomas wrote:
> > 
> > On 09/06/2016 12:07 PM, Ben Greear wrote:
> > > 
> > > 
> > > On 09/06/2016 12:00 PM, Thomas Pedersen wrote:
> > > > 
> > > > 
> > > > Some drivers (ath10k) report MCS 9 @ 20MHz, which
> > > > technically isn't allowed. To get more meaningful value
> > > > than 0 out of this however, just cap the bitrate for 20MHz
> > > > to MCS 8.
> > > 
> > > If it is actually reporting MCS9, why lie about it?  Report it up
> > > the stack as a proper value instead of hiding the issue?
> > 
> > Good point, will send a v2 extrapolating the value to 86.5Mb/s.
> 
> That makes no sense either, IMHO.
> 
> Are you saying that ath10k actually somehow manages to use an invalid
> bitrate over the air?!
> 
> It seems more likely that it's actually just misreporting what it's
> doing, and thus the issue should be fixed in ath10k.

Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9) results
in lower effective bitrate than just using MCS 8 (unless you're using 3
spatial streams). Sounds like a rate control or reporting bug then.
Please drop this.

Thanks,
Thomas

Re: ath10k mesh + ap + encryption?

[Pedersen, Thomas]

On Tue, 2016-09-13 at 14:30 +0200, Simon Wunderlich wrote:
> On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote:
> > 
> > Simon Wunderlich  writes:
> > > 
> > > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle
> > > wrote:
> > > > 
> > > > Simon Wunderlich  writes:
> > > > > 
> > > > > we have done some experiments last week on ath10k, trying to
> > > > > run mesh
> > > > > (802.11s) and access point at the same time, both encrypted.
> > > > > 
> > > > > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> > > > > firmware-5.bin_10.2.4.70.42-2 and the included
> > > > > wpa_supplicant, which
> > > > > gave
> > > > > us a working encrypted 802.11s network. However, starting an
> > > > > AP at the
> > > > > same time didn't work (AP doesn't beacon). This wasn't a
> > > > > problem when
> > > > > 802.11s was running unencrypted.
> > > > > 
> > > > > We also tested version 10.2.4.97 (from codeaurora), which is
> > > > > now
> > > > > default
> > > > > in
> > > > > LEDE. However, this version apparently doesn't support 11s
> > > > > mesh at all
> > > > > (WMI_SERVICE_MESH_11S is disabled in the service map, but
> > > > > cfg/mac80211
> > > > > advertises support).
> > > > > 
> > > > > So here are my questions:
> > > > >  * Did anyone succesfully run AP and mesh, both encrypted at
> > > > > the same
> > > > >  time?
> > > > >  * Do you have any pointers how we could fix this? Could it
> > > > > be fixable
> > > > >  in
> > > > >  the>
> > > > > 
> > > > > driver (i.e. not in firmware)?
> > > > > 
> > > > >  * Does anyone have an idea if 11s will be supported in
> > > > > future
> > > > >  versions? I
> > > > > 
> > > > > didn't find any changelogs, but having 11s mode no longer in
> > > > > the
> > > > > service
> > > > > map does not make me optimistic.
> > > > 
> > > > Why is LEDE using 10.2.4.97? It seems to be a quite old release
> > > > and I
> > > > have no knowledge if anyone even tests that firmware branch
> > > > with ath10k.
> > > > I recommend to only use firmware releases from ath10k-
> > > > firmware.git as we
> > > > use those internally with ath10k. In any case, don't make any
> > > > assumptions about future from that firmware branch as it's so
> > > > old.
> > > 
> > > This was introduced in December 25th, 2015 after some firmware-
> > > related
> > > problems. I'm CC'ing Martin Blumenstingl who suggested this
> > > change.
> > > 
> > > Since then, ath10k is pulling firmware from here (unless ct
> > > firmware is
> > > used):
> > > 
> > > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmw
> > > are/plain
> > > /
> > > 10.2.4/firmware-5.bin_10.2.4.97-1
> > > 
> > > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70,
> > > but you
> > > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise
> > > from
> > > the numbers. However, 10.2.4.70 has much more sub-revisions.
> > 
> > As I said before, I just deliver the firmware files to the
> > community and
> > the firmware team creates the actual releases. But my understanding
> > is
> > that these are from different branches which are built
> > independently
> > (and might have different features, like in this case the mesh
> > support)
> > so I would not make any conclusions if any firmware is "better"
> > just
> > from the numbers alone.
> 
> you are right ... those numbers are not a good pointer. I found this
> repo, and 
> from the checkin dates it looks like 10.2.4.97 is indeed way older
> (from 
> September 2015) than 10.2.4.70.42 (April 2016):
> 
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/
> log/10.2.4
> 
> I would agree that Changelogs would be helpful.
> 
> Thanks for the clarification. We will then stick to the 70's branch
> then.
> 
> Does anyone have pointers for the other questions? :) I would believe
> hat many 
> people would be interested in running AP + Mesh encrypted at the same
> time (at 
> least in the open source community ...).

We're testing encrypted AP + Mesh quite successfully right now with
this firmware: https://github.com/kvalo/ath10k-firmware/commit/307cb46b
06661ebd3186723b5002de769c7add83, of course that is for a QCA4019 chip.
Which chip are you using? I can poke the firmware guys for possibility
of getting a 10.4.3.2 firmware build for it.

thomas

Re: pull-request mwifiex-firmware 2015-09-12

[Kyle McMartin]

On Mon, Sep 12, 2016 at 12:40:23PM +, Amitkumar Karwar wrote:
> The following changes since commit e92f8b3f65443764297b947b1843955d9a65dde7:
> 
>   linux-firmware: update Marvell USB8797-B0 firmware image (2015-11-02 
> 06:25:05 -0500)
> 
> are available in the git repository at:
> 
>   git://git.marvell.com/mwifiex-firmware.git master
> 
> for you to fetch changes up to 1e0f28ad5a26b2c86e55dbad3141b2ec2de804f7:
> 
>   linux-firmware: update WHENCE file for Marvell firmware versions 
> (2016-09-12 17:12:42 +0530)
> 

Pulled, thanks.

--Kyle

[PATCH 3/6] nl80211: only allow WEP keys during connect command

[Johannes Berg]

From: Johannes Berg 

This was already documented that way in nl80211.h, but the
parsing code still accepted other key types. Change it to
really only accept WEP keys as documented.

Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 6fe14b5d1af3..739d0a780d83 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -881,16 +881,19 @@ nl80211_parse_connkeys(struct cfg80211_registered_device 
*rdev,
 parse.idx, false, NULL);
if (err)
goto error;
+   if (parse.p.cipher != WLAN_CIPHER_SUITE_WEP40 &&
+   parse.p.cipher != WLAN_CIPHER_SUITE_WEP104) {
+   err = -EINVAL;
+   goto error;
+   }
result->params[parse.idx].cipher = parse.p.cipher;
result->params[parse.idx].key_len = parse.p.key_len;
result->params[parse.idx].key = result->data[parse.idx];
memcpy(result->data[parse.idx], parse.p.key, parse.p.key_len);
 
-   if (parse.p.cipher == WLAN_CIPHER_SUITE_WEP40 ||
-   parse.p.cipher == WLAN_CIPHER_SUITE_WEP104) {
-   if (no_ht)
-   *no_ht = true;
-   }
+   /* must be WEP key if we got here */
+   if (no_ht)
+   *no_ht = true;
}
 
return result;
-- 
2.8.1

Re: Support of rtl8723bs

[Larry Finger]

On 09/13/2016 02:47 AM, Hanno Zulla wrote:

Hi,


The issues I am aware of is to start out changing the register access
macros into function pointers and stick them all into the fileops
structure. Provide a set of SDIO ones to match the USB ones. Then you
will need some code to detect the device, as that part will obviously be
different from the USB device detection.

I know there are a few issues to look out for in the hw register init
files to look out for too, that does some special casing for SDIO, but
that should be limited. I am happy to point someone in the right
direction on that when they get to that.


I had a brief look into the sources of other drivers implementing SDIO,
but not being a kernel-dev, this is out of my league.

If you decide to reprioritize your TODO-List in favour of adding SDIO
sooner, I'll be gladly testing this for you on my hardware (and buy you
a beer).


I received a CherryTrail z8300 device yesterday with RTL8723BS wifi and BT. I 
have started making the changes that Jes suggested. Once I get something 
running, I will post patches here for review, and I will also make them 
available in Bastien's repo.


I make no promises on when anything will be available.

Larry

[PATCH 4/6] cfg80211: wext: only allow WEP keys to be configured before connected

[Johannes Berg]

From: Johannes Berg 

When not connected, anything but WEP keys shouldn't be allowed to be
configured for later - only static WEP keys make sense at this point.
Change wext to reject anything else just like nl80211 does.

Signed-off-by: Johannes Berg 
---
 net/wireless/wext-compat.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index 9f27221c8913..e45a76449b43 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -487,6 +487,9 @@ static int __cfg80211_set_encryption(struct 
cfg80211_registered_device *rdev,
err = 0;
if (wdev->current_bss)
err = rdev_add_key(rdev, dev, idx, pairwise, addr, params);
+   else if (params->cipher != WLAN_CIPHER_SUITE_WEP40 &&
+params->cipher != WLAN_CIPHER_SUITE_WEP104)
+   return -EINVAL;
if (err)
return err;
 
-- 
2.8.1

[PATCH 5/6] cfg80211: validate key index better

[Johannes Berg]

From: Johannes Berg 

Don't accept it if a key_idx < 0 snuck through, reject WEP keys with
key index 4 and 5 (which are used for IGTKs) and don't allow IGTKs
with key indices other than 4 and 5. This makes the key data match
expectations better.

Signed-off-by: Johannes Berg 
---
 net/wireless/util.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/net/wireless/util.c b/net/wireless/util.c
index 0675f513e7b9..81fa16b36d30 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -218,7 +218,7 @@ int cfg80211_validate_key_settings(struct 
cfg80211_registered_device *rdev,
   struct key_params *params, int key_idx,
   bool pairwise, const u8 *mac_addr)
 {
-   if (key_idx > 5)
+   if (key_idx < 0 || key_idx > 5)
return -EINVAL;
 
if (!pairwise && mac_addr && !(rdev->wiphy.flags & WIPHY_FLAG_IBSS_RSN))
@@ -249,7 +249,13 @@ int cfg80211_validate_key_settings(struct 
cfg80211_registered_device *rdev,
/* Disallow BIP (group-only) cipher as pairwise cipher */
if (pairwise)
return -EINVAL;
+   if (key_idx < 4)
+   return -EINVAL;
break;
+   case WLAN_CIPHER_SUITE_WEP40:
+   case WLAN_CIPHER_SUITE_WEP104:
+   if (key_idx < 0 || key_idx > 3)
+   return -EINVAL;
default:
break;
}
-- 
2.8.1

[PATCH 2/6] nl80211: fix connect keys range check

[Johannes Berg]

From: Johannes Berg 

Only key index 0-3 should be accepted, 4/5 are for IGTKs and
cannot be used as connect keys. Fix the range checking to not
allow such erroneous configurations.

Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index c96e22b906af..6fe14b5d1af3 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -866,7 +866,7 @@ nl80211_parse_connkeys(struct cfg80211_registered_device 
*rdev,
err = -EINVAL;
if (!parse.p.key)
goto error;
-   if (parse.idx < 0 || parse.idx > 4)
+   if (parse.idx < 0 || parse.idx > 3)
goto error;
if (parse.def) {
if (def)
-- 
2.8.1

[PATCH 1/6] cfg80211: disallow shared key authentication with key index 4

[Johannes Berg]

From: Johannes Berg 

Key index 4 can only be used for an IGTK, so the range checks
for shared key authentication should treat 4 as an error, fix
that in the code.

Signed-off-by: Johannes Berg 
---
 net/wireless/mlme.c| 2 +-
 net/wireless/nl80211.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index c284d883c349..d6abb0704db5 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ int cfg80211_mlme_auth(struct cfg80211_registered_device 
*rdev,
ASSERT_WDEV_LOCK(wdev);
 
if (auth_type == NL80211_AUTHTYPE_SHARED_KEY)
-   if (!key || !key_len || key_idx < 0 || key_idx > 4)
+   if (!key || !key_len || key_idx < 0 || key_idx > 3)
return -EINVAL;
 
if (wdev->current_bss &&
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 83c6445ebf33..c96e22b906af 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7388,7 +7388,7 @@ static int nl80211_authenticate(struct sk_buff *skb, 
struct genl_info *info)
(key.p.cipher != WLAN_CIPHER_SUITE_WEP104 ||
 key.p.key_len != WLAN_KEY_LEN_WEP104))
return -EINVAL;
-   if (key.idx > 4)
+   if (key.idx > 3)
return -EINVAL;
} else {
key.p.key_len = 0;
-- 
2.8.1

[PATCH 6/6] cfg80211: reduce connect key caching struct size

[Johannes Berg]

From: Johannes Berg 

After the previous patches, connect keys can only (correctly)
be used for storing static WEP keys. Therefore, remove all the
data for dealing with key index 4/5 and reduce the size of the
key material to the maximum for WEP keys.

Signed-off-by: Johannes Berg 
---
 net/wireless/core.h| 6 +++---
 net/wireless/ibss.c| 6 ++
 net/wireless/nl80211.c | 1 -
 net/wireless/util.c| 5 +
 net/wireless/wext-compat.c | 6 +++---
 net/wireless/wext-sme.c| 3 +--
 6 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/net/wireless/core.h b/net/wireless/core.h
index eee91443924d..e3c13ae9 100644
--- a/net/wireless/core.h
+++ b/net/wireless/core.h
@@ -249,9 +249,9 @@ struct cfg80211_event {
 };
 
 struct cfg80211_cached_keys {
-   struct key_params params[6];
-   u8 data[6][WLAN_MAX_KEY_LEN];
-   int def, defmgmt;
+   struct key_params params[4];
+   u8 data[4][WLAN_KEY_LEN_WEP104];
+   int def;
 };
 
 enum cfg80211_chan_mode {
diff --git a/net/wireless/ibss.c b/net/wireless/ibss.c
index 4a4dda53bdf1..896cbb20b6e1 100644
--- a/net/wireless/ibss.c
+++ b/net/wireless/ibss.c
@@ -284,10 +284,8 @@ int cfg80211_ibss_wext_join(struct 
cfg80211_registered_device *rdev,
if (!netif_running(wdev->netdev))
return 0;
 
-   if (wdev->wext.keys) {
+   if (wdev->wext.keys)
wdev->wext.keys->def = wdev->wext.default_key;
-   wdev->wext.keys->defmgmt = wdev->wext.default_mgmt_key;
-   }
 
wdev->wext.ibss.privacy = wdev->wext.default_key != -1;
 
@@ -295,7 +293,7 @@ int cfg80211_ibss_wext_join(struct 
cfg80211_registered_device *rdev,
ck = kmemdup(wdev->wext.keys, sizeof(*ck), GFP_KERNEL);
if (!ck)
return -ENOMEM;
-   for (i = 0; i < 6; i++)
+   for (i = 0; i < 4; i++)
ck->params[i].key = ck->data[i];
}
err = __cfg80211_join_ibss(rdev, wdev->netdev,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 739d0a780d83..8c6cbaac7d89 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -854,7 +854,6 @@ nl80211_parse_connkeys(struct cfg80211_registered_device 
*rdev,
return ERR_PTR(-ENOMEM);
 
result->def = -1;
-   result->defmgmt = -1;
 
nla_for_each_nested(key, keys, rem) {
memset(, 0, sizeof(parse));
diff --git a/net/wireless/util.c b/net/wireless/util.c
index 81fa16b36d30..dea2398329c4 100644
--- a/net/wireless/util.c
+++ b/net/wireless/util.c
@@ -912,7 +912,7 @@ void cfg80211_upload_connect_keys(struct wireless_dev *wdev)
if (!wdev->connect_keys)
return;
 
-   for (i = 0; i < 6; i++) {
+   for (i = 0; i < 4; i++) {
if (!wdev->connect_keys->params[i].cipher)
continue;
if (rdev_add_key(rdev, dev, i, false, NULL,
@@ -925,9 +925,6 @@ void cfg80211_upload_connect_keys(struct wireless_dev *wdev)
netdev_err(dev, "failed to set defkey %d\n", i);
continue;
}
-   if (wdev->connect_keys->defmgmt == i)
-   if (rdev_set_default_mgmt_key(rdev, dev, i))
-   netdev_err(dev, "failed to set mgtdef %d\n", i);
}
 
kzfree(wdev->connect_keys);
diff --git a/net/wireless/wext-compat.c b/net/wireless/wext-compat.c
index e45a76449b43..7b97d43b27e1 100644
--- a/net/wireless/wext-compat.c
+++ b/net/wireless/wext-compat.c
@@ -408,10 +408,10 @@ static int __cfg80211_set_encryption(struct 
cfg80211_registered_device *rdev,
 
if (!wdev->wext.keys) {
wdev->wext.keys = kzalloc(sizeof(*wdev->wext.keys),
- GFP_KERNEL);
+ GFP_KERNEL);
if (!wdev->wext.keys)
return -ENOMEM;
-   for (i = 0; i < 6; i++)
+   for (i = 0; i < 4; i++)
wdev->wext.keys->params[i].key =
wdev->wext.keys->data[i];
}
@@ -460,7 +460,7 @@ static int __cfg80211_set_encryption(struct 
cfg80211_registered_device *rdev,
if (err == -ENOENT)
err = 0;
if (!err) {
-   if (!addr) {
+   if (!addr && idx < 4) {
memset(wdev->wext.keys->data[idx], 0,
   sizeof(wdev->wext.keys->data[idx]));
wdev->wext.keys->params[idx].key_len = 0;
diff --git a/net/wireless/wext-sme.c b/net/wireless/wext-sme.c
index a4e8af3321d2..f6523a4387cc 100644
--- a/net/wireless/wext-sme.c
+++ b/net/wireless/wext-sme.c
@@ -35,7 +35,6 @@ int 

[PATCH] cfg80211: disallow shared key authentication with key index 4

[Johannes Berg]

From: Johannes Berg 

Key index 4 can only be used for an IGTK, so the range checks
for shared key authentication should treat 4 as an error, fix
that in the code.

Signed-off-by: Johannes Berg 
---
 net/wireless/mlme.c| 2 +-
 net/wireless/nl80211.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/mlme.c b/net/wireless/mlme.c
index c284d883c349..d6abb0704db5 100644
--- a/net/wireless/mlme.c
+++ b/net/wireless/mlme.c
@@ -222,7 +222,7 @@ int cfg80211_mlme_auth(struct cfg80211_registered_device 
*rdev,
ASSERT_WDEV_LOCK(wdev);
 
if (auth_type == NL80211_AUTHTYPE_SHARED_KEY)
-   if (!key || !key_len || key_idx < 0 || key_idx > 4)
+   if (!key || !key_len || key_idx < 0 || key_idx > 3)
return -EINVAL;
 
if (wdev->current_bss &&
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index aca8f820d155..739d0a780d83 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -7391,7 +7391,7 @@ static int nl80211_authenticate(struct sk_buff *skb, 
struct genl_info *info)
(key.p.cipher != WLAN_CIPHER_SUITE_WEP104 ||
 key.p.key_len != WLAN_KEY_LEN_WEP104))
return -EINVAL;
-   if (key.idx > 4)
+   if (key.idx > 3)
return -EINVAL;
} else {
key.p.key_len = 0;
-- 
2.8.1

Re: [PATCH 2/2] ath10k: add platform regulatory domain support

[Bartosz Markowski]

On 12 September 2016 at 17:35, Valo, Kalle  wrote:

[...]

> > +#ifdef CONFIG_ACPI
> > +#define WRD_METHOD "WRDD"
> > +#define WRDD_WIFI  (0x07)
> > +
> > +static u32 ath10k_mac_wrdd_get_mcc(struct ath10k *ar, union acpi_object 
> > *wrdd)
> > +{
>
> I don't think the ifdef is really necessary, acpi.h should handle that
> (hopefully). Also I changed the error handling to use standard error
> values and changed the info messages to dbg, they are too spammy in my
> opinion. Please check carefully my changes in the pending branch:
>
> https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/?h=pending=fe91745381ec3999d8de6dedb07b396c82539717

I'm OK with the changes, I have not tried that though, except of
reviewing and compiling it (do not have access to the chromebook for
next few days). If you want to wait with it until I test it, it's fine
too.

Bartosz

[PATCH] nl80211: validate number of probe response CSA counters

[Johannes Berg]

From: Johannes Berg 

Due to an apparent copy/paste bug, the number of counters for the
beacon configuration were checked twice, instead of checking the
number of probe response counters. Fix this to check the number of
probe response counters before parsing those.

Signed-off-by: Johannes Berg 
---
 net/wireless/nl80211.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ef234d2fd854..a65c94f202f8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -6998,7 +6998,7 @@ static int nl80211_channel_switch(struct sk_buff *skb, 
struct genl_info *info)
 
params.n_counter_offsets_presp = len / sizeof(u16);
if (rdev->wiphy.max_num_csa_counters &&
-   (params.n_counter_offsets_beacon >
+   (params.n_counter_offsets_presp >
 rdev->wiphy.max_num_csa_counters))
return -EINVAL;
 
-- 
2.8.1

[PATCH] mac80211: remove useless open_count check

[Johannes Berg]

From: Johannes Berg 

__ieee80211_suspend() checks early on if there's anything
to do by checking open_count, so there's no need to check
again later in the function. Remove the useless check.

Signed-off-by: Johannes Berg 
---
 net/mac80211/pm.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/net/mac80211/pm.c b/net/mac80211/pm.c
index 00a43a70e1fc..28a3a0957c9e 100644
--- a/net/mac80211/pm.c
+++ b/net/mac80211/pm.c
@@ -178,8 +178,7 @@ int __ieee80211_suspend(struct ieee80211_hw *hw, struct 
cfg80211_wowlan *wowlan)
WARN_ON(!list_empty(>chanctx_list));
 
/* stop hardware - this must stop RX */
-   if (local->open_count)
-   ieee80211_stop_device(local);
+   ieee80211_stop_device(local);
 
  suspend:
local->suspended = true;
-- 
2.8.1

FW: {SOLVED }RE: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )

[Merchut, Addison]

From: Merchut, Addison 
Sent: Tuesday, September 13, 2016 7:51 AM
To: 'linuxw...@intel.com' ; 
'linux-wireless@vger.kernel.org' 
Cc: Nudo, Al ; Unetich, Rich ; DeCarlo, 
Bob 
Subject: {SOLVED }RE: Only one of two Intel Wireless 7260 PCI Cards are 
assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )

I have solved this issue after finding this page: 
https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi/core_release
Thank you for your documentation. It is very friendly and easy to read. 

If I may, I suggest that you please point 
https://wireless.wiki.kernel.org/en/users/Drivers/iwlwifi to the core_release 
page in some equally friendly way. 

Thanks again, and keep up the great work .

From: Merchut, Addison 
Sent: Monday, September 12, 2016 3:21 PM
To: 'linuxw...@intel.com' ; 
'linux-wireless@vger.kernel.org' 
Cc: Nudo, Al ; Unetich, Rich ; DeCarlo, 
Bob 
Subject: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical 
name (ubuntu 16.04 :: 4.7.0-040700-generic )

I believe I have an issue with the Intel wireless 7260 pci cards on my linux 
desktop

I have two wireless cards on a test PC I'm working on. And while I can see both 
cards, only the top card (in the physical location) is actually getting 
assigned the logical (interface) name.

This seems to be interment (though I've only had this computer running for two 
days) because there has been at least one occasion that I have seen both cards 
assigned an interface name at the same time (via ifconfig and NM). However, 
when I've had to restart the computer, the names are not always assigned for 
the 2nd (bottom) card -this is the case most of the time. 

Attached is the dmesg for the case where I was able to get both cards to work 
(dm.txt) and the case where I am not able to get both cards to work (dmbad.txt)

I've switched out the cards (with other 7260 cards), move the cards to other 
locations, exchanged the locations of the cards, BUT only the top most device 
is ever assigned the an interface name.
I'm running: 4.7.0-040700-generic GNU/Linux Ubuntu 16.04.1 LTS

The two cards are the same Intel Corporation Wireless 7260:
# cat /sys/bus/pci/devices/\:01\:00.0/uevent 
    DRIVER=iwlwifi
    PCI_CLASS=28000
    PCI_ID=8086:08B1
    PCI_SUBSYS_ID=8086:4070
    PCI_SLOT_NAME=:01:00.0
    MODALIAS=pci:v8086d08B1sv8086sd4070bc02sc80i00
# cat /sys/bus/pci/devices/\:02\:00.0/uevent 
    DRIVER=iwlwifi
    PCI_CLASS=28000
    PCI_ID=8086:08B1
    PCI_SUBSYS_ID=8086:4070
    PCI_SLOT_NAME=:02:00.0
    MODALIAS=pci:v8086d08B1sv8086sd4070bc02sc80i00

Only one of the devices is getting assigned a logical name:
#sudo lshw -class network
      
      *-network   
       description: Wireless interface
       product: Wireless 7260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@:01:00.0
       logical name: wlp1s0
       version: 73
       serial: 7c:5c:f8:d2:6c:52
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list 
ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi 
driverversion=4.7.0-040700-generic firmware=16.242414.0 latency=0 link=no 
multicast=yes wireless=IEEE 802.11
       resources: irq:32 memory:f7d0-f7d01fff
      *-network
       description: Network controller
       product: Wireless 7260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@:02:00.0
       version: 73
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list
       configuration: driver=iwlwifi latency=0
       resources: irq:33 memory:f7c0-f7c01fff



dmesg does not show that the 2nd device on bus :02:00.0 has been detected 
by the wifi driver

{Attached as dmbad.txt}


and ifconfig only shows one device (obviously since lshw showed that only one 
was getting assigned a logical name)

#ifconfig 
...
      wlp1s0    Link encap:Ethernet  HWaddr 7c:5c:f8:d2:6c:52  
    UP BROADCAST MULTICAST  MTU:1500  Metric:1
        RX packets:0 errors:0 dropped:0 

Re: [PATCH] ath10k: Spelling and miscellaneous neatening

[Valo, Kalle]

Joe Perches  writes:

> Correct some trivial comment typos.
> Remove unnecessary parentheses in a long line.
> Convert a return; before the end of a void function definition to just ;
>
> Signed-off-by: Joe Perches 

[...]

> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -2118,7 +2118,7 @@ err:
>   /* TODO: It's probably a good idea to release device from the driver
>* but calling device_release_driver() here will cause a deadlock.
>*/
> - return;
> + ;
>  }

I don't think this improves anything, I dropped this part from the patch
in my pending branch.

-- 
Kalle Valo

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Tuesday, September 13, 2016 11:25:21 AM CEST Valo, Kalle wrote:
> Simon Wunderlich  writes:
> > On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> >> Simon Wunderlich  writes:
> >> > we have done some experiments last week on ath10k, trying to run mesh
> >> > (802.11s) and access point at the same time, both encrypted.
> >> > 
> >> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> >> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which
> >> > gave
> >> > us a working encrypted 802.11s network. However, starting an AP at the
> >> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> >> > 802.11s was running unencrypted.
> >> > 
> >> > We also tested version 10.2.4.97 (from codeaurora), which is now
> >> > default
> >> > in
> >> > LEDE. However, this version apparently doesn't support 11s mesh at all
> >> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> >> > advertises support).
> >> > 
> >> > So here are my questions:
> >> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >> >  time?
> >> >  * Do you have any pointers how we could fix this? Could it be fixable
> >> >  in
> >> >  the>
> >> > 
> >> > driver (i.e. not in firmware)?
> >> > 
> >> >  * Does anyone have an idea if 11s will be supported in future
> >> >  versions? I
> >> > 
> >> > didn't find any changelogs, but having 11s mode no longer in the
> >> > service
> >> > map does not make me optimistic.
> >> 
> >> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> >> have no knowledge if anyone even tests that firmware branch with ath10k.
> >> I recommend to only use firmware releases from ath10k-firmware.git as we
> >> use those internally with ath10k. In any case, don't make any
> >> assumptions about future from that firmware branch as it's so old.
> > 
> > This was introduced in December 25th, 2015 after some firmware-related
> > problems. I'm CC'ing Martin Blumenstingl who suggested this change.
> > 
> > Since then, ath10k is pulling firmware from here (unless ct firmware is
> > used):
> > 
> > https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain
> > /
> > 10.2.4/firmware-5.bin_10.2.4.97-1
> > 
> > However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you
> > say 10.2.4.70.42-2 is more recent? I would have assumed otherwise from
> > the numbers. However, 10.2.4.70 has much more sub-revisions.
> 
> As I said before, I just deliver the firmware files to the community and
> the firmware team creates the actual releases. But my understanding is
> that these are from different branches which are built independently
> (and might have different features, like in this case the mesh support)
> so I would not make any conclusions if any firmware is "better" just
> from the numbers alone.

you are right ... those numbers are not a good pointer. I found this repo, and 
from the checkin dates it looks like 10.2.4.97 is indeed way older (from 
September 2015) than 10.2.4.70.42 (April 2016):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/log/10.2.4

I would agree that Changelogs would be helpful.

Thanks for the clarification. We will then stick to the 70's branch then.

Does anyone have pointers for the other questions? :) I would believe hat many 
people would be interested in running AP + Mesh encrypted at the same time (at 
least in the open source community ...).

Thanks,
  Simon

signature.asc
Description: This is a digitally signed message part.

Re: [3/3] ath10k: Improve logging message.

[Kalle Valo]

Ben Greear  wrote:
> From: Ben Greear 
> 
> Helps to know the sta pointer.
> 
> Signed-off-by: Ben Greear 

Thanks, 1 patch applied to ath-next branch of ath.git:

3040420158c1 ath10k: improve logging message

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9289043/

[ANNOUNCE] netdev 1.2 tokyo weekly update (13th September, 2016)

[Hajime Tazaki]

Hello folks,

I hope you're fine and ready to trip to Tokyo.

Here is an weekly update of Netdev 1.2 Tokyo.

== Keynote talk ==

We confirmed that David Miller will give a keynote titled
"Fast Programmable Networks & Encapsulated Protocols".


== Newly accepted sessions ==

We also accepted one additional talk in the last week.

- Network interface configuration on a Linux NOS
  by Roopa Prabhu

Full list of accepted sessions is available here.

http://netdevconf.org/1.2/accepted-sessions.html


== Our sponsors ==

We got new sponsors, Cisco as a Gold sponsor, LWN.net as a
Media sponsor.  Many thanks for your support.

- Platinum
Verizon, Facebook, Cumulus Networks
- Gold
Mojatatu Networks, VMWare, Google, NTT, LinkedIn, Cisco (new)
- Silver
NetApp, IIJ, Netronome, SolarFlare, Mellanox, Sophos
- Bronze
Zen Load Balancer
- Media Sponsor
lwn.net (new)

Twitter: https://twitter.com/netdev01
Web: http://netdevconf.org/1.2/


== Others ==

Be prepared for your travel. Hotel and travel information
are available on the web pages.

http://netdevconf.org/1.2/travel.html
http://netdevconf.org/1.2/hotel.html

The early bird tickets is still available until 15th.
Please be registered - your early registration is always
helpful to organize a great conference.

http://netdevconf.org/1.2/registration.html


Looking forward to seeing you in Tokyo very soon.

-- Hajime

Re: ath10k: remove unused variable ar_pci

[Kalle Valo]

Chaehyun Lim  wrote:
> Trival fix to remove unused variable ar_pci in ath10k_pci_tx_pipe_cleanup
> when building with W=1:
> drivers/net/wireless/ath/ath10k/pci.c:1696:21: warning: variable
> 'ar_pci' set but not used [-Wunused-but-set-variable]
> 
> Signed-off-by: Chaehyun Lim 

Thanks, 1 patch applied to ath-next branch of ath.git:

214d55394481 ath10k: remove unused variable ar_pci

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9313963/

Re: ath10k: enable peer stats by default

[Kalle Valo]

"Pedersen, Thomas"  wrote:
> IFTYPE_MESH_POINT need to rely on these for accurate path
> selection metrics. Other modes will probably also find
> them useful. Enabling peer stats has the side effect of
> reducing max number of STAs from 128 to 118. There should
> be negligible performance impact.
> 
> If users really need 128 STAs and don't mind losing out on
> peer stats, they can still disable them:
> 
> echo 0 > debugfs/ieee80211/phyn/ath10k/peer_stats
> 
> Signed-off-by: Thomas Pedersen 

Thanks, 1 patch applied to ath-next branch of ath.git:

8c1d7fa53166 ath10k: enable peer stats by default

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9317865/

Re: [V2] ath10k: fix memory leak on caldata on error exit path

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> caldata is not being free'd on the error exit path, causing
> a memory leak and data definitely should not be freed. Free
> caldata instead of data.
> 
> Thanks to Kalle Valo for spotting that data should not be
> free'd.
> 
> Signed-off-by: Colin Ian King 

Thanks, 1 patch applied to ath-next branch of ath.git:

5f4761dda2ba ath10k: fix memory leak on caldata on error exit path

-- 
Sent by pwcli
https://patchwork.kernel.org/patch/9312163/

FW: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical name (ubuntu 16.04 :: 4.7.0-040700-generic )

[Merchut, Addison]

From: Merchut, Addison 
Sent: Monday, September 12, 2016 3:21 PM
To: 'linuxw...@intel.com' ; 
'linux-wireless@vger.kernel.org' 
Cc: Nudo, Al ; Unetich, Rich ; DeCarlo, 
Bob 
Subject: Only one of two Intel Wireless 7260 PCI Cards are assigned a logical 
name (ubuntu 16.04 :: 4.7.0-040700-generic )

I believe I have an issue with the Intel wireless 7260 pci cards on my linux 
desktop

I have two wireless cards on a test PC I'm working on. And while I can see both 
cards, only the top card (in the physical location) is actually getting 
assigned the logical (interface) name.

This seems to be interment (though I've only had this computer running for two 
days) because there has been at least one occasion that I have seen both cards 
assigned an interface name at the same time (via ifconfig and NM). However, 
when I've had to restart the computer, the names are not always assigned for 
the 2nd (bottom) card -this is the case most of the time. 

Attached is the dmesg for the case where I was able to get both cards to work 
(dm.txt) and the case where I am not able to get both cards to work (dmbad.txt)

I've switched out the cards (with other 7260 cards), move the cards to other 
locations, exchanged the locations of the cards, BUT only the top most device 
is ever assigned the an interface name.
I'm running: 4.7.0-040700-generic GNU/Linux Ubuntu 16.04.1 LTS

The two cards are the same Intel Corporation Wireless 7260:
# cat /sys/bus/pci/devices/\:01\:00.0/uevent 
    DRIVER=iwlwifi
    PCI_CLASS=28000
    PCI_ID=8086:08B1
    PCI_SUBSYS_ID=8086:4070
    PCI_SLOT_NAME=:01:00.0
    MODALIAS=pci:v8086d08B1sv8086sd4070bc02sc80i00
# cat /sys/bus/pci/devices/\:02\:00.0/uevent 
    DRIVER=iwlwifi
    PCI_CLASS=28000
    PCI_ID=8086:08B1
    PCI_SUBSYS_ID=8086:4070
    PCI_SLOT_NAME=:02:00.0
    MODALIAS=pci:v8086d08B1sv8086sd4070bc02sc80i00

Only one of the devices is getting assigned a logical name:
#sudo lshw -class network
      
      *-network   
       description: Wireless interface
       product: Wireless 7260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@:01:00.0
       logical name: wlp1s0
       version: 73
       serial: 7c:5c:f8:d2:6c:52
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list 
ethernet physical wireless
       configuration: broadcast=yes driver=iwlwifi 
driverversion=4.7.0-040700-generic firmware=16.242414.0 latency=0 link=no 
multicast=yes wireless=IEEE 802.11
       resources: irq:32 memory:f7d0-f7d01fff
      *-network
       description: Network controller
       product: Wireless 7260
       vendor: Intel Corporation
       physical id: 0
       bus info: pci@:02:00.0
       version: 73
       width: 64 bits
       clock: 33MHz
       capabilities: pm msi pciexpress bus_master cap_list
       configuration: driver=iwlwifi latency=0
       resources: irq:33 memory:f7c0-f7c01fff



dmesg does not show that the 2nd device on bus :02:00.0 has been detected 
by the wifi driver

{Attached as dmbad.txt}


and ifconfig only shows one device (obviously since lshw showed that only one 
was getting assigned a logical name)

#ifconfig 
...
      wlp1s0    Link encap:Ethernet  HWaddr 7c:5c:f8:d2:6c:52  
    UP BROADCAST MULTICAST  MTU:1500  Metric:1
        RX packets:0 errors:0 dropped:0 overruns:0 
frame:0
        TX packets:0 errors:0 dropped:0 overruns:0 
carrier:0
        collisions:0 txqueuelen:1000 
    RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)


#ls /lib/firmware | grep 7260
    iwlwifi-7260-10.ucode
    iwlwifi-7260-12.ucode
    iwlwifi-7260-13.ucode
    iwlwifi-7260-14.ucode
    iwlwifi-7260-16.ucode
    iwlwifi-7260-7.ucode
    iwlwifi-7260-8.ucode
    iwlwifi-7260-9.ucode

#modinfo iwlwifi
      filename:   
/lib/modules/4.7.0-040700-generic/kernel/drivers/net/wireless/intel/iwlwifi/iwlwifi.ko
      license:    GPL
      author: Copyright(c) 2003- 2015 Intel 

Re: ath10k mesh + ap + encryption?

[Sebastian Gottschall]

Am 13.09.2016 um 13:25 schrieb Valo, Kalle:

Simon Wunderlich  writes:


On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:

Simon Wunderlich  writes:

we have done some experiments last week on ath10k, trying to run mesh
(802.11s) and access point at the same time, both encrypted.

We have tested a recent LEDE (reboot-1519-g42f559e) but with
firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
us a working encrypted 802.11s network. However, starting an AP at the
same time didn't work (AP doesn't beacon). This wasn't a problem when
802.11s was running unencrypted.

We also tested version 10.2.4.97 (from codeaurora), which is now default
in
LEDE. However, this version apparently doesn't support 11s mesh at all
(WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
advertises support).

So here are my questions:
  * Did anyone succesfully run AP and mesh, both encrypted at the same
  time?
  * Do you have any pointers how we could fix this? Could it be fixable in
  the>
driver (i.e. not in firmware)?

  * Does anyone have an idea if 11s will be supported in future versions? I

didn't find any changelogs, but having 11s mode no longer in the service
map does not make me optimistic.

Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
have no knowledge if anyone even tests that firmware branch with ath10k.
I recommend to only use firmware releases from ath10k-firmware.git as we
use those internally with ath10k. In any case, don't make any
assumptions about future from that firmware branch as it's so old.

This was introduced in December 25th, 2015 after some firmware-related
problems. I'm CC'ing Martin Blumenstingl who suggested this change.

Since then, ath10k is pulling firmware from here (unless ct firmware is used):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
10.2.4/firmware-5.bin_10.2.4.97-1

However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say
10.2.4.70.42-2 is more recent? I would have assumed otherwise from the
numbers. However, 10.2.4.70 has much more sub-revisions.

As I said before, I just deliver the firmware files to the community and
the firmware team creates the actual releases. But my understanding is
that these are from different branches which are built independently
(and might have different features, like in this case the mesh support)
so I would not make any conclusions if any firmware is "better" just
from the numbers alone.
would be good to have changelogs so see what has been changed to test 
what they have changed in the fw





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Berliner Ring 101, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565

Re: ath10k mesh + ap + encryption?

[Valo, Kalle]

Simon Wunderlich  writes:

> On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
>> Simon Wunderlich  writes:
>> > we have done some experiments last week on ath10k, trying to run mesh
>> > (802.11s) and access point at the same time, both encrypted.
>> > 
>> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
>> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
>> > us a working encrypted 802.11s network. However, starting an AP at the
>> > same time didn't work (AP doesn't beacon). This wasn't a problem when
>> > 802.11s was running unencrypted.
>> > 
>> > We also tested version 10.2.4.97 (from codeaurora), which is now default
>> > in
>> > LEDE. However, this version apparently doesn't support 11s mesh at all
>> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
>> > advertises support).
>> > 
>> > So here are my questions:
>> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
>> >  time?
>> >  * Do you have any pointers how we could fix this? Could it be fixable in
>> >  the> 
>> > driver (i.e. not in firmware)?
>> > 
>> >  * Does anyone have an idea if 11s will be supported in future versions? I
>> > 
>> > didn't find any changelogs, but having 11s mode no longer in the service
>> > map does not make me optimistic.
>> 
>> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
>> have no knowledge if anyone even tests that firmware branch with ath10k.
>> I recommend to only use firmware releases from ath10k-firmware.git as we
>> use those internally with ath10k. In any case, don't make any
>> assumptions about future from that firmware branch as it's so old.
>
> This was introduced in December 25th, 2015 after some firmware-related 
> problems. I'm CC'ing Martin Blumenstingl who suggested this change.
>
> Since then, ath10k is pulling firmware from here (unless ct firmware is used):
>
> https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
> 10.2.4/firmware-5.bin_10.2.4.97-1
>
> However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say 
> 10.2.4.70.42-2 is more recent? I would have assumed otherwise from the 
> numbers. However, 10.2.4.70 has much more sub-revisions.

As I said before, I just deliver the firmware files to the community and
the firmware team creates the actual releases. But my understanding is
that these are from different branches which are built independently
(and might have different features, like in this case the mesh support)
so I would not make any conclusions if any firmware is "better" just
from the numbers alone.

-- 
Kalle Valo

Re: ath10k mesh + ap + encryption?

[Simon Wunderlich]

On Tuesday, September 13, 2016 10:59:31 AM CEST Valo, Kalle wrote:
> Simon Wunderlich  writes:
> > we have done some experiments last week on ath10k, trying to run mesh
> > (802.11s) and access point at the same time, both encrypted.
> > 
> > We have tested a recent LEDE (reboot-1519-g42f559e) but with
> > firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave
> > us a working encrypted 802.11s network. However, starting an AP at the
> > same time didn't work (AP doesn't beacon). This wasn't a problem when
> > 802.11s was running unencrypted.
> > 
> > We also tested version 10.2.4.97 (from codeaurora), which is now default
> > in
> > LEDE. However, this version apparently doesn't support 11s mesh at all
> > (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211
> > advertises support).
> > 
> > So here are my questions:
> >  * Did anyone succesfully run AP and mesh, both encrypted at the same
> >  time?
> >  * Do you have any pointers how we could fix this? Could it be fixable in
> >  the> 
> > driver (i.e. not in firmware)?
> > 
> >  * Does anyone have an idea if 11s will be supported in future versions? I
> > 
> > didn't find any changelogs, but having 11s mode no longer in the service
> > map does not make me optimistic.
> 
> Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
> have no knowledge if anyone even tests that firmware branch with ath10k.
> I recommend to only use firmware releases from ath10k-firmware.git as we
> use those internally with ath10k. In any case, don't make any
> assumptions about future from that firmware branch as it's so old.

This was introduced in December 25th, 2015 after some firmware-related 
problems. I'm CC'ing Martin Blumenstingl who suggested this change.

Since then, ath10k is pulling firmware from here (unless ct firmware is used):

https://source.codeaurora.org/quic/qsdk/oss/firmware/ath10k-firmware/plain/
10.2.4/firmware-5.bin_10.2.4.97-1

However, I don't understand the numbering? 10.2.4.97 > 10.2.4.70, but you say 
10.2.4.70.42-2 is more recent? I would have assumed otherwise from the 
numbers. However, 10.2.4.70 has much more sub-revisions. Is there any document 
describing the revisions? I don't understand it at least from this wiki page 
[1].

Thanks!
Simon

[1] https://wireless.wiki.kernel.org/en/users/Drivers/ath10k/firmware



signature.asc
Description: This is a digitally signed message part.

Re: ath10k mesh + ap + encryption?

[Valo, Kalle]

Simon Wunderlich  writes:

> we have done some experiments last week on ath10k, trying to run mesh 
> (802.11s) and access point at the same time, both encrypted. 
>
> We have tested a recent LEDE (reboot-1519-g42f559e) but with 
> firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us 
> a 
> working encrypted 802.11s network. However, starting an AP at the same time 
> didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was 
> running unencrypted.
>
> We also tested version 10.2.4.97 (from codeaurora), which is now default in 
> LEDE. However, this version apparently doesn't support 11s mesh at all 
> (WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 
> advertises support).
>
> So here are my questions:
>
>  * Did anyone succesfully run AP and mesh, both encrypted at the same time?
>  * Do you have any pointers how we could fix this? Could it be fixable in the 
> driver (i.e. not in firmware)?
>  * Does anyone have an idea if 11s will be supported in future versions? I 
> didn't find any changelogs, but having 11s mode no longer in the service map 
> does not make me optimistic.

Why is LEDE using 10.2.4.97? It seems to be a quite old release and I
have no knowledge if anyone even tests that firmware branch with ath10k.
I recommend to only use firmware releases from ath10k-firmware.git as we
use those internally with ath10k. In any case, don't make any
assumptions about future from that firmware branch as it's so old.

-- 
Kalle Valo

[PATCH v4] cfg80211: Add support to configure a beacon data rate

[Purushottam Kushwaha]

This allows an option to configure a single beacon tx rate (u8) for an AP.

Signed-off-by: Purushottam Kushwaha 
---
 include/net/cfg80211.h |  25 +--
 net/wireless/nl80211.c | 504 +++--
 2 files changed, 296 insertions(+), 233 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index d5e7f69..c58afc8 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -676,6 +676,18 @@ struct cfg80211_acl_data {
struct mac_address mac_addrs[];
 };
 
+/*
+ * cfg80211_bitrate_mask - masks for bitrate control
+ */
+struct cfg80211_bitrate_mask {
+   struct {
+   u32 legacy;
+   u8 ht_mcs[IEEE80211_HT_MCS_MASK_LEN];
+   u16 vht_mcs[NL80211_VHT_NSS_MAX];
+   enum nl80211_txrate_gi gi;
+   } control[NUM_NL80211_BANDS];
+};
+
 /**
  * struct cfg80211_ap_settings - AP configuration
  *
@@ -700,6 +712,7 @@ struct cfg80211_acl_data {
  * MAC address based access control
  * @pbss: If set, start as a PCP instead of AP. Relevant for DMG
  * networks.
+ * @beacon_rate: masks for setting user configured beacon tx rate.
  */
 struct cfg80211_ap_settings {
struct cfg80211_chan_def chandef;
@@ -719,6 +732,7 @@ struct cfg80211_ap_settings {
bool p2p_opp_ps;
const struct cfg80211_acl_data *acl;
bool pbss;
+   struct cfg80211_bitrate_mask beacon_rate;
 };
 
 /**
@@ -2001,17 +2015,6 @@ enum wiphy_params_flags {
WIPHY_PARAM_DYN_ACK = 1 << 5,
 };
 
-/*
- * cfg80211_bitrate_mask - masks for bitrate control
- */
-struct cfg80211_bitrate_mask {
-   struct {
-   u32 legacy;
-   u8 ht_mcs[IEEE80211_HT_MCS_MASK_LEN];
-   u16 vht_mcs[NL80211_VHT_NSS_MAX];
-   enum nl80211_txrate_gi gi;
-   } control[NUM_NL80211_BANDS];
-};
 /**
  * struct cfg80211_pmksa - PMK Security Association
  *
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7ebad35..f49b7df 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -3324,6 +3324,274 @@ static int nl80211_set_mac_acl(struct sk_buff *skb, 
struct genl_info *info)
return err;
 }
 
+static u32 rateset_to_mask(struct ieee80211_supported_band *sband,
+  u8 *rates, u8 rates_len)
+{
+   u8 i;
+   u32 mask = 0;
+
+   for (i = 0; i < rates_len; i++) {
+   int rate = (rates[i] & 0x7f) * 5;
+   int ridx;
+
+   for (ridx = 0; ridx < sband->n_bitrates; ridx++) {
+   struct ieee80211_rate *srate =
+   >bitrates[ridx];
+   if (rate == srate->bitrate) {
+   mask |= 1 << ridx;
+   break;
+   }
+   }
+   if (ridx == sband->n_bitrates)
+   return 0; /* rate not found */
+   }
+
+   return mask;
+}
+
+static bool ht_rateset_to_mask(struct ieee80211_supported_band *sband,
+  u8 *rates, u8 rates_len,
+  u8 mcs[IEEE80211_HT_MCS_MASK_LEN])
+{
+   u8 i;
+
+   memset(mcs, 0, IEEE80211_HT_MCS_MASK_LEN);
+
+   for (i = 0; i < rates_len; i++) {
+   int ridx, rbit;
+
+   ridx = rates[i] / 8;
+   rbit = BIT(rates[i] % 8);
+
+   /* check validity */
+   if ((ridx < 0) || (ridx >= IEEE80211_HT_MCS_MASK_LEN))
+   return false;
+
+   /* check availability */
+   if (sband->ht_cap.mcs.rx_mask[ridx] & rbit)
+   mcs[ridx] |= rbit;
+   else
+   return false;
+   }
+
+   return true;
+}
+
+static u16 vht_mcs_map_to_mcs_mask(u8 vht_mcs_map)
+{
+   u16 mcs_mask = 0;
+
+   switch (vht_mcs_map) {
+   case IEEE80211_VHT_MCS_NOT_SUPPORTED:
+   break;
+   case IEEE80211_VHT_MCS_SUPPORT_0_7:
+   mcs_mask = 0x00FF;
+   break;
+   case IEEE80211_VHT_MCS_SUPPORT_0_8:
+   mcs_mask = 0x01FF;
+   break;
+   case IEEE80211_VHT_MCS_SUPPORT_0_9:
+   mcs_mask = 0x03FF;
+   break;
+   default:
+   break;
+   }
+
+   return mcs_mask;
+}
+
+static void vht_build_mcs_mask(u16 vht_mcs_map,
+  u16 vht_mcs_mask[NL80211_VHT_NSS_MAX])
+{
+   u8 nss;
+
+   for (nss = 0; nss < NL80211_VHT_NSS_MAX; nss++) {
+   vht_mcs_mask[nss] = vht_mcs_map_to_mcs_mask(vht_mcs_map & 0x03);
+   vht_mcs_map >>= 2;
+   }
+}
+
+static bool vht_set_mcs_mask(struct ieee80211_supported_band *sband,
+struct nl80211_txrate_vht *txrate,
+u16 mcs[NL80211_VHT_NSS_MAX])
+{
+   u16 tx_mcs_map = le16_to_cpu(sband->vht_cap.vht_mcs.tx_mcs_map);
+ 

RE: [PATCH v3] cfg80211: Add support to configure a beacon data rate

[Kushwaha, Purushottam]

Hi Johannes,

> All of these just move around, right?
Yes, just moved around. 

> I think it would be good to split out this "single rate" thing into a helper 
> function.
sure, will raise a new patchset with this change.

Thanks,
Purushottam

ath10k mesh + ap + encryption?

[Simon Wunderlich]

Hi,

we have done some experiments last week on ath10k, trying to run mesh 
(802.11s) and access point at the same time, both encrypted. 

We have tested a recent LEDE (reboot-1519-g42f559e) but with 
firmware-5.bin_10.2.4.70.42-2 and the included wpa_supplicant, which gave us a 
working encrypted 802.11s network. However, starting an AP at the same time 
didn't work (AP doesn't beacon). This wasn't a problem when 802.11s was 
running unencrypted.

We also tested version 10.2.4.97 (from codeaurora), which is now default in 
LEDE. However, this version apparently doesn't support 11s mesh at all 
(WMI_SERVICE_MESH_11S is disabled in the service map, but cfg/mac80211 
advertises support).

So here are my questions:

 * Did anyone succesfully run AP and mesh, both encrypted at the same time?
 * Do you have any pointers how we could fix this? Could it be fixable in the 
driver (i.e. not in firmware)?
 * Does anyone have an idea if 11s will be supported in future versions? I 
didn't find any changelogs, but having 11s mode no longer in the service map 
does not make me optimistic.

Thanks,
 Simon

signature.asc
Description: This is a digitally signed message part.

Re: Support of rtl8723bs

[Hanno Zulla]

Hi,

> The issues I am aware of is to start out changing the register access
> macros into function pointers and stick them all into the fileops
> structure. Provide a set of SDIO ones to match the USB ones. Then you
> will need some code to detect the device, as that part will obviously be
> different from the USB device detection.
> 
> I know there are a few issues to look out for in the hw register init
> files to look out for too, that does some special casing for SDIO, but
> that should be limited. I am happy to point someone in the right
> direction on that when they get to that.

I had a brief look into the sources of other drivers implementing SDIO,
but not being a kernel-dev, this is out of my league.

If you decide to reprioritize your TODO-List in favour of adding SDIO
sooner, I'll be gladly testing this for you on my hardware (and buy you
a beer).

Kind regards,

Hanno

Re: [PATCH v6 1/3] Documentation: dt: net: add ath9k wireless device binding

[Oleksij Rempel]

Am 09.09.2016 um 22:57 schrieb Martin Blumenstingl:
> On Fri, Sep 9, 2016 at 9:48 AM, Oleksij Rempel  wrote:
>>> +Optional properties:
>>> +- reg: Address and length of the register set for the device.
>>> +- qca,clk-25mhz: Defines that a 25MHz clock is used
>>
>> Some SoCs even Atheros WiSoCs use WiFi clock for System Clock. In this
>> case we need to use clock framework any way, so why not in this case too?
>> Provide dummy static clock in DT and connect it with this node?
>>
>> osc25m: oscillator {
>> compatible = "fixed-clock";
>> #clock-cells = <0>;
>> clock-frequency = <2500>;
>> clock-accuracy = <3>;
>> };
>>
>> acc: clock-controller@8004 {
>> compatible = "some-clock-controller";
>> #clock-cells = <1>;
>> clocks = <>;
>> reg = <0x8004 0x204>;
>> };
>>
>>
>>  {
>> ath9k@168c,002d {
>> compatible = "pci168c,002d";
>> reg = <0x7000 0 0 0 0x1000>;
>> clocks = <>;
>> qca,disable-5ghz;
>> };
>> };
>>
>>
>> driver will need to use clk_get and compare frequency instead of
>> of_property_read_bool(np, "qca,clk-25mhz"). In this case you will need
>> to define source clock only one time and reuse it by all affected DT
>> nodes. If we have 40MHz clock you will only need to change it in
>> fixed-clock.
> that does sound like a good idea, thanks for that input!
> However, I will remove the property for the first version because I am
> trying to get PCI(e) devices supported. OF support for AHB (WiSoC)
> needs more work (in other places, like ahb.c) anyways.
> But this suggestion should be remembered!
> 
>>> +- qca,no-eeprom: Indicates that there is no physical EEPROM connected to 
>>> the
>>> + ath9k wireless chip (in this case the calibration /
>>> + EEPROM data will be loaded from userspace using the
>>> + kernel firmware loader).
>>> +- qca,disable-2ghz: Overrides the settings from the EEPROM and disables the
>>> + 2.4GHz band. Setting this property is only needed
>>> + when the RF circuit does not support the 2.4GHz band
>>> + while it is enabled nevertheless in the EEPROM.
>>> +- qca,disable-5ghz: Overrides the settings from the EEPROM and disables the
>>> + 5GHz band. Setting this property is only needed when
>>> + the RF circuit does not support the 5GHz band while
>>> + it is enabled nevertheless in the EEPROM.
>>
>> This option can be reused for every WiFi controller. Not only for qca.
>> So may be instead of adding vendor specific name, make it reusable for
>> all vendors. Instead of qca,disable-5ghz and qca,disable-2ghz make
>> disable-5ghz and disable-2ghz?
> I am personally fine with anything that fits best into the grand
> scheme of things.
> There are three scenarios I can think of which may be influenced by
> devicetree configuration:
> a) let the driver decide automatically whether the 2.4GHz and/or 5GHz
> band is/are enabled
> b) explicitly disable either bands (because the driver thinks due to
> whatever reason that a band is supported while in reality it isn't)
> c) explicitly enable a band (for example because the driver cannot
> automagically detect which band should be enabled)
> 
> for ath9k we default to a) but also allow b): the EEPROM (device
> specific calibration data) contains information about which bands are
> enabled (or not). But some manufacturers are shipping devices for
> example with the 5G band enabled, while the actual hardware doesn't
> support it.
> 
> Felix' mt76 driver for example defaults to case a) but allows
> overriding (= forcefully enabling or disabling) a specific band.
> 
> If we decide how this should look like in the devicetree then I can go
> ahead and implement it accordingly.

To avoid possible conflict with other device-tree bindings i would
suggest this kind of naming:
ieee80211-5ghz-enalbe
ieee80211-5ghz-disable
ieee80211-2.4ghz-enalbe
ieee80211-2.4ghz-disable

i assume at some point we would get even more eeprom overrides. For
example disable/enable some modulation and so on.

we would need 80211 specific functions to read this overrides from
device-tree and/or acpi.

any feedback from DT maintainers?
-- 
Regards,
Oleksij



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v3] mac80211: Re-structure aqm debugfs output and keep CoDel stats per txq

[Johannes Berg]

On Mon, 2016-09-12 at 15:55 +0200, Toke Høiland-Jørgensen wrote:
> Currently the 'aqm' stats in mac80211 only keeps overlimit drop
> stats,
> not CoDel stats. This moves the CoDel stats into the txqi structure
> to
> keep them per txq in order to show them in debugfs.
> 
> In addition, the aqm debugfs output is restructured by splitting it
> up
> into three files: One global per phy, one per netdev and one per
> station, in the appropriate directories. The files are all called
> aqm,
> and are only created if the driver supports the wake_tx_queue op
> (rather
> than emitting an error on open as previously).
> 
Applied, thanks.

johannes

[PATCH] mac80211: simplify TDLS RA lookup

[Johannes Berg]

From: Johannes Berg 

smatch pointed out that the second check of "tdls_auth" was
pointless since if it was true, we returned from the function
already. We can further simplify the code by moving the first
check (if it's a TDLS peer at all) into the outer if, to only
handle that inside. This simplifies the control flow here.

Signed-off-by: Johannes Berg 
---
 net/mac80211/tx.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ee9e7d60cb78..61d302d97145 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -2263,15 +2263,9 @@ static int ieee80211_lookup_ra_sta(struct 
ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_STATION:
if (sdata->wdev.wiphy->flags & WIPHY_FLAG_SUPPORTS_TDLS) {
sta = sta_info_get(sdata, skb->data);
-   if (sta) {
-   bool tdls_peer, tdls_auth;
-
-   tdls_peer = test_sta_flag(sta,
- WLAN_STA_TDLS_PEER);
-   tdls_auth = test_sta_flag(sta,
-   WLAN_STA_TDLS_PEER_AUTH);
-
-   if (tdls_peer && tdls_auth) {
+   if (sta && test_sta_flag(sta, WLAN_STA_TDLS_PEER)) {
+   if (test_sta_flag(sta,
+ WLAN_STA_TDLS_PEER_AUTH)) {
*sta_out = sta;
return 0;
}
@@ -2283,8 +2277,7 @@ static int ieee80211_lookup_ra_sta(struct 
ieee80211_sub_if_data *sdata,
 * after a TDLS sta is removed due to being
 * unreachable.
 */
-   if (tdls_peer && !tdls_auth &&
-   !ieee80211_is_tdls_setup(skb))
+   if (!ieee80211_is_tdls_setup(skb))
return -EINVAL;
}
 
-- 
2.8.1