* [PATCH 4/5] wlcore: Fix config firmware loading issues
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160917160633.8767-1-tony@atomide.com>
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 <tony@atomide.com>
---
drivers/net/wireless/ti/wlcore/boot.c | 15 +++++++++----
drivers/net/wireless/ti/wlcore/main.c | 36 ++++++++++++++++++++-----------
drivers/net/wireless/ti/wlcore/wlcore_i.h | 7 ------
3 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ti/wlcore/boot.c b/drivers/net/wireless/ti/wlcore/boot.c
--- 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(&pdev->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
--- 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)
{
- int ret;
+ struct wlcore_platdev_data *pdev_data = dev_get_platdata(&pdev->dev);
+ const char *nvs_name;
+ int ret = 0;
- if (!wl->ops || !wl->ptable)
+ if (!wl->ops || !wl->ptable || !pdev_data)
return -EINVAL;
wl->dev = &pdev->dev;
wl->pdev = pdev;
platform_set_drvdata(pdev, wl);
- ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
- WL12XX_NVS_NAME, &pdev->dev, GFP_KERNEL,
- wl, wlcore_nvs_cb);
- if (ret < 0) {
- wl1271_error("request_firmware_nowait failed: %d", ret);
- complete_all(&wl->nvs_loading_complete);
+ if (pdev_data->family && pdev_data->family->nvs_name) {
+ nvs_name = pdev_data->family->nvs_name;
+ ret = request_firmware_nowait(THIS_MODULE, FW_ACTION_HOTPLUG,
+ nvs_name, &pdev->dev, GFP_KERNEL,
+ wl, wlcore_nvs_cb);
+ if (ret < 0) {
+ wl1271_error("request_firmware_nowait failed for %s: %d",
+ nvs_name, ret);
+ complete_all(&wl->nvs_loading_complete);
+ }
+ } else {
+ wlcore_nvs_cb(NULL, wl);
}
return ret;
@@ -6533,9 +6544,11 @@ EXPORT_SYMBOL_GPL(wlcore_probe);
int wlcore_remove(struct platform_device *pdev)
{
+ struct wlcore_platdev_data *pdev_data = dev_get_platdata(&pdev->dev);
struct wl1271 *wl = platform_get_drvdata(pdev);
- wait_for_completion(&wl->nvs_loading_complete);
+ if (pdev_data->family && pdev_data->family->nvs_name)
+ wait_for_completion(&wl->nvs_loading_complete);
if (!wl->initialized)
return 0;
@@ -6572,4 +6585,3 @@ MODULE_PARM_DESC(no_recovery, "Prevent HW recovery. FW will remain stuck.");
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Luciano Coelho <coelho@ti.com>");
MODULE_AUTHOR("Juuso Oikarinen <juuso.oikarinen@nokia.com>");
-MODULE_FIRMWARE(WL12XX_NVS_NAME);
diff --git a/drivers/net/wireless/ti/wlcore/wlcore_i.h b/drivers/net/wireless/ti/wlcore/wlcore_i.h
--- a/drivers/net/wireless/ti/wlcore/wlcore_i.h
+++ b/drivers/net/wireless/ti/wlcore/wlcore_i.h
@@ -35,13 +35,6 @@
#include "conf.h"
#include "ini.h"
-/*
- * wl127x and wl128x are using the same NVS file name. However, the
- * ini parameters between them are different. The driver validates
- * the correct NVS size in wl1271_boot_upload_nvs().
- */
-#define WL12XX_NVS_NAME "ti-connectivity/wl1271-nvs.bin"
-
struct wilink_family_data {
const char *name;
const char *nvs_name; /* wl12xx nvs file */
--
2.9.3
^ permalink raw reply
* [PATCH 5/5] wlcore: wl18xx: Use chip specific configuration firmware
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160917160633.8767-1-tony@atomide.com>
Use the wl18xx specific config firmware we now have available.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
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
--- 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(&fw, WL18XX_CONF_FILE_NAME, dev);
+ ret = request_firmware(&fw, 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(&pdev->dev);
struct wl18xx_priv *priv = wl->priv;
- if (wl18xx_load_conf_file(dev, &wl->conf, &priv->conf) < 0) {
+ if (wl18xx_load_conf_file(dev, &wl->conf, &priv->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 <coelho@ti.com>");
MODULE_FIRMWARE(WL18XX_FW_NAME);
-MODULE_FIRMWARE(WL18XX_CONF_FILE_NAME);
--
2.9.3
^ permalink raw reply
* [PATCH 3/5] wlcore: spi: Populate config firmware data
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160917160633.8767-1-tony@atomide.com>
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 <tony@atomide.com>
---
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
--- 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 = &wl12xx_data},
- { .compatible = "ti,wl1273", .data = &wl12xx_data},
- { .compatible = "ti,wl1281", .data = &wl12xx_data},
- { .compatible = "ti,wl1283", .data = &wl12xx_data},
+ { .compatible = "ti,wl1271", .data = &wl127x_data},
+ { .compatible = "ti,wl1273", .data = &wl127x_data},
+ { .compatible = "ti,wl1281", .data = &wl128x_data},
+ { .compatible = "ti,wl1283", .data = &wl128x_data},
{ .compatible = "ti,wl1801", .data = &wl18xx_data},
{ .compatible = "ti,wl1805", .data = &wl18xx_data},
{ .compatible = "ti,wl1807", .data = &wl18xx_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(&spi->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(&pdev_data, 0x00, sizeof(pdev_data));
+ pdev_data = devm_kzalloc(&spi->dev, sizeof(*pdev_data), GFP_KERNEL);
+ if (!pdev_data)
+ return -ENOMEM;
- pdev_data.if_ops = &spi_ops;
+ pdev_data->if_ops = &spi_ops;
glue = devm_kzalloc(&spi->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, &pdev_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, &pdev_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
^ permalink raw reply
* [PATCH 2/5] wlcore: sdio: Populate config firmware data
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160917160633.8767-1-tony@atomide.com>
Configure the config firmware names and make it available
in platform data.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
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
--- 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 = &wl127x_data },
+ { .compatible = "ti,wl1273", .data = &wl127x_data },
+ { .compatible = "ti,wl1281", .data = &wl128x_data },
+ { .compatible = "ti,wl1283", .data = &wl128x_data },
+ { .compatible = "ti,wl1801", .data = &wl18xx_data },
+ { .compatible = "ti,wl1805", .data = &wl18xx_data },
+ { .compatible = "ti,wl1807", .data = &wl18xx_data },
+ { .compatible = "ti,wl1831", .data = &wl18xx_data },
+ { .compatible = "ti,wl1835", .data = &wl18xx_data },
+ { .compatible = "ti,wl1837", .data = &wl18xx_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(&pdev_data, 0x00, sizeof(pdev_data));
- pdev_data.if_ops = &sdio_ops;
+ pdev_data = devm_kzalloc(&func->dev, sizeof(*pdev_data), GFP_KERNEL);
+ if (!pdev_data)
+ return -ENOMEM;
- glue = kzalloc(sizeof(*glue), GFP_KERNEL);
- if (!glue) {
- dev_err(&func->dev, "can't allocate glue\n");
- goto out;
- }
+ pdev_data->if_ops = &sdio_ops;
+
+ glue = devm_kzalloc(&func->dev, sizeof(*glue), GFP_KERNEL);
+ if (!glue)
+ return -ENOMEM;
glue->dev = &func->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(&func->dev, &irq, &pdev_data);
+ ret = wlcore_probe_of(&func->dev, &irq, 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 = &func->dev;
@@ -341,8 +362,8 @@ static int wl1271_probe(struct sdio_func *func,
goto out_dev_put;
}
- ret = platform_device_add_data(glue->core, &pdev_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;
@@ -358,9 +379,6 @@ static int wl1271_probe(struct sdio_func *func,
out_dev_put:
platform_device_put(glue->core);
-out_free_glue:
- kfree(glue);
-
out:
return ret;
}
--
2.9.3
^ permalink raw reply
* [PATCH 1/5] wlcore: Prepare family to fix nvs file handling
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160917160633.8767-1-tony@atomide.com>
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 <tony@atomide.com>
---
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
--- 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(&spi->dev, "selected chip familiy is %s\n",
+ dev_info(&spi->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
--- 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) & 0xffff))
#define WL1271_TX_SECURITY_HI32(s) ((u32)(((s) >> 16) & 0xffffffff))
#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
^ permalink raw reply
* [PATCHv2 0/5] Fix wlcore config firwmare annoyances
From: Tony Lindgren @ 2016-09-17 16:06 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Luca Coelho, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
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.
Changes since v1:
- Fix copy paste typo for the SPI related changes as noted by
Kalle Valo
- Fix uninitialized ret variable warning as noted by Kalle Valo
Regards,
Tony
Tony Lindgren (5):
wlcore: Prepare family to fix nvs file handling
wlcore: sdio: Populate config firmware data
wlcore: spi: 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 | 36 ++++++++++-----
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, 123 insertions(+), 83 deletions(-)
--
2.9.3
^ permalink raw reply
* ath9k_htc kernel driver regression affecting throughput
From: bruce m beach @ 2016-09-17 15:52 UTC (permalink / raw)
To: linux-wireless; +Cc: linux
>> Hm.. found here one report about bad perfomance on this driver
>> https://ubuntuforums.org/showthread.php?t=2312343
>>
>> affected persons seems to use WEP encryption.
>>
>> What encryption do are you using?
I just wish I could do some testing on a single machine. Every test
suite I've seen always involves 2 machines. Why can't I use the wifi
chip on the mother board and the ar9271(a usb stick) to test basic
communications on the ar9271. The problem is I don't know where to begin.
Bruce
^ permalink raw reply
* Re: [PATCH 0/5] Fix wlcore config firwmare annoyances
From: Tony Lindgren @ 2016-09-17 15:37 UTC (permalink / raw)
To: Kalle Valo
Cc: Eyal Reizer, Guy Mishol, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <87k2ea7dmm.fsf@kamboji.qca.qualcomm.com>
* Kalle Valo <kvalo@codeaurora.org> [160917 08:25]:
> Tony Lindgren <tony@atomide.com> writes:
>
> > 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
>
> I saw a new warning which I think is a valid one:
>
> drivers/net/wireless/ti/wlcore/main.c: In function 'wlcore_probe':
> drivers/net/wireless/ti/wlcore/main.c:6518:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
Oops sorry about that, will check and repost.
Regards,
Tony
^ permalink raw reply
* Re: mwifiex: fix error handling in mwifiex_create_custom_regdomain
From: Kalle Valo @ 2016-09-17 15:26 UTC (permalink / raw)
To: Bob Copeland
Cc: linux-wireless, Bob Copeland, Amitkumar Karwar,
Nishant Sarmukadam
In-Reply-To: <20160914124236.1951-1-me@bobcopeland.com>
Bob Copeland <me@bobcopeland.com> wrote:
> smatch reports:
>
> sta_cmdresp.c:1053 mwifiex_create_custom_regdomain() warn: possible memory leak of 'regd'
>
> Indeed, mwifiex_create_custom_regdomain() returns NULL in the
> case that channel is missing in the TLV without freeing regd.
>
> Moreover, some other error paths in this function return ERR_PTR
> values which are assigned without checking to the regd field in
> the mwifiex_adapter struct. The latter is only null-checked where
> used.
>
> Fix by freeing regd in the error path, and only update
> priv->adapter->regd if the returned pointer is valid.
>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Cc: Nishant Sarmukadam <nishants@marvell.com>
> Signed-off-by: Bob Copeland <me@bobcopeland.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
92ca4f92eca7 mwifiex: fix error handling in mwifiex_create_custom_regdomain
--
Sent by pwcli
https://patchwork.kernel.org/patch/9331337/
^ permalink raw reply
* Re: [PATCH 0/5] Fix wlcore config firwmare annoyances
From: Kalle Valo @ 2016-09-17 15:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Eyal Reizer, Guy Mishol, Maital Hahn, Maxim Altshul,
Shahar Patury, linux-wireless, linux-omap
In-Reply-To: <20160913215043.29454-1-tony@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> 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
I saw a new warning which I think is a valid one:
drivers/net/wireless/ti/wlcore/main.c: In function 'wlcore_probe':
drivers/net/wireless/ti/wlcore/main.c:6518:6: warning: 'ret' may be used uninitialized in this function [-Wuninitialized]
--
Kalle Valo
^ permalink raw reply
* Re: [1/1] rtl8xxxu: Implement 8192e specific power down sequence
From: Kalle Valo @ 2016-09-17 15:17 UTC (permalink / raw)
To: Jes Sorensen; +Cc: linux-wireless, Larry.Finger, Jes Sorensen
In-Reply-To: <1473793395-28927-2-git-send-email-Jes.Sorensen@redhat.com>
Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> From: Jes Sorensen <Jes.Sorensen@redhat.com>
>
> 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 <Jes.Sorensen@redhat.com>
Thanks, 1 patch applied to wireless-drivers-next.git:
f1785fbf7c0b rtl8xxxu: Implement 8192e specific power down sequence
--
Sent by pwcli
https://patchwork.kernel.org/patch/9329843/
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 15:14 UTC (permalink / raw)
To: Johannes Berg
Cc: igor.mitsyanko.os, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1474125118.7623.3.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
> On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote:
>>=C2=A0
>> Sorry, I was unclear. I meant the whole file
> [...]
Argh, I meant the whole driver of course, not just the file.
> Ah, ok - yeah, I think you're right - I think the supported_band ones
> can be, for example, and probably others as well.
Maybe also some of the pci related.
--=20
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2016-09-15-2
From: Kalle Valo @ 2016-09-17 15:12 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1474012383.5664.62.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> This is v2 of my pull-request. =C2=A0I have fixed the compilation error w=
ith
> alpha (and possibly other) platforms.
>
> I'll send v2 of the changed patch as a reply to this email.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit 76f8c0e17edc6eba43f84952e5a87c7f50f693=
70:
>
> =C2=A0 iwlwifi: pcie: remove dead code (2016-08-30 14:16:43 +0300)
>
> are available in the git repository at:
>
> =C2=A0 git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next=
.git tags/iwlwifi-next-for-kalle-2016-09-15-2
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Johannes Berg @ 2016-09-17 15:11 UTC (permalink / raw)
To: Kalle Valo
Cc: igor.mitsyanko.os, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <87wpia7eou.fsf@kamboji.qca.qualcomm.com>
On Sat, 2016-09-17 at 18:01 +0300, Kalle Valo wrote:
>
> Sorry, I was unclear. I meant the whole file
[...]
Ah, ok - yeah, I think you're right - I think the supported_band ones
can be, for example, and probably others as well.
johannes
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 15:01 UTC (permalink / raw)
To: Johannes Berg
Cc: igor.mitsyanko.os, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1474123851.7623.2.camel@sipsolutions.net>
Johannes Berg <johannes@sipsolutions.net> writes:
>> I guess some of these static variables could be also const, but
>> didn't check.
>
> I think both bitrates and channels can't be, due to cfg80211 writing
> some (global) flags there on init.
Sorry, I was unclear. I meant the whole file, not just what was in my
mail:
qtnfmac/cfg80211.c:static struct ieee80211_rate qtnf_rates[] = {
qtnfmac/cfg80211.c:static struct ieee80211_channel qtnf_channels_2ghz[] = {
qtnfmac/cfg80211.c:static struct ieee80211_supported_band qtnf_band_2ghz = {
qtnfmac/cfg80211.c:static struct ieee80211_channel qtnf_channels_5ghz[] = {
qtnfmac/cfg80211.c:static struct ieee80211_supported_band qtnf_band_5ghz = {
qtnfmac/cfg80211.c:static struct cfg80211_ops qtn_cfg80211_ops = {
qtnfmac/pcie.c:static struct qtnf_bus_ops qtnf_pcie_bus_ops = {
qtnfmac/pcie.c:static struct attribute *qtnf_sysfs_entries[] = {
qtnfmac/pcie.c:static struct attribute_group qtnf_attrs_group = {
qtnfmac/pcie.c:static struct pci_device_id qtnf_pcie_devid_table[] = {
qtnfmac/pcie.c:static struct pci_driver qtnf_pcie_drv_data = {
Anyway, nothing important. Just something which I started to wonder
while reading the code.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Johannes Berg @ 2016-09-17 14:50 UTC (permalink / raw)
To: Kalle Valo, igor.mitsyanko.os
Cc: linux-wireless, Avinash Patil, Dmitrii Lebed, Sergei Maksimenko,
Sergey Matyukevich, Bindu Therthala, Huizhao Wang, Kamlesh Rath
In-Reply-To: <87eg4i8wqi.fsf@kamboji.qca.qualcomm.com>
> drivers/net/wireless/quantenna/qtnfmac/event.c: In function
> `qtnf_event_handle_scan_complete':
> drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning:
> passing argument 2 of `cfg80211_scan_done' makes pointer from integer
> without a cast [enabled by default]
Yes, cfg80211_scan_done() changed fairly recently for sure.
> ./include/net/cfg80211.h:4104:6: note: expected `struct
> cfg80211_scan_info *' but argument is of type `u32'
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function
> `qtnf_virtual_intf_cleanup':
> drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:1093:4: warning:
> passing argument 2 of `cfg80211_scan_done' makes pointer from integer
> without a cast [enabled by default]
> ./include/net/cfg80211.h:4104:6: note: expected `struct
> cfg80211_scan_info *' but argument is of type `int'
>
These also seem related.
> > +F: drivers/net/wireless/quantenna/qtnfmac
> The include directory is not listed.
Should really just stop after quantenna/ I'd think? As long as it's
just a single driver, you might as well claim maintenance over
everything there :)
> I guess some of these static variables could be also const, but
> didn't check.
I think both bitrates and channels can't be, due to cfg80211 writing
some (global) flags there on init.
johannes
^ permalink raw reply
* Re: pull-request: iwlwifi 2016-09-15
From: Kalle Valo @ 2016-09-17 14:08 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1473955833.5664.38.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Hi Kalle,
>
> Here is one more patch intended for 4.8. =C2=A0It's small and low risk, j=
ust
> moving some lines of code around, to prevent a firmware crash in
> certain situations.
>
> Let me know if everything's fine (or not). :)
>
> Luca.
>
>
> The following changes since commit a904a08b5fee5317ff0f7b8212aa5d0776795a=
52:
>
> =C2=A0 iwlwifi: mvm: Advertise support for AP channel width change (2016-=
08-29 22:29:06 +0300)
>
> are available in the git repository at:
>
> =C2=A0 git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixe=
s.git tags/iwlwifi-for-kalle-2016-09-15
Pulled, thanks.
--=20
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:59 UTC (permalink / raw)
To: Igor Mitsyanko
Cc: Johannes Berg, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <fd6ee9cd-71fd-352a-e1cd-61d36b296057@quantenna.com>
Igor Mitsyanko <igor.mitsyanko.os@quantenna.com> writes:
> thank for review and sorry for long delays in replies. A parallel
> thread with Dave a discussion was initiated regarding HW platform
> samples availability. Current driver implementation supports a newer
> QSR10G platform, which availability is limited due to the platform
> still being in development stage. We're working on supporting
> Quantenna's current QSR1000 platform too, what would be the best
> approach to this:
> - have QSR1000 platform support ready, amend it to current patch and
> post it as a new patch revision (there should be a certain amount of
> new code);
> - have current patch accepted by community first, and then post a new
> patch (adding new platform support) one on top of it.
I prefer the latter option. Let's first try to get the driver applied
and then you can submit more features as followup patches.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:56 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
<igor.mitsyanko.os@quantenna.com> writes:
> From: Avinash Patil <avinashp@quantenna.com>
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
More comments:
> +/* FW names */
> +
> +#define QTN_PCI_FW_NAME "pearl-linux.lzma.img"
The firmware name gives no indication what this file is about (remember
that linux-firmware.git has a lot of files). Please name it properly,
don't just use what is used in by firmware build scripts :) Take into
account also future hw support, all firmware files need to coexist in
the same repository without user invention. In a way the firmware
filename is part of kernel/userspace interface and needs to be stable.
For example, you could use something like "qtnfmac/qsr10g.img" (assuming
qsr10g is the name of chip).
I forgot already, is the firmware image ready for submission to
linux-firmware.git?
> + pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
> + reg ? "" : "un", frame_type);
The driver seems to be quite spammy with info messages:
qtnfmac/cfg80211.c: pr_info("%s: %sregistered mgmt frame type 0x%x\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s cipher=%x, idx=%u, pairwise=%u\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, pairwise=%u\n", __func__, key_index,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u, unicast=%u, multicast=%u\n", __func__,
qtnfmac/cfg80211.c: pr_info("QTNF: %s idx=%u\n", __func__, key_index);
qtnfmac/cfg80211.c: pr_info("%s: initiator=%d, alpha=%c%c, macid=%d\n", __func__,
qtnfmac/cfg80211.c: pr_info("%s: MAX_IF: %zu; MODES: %.4X; RADAR WIDTHS: %.2X\n", __func__,
qtnfmac/cfg80211.c: pr_info("macid=%d, phymode=%#x\n", mac->macid, mac->macinfo.phymode);
qtnfmac/commands.c: pr_info("%s: unexpected TLV type: %.4X\n",
qtnfmac/commands.c: pr_info("%s: STA %pM not found\n", __func__, sta_mac);
qtnfmac/commands.c: pr_info("country-code from EP: %c%c\n", hwinfo->country_code[0],
qtnfmac/commands.c: pr_info("fw_version = %d, num_mac=%d, mac_bitmap=%#x\n",
qtnfmac/commands.c: pr_info("iface limit record count=%zu\n", record_count);
qtnfmac/commands.c: pr_info("MAC%d reported channels %d\n",
qtnfmac/init.c: pr_info("%s: macid=%d\n", __func__, macid);
qtnfmac/pcie.c: pr_info("enabled PCIE MSI interrupt\n");
qtnfmac/pcie.c: pr_info("%s: BAR[%u] vaddr=0x%p busaddr=0x%p len=%u\n",
qtnfmac/pcie.c: pr_info("%s: set mps to %d (was %d, max %d)\n",
qtnfmac/pcie.c: pr_info("fw download started: fw start addr = 0x%p, size=%d\n",
qtnfmac/pcie.c: pr_info("fw download completed: totally sent %d blocks\n", blk);
qtnfmac/pcie.c: pr_info("RC is ready to boot EP...\n");
qtnfmac/pcie.c: pr_info("starting download firmware %s...\n", bus->fwname);
qtnfmac/pcie.c: pr_info("successful init of PCI device %x\n", pdev->device);
qtnfmac/pcie.c: pr_info("Register Quantenna FullMAC PCIE driver\n");
qtnfmac/pcie.c: pr_info("Unregister Quantenna FullMAC PCIE driver\n");
qtnfmac/trans.c: pr_info("%s: interrupted\n", __func__);
qtnfmac/trans.c: pr_info("%s: skb dropped\n", __func__);
Usualle the preference is that driver is quiet until something goes
wrong. I hope some of these could be debug messages.
> --- /dev/null
> +++ b/drivers/net/wireless/quantenna/qtnfmac/pcie.c
> @@ -0,0 +1,1374 @@
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + **/
> +
> +#undef DEBUG
Why?
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-09-15
From: David Miller @ 2016-09-17 13:54 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zin99p3y.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Thu, 15 Sep 2016 18:09:21 +0300
> here's the first pull request for 4.9. The ones I want to point out are
> the FIELD_PREP() and FIELD_GET() macros added to bitfield.h, which are
> reviewed by Linus, and make it possible to remove util.h from mt7601u.
>
> Also we have new HW support to various drivers and other smaller
> features, the signed tag below contains more information. And I pulled
> my ath-current (uses older net tree as the baseline) branch to fix a
> conflict in ath10k.
>
> Once again the diffstat from git request-pull was wrong. I fixed it by
> manually copying the diffstat from a test pull against net-next, so
> everything should be ok. But please let me know if there are any
> problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH v2 RESEND] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets
From: Kalle Valo @ 2016-09-17 13:46 UTC (permalink / raw)
To: igor.mitsyanko.os
Cc: johannes, linux-wireless, Avinash Patil, Dmitrii Lebed,
Sergei Maksimenko, Sergey Matyukevich, Bindu Therthala,
Huizhao Wang, Kamlesh Rath
In-Reply-To: <1466460688-28160-1-git-send-email-igor.mitsyanko.os@quantenna.com>
<igor.mitsyanko.os@quantenna.com> writes:
> From: Avinash Patil <avinashp@quantenna.com>
>
> This patch adds support for new FullMAC WiFi driver for Quantenna
> QSR10G chipsets.
>
> QSR10G is Quantenna's 8x8, 160M, 11ac offering.
> QSR10G supports 2 simultaneous WMACs- one 5G and one 2G. 5G WMAC
> supports 160M, 8x8 configuration.
> FW supports 8 concurrent virtual interfaces on each WMAC.
>
> Patch introduces 2 new drivers- qtnfmac.ko for interfacing with
> kernel/cfg80211 and qtnfmac_pcie.ko for PCIe bus interface.
>
> Signed-off-by: Dmitrii Lebed <dlebed@quantenna.com>
> Signed-off-by: Sergei Maksimenko <smaksimenko@quantenna.com>
> Signed-off-by: Sergey Matyukevich <smatyukevich@quantenna.com>
> Signed-off-by: Bindu Therthala <btherthala@quantenna.com>
> Signed-off-by: Huizhao Wang <hwang@quantenna.com>
> Signed-off-by: Kamlesh Rath <krath@quantenna.com>
> Signed-off-by: Avinash Patil <avinashp@quantenna.com>
> Signed-off-by: Igor Mitsyanko <igor.mitsyanko.os@quantenna.com>
I read this through and looking good. Below are some comments.
I also saw few warnings but I suspect they are because of cfg80211 API
changes (didn't bother to check that now):
drivers/net/wireless/quantenna/qtnfmac/event.c: In function `qtnf_event_handle_scan_complete':
drivers/net/wireless/quantenna/qtnfmac/event.c:342:2: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `u32'
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c: In function `qtnf_virtual_intf_cleanup':
drivers/net/wireless/quantenna/qtnfmac/cfg80211.c:1093:4: warning: passing argument 2 of `cfg80211_scan_done' makes pointer from integer without a cast [enabled by default]
./include/net/cfg80211.h:4104:6: note: expected `struct cfg80211_scan_info *' but argument is of type `int'
> Resend to correct email kvalo@codeaurora.org.
BTW, no need to send me directly. I take patches directly from patchwork
so sending them to linux-wireless is enough. Doesn't do any harm to send
them to, I just immediately delete them from my INBOX :)
> Changelist V1->V2:
> 1. Get rid of confidentiality footer.
> 2. Rewrite qlink.h header to make it easier to use, add
> documentation to most of qlink.h definitions.
>
> MAINTAINERS | 8 +
> drivers/net/wireless/Kconfig | 1 +
> drivers/net/wireless/Makefile | 1 +
> drivers/net/wireless/quantenna/Kconfig | 16 +
> drivers/net/wireless/quantenna/Makefile | 6 +
> drivers/net/wireless/quantenna/include/bus.h | 195 ++
> .../wireless/quantenna/include/pcie_regs_pearl.h | 353 ++++
> drivers/net/wireless/quantenna/include/qlink.h | 939 ++++++++++
> .../net/wireless/quantenna/include/qtn_hw_ids.h | 34 +
> .../net/wireless/quantenna/include/shm_ipc_defs.h | 46 +
Is there a particular reason why you have a separate include directory?
There's just one quantenna driver for now so the extra include directory
feels unnecessary. I would prefer to have that only once there are two
quantenna drivers and we know exactly what is shared between the two.
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9151,6 +9151,14 @@ L: qemu-devel@nongnu.org
> S: Maintained
> F: drivers/firmware/qemu_fw_cfg.c
>
> +QUANTENNA QTNFMAC WIRELESS DRIVER
> +M: Igor Mitsyanko <imitsyanko@quantenna.com>
> +M: Avinash Patil <avinashp@quantenna.com>
> +M: Sergey Matyukevich <smatyukevich@quantenna.com>
> +L: linux-wireless@vger.kernel.org
> +S: Maintained
> +F: drivers/net/wireless/quantenna/qtnfmac
The include directory is not listed.
> +ccflags-y += -D__CHECK_ENDIAN
Very good.
> +/* Supported rates to be advertised to the cfg80211 */
> +static struct ieee80211_rate qtnf_rates[] = {
> + {.bitrate = 10, .hw_value = 2, },
> + {.bitrate = 20, .hw_value = 4, },
> + {.bitrate = 55, .hw_value = 11, },
> + {.bitrate = 110, .hw_value = 22, },
> + {.bitrate = 60, .hw_value = 12, },
> + {.bitrate = 90, .hw_value = 18, },
> + {.bitrate = 120, .hw_value = 24, },
> + {.bitrate = 180, .hw_value = 36, },
> + {.bitrate = 240, .hw_value = 48, },
> + {.bitrate = 360, .hw_value = 72, },
> + {.bitrate = 480, .hw_value = 96, },
> + {.bitrate = 540, .hw_value = 108, },
> +};
> +
> +/* Channel definitions to be advertised to cfg80211 */
> +static struct ieee80211_channel qtnf_channels_2ghz[] = {
> + {.center_freq = 2412, .hw_value = 1, },
> + {.center_freq = 2417, .hw_value = 2, },
> + {.center_freq = 2422, .hw_value = 3, },
> + {.center_freq = 2427, .hw_value = 4, },
> + {.center_freq = 2432, .hw_value = 5, },
> + {.center_freq = 2437, .hw_value = 6, },
> + {.center_freq = 2442, .hw_value = 7, },
> + {.center_freq = 2447, .hw_value = 8, },
> + {.center_freq = 2452, .hw_value = 9, },
> + {.center_freq = 2457, .hw_value = 10, },
> + {.center_freq = 2462, .hw_value = 11, },
> + {.center_freq = 2467, .hw_value = 12, },
> + {.center_freq = 2472, .hw_value = 13, },
> + {.center_freq = 2484, .hw_value = 14, },
> +};
I guess some of these static variables could be also const, but didn't
check.
> +MODULE_AUTHOR("Quantenna Communications");
> +MODULE_DESCRIPTION("Quantenna 802.11 wireless LAN FullMAC driver.");
> +MODULE_LICENSE("Dual BSD/GPL");
[...]
> +++ b/drivers/net/wireless/quantenna/qtnfmac/core.h
> @@ -0,0 +1,170 @@
> +/**
> + * Copyright (c) 2015-2016 Quantenna Communications, Inc.
> + * All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + **/
MODULE_LICENSE() doesn't match license in headers, is that correct?
> +static int
> +qtnf_event_handle_sta_assoc(struct qtnf_wmac *mac, struct qtnf_vif *vif,
> + const struct qlink_event_sta_assoc *sta_assoc,
> + u16 len)
> +{
> + const u8 *sta_addr;
> + u16 frame_control;
> + struct station_info sinfo = { 0 };
> + size_t payload_len;
> + u16 tlv_type;
> + u16 tlv_value_len;
> + size_t tlv_full_len;
> + const struct qlink_tlv_hdr *tlv;
> +
> + if (unlikely(len < sizeof(*sta_assoc))) {
> + pr_err("%s: payload is too short (%u < %zu)\n", __func__,
> + len, sizeof(*sta_assoc));
> + return -EINVAL;
> + }
I see unlikely() used a lot, I counted 145 times. Not a big issue but I
don't see the point. In hot path I understand using it, but not
everywhere.
> +/* sysfs knobs: stats and other diagnistics */
Johannes also commented about this. Please use debugfs or some generic
interface.
--
Kalle Valo
^ permalink raw reply
* Re: [athk9] beacon.c:642 ath9k_calculate_summary_state dump
From: Kalle Valo @ 2016-09-17 13:29 UTC (permalink / raw)
To: Vidar Haarr; +Cc: linux-wireless
In-Reply-To: <CAJiC63F-O5KeCP+JZjW38uNDc=umXcOZVGma_SyiaTm70fGQ3A@mail.gmail.com>
Vidar Haarr <vidar@heidrunbryggeri.no> writes:
> I'm seeing the message below spammed continously in journald, even
> with 4.8-rc6. It's so bad that it throttles the CPU performance every
> few seconds.
>
> I found https://patchwork.kernel.org/patch/9247699/ which seems related.
[...]
> sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
> /home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
> ath9k_calculate_summary_state+0x135/0x390 [ath9k]
Looks like exactly the same problem, but the fix (below) is not in
v4.8-rc6. Should be in -rc7 which Linus hopefully releases on Sunday.
Please test that and report if the problem continues.
05860bed491b ath9k: fix client mode beacon configuration
--
Kalle Valo
^ permalink raw reply
* [athk9] beacon.c:642 ath9k_calculate_summary_state dump
From: Vidar Haarr @ 2016-09-17 9:49 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm seeing the message below spammed continously in journald, even
with 4.8-rc6. It's so bad that it throttles the CPU performance every
few seconds.
I found https://patchwork.kernel.org/patch/9247699/ which seems related.
I am not subscribed to linux-wireless.
First, here's some system info, then the stack trace at the bottom.
$ lspci
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM
Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210
Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset
Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset
Family PCI Express Root Port 2 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset
Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC
Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family
6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family
SMBus Controller (rev 04)
02:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network
Adapter (rev 01)
$ sudo lshw -class network
[sudo] passord for folk:
*-network
description: Wireless interface
product: AR9462 Wireless Network Adapter
vendor: Qualcomm Atheros
physical id: 0
bus info: pci@0000:02:00.0
logical name: wlan0
version: 01
serial: 24:ec:99:7f:0e:30
width: 64 bits
clock: 33MHz
capabilities: pm msi pciexpress bus_master cap_list rom
ethernet physical wireless
configuration: broadcast=yes driver=ath9k
driverversion=4.8.0-040800rc6-generic firmware=N/A ip=192.168.1.176
latency=0 link=yes multicast=yes wireless=IEEE 802.11
resources: irq:17 memory:f0400000-f047ffff memory:f0480000-f048ffff
$ uname -a
Linux edbpc 4.8.0-040800rc6-generic #201609121119 SMP Mon Sep 12
15:21:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
rfkill list all
0: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
1: phy0: Wireless LAN
Soft blocked: no
Hard blocked: no
sep. 17 11:38:36 edbpc kernel: WARNING: CPU: 0 PID: 1684 at
/home/kernel/COD/linux/drivers/net/wireless/ath/ath9k/beacon.c:642
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel: Modules linked in: fuse ctr ccm
binfmt_misc nls_utf8 nls_cp437 vfat fat intel_rapl
x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_hdmi
snd_hda_codec_realtek snd_hda_codec_generic arc4 snd_hda_intel
snd_hda_codec snd_hda_core ath9k snd_hwdep ath9k_common ath9k_hw
snd_pcm ath kvm_intel snd_seq_midi uvcvideo snd_seq_midi_event
mac80211 kvm videobuf2_vmalloc snd_rawmidi irqbypass videobuf2_memops
snd_seq crct10dif_pclmul videobuf2_v4l2 crc32_pclmul videobuf2_core
snd_seq_device videodev ghash_clmulni_intel cryptd intel_cstate
cfg80211 media intel_rapl_perf snd_timer ath3k btusb btrtl btbcm
btintel efi_pstore bluetooth snd joydev rfkill efivars lpc_ich
serio_raw sg shpchp mei_me soundcore mfd_core mei evdev fujitsu_laptop
battery ac tpm_tis tpm_tis_core tpm lp parport loop efivarfs
sep. 17 11:38:36 edbpc kernel: ip_tables x_tables autofs4 ext4 crc16
jbd2 fscrypto mbcache hid_generic usbhid hid uas usb_storage sd_mod
i915 ahci crc32c_intel libahci libata psmouse i2c_algo_bit scsi_mod
drm_kms_helper xhci_pci syscopyarea ehci_pci xhci_hcd sysfillrect
ehci_hcd sysimgblt fb_sys_fops usbcore drm usb_common fan thermal
video fjes button
sep. 17 11:38:36 edbpc kernel: CPU: 0 PID: 1684 Comm: kworker/u16:0
Tainted: G W 4.8.0-040800rc6-generic #201609121119
sep. 17 11:38:36 edbpc kernel: Hardware name: FUJITSU LIFEBOOK
UH572/FJNBB31 , BIOS 2.15 07/29/2013
sep. 17 11:38:36 edbpc kernel: Workqueue: phy0 ieee80211_scan_work [mac80211]
sep. 17 11:38:36 edbpc kernel: 0000000000000286 00000000189cb902
ffffffffab33fb84 0000000000000000
sep. 17 11:38:36 edbpc kernel: 0000000000000000 ffffffffab07f69e
ffff96690ec45580 ffff96690ec46e10
sep. 17 11:38:36 edbpc kernel: ffff96690ec74018 ffff96690ec74018
ffff966912773360 ffff966912773360
sep. 17 11:38:36 edbpc kernel: Call Trace:
sep. 17 11:38:36 edbpc kernel: [<ffffffffab33fb84>] ? dump_stack+0x5c/0x78
sep. 17 11:38:36 edbpc kernel: [<ffffffffab07f69e>] ? __warn+0xbe/0xe0
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a0b5>] ?
ath9k_calculate_summary_state+0x135/0x390 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a332>] ?
ath_complete_reset+0x22/0x130 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a55e>] ?
ath_reset_internal+0x11e/0x1e0 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b7a656>] ?
ath_reset+0x36/0x50 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b82e5a>] ?
ath_chanctx_set_channel+0x13a/0x250 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc0b796c9>] ?
ath9k_config+0xb9/0x1e0 [ath9k]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09a9d05>] ?
ieee80211_hw_config+0x85/0x3e0 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09b52ed>] ?
__ieee80211_scan_completed+0xfd/0x470 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffc09b5eeb>] ?
ieee80211_scan_work+0x7b/0x490 [mac80211]
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098ae4>] ?
process_one_work+0x184/0x4b0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098e5d>] ? worker_thread+0x4d/0x480
sep. 17 11:38:36 edbpc kernel: [<ffffffffab6188b1>] ? __schedule+0x261/0x720
sep. 17 11:38:36 edbpc kernel: [<ffffffffab098e10>] ?
process_one_work+0x4b0/0x4b0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab09efbd>] ? kthread+0xcd/0xf0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab02c751>] ? __switch_to+0x2c1/0x7a0
sep. 17 11:38:36 edbpc kernel: [<ffffffffab61d41f>] ? ret_from_fork+0x1f/0x40
sep. 17 11:38:36 edbpc kernel: [<ffffffffab09eef0>] ?
kthread_create_on_node+0x1a0/0x1a0
sep. 17 11:38:36 edbpc kernel: ---[ end trace 4e47cb6784f0f49d ]---
--
Vidar
^ permalink raw reply
* Re: [PATCH 4/4] ath10k: fix spurious tx/rx during boot
From: Hsu, Ryan @ 2016-09-16 22:37 UTC (permalink / raw)
To: michal.kazior@tieto.com, Valo, Kalle
Cc: marek.puzyniak@tieto.com, linux-wireless@vger.kernel.org,
ath10k@lists.infradead.org
In-Reply-To: <1468924452-23877-5-git-send-email-michal.kazior@tieto.com>
On 07/19/2016 03:34 AM, Michal Kazior wrote:
> =20
> +static int ath10k_core_reset_rx_filter(struct ath10k *ar)
> +{
> + int ret;
> + int vdev_id;
> + int vdev_type;
> + int vdev_subtype;
> + const u8 *vdev_addr;
> +
> + vdev_id =3D 0;
> + vdev_type =3D WMI_VDEV_TYPE_STA;
> + vdev_subtype =3D ath10k_wmi_get_vdev_subtype(ar, WMI_VDEV_SUBTYPE_NONE)=
;
> + vdev_addr =3D ar->mac_addr;
> +
> + ret =3D ath10k_wmi_vdev_create(ar, vdev_id, vdev_type, vdev_subtype,
> + vdev_addr);
> + if (ret) {
> + ath10k_err(ar, "failed to create dummy vdev: %d\n", ret);
> + return ret;
> + }
> +
> + ret =3D ath10k_wmi_vdev_delete(ar, vdev_id);
> + if (ret) {
> + ath10k_err(ar, "failed to delete dummy vdev: %d\n", ret);
> + return ret;
> + }
> +
> + /* WMI and HTT may use separate HIF pipes and are not guaranteed to be
> + * serialized properly implicitly.
> + *
> + * Moreover (most) WMI commands have no explicit acknowledges. It is
> + * possible to infer it implicitly by poking firmware with echo
> + * command - getting a reply means all preceding comments have been
> + * (mostly) processed.
> + *
> + * In case of vdev create/delete this is sufficient.
> + *
> + * Without this it's possible to end up with a race when HTT Rx ring is
> + * started before vdev create/delete hack is complete allowing a short
> + * window of opportunity to receive (and Tx ACK) a bunch of frames.
> + */
> + ret =3D ath10k_wmi_barrier(ar);
QCA6174 UTF firmware seems doesn't support the WMI_ECHO command.
[16460.274822] ath10k_pci 0000:04:00.0: wmi tlv echo value 0x0ba991e9
...
[16463.461970] ath10k_pci 0000:04:00.0: failed to ping firmware: -110
[16463.461975] ath10k_pci 0000:04:00.0: failed to reset rx filter: -110
Has anyone verified any AP solution to see if UTF mode is still working=20
with after this patch?
Anyway, I would like to exclude the workaround from all solution's UTF mode=
.
Michal any concerns? (or maybe just for QCA61x4 if any...)
> + if (ret) {
> + ath10k_err(ar, "failed to ping firmware: %d\n", ret);
> + return ret;
> + }
> +
> + return 0;
> +}
>
^ permalink raw reply
* Re: [PATCH] cfg80211: cap 20MHz VHT bitrate at MCS 8
From: Pedersen, Thomas @ 2016-09-16 18:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: Ben Greear, linux-wireless
In-Reply-To: <1473789740.5622.3.camel@sipsolutions.net>
T24gVHVlLCAyMDE2LTA5LTEzIGF0IDIwOjAyICswMjAwLCBKb2hhbm5lcyBCZXJnIHdyb3RlOg0K
PiA+IFllYWggc28gYXBwYXJlbnRseSB0aGUgb3ZlcmhlYWQgaW52b2x2ZWQgaW4gMjU2LVFBTSA1
LzYgKE1DUyA5KQ0KPiA+IHJlc3VsdHMgaW4gbG93ZXIgZWZmZWN0aXZlIGJpdHJhdGUgdGhhbiBq
dXN0IHVzaW5nIE1DUyA4ICh1bmxlc3MNCj4gPiB5b3UncmUgdXNpbmcgMyBzcGF0aWFsIHN0cmVh
bXMpLg0KPiANCj4gQWguIEkgdG9vayBhIC0gdmVyeSBicmllZiAtIGxvb2sgYXQgd2h5IHRoaXMg
b25lIGlzIGludmFsaWQgYW5kDQo+IGNvdWxkbid0IGZpZ3VyZSBpdCBvdXQuDQoNCkkgZG9uJ3Qg
a25vdyB3aGF0IEknbSB0YWxraW5nIGFib3V0LiBUaGlzIHdhcyBhIG1pc2NvbW11bmljYXRpb24g
ZnJvbQ0KdGhlIHN5c3RlbXMgdGVhbS4gSSB0aGluayBpdCB3YXMgYmVjYXVzZSBFVk0gdGFyZ2V0
cyB3ZXJlIHRvbyBoaWdoLCBidXQNCkxEUEMgZml4ZXMgdGhhdCwgc2VlIGJlbG93Lg0KDQo+ID4g
IFNvdW5kcyBsaWtlIGEgcmF0ZSBjb250cm9sIG9yIHJlcG9ydGluZyBidWcgdGhlbi4NCj4gPiBQ
bGVhc2UgZHJvcCB0aGlzLg0KPiA+IA0KPiBPaywgdGhhbmtzLg0KDQpBY3R1YWxseSwgY2FuIHlv
dSBhcHBseSB0aGUgdjIgKGNmZzgwMjExOiBhZGQgYml0cmF0ZSBmb3IgMjBNSHogTUNTIDkpDQpv
ZiB0aGlzPyBTeXN0ZW1zIGd1eXMgY29uZmlybWVkIHRoZXkgdXNlIE1DUyA5IEAgMjBNSHogd2hl
biBMRFBDIGlzDQplbmFibGVkLiBBbHNvIGNvbmZpcm1lZCBiaXRyYXRlIHNob3VsZCBiZSBvay4N
Cg0KVGhhbmtzLA0KDQp0aG9tYXMNCg==
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox