Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[David Miller]

From: Marcel Holtmann 
Date: Wed, 22 Mar 2017 20:23:15 +0100

> Hi Dave,
> 
>>> By moving these client drivers to use RPMSG instead of the direct SMD
>>> API we can reuse them ontop of the newly added GLINK wire-protocol
>>> support found in the 820 and 835 Qualcomm platforms.
>>> 
>>> As the new (RPMSG-based) and old SMD implementations are mutually
>>> exclusive we have to change all client drivers in one commit, to make
>>> sure we have a working system before and after this transition.
>>> 
>>> Signed-off-by: Bjorn Andersson 
>>> ---
>>> 
>>> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
>>> (https://lkml.org/lkml/2017/3/20/1038).
>> 
>> Just some questions since I'm supposed to merge this into my net-next
>> tree.
>> 
>> What is the status of the Kconfig dependency fix and how will I be
>> getting it?
> 
> I acked that one separately and added you:
> 
> [PATCH v2] Bluetooth: btqcomsmd: fix compile-test dependency

I applied this to my 'net' tree, thanks.

Re: [PATCH 4.11] genetlink: fix counting regression on ctrl_dumpfamily()

[David Miller]

From: Stanislaw Gruszka 
Date: Wed, 22 Mar 2017 16:08:33 +0100

> Commit 2ae0f17df1cd ("genetlink: use idr to track families") replaced
> 
>   if (++n < fams_to_skip)
>   continue;
> into:
> 
>   if (n++ < fams_to_skip)
>   continue;
> 
> This subtle change cause that on retry ctrl_dumpfamily() call we omit
> one family that failed to do ctrl_fill_info() on previous call, because
> cb->args[0] = n number counts also family that failed to do
> ctrl_fill_info().
> 
> Patch fixes the problem and avoid confusion in the future just decrease
> n counter when ctrl_fill_info() fail.
> 
> User visible problem caused by this bug is failure to get access to
> some genetlink family i.e. nl80211. However problem is reproducible
> only if number of registered genetlink families is big enough to
> cause second call of ctrl_dumpfamily().
> 
> Cc: Xose Vazquez Perez 
> Cc: Larry Finger 
> Cc: Johannes Berg 
> Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
> Signed-off-by: Stanislaw Gruszka 

Applied and queued up for -stable, thanks.

Re: [PATCH 4.11] genetlink: fix counting regression on ctrl_dumpfamily()

[Johannes Berg]

On Wed, 2017-03-22 at 16:08 +0100, Stanislaw Gruszka wrote:
> Commit 2ae0f17df1cd ("genetlink: use idr to track families") replaced
> 
>   if (++n < fams_to_skip)
>   continue;
> into:
> 
>   if (n++ < fams_to_skip)
>   continue;

D'oh. I don't know how that ended up in there, tbh.

Acked-by: Johannes Berg 

johannes

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[Bjorn Andersson]

On Wed 22 Mar 11:44 PDT 2017, David Miller wrote:

> From: Bjorn Andersson 
> Date: Mon, 20 Mar 2017 16:35:42 -0700
> 
> > By moving these client drivers to use RPMSG instead of the direct SMD
> > API we can reuse them ontop of the newly added GLINK wire-protocol
> > support found in the 820 and 835 Qualcomm platforms.
> > 
> > As the new (RPMSG-based) and old SMD implementations are mutually
> > exclusive we have to change all client drivers in one commit, to make
> > sure we have a working system before and after this transition.
> > 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> > (https://lkml.org/lkml/2017/3/20/1038).
> 
> Just some questions since I'm supposed to merge this into my net-next
> tree.
> 
> What is the status of the Kconfig dependency fix and how will I be
> getting it?
> 

There are two Kconfig dependencies in play here, the first is
c3104aae5d8c ("remoteproc: qcom: fix QCOM_SMD dependencies"), this was
picked up by Linus yesterday and will as such be in v4.10-rc4.

The other dependency, is the one Marcel wants you to pick up here is
https://patchwork.kernel.org/patch/9635385/. It's on LKML, but if you
want I can resend it with you as direct recipient, with Marcel's ack.

Likely Arnd would like this fix to be sent upstream for v4.11 already.

> Second, should I merge all three of these patches to net-next or just
> this one?
> 

I would like all three to be merged in this cycle and in addition I have
a couple of patches coming up that will cause some minor conflicts with
patch 2 - so I would prefer if patch 2 was available in a tag I can
merge into my tree.

Would it be possible for you to prepare merge all 4 (these 3 and the
bluetooth fix) and prepare a tag for Andy, Marcel and myself to include
in our trees?

Regards,
Bjorn

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[Andy Gross]

On Wed, Mar 22, 2017 at 11:44:39AM -0700, David Miller wrote:
> From: Bjorn Andersson 
> Date: Mon, 20 Mar 2017 16:35:42 -0700
> 
> > By moving these client drivers to use RPMSG instead of the direct SMD
> > API we can reuse them ontop of the newly added GLINK wire-protocol
> > support found in the 820 and 835 Qualcomm platforms.
> > 
> > As the new (RPMSG-based) and old SMD implementations are mutually
> > exclusive we have to change all client drivers in one commit, to make
> > sure we have a working system before and after this transition.
> > 
> > Signed-off-by: Bjorn Andersson 
> > ---
> > 
> > Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> > (https://lkml.org/lkml/2017/3/20/1038).
> 
> Just some questions since I'm supposed to merge this into my net-next
> tree.
> 
> What is the status of the Kconfig dependency fix and how will I be
> getting it?
> 
> Second, should I merge all three of these patches to net-next or just
> this one?

David,
I ack'd all three.  Please take these through your tree.


Bjorn,
Are we going to need an immutable branch or tag for sychronizing work?

Regards,

Andy Gross

Re: [PATCH 3/3] soc: qcom: smd-rpm: Add msm8996 compatibility

[Andy Gross]

On Mon, Mar 20, 2017 at 04:35:44PM -0700, Bjorn Andersson wrote:
> With the RPM driver transitioned to RPMSG we can reuse the SMD-RPM
> driver ontop of GLINK for 8996, without any modifications.
> 
> Signed-off-by: Bjorn Andersson 

Acked-by: Andy Gross 

Re: [PATCH 2/3] soc: qcom: smd: Remove standalone driver

[Andy Gross]

On Mon, Mar 20, 2017 at 04:35:43PM -0700, Bjorn Andersson wrote:
> Remove the standalone SMD implementation as we have transitioned the
> client drivers to use the RPMSG based one.
> 
> Also remove all dependencies on QCOM_SMD from Kconfig files, in order to
> keep them selectable in the absence of the removed symbol.
> 
> Signed-off-by: Bjorn Andersson 

Acked-by: Andy Gross 

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[Andy Gross]

On Mon, Mar 20, 2017 at 04:35:42PM -0700, Bjorn Andersson wrote:
> By moving these client drivers to use RPMSG instead of the direct SMD
> API we can reuse them ontop of the newly added GLINK wire-protocol
> support found in the 820 and 835 Qualcomm platforms.
> 
> As the new (RPMSG-based) and old SMD implementations are mutually
> exclusive we have to change all client drivers in one commit, to make
> sure we have a working system before and after this transition.
> 
> Signed-off-by: Bjorn Andersson 
> ---

For the qcom/smd parts:

Acked-by: Andy Gross 

Re: [PATCH] brcmfmac: update BRCMFMAC symbol description

[Rafał Miłecki]

On 2017-03-22 20:38, Arend Van Spriel wrote:

On 21-3-2017 15:43, Rafał Miłecki wrote:

From: Rafał Miłecki 

For quite some time now brcmfmac supports 802.11ac chipsets and it's
not limited to embedded devices only. There are even standalone PCIe
cards based on BCM43602 or BCM4366.


minor comments below.

Reviewed-by: Arend van Spriel 

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/Kconfig | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
b/drivers/net/wireless/broadcom/brcm80211/Kconfig

index d93561f6ef97..817cb28f518f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
+++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
@@ -18,14 +18,14 @@ config BRCMSMAC
  module, the driver will be called brcmsmac.ko.

 config BRCMFMAC
-   tristate "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
+   tristate "Broadcom IEEE802.11n WLAN driver"


You still mention 11n. Let's drop the 'n' here or IEEE802.11n entirely
like below. Would like to keep the term FullMAC though.


No idea how I missed that. Even commit message says we support 802.11ac 
now ;)

[PATCH v2 1/5] NFC: pn544: Get rid of platform data

[Andy Shevchenko]

Legacy platform data must go away. We are on the safe side here since
there are no users of it in the kernel.

If anyone by any odd reason needs it the GPIO lookup tables and
built-in device properties at your service.

Signed-off-by: Andy Shevchenko 
---
 drivers/nfc/pn544/i2c.c | 43 ++---
 include/linux/platform_data/pn544.h | 43 -
 2 files changed, 6 insertions(+), 80 deletions(-)
 delete mode 100644 include/linux/platform_data/pn544.h

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index f837c39a8017..41e518ee148e 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -31,7 +31,7 @@
 #include 
 #include 
 #include 
-#include 
+
 #include 
 
 #include 
@@ -973,7 +973,6 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
 {
struct pn544_i2c_phy *phy;
-   struct pn544_nfc_platform_data *pdata;
int r = 0;
 
dev_dbg(>dev, "%s\n", __func__);
@@ -995,32 +994,13 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
 
-   pdata = client->dev.platform_data;
-
/* No platform data, using device tree. */
-   if (!pdata && client->dev.of_node) {
+   if (client->dev.of_node) {
r = pn544_hci_i2c_of_request_resources(client);
if (r) {
nfc_err(>dev, "No DT data\n");
return r;
}
-   /* Using platform data. */
-   } else if (pdata) {
-
-   if (pdata->request_resources == NULL) {
-   nfc_err(>dev, "request_resources() missing\n");
-   return -EINVAL;
-   }
-
-   r = pdata->request_resources(client);
-   if (r) {
-   nfc_err(>dev,
-   "Cannot get platform resources\n");
-   return r;
-   }
-
-   phy->gpio_en = pdata->get_gpio(NFC_GPIO_ENABLE);
-   phy->gpio_fw = pdata->get_gpio(NFC_GPIO_FW_RESET);
/* Using ACPI */
} else if (ACPI_HANDLE(>dev)) {
r = pn544_hci_i2c_acpi_request_resources(client);
@@ -1057,12 +1037,8 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
free_irq(client->irq, phy);
 
 err_rti:
-   if (!pdata) {
-   gpio_free(phy->gpio_en);
-   gpio_free(phy->gpio_fw);
-   } else if (pdata->free_resources) {
-   pdata->free_resources();
-   }
+   gpio_free(phy->gpio_en);
+   gpio_free(phy->gpio_fw);
 
return r;
 }
@@ -1070,7 +1046,6 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
 static int pn544_hci_i2c_remove(struct i2c_client *client)
 {
struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
-   struct pn544_nfc_platform_data *pdata = client->dev.platform_data;
 
dev_dbg(>dev, "%s\n", __func__);
 
@@ -1085,14 +1060,8 @@ static int pn544_hci_i2c_remove(struct i2c_client 
*client)
 
free_irq(client->irq, phy);
 
-   /* No platform data, GPIOs have been requested by this driver */
-   if (!pdata) {
-   gpio_free(phy->gpio_en);
-   gpio_free(phy->gpio_fw);
-   /* Using platform data */
-   } else if (pdata->free_resources) {
-   pdata->free_resources();
-   }
+   gpio_free(phy->gpio_en);
+   gpio_free(phy->gpio_fw);
 
return 0;
 }
diff --git a/include/linux/platform_data/pn544.h 
b/include/linux/platform_data/pn544.h
deleted file mode 100644
index 5ce1ab983f44..
--- a/include/linux/platform_data/pn544.h
+++ /dev/null
@@ -1,43 +0,0 @@
-/*
- * Driver include for the PN544 NFC chip.
- *
- * Copyright (C) Nokia Corporation
- *
- * Author: Jari Vanhala 
- * Contact: Matti Aaltoenn 
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, see .
- */
-
-#ifndef _PN544_H_
-#define _PN544_H_
-
-#include 
-
-enum {
-   NFC_GPIO_ENABLE,
-   NFC_GPIO_FW_RESET,
-   NFC_GPIO_IRQ
-};
-
-/* board config */
-struct pn544_nfc_platform_data {
-   int (*request_resources) (struct i2c_client *client);
-   void (*free_resources) (void);
-   void (*enable) (int fw);

[PATCH v2 4/5] NFC: pn544: Add GPIO ACPI mapping table

[Andy Shevchenko]

In order to make GPIO ACPI library stricter prepare users of
gpiod_get_index() to correctly behave when there no mapping is
provided by firmware.

Here we add explicit mapping between _CRS GpioIo() resources and
their names used in the driver.

Signed-off-by: Andy Shevchenko 
---
 drivers/nfc/pn544/i2c.c | 21 +
 1 file changed, 17 insertions(+), 4 deletions(-)

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 5e780e7a28e5..6226d220f1d0 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -870,22 +870,34 @@ static void pn544_hci_i2c_fw_work(struct work_struct 
*work)
}
 }
 
+static const struct acpi_gpio_params enable_gpios = { 1, 0, false };
+static const struct acpi_gpio_params firmware_gpios = { 2, 0, false };
+
+static const struct acpi_gpio_mapping acpi_pn544_gpios[] = {
+   { "enable-gpios", _gpios, 1 },
+   { "firmware-gpios", _gpios, 1 },
+   { },
+};
+
 static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
 {
struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
struct device *dev = >dev;
+   int ret;
+
+   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_pn544_gpios);
+   if (ret)
+   return ret;
 
/* Get EN GPIO from ACPI */
-   phy->gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1,
-GPIOD_OUT_LOW);
+   phy->gpiod_en = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
if (IS_ERR(phy->gpiod_en)) {
nfc_err(dev, "Unable to get EN GPIO\n");
return PTR_ERR(phy->gpiod_en);
}
 
/* Get FW GPIO from ACPI */
-   phy->gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2,
-GPIOD_OUT_LOW);
+   phy->gpiod_fw = devm_gpiod_get(dev, "firmware", GPIOD_OUT_LOW);
if (IS_ERR(phy->gpiod_fw)) {
nfc_err(dev, "Unable to get FW GPIO\n");
return PTR_ERR(phy->gpiod_fw);
@@ -997,6 +1009,7 @@ static int pn544_hci_i2c_remove(struct i2c_client *client)
if (phy->powered)
pn544_hci_i2c_disable(phy);
 
+   acpi_dev_remove_driver_gpios(ACPI_COMPANION(>dev));
return 0;
 }
 
-- 
2.11.0

[PATCH v2 3/5] NFC: pn544: Convert to use devm_request_threaded_irq()

[Andy Shevchenko]

The error handling will be neat and short when using managed resources.

Convert the driver to use devm_request_threaded_irq().

Signed-off-by: Andy Shevchenko 
---
 drivers/nfc/pn544/i2c.c | 16 +---
 1 file changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index b4001306aff8..5e780e7a28e5 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -963,9 +963,10 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
 
pn544_hci_i2c_platform_init(phy);
 
-   r = request_threaded_irq(client->irq, NULL, pn544_hci_i2c_irq_thread_fn,
-IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-PN544_HCI_I2C_DRIVER_NAME, phy);
+   r = devm_request_threaded_irq(>dev, client->irq, NULL,
+ pn544_hci_i2c_irq_thread_fn,
+ IRQF_TRIGGER_RISING | IRQF_ONESHOT,
+ PN544_HCI_I2C_DRIVER_NAME, phy);
if (r < 0) {
nfc_err(>dev, "Unable to register IRQ handler\n");
return r;
@@ -976,14 +977,9 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
PN544_HCI_I2C_LLC_MAX_PAYLOAD,
pn544_hci_i2c_fw_download, >hdev);
if (r < 0)
-   goto err_hci;
+   return r;
 
return 0;
-
-err_hci:
-   free_irq(client->irq, phy);
-
-   return r;
 }
 
 static int pn544_hci_i2c_remove(struct i2c_client *client)
@@ -1001,8 +997,6 @@ static int pn544_hci_i2c_remove(struct i2c_client *client)
if (phy->powered)
pn544_hci_i2c_disable(phy);
 
-   free_irq(client->irq, phy);
-
return 0;
 }
 
-- 
2.11.0

[PATCH v2 5/5] NFC: pn544: Get rid of code duplication in ->probe()

[Andy Shevchenko]

Since OF and ACPI case almost the same get rid of code duplication
by moving gpiod_get() calls directly to ->probe().

Signed-off-by: Andy Shevchenko 
---
 The patch depends on early sent 
http://marc.info/?l=linux-wireless=149021085530803=2

 drivers/nfc/pn544/i2c.c | 84 ++---
 1 file changed, 17 insertions(+), 67 deletions(-)

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 6226d220f1d0..daa48531b7ae 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -879,58 +879,10 @@ static const struct acpi_gpio_mapping acpi_pn544_gpios[] 
= {
{ },
 };
 
-static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
-{
-   struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
-   struct device *dev = >dev;
-   int ret;
-
-   ret = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_pn544_gpios);
-   if (ret)
-   return ret;
-
-   /* Get EN GPIO from ACPI */
-   phy->gpiod_en = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
-   if (IS_ERR(phy->gpiod_en)) {
-   nfc_err(dev, "Unable to get EN GPIO\n");
-   return PTR_ERR(phy->gpiod_en);
-   }
-
-   /* Get FW GPIO from ACPI */
-   phy->gpiod_fw = devm_gpiod_get(dev, "firmware", GPIOD_OUT_LOW);
-   if (IS_ERR(phy->gpiod_fw)) {
-   nfc_err(dev, "Unable to get FW GPIO\n");
-   return PTR_ERR(phy->gpiod_fw);
-   }
-
-   return 0;
-}
-
-static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
-{
-   struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
-   struct device *dev = >dev;
-
-   /* Obtaining EN GPIO from device tree */
-   phy->gpiod_en = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
-   if (IS_ERR(phy->gpiod_en)) {
-   nfc_err(dev, "Failed to get EN gpio\n");
-   return PTR_ERR(phy->gpiod_en);
-   }
-
-   /* Obtaining FW GPIO from device tree */
-   phy->gpiod_fw = devm_gpiod_get(dev, "firmware", GPIOD_OUT_LOW);
-   if (IS_ERR(phy->gpiod_fw)) {
-   nfc_err(dev, "Failed to get FW gpio\n");
-   return PTR_ERR(phy->gpiod_fw);
-   }
-
-   return 0;
-}
-
 static int pn544_hci_i2c_probe(struct i2c_client *client,
   const struct i2c_device_id *id)
 {
+   struct device *dev = >dev;
struct pn544_i2c_phy *phy;
int r = 0;
 
@@ -953,24 +905,22 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
phy->i2c_dev = client;
i2c_set_clientdata(client, phy);
 
-   /* No platform data, using device tree. */
-   if (client->dev.of_node) {
-   r = pn544_hci_i2c_of_request_resources(client);
-   if (r) {
-   nfc_err(>dev, "No DT data\n");
-   return r;
-   }
-   /* Using ACPI */
-   } else if (ACPI_HANDLE(>dev)) {
-   r = pn544_hci_i2c_acpi_request_resources(client);
-   if (r) {
-   nfc_err(>dev,
-   "Cannot get ACPI data\n");
-   return r;
-   }
-   } else {
-   nfc_err(>dev, "No platform data\n");
-   return -EINVAL;
+   r = acpi_dev_add_driver_gpios(ACPI_COMPANION(dev), acpi_pn544_gpios);
+   if (r)
+   nfc_dbg(dev, "Unable to add GPIO mapping table\n");
+
+   /* Get EN GPIO */
+   phy->gpiod_en = devm_gpiod_get(dev, "enable", GPIOD_OUT_LOW);
+   if (IS_ERR(phy->gpiod_en)) {
+   nfc_err(dev, "Unable to get EN GPIO\n");
+   return PTR_ERR(phy->gpiod_en);
+   }
+
+   /* Get FW GPIO */
+   phy->gpiod_fw = devm_gpiod_get(dev, "firmware", GPIOD_OUT_LOW);
+   if (IS_ERR(phy->gpiod_fw)) {
+   nfc_err(dev, "Unable to get FW GPIO\n");
+   return PTR_ERR(phy->gpiod_fw);
}
 
pn544_hci_i2c_platform_init(phy);
-- 
2.11.0

[PATCH v2 2/5] NFC: pn544: Covert to use GPIO descriptor

[Andy Shevchenko]

Since we got rid of platform data, the driver may use
GPIO descriptor directly.

This change fixes a potential issue of double freeing GPIOs in ACPI
case by converting to devm_gpiod_get().

Signed-off-by: Andy Shevchenko 
---
 drivers/nfc/pn544/i2c.c | 126 +---
 1 file changed, 33 insertions(+), 93 deletions(-)

diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 41e518ee148e..b4001306aff8 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -21,9 +21,6 @@
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -165,8 +162,9 @@ struct pn544_i2c_phy {
struct i2c_client *i2c_dev;
struct nfc_hci_dev *hdev;
 
-   unsigned int gpio_en;
-   unsigned int gpio_fw;
+   struct gpio_desc *gpiod_en;
+   struct gpio_desc *gpiod_fw;
+
unsigned int en_polarity;
 
u8 hw_variant;
@@ -208,19 +206,18 @@ static void pn544_hci_i2c_platform_init(struct 
pn544_i2c_phy *phy)
nfc_info(>i2c_dev->dev, "Detecting nfc_en polarity\n");
 
/* Disable fw download */
-   gpio_set_value_cansleep(phy->gpio_fw, 0);
+   gpiod_set_value_cansleep(phy->gpiod_fw, 0);
 
for (polarity = 0; polarity < 2; polarity++) {
phy->en_polarity = polarity;
retry = 3;
while (retry--) {
/* power off */
-   gpio_set_value_cansleep(phy->gpio_en,
-   !phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_en, 
!phy->en_polarity);
usleep_range(1, 15000);
 
/* power on */
-   gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_en, 
phy->en_polarity);
usleep_range(1, 15000);
 
/* send reset */
@@ -239,14 +236,13 @@ static void pn544_hci_i2c_platform_init(struct 
pn544_i2c_phy *phy)
"Could not detect nfc_en polarity, fallback to active high\n");
 
 out:
-   gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_en, !phy->en_polarity);
 }
 
 static void pn544_hci_i2c_enable_mode(struct pn544_i2c_phy *phy, int run_mode)
 {
-   gpio_set_value_cansleep(phy->gpio_fw,
-   run_mode == PN544_FW_MODE ? 1 : 0);
-   gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_fw, run_mode == PN544_FW_MODE ? 1 : 
0);
+   gpiod_set_value_cansleep(phy->gpiod_en, phy->en_polarity);
usleep_range(1, 15000);
 
phy->run_mode = run_mode;
@@ -269,14 +265,14 @@ static void pn544_hci_i2c_disable(void *phy_id)
 {
struct pn544_i2c_phy *phy = phy_id;
 
-   gpio_set_value_cansleep(phy->gpio_fw, 0);
-   gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_fw, 0);
+   gpiod_set_value_cansleep(phy->gpiod_en, !phy->en_polarity);
usleep_range(1, 15000);
 
-   gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_en, phy->en_polarity);
usleep_range(1, 15000);
 
-   gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
+   gpiod_set_value_cansleep(phy->gpiod_en, !phy->en_polarity);
usleep_range(1, 15000);
 
phy->powered = 0;
@@ -877,96 +873,47 @@ static void pn544_hci_i2c_fw_work(struct work_struct 
*work)
 static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
 {
struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
-   struct gpio_desc *gpiod_en, *gpiod_fw;
struct device *dev = >dev;
 
/* Get EN GPIO from ACPI */
-   gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1,
-   GPIOD_OUT_LOW);
-   if (IS_ERR(gpiod_en)) {
+   phy->gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1,
+GPIOD_OUT_LOW);
+   if (IS_ERR(phy->gpiod_en)) {
nfc_err(dev, "Unable to get EN GPIO\n");
-   return -ENODEV;
+   return PTR_ERR(phy->gpiod_en);
}
 
-   phy->gpio_en = desc_to_gpio(gpiod_en);
-
/* Get FW GPIO from ACPI */
-   gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2,
-   GPIOD_OUT_LOW);
-   if (IS_ERR(gpiod_fw)) {
+   phy->gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2,
+GPIOD_OUT_LOW);
+   if (IS_ERR(phy->gpiod_fw)) {
nfc_err(dev, "Unable to get FW GPIO\n");
-   return -ENODEV;
+   return PTR_ERR(phy->gpiod_fw);
}
 
-   

Re: [PATCH] brcmfmac: wrap brcmf_fws_(de)init into bcdc layer

[Arend Van Spriel]

On 21-3-2017 14:44, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> fwsignal is only used by bcdc. Create new protocol interface functions
> for core code to perform proto specific (de)initialization. This makes
> core agnostic to the protocol which will allow further optimizations.
> We will be able to avoid compiling unused protocols or modularize them.

Thanks, Rafał

Franky had tackled this with two patches, which are queued to be submitted.

Regards,
Arend

[PATCH] ath9k_hw: fix channel maximum power level test

[Felix Fietkau]

The tx power applied by set_txpower is limited by the CTL (conformance
test limit) entries in the EEPROM. These can change based on the user
configured regulatory domain.
Depending on the EEPROM data this can cause the tx power to become too
limited, if the original regdomain CTLs impose lowr limits than the CTLs
of the user configured regdomain.

To fix this issue, set the initial channel limits without any CTL
restrictions and only apply the CTL at run time when setting the channel
and the real tx power.

Cc: sta...@vger.kernel.org
Signed-off-by: Felix Fietkau 
---
 drivers/net/wireless/ath/ath9k/hw.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/hw.c 
b/drivers/net/wireless/ath/ath9k/hw.c
index 17ca60482b5f..3346cbf63b9c 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -2937,10 +2937,14 @@ void ath9k_hw_apply_txpower(struct ath_hw *ah, struct 
ath9k_channel *chan,
struct ieee80211_channel *channel;
int chan_pwr, new_pwr, max_gain;
int ant_gain, ant_reduction = 0;
+   u16 ctl = NO_CTL;
 
if (!chan)
return;
 
+   if (!test)
+   ctl = ath9k_regd_get_ctl(reg, chan);
+
channel = chan->chan;
chan_pwr = min_t(int, channel->max_power * 2, MAX_RATE_POWER);
new_pwr = min_t(int, chan_pwr, reg->power_limit);
@@ -2950,9 +2954,7 @@ void ath9k_hw_apply_txpower(struct ath_hw *ah, struct 
ath9k_channel *chan,
if (ant_gain > max_gain)
ant_reduction = ant_gain - max_gain;
 
-   ah->eep_ops->set_txpower(ah, chan,
-ath9k_regd_get_ctl(reg, chan),
-ant_reduction, new_pwr, test);
+   ah->eep_ops->set_txpower(ah, chan, ctl, ant_reduction, new_pwr, test);
 }
 
 void ath9k_hw_set_txpowerlimit(struct ath_hw *ah, u32 limit, bool test)
-- 
2.11.0

Re: [PATCH] brcmfmac: make PCIe bus support a separated module

[Arend Van Spriel]

On 21-3-2017 15:48, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> Right now whole brcmfmac is a single module. Enabling one bus support
> increases brcmfmac.ko size which may be unwanted for some embedded
> devices like home routers. With this change brcmfmac gets modularized.
> It's possible to build brcmfmac without PCIe support and when required
> just install/load a proper module.
> 
> A similar modification of SDIO and USB support should follow.

Not sure I see much benefit in this. Please note that the individual bus
support can already be selected through Kconfig to reduce the module
size for embedded devices. When using this module approach you have to
export symbols which also have a price when it comes to module size.

Regards,
Arend

> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/net/wireless/broadcom/brcm80211/Kconfig   |  2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile |  6 --
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c   |  5 +
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c |  5 +
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/commonring.c |  2 ++
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c   | 10 +++---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c   |  3 +++
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.c |  1 +
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c   | 11 
> +--
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.h   |  5 -
>  10 files changed, 33 insertions(+), 17 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
> b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> index ab42b1fea03c..d93561f6ef97 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -57,7 +57,7 @@ config BRCMFMAC_USB
> use the driver for an USB wireless card.
>  
>  config BRCMFMAC_PCIE
> - bool "PCIE bus interface support for FullMAC driver"
> + tristate "Broadcom FullMAC WLAN support for PCIE bus"
>   depends on BRCMFMAC
>   depends on PCI
>   depends on HAS_DMA
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> index 0383ba559edc..f60e6a9a9a77 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile
> @@ -46,11 +46,13 @@ brcmfmac-$(CONFIG_BRCMFMAC_SDIO) += \
>   bcmsdh.o
>  brcmfmac-$(CONFIG_BRCMFMAC_USB) += \
>   usb.o
> -brcmfmac-$(CONFIG_BRCMFMAC_PCIE) += \
> - pcie.o
>  brcmfmac-$(CONFIG_BRCMDBG) += \
>   debug.o
>  brcmfmac-$(CONFIG_BRCM_TRACING) += \
>   tracepoint.o
>  brcmfmac-$(CONFIG_OF) += \
>   of.o
> +
> +obj-$(CONFIG_BRCMFMAC_PCIE) += brcmfmac-pcie.o
> +brcmfmac-pcie-objs += \
> + pcie.o
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> index 05f22ff81d60..536df11f376c 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
> @@ -1095,6 +1095,7 @@ struct brcmf_chip *brcmf_chip_attach(void *ctx,
>   brcmf_chip_detach(>pub);
>   return ERR_PTR(err);
>  }
> +EXPORT_SYMBOL_GPL(brcmf_chip_attach);
>  
>  void brcmf_chip_detach(struct brcmf_chip *pub)
>  {
> @@ -1109,6 +1110,7 @@ void brcmf_chip_detach(struct brcmf_chip *pub)
>   }
>   kfree(chip);
>  }
> +EXPORT_SYMBOL_GPL(brcmf_chip_detach);
>  
>  struct brcmf_core *brcmf_chip_get_core(struct brcmf_chip *pub, u16 coreid)
>  {
> @@ -1122,6 +1124,7 @@ struct brcmf_core *brcmf_chip_get_core(struct 
> brcmf_chip *pub, u16 coreid)
>  
>   return NULL;
>  }
> +EXPORT_SYMBOL_GPL(brcmf_chip_get_core);
>  
>  struct brcmf_core *brcmf_chip_get_chipcommon(struct brcmf_chip *pub)
>  {
> @@ -1176,6 +1179,7 @@ void brcmf_chip_resetcore(struct brcmf_core *pub, u32 
> prereset, u32 reset,
>   core = container_of(pub, struct brcmf_core_priv, pub);
>   core->chip->resetcore(core, prereset, reset, postreset);
>  }
> +EXPORT_SYMBOL_GPL(brcmf_chip_resetcore);
>  
>  static void
>  brcmf_chip_cm3_set_passive(struct brcmf_chip_priv *chip)
> @@ -1317,6 +1321,7 @@ bool brcmf_chip_set_active(struct brcmf_chip *pub, u32 
> rstvec)
>  
>   return false;
>  }
> +EXPORT_SYMBOL_GPL(brcmf_chip_set_active);
>  
>  bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
>  {
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> index 7a2b49587b4d..cfe2ee0947b6 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
> @@ -51,6 +51,7 @@ 

Re: [PATCH] brcmfmac: update BRCMFMAC symbol description

[Arend Van Spriel]

On 21-3-2017 15:43, Rafał Miłecki wrote:
> From: Rafał Miłecki 
> 
> For quite some time now brcmfmac supports 802.11ac chipsets and it's
> not limited to embedded devices only. There are even standalone PCIe
> cards based on BCM43602 or BCM4366.

minor comments below.

Reviewed-by: Arend van Spriel 
> Signed-off-by: Rafał Miłecki 
> ---
>  drivers/net/wireless/broadcom/brcm80211/Kconfig | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/Kconfig 
> b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> index d93561f6ef97..817cb28f518f 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/Kconfig
> +++ b/drivers/net/wireless/broadcom/brcm80211/Kconfig
> @@ -18,14 +18,14 @@ config BRCMSMAC
> module, the driver will be called brcmsmac.ko.
>  
>  config BRCMFMAC
> - tristate "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
> + tristate "Broadcom IEEE802.11n WLAN driver"

You still mention 11n. Let's drop the 'n' here or IEEE802.11n entirely
like below. Would like to keep the term FullMAC though.

Regards,
Arend

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[Marcel Holtmann]

Hi Dave,

>> By moving these client drivers to use RPMSG instead of the direct SMD
>> API we can reuse them ontop of the newly added GLINK wire-protocol
>> support found in the 820 and 835 Qualcomm platforms.
>> 
>> As the new (RPMSG-based) and old SMD implementations are mutually
>> exclusive we have to change all client drivers in one commit, to make
>> sure we have a working system before and after this transition.
>> 
>> Signed-off-by: Bjorn Andersson 
>> ---
>> 
>> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
>> (https://lkml.org/lkml/2017/3/20/1038).
> 
> Just some questions since I'm supposed to merge this into my net-next
> tree.
> 
> What is the status of the Kconfig dependency fix and how will I be
> getting it?

I acked that one separately and added you:

[PATCH v2] Bluetooth: btqcomsmd: fix compile-test dependency

> Second, should I merge all three of these patches to net-next or just
> this one?

I think you have to take all 3 patches. Otherwise it will break.

Regards

Marcel

[PATCH v1] NFC: Add nfc_dbg() macro

[Andy Shevchenko]

In some cases nfc_dbg() is useful. Add such macro to a header.

Signed-off-by: Andy Shevchenko 
---
 include/net/nfc/nfc.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/nfc/nfc.h b/include/net/nfc/nfc.h
index 1a3de8b34ad2..bbdc73a3239d 100644
--- a/include/net/nfc/nfc.h
+++ b/include/net/nfc/nfc.h
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#define nfc_dbg(dev, fmt, ...) dev_dbg((dev), "NFC: " fmt, ##__VA_ARGS__)
 #define nfc_info(dev, fmt, ...) dev_info((dev), "NFC: " fmt, ##__VA_ARGS__)
 #define nfc_err(dev, fmt, ...) dev_err((dev), "NFC: " fmt, ##__VA_ARGS__)
 
-- 
2.11.0

[PATCH v1] NFC: netlink: Use error code from nfc_activate_target()

[Andy Shevchenko]

It looks like a typo to assign a return code to a variable which is not
used. Found due to a compiler warning:

net/nfc/netlink.c: In function ‘nfc_genl_activate_target’:
net/nfc/netlink.c:903:6: warning: variable ‘rc’ set but not used 
[-Wunused-but-set-variable]
  int rc;
^~

Signed-off-by: Andy Shevchenko 
---
 net/nfc/netlink.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
index 03f3d5c7beb8..03be522127ec 100644
--- a/net/nfc/netlink.c
+++ b/net/nfc/netlink.c
@@ -918,7 +918,7 @@ static int nfc_genl_activate_target(struct sk_buff *skb, 
struct genl_info *info)
rc = nfc_activate_target(dev, target_idx, protocol);
 
nfc_put_device(dev);
-   return 0;
+   return rc;
 }
 
 static int nfc_genl_dep_link_up(struct sk_buff *skb, struct genl_info *info)
-- 
2.11.0

Re: pull-request: wireless-drivers 2017-03-21

[David Miller]

From: Kalle Valo 
Date: Tue, 21 Mar 2017 15:54:47 +0200

> few smallish fixes for 4.11. Please let me know if there are any
> problems.

Pulled, thanks Kalle.

Re: [PATCH 1/3] soc: qcom: smd: Transition client drivers from smd to rpmsg

[David Miller]

From: Bjorn Andersson 
Date: Mon, 20 Mar 2017 16:35:42 -0700

> By moving these client drivers to use RPMSG instead of the direct SMD
> API we can reuse them ontop of the newly added GLINK wire-protocol
> support found in the 820 and 835 Qualcomm platforms.
> 
> As the new (RPMSG-based) and old SMD implementations are mutually
> exclusive we have to change all client drivers in one commit, to make
> sure we have a working system before and after this transition.
> 
> Signed-off-by: Bjorn Andersson 
> ---
> 
> Based on v4.11-rc3 with Arnd's Kconfig dependency fixes for BT_QCOMSMD
> (https://lkml.org/lkml/2017/3/20/1038).

Just some questions since I'm supposed to merge this into my net-next
tree.

What is the status of the Kconfig dependency fix and how will I be
getting it?

Second, should I merge all three of these patches to net-next or just
this one?

Thanks.

[Netdev] ANNOUNCE: New silver sponsor!

[Jamal Hadi Salim]

The organizing committee would like to announce a new silver sponsor:
Solarflare.

Solarflare is returning as a silver sponsor again this year. Welcome 
back and many thanks for your support!


cheers,
jamal

Re: [PATCH v1 1/2] NFC: pn544: Request GPIOs with proper connection IDs

[Shevchenko, Andriy]

On Tue, 2017-03-07 at 12:15 +0200, Andy Shevchenko wrote:
> On Tue, 2017-03-07 at 12:12 +0200, Andy Shevchenko wrote:
> > Since ACPI does support _DSD we might have a firmware that provides
> > a
> > GPIO mapping in DSDT. When GPIO is requested the core will check for
> > property with given name. That's why we have to follow the standard
> > names which are already in use in DT case.
> > 
> > Request GPIOs with proper connection IDs, i.e. use same names as
> > used
> > for DT case.
> > 
> > In the future ACPI and DT cases might be unified.
> 
> Discard this series, it should be v2, just resent.

While I'm preparing v2, there is a most important question has arisen.

Do we have any evidence of NXP5440 (ACPI ID) in *real* world?

To me it (the ID itself) sounds artificial and wilfully invented. In
case I'm right it must be removed from the driver. Otherwise, I would
like to see documentation or alike with DSDT excerpt and model of the
real device which has it.

-- 
Andy Shevchenko 
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Larry Finger]

On 03/22/2017 10:15 AM, Stanislaw Gruszka wrote:

On Sat, Mar 18, 2017 at 04:30:04PM -0500, Larry Finger wrote:

On 03/18/2017 02:45 PM, Johannes Berg wrote:

On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:


I have duplicated your bug and I have bisected it to

commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
Author: Johannes Berg 
Date:   Mon Oct 24 14:40:04 2016 +0200

genetlink: use idr to track families

This patch is quite extensive and I have no idea which part is
failing, thus all I can do is report this confirmation.


I don't think that makes any sense - have you verified that reverting
that makes it go away?


Due to conflicts, I cannot simply revert it; however if I check out
the previous commit 489111e5c25b93be80340c3113d71903d7c82136
("genetlink: statically initialize families"), then the kernel is
OK.


I just posted a patch which most likely fixes this problem. I have some
other issue on my setup, but seems this issue is also caused by the
same bug in 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a.


Stanislaw,

Your patch does fix this problem. Thanks.

Larry

Re: [BUG] with a 4.10.x kernel it's impossible to apply country regulatory rules

[Stanislaw Gruszka]

On Sat, Mar 18, 2017 at 04:30:04PM -0500, Larry Finger wrote:
> On 03/18/2017 02:45 PM, Johannes Berg wrote:
> >On Sat, 2017-03-18 at 12:41 -0500, Larry Finger wrote:
> >>
> >>I have duplicated your bug and I have bisected it to
> >>
> >>commit 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a
> >>Author: Johannes Berg 
> >>Date:   Mon Oct 24 14:40:04 2016 +0200
> >>
> >> genetlink: use idr to track families
> >>
> >>This patch is quite extensive and I have no idea which part is
> >>failing, thus all I can do is report this confirmation.
> >
> >I don't think that makes any sense - have you verified that reverting
> >that makes it go away?
> 
> Due to conflicts, I cannot simply revert it; however if I check out
> the previous commit 489111e5c25b93be80340c3113d71903d7c82136
> ("genetlink: statically initialize families"), then the kernel is
> OK.

I just posted a patch which most likely fixes this problem. I have some
other issue on my setup, but seems this issue is also caused by the
same bug in 2ae0f17df1cd52aafd1ab0415ea1f1dd56dc0e2a.

Stanislaw

[PATCH 4.11] genetlink: fix counting regression on ctrl_dumpfamily()

[Stanislaw Gruszka]

Commit 2ae0f17df1cd ("genetlink: use idr to track families") replaced

if (++n < fams_to_skip)
continue;
into:

if (n++ < fams_to_skip)
continue;

This subtle change cause that on retry ctrl_dumpfamily() call we omit
one family that failed to do ctrl_fill_info() on previous call, because
cb->args[0] = n number counts also family that failed to do
ctrl_fill_info().

Patch fixes the problem and avoid confusion in the future just decrease
n counter when ctrl_fill_info() fail.

User visible problem caused by this bug is failure to get access to
some genetlink family i.e. nl80211. However problem is reproducible
only if number of registered genetlink families is big enough to
cause second call of ctrl_dumpfamily().

Cc: Xose Vazquez Perez 
Cc: Larry Finger 
Cc: Johannes Berg 
Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
Signed-off-by: Stanislaw Gruszka 
---
Dave, please also target this for 4.10+ -stable.

 net/netlink/genetlink.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index fb6e10f..92e0981 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -783,8 +783,10 @@ static int ctrl_dumpfamily(struct sk_buff *skb, struct 
netlink_callback *cb)
 
if (ctrl_fill_info(rt, NETLINK_CB(cb->skb).portid,
   cb->nlh->nlmsg_seq, NLM_F_MULTI,
-  skb, CTRL_CMD_NEWFAMILY) < 0)
+  skb, CTRL_CMD_NEWFAMILY) < 0) {
+   n--;
break;
+   }
}
 
cb->args[0] = n;
-- 
1.7.1

Re: [2/2] zd1211rw: fix NULL-deref at probe

[Johan Hovold]

On Wed, Mar 22, 2017 at 03:02:12PM +0200, Kalle Valo wrote:
> Johan Hovold  writes:
> 
> > On Wed, Mar 22, 2017 at 09:04:15AM +, Kalle Valo wrote:
> >> Johan Hovold  wrote:
> >> > Make sure to check the number of endpoints to avoid dereferencing a
> >> > NULL-pointer or accessing memory beyond the endpoint array should a
> >> > malicious device lack the expected endpoints.
> >> > 
> >> > Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM
> >> > device into WLAN device")
> >> > Cc: Daniel Drake 
> >> > Signed-off-by: Johan Hovold 
> >> 
> >> Patch applied to wireless-drivers-next.git, thanks.
> >> 
> >> ca260ece6a57 zd1211rw: fix NULL-deref at probe
> >
> > What about patch 1/2 which fixes the same bug (literally copied from the
> > zd1211rw driver)?
> 
> I will apply that to my separate ath.git tree, just didn't get to your
> patch yet.

Ah, ok. 

> > And as these fixes should be backported to stable (I left out the tag
> > for networking drivers)
> 
> Actually for wireless drivers you should add the stable tag.

Alright, will do in the future.

> > why only apply to -next?
> 
> I didn't see that the fix was important enough for 4.11.

Ok, but fixes for these types of crashes that can be triggered by a
malicious device have typically gone into the current -rc (a couple just
went in through the net tree for example).

Thanks,
Johan

Re: [2/2] zd1211rw: fix NULL-deref at probe

[Kalle Valo]

Johan Hovold  writes:

> On Wed, Mar 22, 2017 at 09:04:15AM +, Kalle Valo wrote:
>> Johan Hovold  wrote:
>> > Make sure to check the number of endpoints to avoid dereferencing a
>> > NULL-pointer or accessing memory beyond the endpoint array should a
>> > malicious device lack the expected endpoints.
>> > 
>> > Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM
>> > device into WLAN device")
>> > Cc: Daniel Drake 
>> > Signed-off-by: Johan Hovold 
>> 
>> Patch applied to wireless-drivers-next.git, thanks.
>> 
>> ca260ece6a57 zd1211rw: fix NULL-deref at probe
>
> What about patch 1/2 which fixes the same bug (literally copied from the
> zd1211rw driver)?

I will apply that to my separate ath.git tree, just didn't get to your
patch yet.

> And as these fixes should be backported to stable (I left out the tag
> for networking drivers)

Actually for wireless drivers you should add the stable tag.

> why only apply to -next?

I didn't see that the fix was important enough for 4.11.

-- 
Kalle Valo

Re: [2/2] zd1211rw: fix NULL-deref at probe

[Johan Hovold]

On Wed, Mar 22, 2017 at 09:04:15AM +, Kalle Valo wrote:
> Johan Hovold  wrote:
> > Make sure to check the number of endpoints to avoid dereferencing a
> > NULL-pointer or accessing memory beyond the endpoint array should a
> > malicious device lack the expected endpoints.
> > 
> > Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into 
> > WLAN device")
> > Cc: Daniel Drake 
> > Signed-off-by: Johan Hovold 
> 
> Patch applied to wireless-drivers-next.git, thanks.
> 
> ca260ece6a57 zd1211rw: fix NULL-deref at probe

What about patch 1/2 which fixes the same bug (literally copied from the
zd1211rw driver)?

And as these fixes should be backported to stable (I left out the tag
for networking drivers), why only apply to -next?

Thanks,
Johan

[REGRESSION] mac80211: IBSS vif queue stopped when started after 11s vif

[Sven Eckelmann]

Hi,

I had following "simple" setup with LEDE with a single ath9k phy and multiple 
vif:

 * encrypted AP
 * encrypted 802.11s meshpoint
 * encrypted IBSS

Everything was started in the order by hostapd/wpa_supplicant (but immediately 
after each other).

The problem which I've experienced was that IBSS was not able to communicate 
with its link partner. The reason for that problem was that the IBSS 
interface's queue was stopped (QUEUE_STATE_DRV_XOFF). This problem disappeared 
when either the IBSS or meshpoint interface was changed to unencrypted (which 
disables wpa_supplicant in LEDE).

It looks like ieee80211_do_open didn't start the queues via 
netif_start_subqueue because local->queue_stop_reasons was for all queues set 
to IEEE80211_QUEUE_STOP_REASON_OFFCHANNEL. This happened because 
ieee80211_offchannel_stop_vifs was called from somewhere in the scan code at 
that time and ieee80211_offchannel_return was not yet called.


This behavior seems to be introduced by 2b730daacee6 ("mac80211: don't start 
new netdev queues if driver stopped"). I have therefore chosen to call it for 
now a regression by this change. Especially because it is rather odd that the 
commit talked about not starting the queues for AP_VLAN and 2b436312f091 
("mac80211: fix queue handling crash") introduced extra code to use the old 
behavior again for AP_VLAN.

But I could be completely wrong about it. It would therefore be interesting 
for me to know who would be responsible to start the queues when 
ieee80211_do_open rejected it for IBSS.

I am now simply using this setup with a revert of 
2b436312f0919c05804fed5aa4b7f255db196e7a and 
2b730daacee6c318bce7b6373c19909e36a74590.

Kind regards,
Sven

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

Re: [v3] rt2x00: add support for MT7620

[Kalle Valo]

Daniel Golle  wrote:
> From: Roman Yeryomin 
> 
> Basic support for MT7620 built-in wireless radio was added to
> OpenWrt in r41441. It has seen some heavy cleaning and refactoring
> since in order to match the Kernel's code quality standards.
> 
> Signed-off-by: Roman Yeryomin 
> Signed-off-by: Daniel Golle 
> Acked-by: Stanislaw Gruszka 

Patch applied to wireless-drivers-next.git, thanks.

41977e86c984 rt2x00: add support for MT7620

-- 
https://patchwork.kernel.org/patch/9635519/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Re: [2/2] zd1211rw: fix NULL-deref at probe

[Kalle Valo]

Johan Hovold  wrote:
> Make sure to check the number of endpoints to avoid dereferencing a
> NULL-pointer or accessing memory beyond the endpoint array should a
> malicious device lack the expected endpoints.
> 
> Fixes: a1030e92c150 ("[PATCH] zd1211rw: Convert installer CDROM device into 
> WLAN device")
> Cc: Daniel Drake 
> Signed-off-by: Johan Hovold 

Patch applied to wireless-drivers-next.git, thanks.

ca260ece6a57 zd1211rw: fix NULL-deref at probe

-- 
https://patchwork.kernel.org/patch/9620721/

Documentation about submitting wireless patches and checking status
from patchwork:

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

Gsoc 2017 - Availability of porjects in Linux Wireless

[Ajay Ramakrishnan]

Hi all.

I would like to work on the GSOC in the Linux Wireless module. I would
like to know what are the available projects upon which I could work
on.

>From the to-do page, I found this: 11v and I would like to work on the below:
1. 11v DMS support:
In AP mode, the packets needs to be saved in a queue and then need
to be sent as unicast to sleeping clients.
STA should receive these packets after waking up listening to beacons.

Test equipments: 1 device as AP and 2 device as STA (to check the DMS support)

2. 11v BSS Transition Management support:
In AP neighbor AP list needs to be sent to the client on request.
The action frames would be prepared at the mac80211 and given to the
driver. The driver just needs to send the packet out. Neighbor list
can be prepared based on a polling mechanism. Each AP can send the
data and during offchannel scan the AP learns details about other APs.
The STA should be able to process this neighbor list and then scan
in those channel alone. This is a network assisted roaming. Once the
packet is received by the driver and received at mac80211, the packet
is parsed and the 11v BTM request frame is identified and neighbor
possible parent list is identified.
Based on this list, roaming is to be done and scanning is done on
those channels alone.

Test equipments: 2 or more devices as APs(to check if neighbor list is
being prepared correctly) and 1 device as STA to validate the message
exchanges


Could you please let me know if these are already implemented in the
Linux Wireless. If someone from the Linux foundation team/Linux
Wireless team is working on this, maybe we can discuss regarding the
available projects and I would like to work on wireless networks.

Thanks,
Arun

Re: [PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

[Sven Eckelmann]

On Dienstag, 21. März 2017 21:56:54 CET Rob Herring wrote:
[...]
> Is this always the case? There's never some variation beyond the
> reference design that a BDF difference can't handle?

I have no knowledge about anything which isn't handled directly by the BDF
variants. But maybe Kalle can correct me here.

[...]
> > They are basically "qcom,ipq4019-wifi" + a product specific string. The 
> > first
> > part is therefore the string which identifies the wifi device(s) in the
> > QCA4018/4019 SoC. The product specific string is simply the part (or a
> > variation of it) which would been used before in
> > "qcom,ath10k-calibration-variant" - just to make it "use a more specific
> > compatible string".
> 
> It would probably be more like: "asus,rt-ac58u-wifi", "qcom,ipq4019-wifi"
> 
> A more specific compatible is insurance that at some later point in
> time you can distinguish between 2 boards due to some difference even
> if now you believe they are "the same".
[...]
> I think the separate property is fine if this is the only one you
> envision needing to add. If there's 10 more properties, then I'd feel
> more strongly towards a board specific compatible string.

Thank you. Let's wait a little bit in case someone from QCA/Codeaurora
has some additional input.

But your comments were really helpful.

Kind regards,
Sven

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