* Re: [PATCH v2 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:24 UTC (permalink / raw)
To: linux-wireless, Linux Kernel, linux-mmc, devicetree
Cc: Tony Lindgren, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052218.10534-3-matt@ranostay.consulting>
On Thu, Jan 12, 2017 at 9:22 PM, Matt Ranostay <matt@ranostay.consulting> wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
Er crap seems how the main patch file got dropped out. Resubmitting in
a minute... sorry!
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> drivers/mmc/core/Kconfig | 10 ++++++++++
> drivers/mmc/core/Makefile | 1 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
> This driver can also be built as a module. If so, the module
> will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> + tristate "HW reset support for SD8787 BT + Wifi module"
> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> + help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
> config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
> mmc_core-$(CONFIG_OF) += pwrseq.o
> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH v3 1/2] devicetree: document new marvell-8xxx and pwrseq-sd8787 options
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
In-Reply-To: <20170113052937.12538-1-matt@ranostay.consulting>
Cc: devicetree@vger.kernel.org
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 ++++++++++++++
.../devicetree/bindings/net/wireless/marvell-8xxx.txt | 7 ++++++-
2 files changed, 20 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
diff --git a/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
new file mode 100644
index 000000000000..1b658351629b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
@@ -0,0 +1,14 @@
+* Marvell SD8787 power sequence provider
+
+Required properties:
+- compatible: must be "mmc-pwrseq-sd8787".
+- pwndn-gpio: contains a power down GPIO specifier.
+- reset-gpio: contains a reset GPIO specifier.
+
+Example:
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-sd8787";
+ pwrdn-gpio = <&twl_gpio 0 GPIO_ACTIVE_LOW>;
+ reset-gpio = <&twl_gpio 1 GPIO_ACTIVE_LOW>;
+ }
diff --git a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
index 980b16df74c3..0854451ff91d 100644
--- a/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
+++ b/Documentation/devicetree/bindings/net/wireless/marvell-8xxx.txt
@@ -1,4 +1,4 @@
-Marvell 8897/8997 (sd8897/sd8997/pcie8997) SDIO/PCIE devices
+Marvell 8787/8897/8997 (sd8787/sd8897/sd8997/pcie8997) SDIO/PCIE devices
------
This node provides properties for controlling the Marvell SDIO/PCIE wireless device.
@@ -8,6 +8,7 @@ connects the device to the system.
Required properties:
- compatible : should be one of the following:
+ * "marvell,sd8787"
* "marvell,sd8897"
* "marvell,sd8997"
* "pci11ab,2b42"
@@ -34,6 +35,9 @@ Optional properties:
so that the wifi chip can wakeup host platform under certain condition.
during system resume, the irq will be disabled to make sure
unnecessary interrupt is not received.
+ - vmmc-supply: a phandle of a regulator, supplying VCC to the card
+ - mmc-pwrseq: phandle to the MMC power sequence node. See "mmc-pwrseq-*"
+ for documentation of MMC power sequence bindings.
Example:
@@ -46,6 +50,7 @@ so that firmware can wakeup host using this device side pin.
&mmc3 {
status = "okay";
vmmc-supply = <&wlan_en_reg>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
cap-power-off-card;
keep-power-in-suspend;
--
2.10.2
^ permalink raw reply related
* [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree
Cc: tony, Matt Ranostay, Ulf Hansson
In-Reply-To: <20170113052937.12538-1-matt@ranostay.consulting>
Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
This can be abstracted to other chipsets if needed in the future.
Cc: Tony Lindgren <tony@atomide.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
---
drivers/mmc/core/Kconfig | 10 ++++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
3 files changed, 128 insertions(+)
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index cdfa8520a4b1..fc1ecdaaa9ca 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -12,6 +12,16 @@ config PWRSEQ_EMMC
This driver can also be built as a module. If so, the module
will be called pwrseq_emmc.
+config PWRSEQ_SD8787
+ tristate "HW reset support for SD8787 BT + Wifi module"
+ depends on OF && (MWIFIEX || BT_MRVL_SDIO)
+ help
+ This selects hardware reset support for the SD8787 BT + Wifi
+ module. By default this option is set to n.
+
+ This driver can also be built as a module. If so, the module
+ will be called pwrseq_sd8787.
+
config PWRSEQ_SIMPLE
tristate "Simple HW reset support for MMC"
default y
diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
index b2a257dc644f..0f81464fa824 100644
--- a/drivers/mmc/core/Makefile
+++ b/drivers/mmc/core/Makefile
@@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
quirks.o slot-gpio.o
mmc_core-$(CONFIG_OF) += pwrseq.o
obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
+obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
new file mode 100644
index 000000000000..f4080fe6439e
--- /dev/null
+++ b/drivers/mmc/core/pwrseq_sd8787.c
@@ -0,0 +1,117 @@
+/*
+ * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
+ *
+ * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
+ *
+ * Based on the original work pwrseq_simple.c
+ * Copyright (C) 2014 Linaro Ltd
+ * Author: Ulf Hansson <ulf.hansson@linaro.org>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include <linux/delay.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/platform_device.h>
+#include <linux/module.h>
+#include <linux/slab.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/gpio/consumer.h>
+
+#include <linux/mmc/host.h>
+
+#include "pwrseq.h"
+
+struct mmc_pwrseq_sd8787 {
+ struct mmc_pwrseq pwrseq;
+ struct gpio_desc *reset_gpio;
+ struct gpio_desc *pwrdn_gpio;
+};
+
+#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
+
+static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
+
+ msleep(300);
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
+}
+
+static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
+
+ gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
+ gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
+}
+
+static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
+ .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
+ .power_off = mmc_pwrseq_sd8787_power_off,
+};
+
+static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
+ { .compatible = "mmc-pwrseq-sd8787",},
+ {/* sentinel */},
+};
+MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
+
+static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq;
+ struct device *dev = &pdev->dev;
+
+ pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
+ if (!pwrseq)
+ return -ENOMEM;
+
+ pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->pwrdn_gpio))
+ return PTR_ERR(pwrseq->pwrdn_gpio);
+
+ pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
+ if (IS_ERR(pwrseq->reset_gpio))
+ return PTR_ERR(pwrseq->reset_gpio);
+
+ pwrseq->pwrseq.dev = dev;
+ pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
+ pwrseq->pwrseq.owner = THIS_MODULE;
+ platform_set_drvdata(pdev, pwrseq);
+
+ return mmc_pwrseq_register(&pwrseq->pwrseq);
+}
+
+static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
+{
+ struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
+
+ mmc_pwrseq_unregister(&pwrseq->pwrseq);
+
+ return 0;
+}
+
+static struct platform_driver mmc_pwrseq_sd8787_driver = {
+ .probe = mmc_pwrseq_sd8787_probe,
+ .remove = mmc_pwrseq_sd8787_remove,
+ .driver = {
+ .name = "pwrseq_sd8787",
+ .of_match_table = mmc_pwrseq_sd8787_of_match,
+ },
+};
+
+module_platform_driver(mmc_pwrseq_sd8787_driver);
+MODULE_LICENSE("GPL v2");
--
2.10.2
^ permalink raw reply related
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
* [PATCH v3 0/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Matt Ranostay @ 2017-01-13 5:29 UTC (permalink / raw)
To: linux-wireless, linux-kernel, linux-mmc, devicetree; +Cc: tony, Matt Ranostay
Changes from v1:
* split devictree docs from pwrseq changes
* rebase devicetree documents due to filename change
* rebase pwrseq patchset
Changes from v2:
* fix rookie mistake missing the main source file and docs
Matt Ranostay (2):
devicetree: document new marvell-8xxx and pwrseq-sd8787 options
mmc: pwrseq: add support for Marvell SD8787 chip
.../devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt | 14 +++
.../bindings/net/wireless/marvell-8xxx.txt | 7 +-
drivers/mmc/core/Kconfig | 10 ++
drivers/mmc/core/Makefile | 1 +
drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++
5 files changed, 148 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/mmc/mmc-pwrseq-sd8787.txt
create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
--
2.10.2
^ permalink raw reply
* Re: [PATCH v3 2/2] mmc: pwrseq: add support for Marvell SD8787 chip
From: Shawn Lin @ 2017-01-13 7:16 UTC (permalink / raw)
To: Matt Ranostay, linux-wireless, linux-kernel, linux-mmc,
devicetree
Cc: shawn.lin, tony, Ulf Hansson
In-Reply-To: <20170113052937.12538-3-matt@ranostay.consulting>
On 2017/1/13 13:29, Matt Ranostay wrote:
> Allow power sequencing for the Marvell SD8787 Wifi/BT chip.
> This can be abstracted to other chipsets if needed in the future.
>
> Cc: Tony Lindgren <tony@atomide.com>
> Cc: Ulf Hansson <ulf.hansson@linaro.org>
> Signed-off-by: Matt Ranostay <matt@ranostay.consulting>
> ---
> drivers/mmc/core/Kconfig | 10 ++++
> drivers/mmc/core/Makefile | 1 +
> drivers/mmc/core/pwrseq_sd8787.c | 117 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 128 insertions(+)
> create mode 100644 drivers/mmc/core/pwrseq_sd8787.c
>
> diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
> index cdfa8520a4b1..fc1ecdaaa9ca 100644
> --- a/drivers/mmc/core/Kconfig
> +++ b/drivers/mmc/core/Kconfig
> @@ -12,6 +12,16 @@ config PWRSEQ_EMMC
> This driver can also be built as a module. If so, the module
> will be called pwrseq_emmc.
>
> +config PWRSEQ_SD8787
> + tristate "HW reset support for SD8787 BT + Wifi module"
> + depends on OF && (MWIFIEX || BT_MRVL_SDIO)
> + help
> + This selects hardware reset support for the SD8787 BT + Wifi
> + module. By default this option is set to n.
> +
> + This driver can also be built as a module. If so, the module
> + will be called pwrseq_sd8787.
> +
I don't like this way, as we have a chance to list lots
configure options here. wifi A,B,C,D...Z, all of them need a
new section here if needed?
Instead, could you just extent pwrseq_simple.c and add you
.compatible = "mmc-pwrseq-sd8787", "mmc-pwrseq-simple"?
> config PWRSEQ_SIMPLE
> tristate "Simple HW reset support for MMC"
> default y
> diff --git a/drivers/mmc/core/Makefile b/drivers/mmc/core/Makefile
> index b2a257dc644f..0f81464fa824 100644
> --- a/drivers/mmc/core/Makefile
> +++ b/drivers/mmc/core/Makefile
> @@ -10,6 +10,7 @@ mmc_core-y := core.o bus.o host.o \
> quirks.o slot-gpio.o
> mmc_core-$(CONFIG_OF) += pwrseq.o
> obj-$(CONFIG_PWRSEQ_SIMPLE) += pwrseq_simple.o
> +obj-$(CONFIG_PWRSEQ_SD8787) += pwrseq_sd8787.o
> obj-$(CONFIG_PWRSEQ_EMMC) += pwrseq_emmc.o
> mmc_core-$(CONFIG_DEBUG_FS) += debugfs.o
> obj-$(CONFIG_MMC_BLOCK) += mmc_block.o
> diff --git a/drivers/mmc/core/pwrseq_sd8787.c b/drivers/mmc/core/pwrseq_sd8787.c
> new file mode 100644
> index 000000000000..f4080fe6439e
> --- /dev/null
> +++ b/drivers/mmc/core/pwrseq_sd8787.c
> @@ -0,0 +1,117 @@
> +/*
> + * pwrseq_sd8787.c - power sequence support for Marvell SD8787 BT + Wifi chip
> + *
> + * Copyright (C) 2016 Matt Ranostay <matt@ranostay.consulting>
> + *
> + * Based on the original work pwrseq_simple.c
> + * Copyright (C) 2014 Linaro Ltd
> + * Author: Ulf Hansson <ulf.hansson@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include <linux/delay.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/platform_device.h>
> +#include <linux/module.h>
> +#include <linux/slab.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/gpio/consumer.h>
> +
> +#include <linux/mmc/host.h>
> +
> +#include "pwrseq.h"
> +
> +struct mmc_pwrseq_sd8787 {
> + struct mmc_pwrseq pwrseq;
> + struct gpio_desc *reset_gpio;
> + struct gpio_desc *pwrdn_gpio;
> +};
> +
> +#define to_pwrseq_sd8787(p) container_of(p, struct mmc_pwrseq_sd8787, pwrseq)
> +
> +static void mmc_pwrseq_sd8787_pre_power_on(struct mmc_host *host)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
> +
> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 1);
> +
> + msleep(300);
> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 1);
> +}
> +
> +static void mmc_pwrseq_sd8787_power_off(struct mmc_host *host)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = to_pwrseq_sd8787(host->pwrseq);
> +
> + gpiod_set_value_cansleep(pwrseq->pwrdn_gpio, 0);
> + gpiod_set_value_cansleep(pwrseq->reset_gpio, 0);
> +}
> +
> +static const struct mmc_pwrseq_ops mmc_pwrseq_sd8787_ops = {
> + .pre_power_on = mmc_pwrseq_sd8787_pre_power_on,
> + .power_off = mmc_pwrseq_sd8787_power_off,
> +};
> +
> +static const struct of_device_id mmc_pwrseq_sd8787_of_match[] = {
> + { .compatible = "mmc-pwrseq-sd8787",},
> + {/* sentinel */},
> +};
> +MODULE_DEVICE_TABLE(of, mmc_pwrseq_sd8787_of_match);
> +
> +static int mmc_pwrseq_sd8787_probe(struct platform_device *pdev)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq;
> + struct device *dev = &pdev->dev;
> +
> + pwrseq = devm_kzalloc(dev, sizeof(*pwrseq), GFP_KERNEL);
> + if (!pwrseq)
> + return -ENOMEM;
> +
> + pwrseq->pwrdn_gpio = devm_gpiod_get(dev, "pwrdn", GPIOD_OUT_LOW);
> + if (IS_ERR(pwrseq->pwrdn_gpio))
> + return PTR_ERR(pwrseq->pwrdn_gpio);
> +
> + pwrseq->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
> + if (IS_ERR(pwrseq->reset_gpio))
> + return PTR_ERR(pwrseq->reset_gpio);
> +
> + pwrseq->pwrseq.dev = dev;
> + pwrseq->pwrseq.ops = &mmc_pwrseq_sd8787_ops;
> + pwrseq->pwrseq.owner = THIS_MODULE;
> + platform_set_drvdata(pdev, pwrseq);
> +
> + return mmc_pwrseq_register(&pwrseq->pwrseq);
> +}
> +
> +static int mmc_pwrseq_sd8787_remove(struct platform_device *pdev)
> +{
> + struct mmc_pwrseq_sd8787 *pwrseq = platform_get_drvdata(pdev);
> +
> + mmc_pwrseq_unregister(&pwrseq->pwrseq);
> +
> + return 0;
> +}
> +
> +static struct platform_driver mmc_pwrseq_sd8787_driver = {
> + .probe = mmc_pwrseq_sd8787_probe,
> + .remove = mmc_pwrseq_sd8787_remove,
> + .driver = {
> + .name = "pwrseq_sd8787",
> + .of_match_table = mmc_pwrseq_sd8787_of_match,
> + },
> +};
> +
> +module_platform_driver(mmc_pwrseq_sd8787_driver);
> +MODULE_LICENSE("GPL v2");
>
--
Best Regards
Shawn Lin
^ permalink raw reply
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Johannes Berg @ 2017-01-13 8:16 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, greearb, mohammed
In-Reply-To: <1484231321-3179-1-git-send-email-michal.kazior@tieto.com>
On Thu, 2017-01-12 at 15:28 +0100, Michal Kazior wrote:
> Station structure is considered as not uploaded
> (to driver) until drv_sta_state() finishes. This
> call is however done after the structure is
> attached to mac80211 internal lists and hashes.
> This means mac80211 can lookup (and use) station
> structure before it is uploaded to a driver.
>
> If this happens (structure exists, but
> sta->uploaded is false) fast_tx path can still be
> taken. Deep in the fastpath call the sta->uploaded
> is checked against to derive "pubsta" argument for
> ieee80211_get_txq(). If sta->uploaded is false
> (and sta is actually non-NULL) ieee80211_get_txq()
> effectively downgraded to vif->txq.
>
> At first glance this may look innocent but coerces
> mac80211 into a state that is almost guaranteed
> (codel may drop offending skb) to crash because a
> station-oriented skb gets queued up on
> vif-oriented txq. The ieee80211_tx_dequeue() ends
> up looking at info->control.flags and tries to use
> txq->sta which in the fail case is NULL.
>
> It's probably pointless to pretend one can
> downgrade skb from sta-txq to vif-txq.
Ok. I understand things until this point, more or less.
What I don't understand - and you haven't really described - is how the
changes fix it? Could you resend with a paragraph added that explains
that?
Also, you're adding a test:
> if (sta && !sta->uploaded)
but couldn't do move that into the existing "if (sta)" block?
Everything before that only ever returns NULL anyway.
johannes
^ permalink raw reply
* Re: [v2,12/13] wil6210: set dma mask to reflect device capability
From: Kalle Valo @ 2017-01-13 8:20 UTC (permalink / raw)
To: Maya Erez; +Cc: Kalle Valo, Hamad Kadmany, linux-wireless, wil6210, Maya Erez
In-Reply-To: <1484226365-10433-13-git-send-email-qca_merez@qca.qualcomm.com>
Maya Erez <qca_merez@qca.qualcomm.com> wrote:
> From: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
>
> 11ad device supports 48 bit addresses, reflect that
> by setting the dma mask accordingly.
>
> Signed-off-by: Hamad Kadmany <qca_hkadmany@qca.qualcomm.com>
> Signed-off-by: Maya Erez <qca_merez@qca.qualcomm.com>
Dropped per Maya's request
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9513167/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] mac80211: initialize SMPS field in HT capabilities
From: Johannes Berg @ 2017-01-13 8:20 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: onelektra
In-Reply-To: <20170111223322.14698-1-nbd@nbd.name>
On Wed, 2017-01-11 at 23:33 +0100, Felix Fietkau wrote:
> ibss and mesh modes copy the ht capabilites from the band without
> overriding the SMPS state. Unfortunately the default value 0 for the
> SMPS field means static SMPS instead of disabled.
>
> This results in HT ibss and mesh setups using only single-stream
> rates,
> even though SMPS is not supposed to be active.
>
> Initialize SMPS to disabled for all bands on ieee80211_hw_register to
> ensure that the value is sane where it is not overriden with the real
> SMPS state.
Hmm. I guess the only other place affected by it will be scanning?
> Reported-by: Elektra Wagenrad <onelektra@gmx.net>
> Signed-off-by: Felix Fietkau <nbd@nbd.name>
> ---
> net/mac80211/main.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index 1822c77f2b1c..c269046aa02b 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -913,10 +913,15 @@ int ieee80211_register_hw(struct ieee80211_hw
> *hw)
> supp_ht = supp_ht || sband->ht_cap.ht_supported;
> supp_vht = supp_vht || sband->vht_cap.vht_supported;
>
> - if (sband->ht_cap.ht_supported)
> - local->rx_chains =
> - max(ieee80211_mcs_to_chains(&sband-
> >ht_cap.mcs),
> - local->rx_chains);
> + if (!sband->ht_cap.ht_supported)
> + continue;
> +
> + local->rx_chains =
> + max(ieee80211_mcs_to_chains(&sband-
> >ht_cap.mcs),
> + local->rx_chains);
> +
> + sband->ht_cap.cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
> + IEEE80211_HT_CAP_SM_PS_SHIFT;
This ... looks fishy. I know it's not, since it sets both bits, but
still.
Additionally, ath10k appears to be setting this to
WLAN_HT_CAP_SM_PS_DYNAMIC already, so apparently it's expecting
something to happen with that value? Is it really correct then to be
overwriting it?
johannes
^ permalink raw reply
* Re: [PATCH] ath10k: prevent sta pointer rcu violation
From: Michal Kazior @ 2017-01-13 8:32 UTC (permalink / raw)
To: Johannes Berg
Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org,
Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <1484292252.19860.5.camel@sipsolutions.net>
On 13 January 2017 at 08:24, Johannes Berg <johannes@sipsolutions.net> wrot=
e:
>
>> Unless you then continue to use that sta pointer after you release
>> data_lock.
>
> Ouch, ok. That's rather strangely hidden though.
>
>> Consider this:
>>
>> > CPU0 CPU1
>> > 1 synchronize_net()
>> > 2 drv_sta_state()
>> > 3 htt_fetch_ind(pid,tid) called
>> > 4 rcu_read_lock()
>> > 5 get(data_lock)
>> > 6 txq=3Dpeers[pid]->sta->txq[tid]
>> > 7 put(data_lock)
>> > 8 get(data_lock)
>> > 9 peer->sta=3D0
>> > 10 put(data_lock)
>> > 11 kfree(sta)
>> > 12 ieee80211_tx_dequeue(txq)
>>
>> Even though there's no code like (9) per se you can think of it as
>> anything that tries to "remove" the peer--sta association
>> (ath10k_peer
>> is removed implicitly via wmi peer delete command and waiting for htt
>> event completion).
>>
>> Holding data_lock for the entire duration of handling fetch
>> indication isn't really good for performance so it's better to fix
>> RCU handling.
>
> Yeah, I see it now - also the comment where this happens. You probably
> should mark some things __rcu though and actually use RCU primitives,
> so the code is actually understandable :)
Good point. I'll do that in another patch.
Micha=C5=82
^ permalink raw reply
* Re: [PATCH] ath10k: prevent sta pointer rcu violation
From: Johannes Berg @ 2017-01-13 7:24 UTC (permalink / raw)
To: Michal Kazior
Cc: Kalle Valo, linux-wireless, ath10k@lists.infradead.org,
Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <CA+BoTQkgD5umVsGnRM4uu_8GO=KjQ6MuJCjQRnSHrDuQdU4z1w@mail.gmail.com>
> Unless you then continue to use that sta pointer after you release
> data_lock.
Ouch, ok. That's rather strangely hidden though.
> Consider this:
>
> > CPU0 CPU1
> > 1 synchronize_net()
> > 2 drv_sta_state()
> > 3 htt_fetch_ind(pid,tid) called
> > 4 rcu_read_lock()
> > 5 get(data_lock)
> > 6 txq=peers[pid]->sta->txq[tid]
> > 7 put(data_lock)
> > 8 get(data_lock)
> > 9 peer->sta=0
> > 10 put(data_lock)
> > 11 kfree(sta)
> > 12 ieee80211_tx_dequeue(txq)
>
> Even though there's no code like (9) per se you can think of it as
> anything that tries to "remove" the peer--sta association
> (ath10k_peer
> is removed implicitly via wmi peer delete command and waiting for htt
> event completion).
>
> Holding data_lock for the entire duration of handling fetch
> indication isn't really good for performance so it's better to fix
> RCU handling.
Yeah, I see it now - also the comment where this happens. You probably
should mark some things __rcu though and actually use RCU primitives,
so the code is actually understandable :)
johannes
^ permalink raw reply
* [PATCH] wext: uninline point wrappers
From: Johannes Berg @ 2017-01-13 8:37 UTC (permalink / raw)
To: linux-wireless; +Cc: Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
With 78, 111 and 85 bytes respectively, the functions
iwe_stream_add_event(), iwe_stream_add_point() and
iwe_stream_add_value() really shouldn't be inlines.
It appears that at least my compiler already decided
the same, and created a single instance of each one
of them for each file using it, but that's still a
number of instances in the system overall, which this
reduces.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/iw_handler.h | 67 +++++-------------------------------------------
net/wireless/wext-core.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 74 insertions(+), 60 deletions(-)
diff --git a/include/net/iw_handler.h b/include/net/iw_handler.h
index c2aa73e5e6bb..2509728650bd 100644
--- a/include/net/iw_handler.h
+++ b/include/net/iw_handler.h
@@ -505,25 +505,8 @@ static inline int iwe_stream_event_len_adjust(struct iw_request_info *info,
/*
* Wrapper to add an Wireless Event to a stream of events.
*/
-static inline char *
-iwe_stream_add_event(struct iw_request_info *info, char *stream, char *ends,
- struct iw_event *iwe, int event_len)
-{
- int lcp_len = iwe_stream_lcp_len(info);
-
- event_len = iwe_stream_event_len_adjust(info, event_len);
-
- /* Check if it's possible */
- if(likely((stream + event_len) < ends)) {
- iwe->len = event_len;
- /* Beware of alignement issues on 64 bits */
- memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
- memcpy(stream + lcp_len, &iwe->u,
- event_len - lcp_len);
- stream += event_len;
- }
- return stream;
-}
+char *iwe_stream_add_event(struct iw_request_info *info, char *stream,
+ char *ends, struct iw_event *iwe, int event_len);
static inline char *
iwe_stream_add_event_check(struct iw_request_info *info, char *stream,
@@ -541,27 +524,8 @@ iwe_stream_add_event_check(struct iw_request_info *info, char *stream,
* Wrapper to add an short Wireless Event containing a pointer to a
* stream of events.
*/
-static inline char *
-iwe_stream_add_point(struct iw_request_info *info, char *stream, char *ends,
- struct iw_event *iwe, char *extra)
-{
- int event_len = iwe_stream_point_len(info) + iwe->u.data.length;
- int point_len = iwe_stream_point_len(info);
- int lcp_len = iwe_stream_lcp_len(info);
-
- /* Check if it's possible */
- if(likely((stream + event_len) < ends)) {
- iwe->len = event_len;
- memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
- memcpy(stream + lcp_len,
- ((char *) &iwe->u) + IW_EV_POINT_OFF,
- IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
- if (iwe->u.data.length && extra)
- memcpy(stream + point_len, extra, iwe->u.data.length);
- stream += event_len;
- }
- return stream;
-}
+char *iwe_stream_add_point(struct iw_request_info *info, char *stream,
+ char *ends, struct iw_event *iwe, char *extra);
static inline char *
iwe_stream_add_point_check(struct iw_request_info *info, char *stream,
@@ -580,25 +544,8 @@ iwe_stream_add_point_check(struct iw_request_info *info, char *stream,
* Be careful, this one is tricky to use properly :
* At the first run, you need to have (value = event + IW_EV_LCP_LEN).
*/
-static inline char *
-iwe_stream_add_value(struct iw_request_info *info, char *event, char *value,
- char *ends, struct iw_event *iwe, int event_len)
-{
- int lcp_len = iwe_stream_lcp_len(info);
-
- /* Don't duplicate LCP */
- event_len -= IW_EV_LCP_LEN;
-
- /* Check if it's possible */
- if(likely((value + event_len) < ends)) {
- /* Add new value */
- memcpy(value, &iwe->u, event_len);
- value += event_len;
- /* Patch LCP */
- iwe->len = value - event;
- memcpy(event, (char *) iwe, lcp_len);
- }
- return value;
-}
+char *iwe_stream_add_value(struct iw_request_info *info, char *event,
+ char *value, char *ends, struct iw_event *iwe,
+ int event_len);
#endif /* _IW_HANDLER_H */
diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 6250b1cfcde5..1a4db6790e20 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -1119,3 +1119,70 @@ int compat_wext_handle_ioctl(struct net *net, unsigned int cmd,
return ret;
}
#endif
+
+char *iwe_stream_add_event(struct iw_request_info *info, char *stream,
+ char *ends, struct iw_event *iwe, int event_len)
+{
+ int lcp_len = iwe_stream_lcp_len(info);
+
+ event_len = iwe_stream_event_len_adjust(info, event_len);
+
+ /* Check if it's possible */
+ if (likely((stream + event_len) < ends)) {
+ iwe->len = event_len;
+ /* Beware of alignement issues on 64 bits */
+ memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+ memcpy(stream + lcp_len, &iwe->u,
+ event_len - lcp_len);
+ stream += event_len;
+ }
+
+ return stream;
+}
+EXPORT_SYMBOL(iwe_stream_add_event);
+
+char *iwe_stream_add_point(struct iw_request_info *info, char *stream,
+ char *ends, struct iw_event *iwe, char *extra)
+{
+ int event_len = iwe_stream_point_len(info) + iwe->u.data.length;
+ int point_len = iwe_stream_point_len(info);
+ int lcp_len = iwe_stream_lcp_len(info);
+
+ /* Check if it's possible */
+ if (likely((stream + event_len) < ends)) {
+ iwe->len = event_len;
+ memcpy(stream, (char *) iwe, IW_EV_LCP_PK_LEN);
+ memcpy(stream + lcp_len,
+ ((char *) &iwe->u) + IW_EV_POINT_OFF,
+ IW_EV_POINT_PK_LEN - IW_EV_LCP_PK_LEN);
+ if (iwe->u.data.length && extra)
+ memcpy(stream + point_len, extra, iwe->u.data.length);
+ stream += event_len;
+ }
+
+ return stream;
+}
+EXPORT_SYMBOL(iwe_stream_add_point);
+
+char *iwe_stream_add_value(struct iw_request_info *info, char *event,
+ char *value, char *ends, struct iw_event *iwe,
+ int event_len)
+{
+ int lcp_len = iwe_stream_lcp_len(info);
+
+ /* Don't duplicate LCP */
+ event_len -= IW_EV_LCP_LEN;
+
+ /* Check if it's possible */
+ if (likely((value + event_len) < ends)) {
+ /* Add new value */
+ memcpy(value, &iwe->u, event_len);
+ value += event_len;
+ /* Patch LCP */
+ iwe->len = value - event;
+ memcpy(event, (char *) iwe, lcp_len);
+ }
+
+ return value;
+}
+EXPORT_SYMBOL(iwe_stream_add_value);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH v3 1/4] cfg80211: Add support to randomize TA of Public Action frames
From: Johannes Berg @ 2017-01-13 8:49 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1484262742-3927-1-git-send-email-jouni@qca.qualcomm.com>
Thanks for the updates, I've applied all of these patches (with 2 very
minor modifications that I've documented in the commit logs)
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: initialize SMPS field in HT capabilities
From: Felix Fietkau @ 2017-01-13 8:54 UTC (permalink / raw)
To: Johannes Berg, linux-wireless; +Cc: onelektra
In-Reply-To: <1484295655.19860.9.camel@sipsolutions.net>
On 2017-01-13 09:20, Johannes Berg wrote:
> On Wed, 2017-01-11 at 23:33 +0100, Felix Fietkau wrote:
>> ibss and mesh modes copy the ht capabilites from the band without
>> overriding the SMPS state. Unfortunately the default value 0 for the
>> SMPS field means static SMPS instead of disabled.
>>
>> This results in HT ibss and mesh setups using only single-stream
>> rates,
>> even though SMPS is not supposed to be active.
>>
>> Initialize SMPS to disabled for all bands on ieee80211_hw_register to
>> ensure that the value is sane where it is not overriden with the real
>> SMPS state.
>
> Hmm. I guess the only other place affected by it will be scanning?
Right.
>> Reported-by: Elektra Wagenrad <onelektra@gmx.net>
>> Signed-off-by: Felix Fietkau <nbd@nbd.name>
>> ---
>> net/mac80211/main.c | 13 +++++++++----
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
>> index 1822c77f2b1c..c269046aa02b 100644
>> --- a/net/mac80211/main.c
>> +++ b/net/mac80211/main.c
>> @@ -913,10 +913,15 @@ int ieee80211_register_hw(struct ieee80211_hw
>> *hw)
>> supp_ht = supp_ht || sband->ht_cap.ht_supported;
>> supp_vht = supp_vht || sband->vht_cap.vht_supported;
>>
>> - if (sband->ht_cap.ht_supported)
>> - local->rx_chains =
>> - max(ieee80211_mcs_to_chains(&sband-
>> >ht_cap.mcs),
>> - local->rx_chains);
>> + if (!sband->ht_cap.ht_supported)
>> + continue;
>> +
>> + local->rx_chains =
>> + max(ieee80211_mcs_to_chains(&sband-
>> >ht_cap.mcs),
>> + local->rx_chains);
>> +
>> + sband->ht_cap.cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
>> + IEEE80211_HT_CAP_SM_PS_SHIFT;
>
> This ... looks fishy. I know it's not, since it sets both bits, but
> still.
>
> Additionally, ath10k appears to be setting this to
> WLAN_HT_CAP_SM_PS_DYNAMIC already, so apparently it's expecting
> something to happen with that value? Is it really correct then to be
> overwriting it?
Actually, that code seems to leave the value at
WLAN_HT_CAP_SM_PS_DISABLED, because it sets that first and doesn't mask
out the field before trying to set it to WLAN_HT_CAP_SM_PS_DYNAMIC.
I don't think it even makes sense to set WLAN_HT_CAP_SM_PS_DYNAMIC at
this point, since it's up to mac80211 to deal with the SMPS state.
Either way, WLAN_HT_CAP_SM_PS_STATIC is a really bad default to have at
init time. If you want, I can change the patch to check for that value
before changing it, but I don't really see the point.
Additionally, I found this ath10k commit:
commit e33a99e227e430a788467e5a85dc29f6df16b983
Author: Peter Oh <poh@qca.qualcomm.com>
Date: Thu Dec 31 15:26:20 2015 +0200
ath10k: set SM power save disabled to default value
Use SMPS disabled as default because FW does not indicate
any support of SMPS.
This change will help STAs out that don’t support SMPS from
sticking on 1SS, since they don’t have method to change it
back to multiple chains.
This change also should not affect power consumption of STAs
supporting SMPS, because they are capable to switch the mode
to dynamic or static either at the end of frame sequence or
by using SMPS action frame.
Signed-off-by: Peter Oh <poh@qca.qualcomm.com>
Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b4bdeb07a012..6146a293601a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3860,7 +3860,8 @@ static struct ieee80211_sta_ht_cap ath10k_get_ht_cap(struct ath10k *ar)
ht_cap.ampdu_density = IEEE80211_HT_MPDU_DENSITY_8;
ht_cap.cap |= IEEE80211_HT_CAP_SUP_WIDTH_20_40;
ht_cap.cap |= IEEE80211_HT_CAP_DSSSCCK40;
- ht_cap.cap |= WLAN_HT_CAP_SM_PS_STATIC << IEEE80211_HT_CAP_SM_PS_SHIFT;
+ ht_cap.cap |=
+ WLAN_HT_CAP_SM_PS_DISABLED << IEEE80211_HT_CAP_SM_PS_SHIFT;
if (ar->ht_cap_info & WMI_HT_CAP_HT20_SGI)
ht_cap.cap |= IEEE80211_HT_CAP_SGI_20;
- Felix
^ permalink raw reply related
* [PATCH] cfg80211: fix a documentation warning
From: Johannes Berg @ 2017-01-13 9:02 UTC (permalink / raw)
To: linux-wireless; +Cc: corbet, linux-doc, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
The new restructured text parser complains about the formatting,
and really this should be a definition list.
Unfortunately, due to it being inside the parameter description,
and the definition list needing a blank line, this adds trailing
whitespace to keep it in the parameter description.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/cfg80211.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index b7aba6e1a586..181e2d544a1b 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -3190,10 +3190,13 @@ struct ieee80211_iface_limit {
* @radar_detect_regions: bitmap of regions supported for radar detection
* @beacon_int_min_gcd: This interface combination supports different
* beacon intervals.
- * = 0 - all beacon intervals for different interface must be same.
- * > 0 - any beacon interval for the interface part of this combination AND
- * *GCD* of all beacon intervals from beaconing interfaces of this
- * combination must be greater or equal to this value.
+ *
+ * = 0
+ * all beacon intervals for different interface must be same.
+ * > 0
+ * any beacon interval for the interface part of this combination AND
+ * GCD of all beacon intervals from beaconing interfaces of this
+ * combination must be greater or equal to this value.
*
* With this structure the driver can describe which interface
* combinations it supports concurrently.
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] mac80211: prevent skb/txq mismatch
From: Michal Kazior @ 2017-01-13 9:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Ben Greear, Mohammed Shafi Shajakhan
In-Reply-To: <1484295383.19860.7.camel@sipsolutions.net>
On 13 January 2017 at 09:16, Johannes Berg <johannes@sipsolutions.net> wrot=
e:
> On Thu, 2017-01-12 at 15:28 +0100, Michal Kazior wrote:
>> Station structure is considered as not uploaded
>> (to driver) until drv_sta_state() finishes. This
>> call is however done after the structure is
>> attached to mac80211 internal lists and hashes.
>> This means mac80211 can lookup (and use) station
>> structure before it is uploaded to a driver.
>>
>> If this happens (structure exists, but
>> sta->uploaded is false) fast_tx path can still be
>> taken. Deep in the fastpath call the sta->uploaded
>> is checked against to derive "pubsta" argument for
>> ieee80211_get_txq(). If sta->uploaded is false
>> (and sta is actually non-NULL) ieee80211_get_txq()
>> effectively downgraded to vif->txq.
>>
>> At first glance this may look innocent but coerces
>> mac80211 into a state that is almost guaranteed
>> (codel may drop offending skb) to crash because a
>> station-oriented skb gets queued up on
>> vif-oriented txq. The ieee80211_tx_dequeue() ends
>> up looking at info->control.flags and tries to use
>> txq->sta which in the fail case is NULL.
>>
>> It's probably pointless to pretend one can
>> downgrade skb from sta-txq to vif-txq.
>
> Ok. I understand things until this point, more or less.
>
> What I don't understand - and you haven't really described - is how the
> changes fix it? Could you resend with a paragraph added that explains
> that?
"Since downgrading unicast traffic to vif->txq must not be done
there's no txq to put a frame on if sta->uploaded is false. Therefore
the code is made to fall back to regular tx() op path if the described
condition is hit. " -- is this sufficient?
> Also, you're adding a test:
>
>> if (sta && !sta->uploaded)
>
> but couldn't do move that into the existing "if (sta)" block?
> Everything before that only ever returns NULL anyway.
Good point. It makes more sense to put the sta->uploaded check in if
(sta) block. I'll move it.
Micha=C5=82
^ permalink raw reply
* Re: [PATCH 6/9] rt2800: fallback from mcs8 to mcs7
From: Stanislaw Gruszka @ 2017-01-13 9:09 UTC (permalink / raw)
To: Felix Fietkau; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin, Kalle Valo
In-Reply-To: <e3c3f693-3d34-ecfc-de13-855c1d75b849@nbd.name>
On Thu, Jan 12, 2017 at 12:10:48PM +0100, Felix Fietkau wrote:
> On 2017-01-06 14:05, Stanislaw Gruszka wrote:
> > If we do not fallback to lower rate, we are unable to calculate
> > correctly number of retries in TX status code.
> >
> > Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
> I think falling back from the lowest dual-stream to the highest
> single-stream rate is a really bad idea.
Ok, Kalle please drop this patch.
> Instead you should get rid of the assumption that fallback rates are
> ordered by their MCS index.
I think I will stay with the current code. With decreased retry
limit setting in other patch, problem is mitigated. For newer
chips there is retry count TX_STA_FIFO_EXT register, so I'll look
into that.
Thanks
Stanislaw
^ permalink raw reply
* Re: [6/9] rt2800: fallback from mcs8 to mcs7
From: Kalle Valo @ 2017-01-13 10:11 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: linux-wireless, Helmut Schaa, Mathias Kresin
In-Reply-To: <1483707918-31480-7-git-send-email-sgruszka@redhat.com>
Stanislaw Gruszka <sgruszka@redhat.com> wrote:
> If we do not fallback to lower rate, we are unable to calculate
> correctly number of retries in TX status code.
>
> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Dropping per Stanislaw's request
Patch set to Changes Requested.
--
https://patchwork.kernel.org/patch/9500913/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* [PATCH] mac80211: fix documentation warnings
From: Johannes Berg @ 2017-01-13 10:12 UTC (permalink / raw)
To: linux-wireless; +Cc: corbet, linux-doc, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
For a few restructured text warnings in mac80211, making the
documentation warning-free (for now). Again, this required
adding trailing whitespace to keep multiple paragraphs in a
parameter description together.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 28 ++++++++++++++++++----------
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 86967b85dfd0..228c72617916 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1771,10 +1771,12 @@ struct ieee80211_sta_rates {
* @max_amsdu_len: indicates the maximal length of an A-MSDU in bytes. This
* field is always valid for packets with a VHT preamble. For packets
* with a HT preamble, additional limits apply:
- * + If the skb is transmitted as part of a BA agreement, the
- * A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
- * + If the skb is not part of a BA aggreement, the A-MSDU maximal
- * size is min(max_amsdu_len, 7935) bytes.
+ *
+ * * If the skb is transmitted as part of a BA agreement, the
+ * A-MSDU maximal size is min(max_amsdu_len, 4065) bytes.
+ * * If the skb is not part of a BA aggreement, the A-MSDU maximal
+ * size is min(max_amsdu_len, 7935) bytes.
+ *
* Both additional HT limits must be enforced by the low level driver.
* This is defined by the spec (IEEE 802.11-2012 section 8.3.2.2 NOTE 2).
* @support_p2p_ps: indicates whether the STA supports P2P PS mechanism or not.
@@ -3212,14 +3214,20 @@ enum ieee80211_reconfig_type {
* nor send aggregates in a way that lost frames would exceed the
* buffer size. If just limiting the aggregate size, this would be
* possible with a buf_size of 8:
- * - TX: 1.....7
- * - RX: 2....7 (lost frame #1)
- * - TX: 8..1...
+ *
+ * - ``TX: 1.....7``
+ * - ``RX: 2....7`` (lost frame #1)
+ * - ``TX: 8..1...``
+ *
* which is invalid since #1 was now re-transmitted well past the
* buffer size of 8. Correct ways to retransmit #1 would be:
- * - TX: 1 or 18 or 81
- * Even "189" would be wrong since 1 could be lost again.
- *
+ *
+ * - ``TX: 1 or``
+ * - ``TX: 18 or``
+ * - ``TX: 81``
+ *
+ * Even ``189`` would be wrong since 1 could be lost again.
+ *
* Returns a negative error code on failure.
* The callback can sleep.
*
--
2.9.3
^ permalink raw reply related
* Re: [PATCH] mac80211: initialize SMPS field in HT capabilities
From: Johannes Berg @ 2017-01-13 10:20 UTC (permalink / raw)
To: Felix Fietkau, linux-wireless; +Cc: onelektra
In-Reply-To: <ba04d61c-3f80-573f-3108-c94a9c991404@nbd.name>
On Fri, 2017-01-13 at 09:54 +0100, Felix Fietkau wrote:
> > Additionally, ath10k appears to be setting this to
> > WLAN_HT_CAP_SM_PS_DYNAMIC already, so apparently it's expecting
> > something to happen with that value? Is it really correct then to
> > be overwriting it?
>
> Actually, that code seems to leave the value at
> WLAN_HT_CAP_SM_PS_DISABLED, because it sets that first and doesn't
> mask out the field before trying to set it to
> WLAN_HT_CAP_SM_PS_DYNAMIC.
Hah, that's funny.
> I don't think it even makes sense to set WLAN_HT_CAP_SM_PS_DYNAMIC at
> this point, since it's up to mac80211 to deal with the SMPS state.
>
> Either way, WLAN_HT_CAP_SM_PS_STATIC is a really bad default to have
> at init time. If you want, I can change the patch to check for that
> value before changing it, but I don't really see the point.
No, I think I agree. But please add a comment that OR'ing in the two
bits will not result in it having strange values - it's a bit
unexpected to see this here and then one has to remember (or look up)
the value of DISABLED to understand the code is fine.
> Additionally, I found this ath10k commit:
>
>
> commit e33a99e227e430a788467e5a85dc29f6df16b983
> Author: Peter Oh <poh@qca.qualcomm.com>
> Date: Thu Dec 31 15:26:20 2015 +0200
>
> ath10k: set SM power save disabled to default value
>
> Use SMPS disabled as default because FW does not indicate
> any support of SMPS.
>
> This change will help STAs out that don’t support SMPS from
> sticking on 1SS, since they don’t have method to change it
> back to multiple chains.
>
> This change also should not affect power consumption of STAs
> supporting SMPS, because they are capable to switch the mode
> to dynamic or static either at the end of frame sequence or
> by using SMPS action frame.
Fun. Though I'd argue that this whole thing should then just be removed
from ath10k.
johannes
^ permalink raw reply
* Re: [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Rafał Miłecki @ 2017-01-13 10:23 UTC (permalink / raw)
To: Kalle Valo
Cc: linux-wireless@vger.kernel.org, Felix Fietkau,
Rafał Miłecki
In-Reply-To: <87fuknl0x9.fsf@codeaurora.org>
On 13 January 2017 at 11:16, Kalle Valo <kvalo@codeaurora.org> wrote:
> Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
>
>> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>>
>> This reverts commit 4c81acab3816 ("bcma: init serial console directly
>> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
>> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
>> *after* ChipCommon initialization so we can't do this so early.
>>
>> This fixes a regression but it seems noone noticed it for about a year.
>> It could be it was because serial was still somehow working, just
>> without IRQs. It doesn't look like a critical patch / fix.
>>
>> Reported-by: Felix Fietkau <nbd@nbd.name>
>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> So this is for 4.11? What about CC stable?
>
> I'll add a Fixes line:
>
> Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon =
code")
After hearing about policy for fixes getting more strict, I thought we
can get it for next only.
Thanks for "Fixes:", I wasn't sure if we need that for reverts.
--=20
Rafa=C5=82
^ permalink raw reply
* Re: [PATCH] Revert "bcma: init serial console directly from ChipCommon code"
From: Kalle Valo @ 2017-01-13 10:16 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Kalle Valo, linux-wireless, Felix Fietkau,
Rafał Miłecki
In-Reply-To: <20170112174451.7124-1-zajec5@gmail.com>
Rafa=C5=82 Mi=C5=82ecki <zajec5@gmail.com> writes:
> From: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
>
> This reverts commit 4c81acab3816 ("bcma: init serial console directly
> from ChipCommon code") as it broke IRQ assignment. Getting IRQ with
> bcma_core_irq helper on SoC requires MIPS core to be set. It happens
> *after* ChipCommon initialization so we can't do this so early.
>
> This fixes a regression but it seems noone noticed it for about a year.
> It could be it was because serial was still somehow working, just
> without IRQs. It doesn't look like a critical patch / fix.
>
> Reported-by: Felix Fietkau <nbd@nbd.name>
> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki <rafal@milecki.pl>
So this is for 4.11? What about CC stable?
I'll add a Fixes line:
Fixes: 4c81acab3816 ("bcma: init serial console directly from ChipCommon co=
de")
--=20
Kalle Valo
^ permalink raw reply
* [PATCH v2] mac80211: initialize SMPS field in HT capabilities
From: Felix Fietkau @ 2017-01-13 10:28 UTC (permalink / raw)
To: linux-wireless; +Cc: johannes, onelektra
ibss and mesh modes copy the ht capabilites from the band without
overriding the SMPS state. Unfortunately the default value 0 for the
SMPS field means static SMPS instead of disabled.
This results in HT ibss and mesh setups using only single-stream rates,
even though SMPS is not supposed to be active.
Initialize SMPS to disabled for all bands on ieee80211_hw_register to
ensure that the value is sane where it is not overriden with the real
SMPS state.
Reported-by: Elektra Wagenrad <onelektra@gmx.net>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
v2: add comment about OR'ing the PS_DISABLED value
net/mac80211/main.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1822c77f2b1c..d253ce71d472 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -913,10 +913,16 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
supp_ht = supp_ht || sband->ht_cap.ht_supported;
supp_vht = supp_vht || sband->vht_cap.vht_supported;
- if (sband->ht_cap.ht_supported)
- local->rx_chains =
- max(ieee80211_mcs_to_chains(&sband->ht_cap.mcs),
- local->rx_chains);
+ if (!sband->ht_cap.ht_supported)
+ continue;
+
+ local->rx_chains =
+ max(ieee80211_mcs_to_chains(&sband->ht_cap.mcs),
+ local->rx_chains);
+
+ /* no need to mask, SM_PS_DISABLED has all bits set */
+ sband->ht_cap.cap |= WLAN_HT_CAP_SM_PS_DISABLED <<
+ IEEE80211_HT_CAP_SM_PS_SHIFT;
/* TODO: consider VHT for RX chains, hopefully it's the same */
}
--
2.11.0
^ permalink raw reply related
* Re: Searching new home for ath[59]k-devel mailing lists
From: Kalle Valo @ 2017-01-13 10:28 UTC (permalink / raw)
To: Michael Renzmann; +Cc: linux-wireless, ath5k-devel, ath9k-devel
In-Reply-To: <49328.217.24.3.26.1483895726.squirrel@webmail.madwifi-project.org>
"Michael Renzmann" <mrenzmann@madwifi-project.org> writes:
> Out of history, the ath5k-devel and ath9k-devel mailing lists have been
> and still are hosted on the mailing list server of the MadWifi project. I
> intend to shut the server down, and thus I'm searching a new loving home
> for the lists.
>
> Besides a new home the lists also need some attention - both would receive
> a fair amount of spam, and thus they need someone who takes care of some
> kind of moderating posts and/or filtering spam.
>
> To be honest, I've not been following things at all for many months. From
> what I can tell it seems that ath5k-devel is pretty quiet. ath9k-devel,
> however, still sees a fair amount of communication; but I didn't look at
> how much of that traffic actually took place here on linux-wireless, just
> CC'ing ath9k-devel.
> This is to say, if there is a broad agreement that one of the lists or
> both of them are no longer required, I'm fine with just closing them in an
> ordered fashion.
I really don't see any need for ath5k-devel, according to git log there
has been five patches for ath5k during the past year.
ath9k is of course a lot more active, 99 patches over the last year. But
still I get the feeling that we don't really need an ath9k specific
mailing list, discussion via linux-wireless should work. And if there
ever comes up a demand to have a dedicated list for ath9k we can then
try find a new one, for example from infradead.org.
So feel free to close both of the lists and thanks for the heads up. Are
you planning to update the MAINTAINERS file or should I?
--
Kalle Valo
^ permalink raw reply
* pull-request: mac80211-next 2017-01-13
From: Johannes Berg @ 2017-01-13 10:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
This is my first pull request for net-next, and it seems a bit
bigger than the past few releases. Detailed information below,
as usual.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 8fa3b6f9392bf6d90cb7b908e07bd90166639f0a:
Merge tag 'cris-for-4.10' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris (2016-12-12 09:06:38 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2017-01-13
for you to fetch changes up to c88215d7050f065afaed33e9599c2ef4e5e6ee22:
cfg80211: Fix documentation for connect result (2017-01-13 09:47:08 +0100)
----------------------------------------------------------------
For 4.11, we seem to have more than in the past few releases:
* socket owner support for connections, so when the wifi
manager (e.g. wpa_supplicant) is killed, connections are
torn down - wpa_supplicant is critical to managing certain
operations, and can opt in to this where applicable
* minstrel & minstrel_ht updates to be more efficient (time and space)
* set wifi_acked/wifi_acked_valid for skb->destructor use in the
kernel, which was already available to userspace
* don't indicate new mesh peers that might be used if there's no
room to add them
* multicast-to-unicast support in mac80211, for better medium usage
(since unicast frames can use *much* higher rates, by ~3 orders of
magnitude)
* add API to read channel (frequency) limitations from DT
* add infrastructure to allow randomizing public action frames for
MAC address privacy (still requires driver support)
* many cleanups and small improvements/fixes across the board
----------------------------------------------------------------
Andrzej Zaborowski (1):
cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
Arend Van Spriel (5):
cfg80211: get rid of name indirection trick for ieee80211_get_channel()
nl80211: check NL80211_ATTR_SCHED_SCAN_INTERVAL only once
nl80211: rework {sched_,}scan event related functions
nl80211: better describe field in struct nl80211_bss_select_rssi_adjust
cfg80211: only pass sband to set_mandatory_flags_band()
Arnd Bergmann (2):
rfkill: hide unused goto label
wext: handle NULL extra data in iwe_stream_add_point better
Ben Greear (1):
mac80211: Show pending txqlen in debugfs.
David Spinadel (1):
mac80211: Add RX flag to indicate ICV stripped
Felix Fietkau (9):
mac80211: minstrel_ht: move supported bitrate mask out of group data
mac80211: minstrel_ht: move short preamble check out of get_rate
mac80211: minstrel_ht: make att_hist and succ_hist u32 instead of u64
mac80211: check for MCS in ieee80211_duration before fetching chanctx
mac80211: minstrel: remove cur_prob from debugfs
mac80211: minstrel: reduce MINSTREL_SCALE
mac80211: minstrel: store probability variance instead of standard deviation
mac80211: minstrel: make prob_ewma u16 instead of u32
mac80211: minstrel_ht: remove obsolete #if for >= 3 streams
Ilan peer (1):
mac80211: Fix addition of mesh configuration element
Johannes Berg (7):
rfkill: simplify rfkill_set_hw_state() slightly
Revert "rfkill: Add rfkill-any LED trigger"
cfg80211: sysfs: use wiphy_name()
wireless: move IEEE80211_NUM_ACS to ieee80211.h
cfg80211: size various nl80211 messages correctly
mac80211: set wifi_acked[_valid] bits for transmitted SKBs
wext: uninline stream addition functions
Jorge Ramirez-Ortiz (1):
cfg80211: wext does not need to set monitor channel in managed mode
Jouni Malinen (1):
cfg80211: Fix documentation for connect result
Kirtika Ruchandani (7):
mac80211: Remove unused 'struct ieee80211_rx_status' ptr
mac80211: Remove unused 'rates_idx' variable
mac80211: Remove unused 'struct rate_control_ref' variable
mac80211: Remove unused 'i' variable
mac80211: Remove unused 'len' variable
mac80211: Remove unused 'sband' and 'local' variables
mac80211: Remove unused 'beaconint_us' variable
Koen Vandeputte (1):
mac80211: only alloc mem if a station doesn't exist yet
Masashi Honma (3):
mac80211: Suppress NEW_PEER_CANDIDATE event if no room
mac80211: Remove invalid flag operations in mesh TSF synchronization
mac80211: Use appropriate name for functions and messages
Michael Braun (2):
nl80211: multicast_to_unicast can be changed while IFF_UP
mac80211: multicast to unicast conversion
Michał Kępień (3):
rfkill: Cleanup error handling in rfkill_init()
rfkill: Add rfkill-any LED trigger
rfkill: Add rfkill-any LED trigger
Purushottam Kushwaha (1):
cfg80211: Specify the reason for connect timeout
Rafał Miłecki (5):
cfg80211: update wireless-regdb repo url in Documentation
cfg80211: fix example REG_RULE usage in Documentation
dt-bindings: document common IEEE 802.11 frequency limit property
cfg80211: move function checking range fit to util.c
cfg80211: support ieee80211-freq-limit DT property
Thomas Huehn (1):
mac80211: minstrel: avoid port control frames for sampling
vamsi krishna (2):
cfg80211: Add support for randomizing TA of Public Action frames
cfg80211: Add support to sched scan to report better BSSs
Documentation/80211/cfg80211.rst | 3 +
.../devicetree/bindings/net/wireless/ieee80211.txt | 24 ++++
Documentation/networking/regulatory.txt | 8 +-
drivers/net/wireless/ath/ath10k/htt_rx.c | 3 +-
drivers/net/wireless/marvell/mwifiex/cfg80211.c | 2 +-
include/linux/ieee80211.h | 2 +
include/net/cfg80211.h | 135 ++++++++++++++------
include/net/iw_handler.h | 66 ++--------
include/net/mac80211.h | 6 +-
include/uapi/linux/nl80211.h | 64 +++++++++-
net/mac80211/cfg.c | 12 ++
net/mac80211/chan.c | 4 +-
net/mac80211/debugfs.c | 27 ++++
net/mac80211/debugfs_netdev.c | 3 +
net/mac80211/ieee80211_i.h | 6 +-
net/mac80211/mesh.c | 7 +-
net/mac80211/mesh.h | 2 +-
net/mac80211/mesh_plink.c | 14 ++-
net/mac80211/mesh_sync.c | 27 ++--
net/mac80211/mlme.c | 4 -
net/mac80211/rc80211_minstrel.c | 21 ++--
net/mac80211/rc80211_minstrel.h | 33 ++---
net/mac80211/rc80211_minstrel_debugfs.c | 24 ++--
net/mac80211/rc80211_minstrel_ht.c | 68 +++-------
net/mac80211/rc80211_minstrel_ht.h | 6 +-
net/mac80211/rc80211_minstrel_ht_debugfs.c | 32 ++---
net/mac80211/rx.c | 4 -
net/mac80211/scan.c | 8 +-
net/mac80211/sta_info.c | 18 ++-
net/mac80211/status.c | 8 +-
net/mac80211/tx.c | 132 +++++++++++++++++++-
net/mac80211/vht.c | 4 -
net/mac80211/wep.c | 3 +-
net/mac80211/wpa.c | 3 +-
net/rfkill/core.c | 100 ++++++++++++---
net/wireless/Makefile | 1 +
net/wireless/core.c | 3 +
net/wireless/core.h | 8 +-
net/wireless/mlme.c | 29 ++++-
net/wireless/nl80211.c | 137 +++++++++++++-------
net/wireless/nl80211.h | 10 +-
net/wireless/of.c | 138 +++++++++++++++++++++
net/wireless/reg.c | 27 ++--
net/wireless/scan.c | 9 +-
net/wireless/sme.c | 72 +++++++++--
net/wireless/sysfs.c | 6 +-
net/wireless/util.c | 30 +++--
net/wireless/wext-core.c | 67 ++++++++++
net/wireless/wext-sme.c | 23 ----
49 files changed, 1016 insertions(+), 427 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/wireless/ieee80211.txt
create mode 100644 net/wireless/of.c
^ 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