Re: [PATCH 2/2] mac80211: Drop new node with weak power

[Masashi Honma]

On 2017/03/16 19:03, Johannes Berg wrote:

I'm not really sure this is the right solution?

It seems to me that it should be a function of the path selection to
take this into account, not prohibiting the longer path entirely?


Right. To calculate metric with RSSI level is better solution than
this solution.


It seems that this is really what the meshcfg.rssi_threshold was
intended for, and the plink code *does* take it into account. Can you
explain where that's breaking down?


Indeed meshcfg.rssi_threshold is already referred by some codes. But
when booting mesh node with user_mpm=1, the codes is not called.
So we need to add another code.

I will update commit log because this patch just enables
meshcfg.rssi_threshold with user_mpm=1.

Masashi Honma.

Fw: [Bug 194903] New: After updating Kernel to 4.9.9 my wireless adapter does not work

[Stephen Hemminger]

Begin forwarded message:

Date: Fri, 17 Mar 2017 02:22:58 +
From: bugzilla-dae...@bugzilla.kernel.org
To: step...@networkplumber.org
Subject: [Bug 194903] New: After updating Kernel to 4.9.9 my wireless adapter 
does not work


https://bugzilla.kernel.org/show_bug.cgi?id=194903

Bug ID: 194903
   Summary: After updating Kernel to 4.9.9 my wireless adapter
does not work
   Product: Networking
   Version: 2.5
Kernel Version: 4.9.9
  Hardware: x86-64
OS: Linux
  Tree: Mainline
Status: NEW
  Severity: blocking
  Priority: P1
 Component: IPV4
  Assignee: step...@networkplumber.org
  Reporter: jemel.robin...@icloud.com
Regression: No

I have a Macbook Pro 13" (7, 1) and when I updated my kernel version to 4.9.9
(F25), my broadcom wireless adapter is no longer detected. I have since updated
to the latest kernel and have gotten the same result. As of now, I am currently
operating at the kernel version prior to 4.9.9 (4.8.6-300.fc25.x86_64
) and I am able to use WiFi with no issues. I have tried uninstalling and
reinstalling the broadcom -wl driver to no avail. I narrowed the issue down to
the kernel simply by updating the kernel only and after reboot, wireless was
gone.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[PATCH] Staging: wilc1000: fix two typos in #define's

[Dylan Leggio]

GAS_INTIAL_REQ should be GAS_INITIAL_REQ.
GAS_INTIAL_RSP should be GAS_INITIAL_RSP.
Improves readability of code.

Signed-off-by: Dylan Leggio 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a37896fcd683..1bb63702c623 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -29,8 +29,8 @@
 #define P2P_INV_REQ0x03
 #define P2P_INV_RSP0x04
 #define PUBLIC_ACT_VENDORSPEC  0x09
-#define GAS_INTIAL_REQ 0x0a
-#define GAS_INTIAL_RSP 0x0b
+#define GAS_INITIAL_REQ0x0a
+#define GAS_INITIAL_RSP0x0b
 
 #define INVALID_CHANNEL0
 
@@ -1477,10 +1477,10 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, 
u32 size)
}
if (buff[ACTION_CAT_ID] == PUB_ACTION_ATTR_ID) {
switch (buff[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
@@ -1666,10 +1666,10 @@ static int mgmt_tx(struct wiphy *wiphy,
curr_channel = chan->hw_value;
}
switch (buf[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
-- 
2.12.0

[PATCH] Staging: wilc1000: fix two typos in #define's

[Dylan Leggio]

GAS_INTIAL_REQ should be GAS_INITIAL_REQ.
GAS_INTIAL_RSP should be GAS_INITIAL_RSP.
Improves readability of code.

Signed-off-by: Dylan Leggio 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a37896fcd683..1bb63702c623 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -29,8 +29,8 @@
 #define P2P_INV_REQ0x03
 #define P2P_INV_RSP0x04
 #define PUBLIC_ACT_VENDORSPEC  0x09
-#define GAS_INTIAL_REQ 0x0a
-#define GAS_INTIAL_RSP 0x0b
+#define GAS_INITIAL_REQ0x0a
+#define GAS_INITIAL_RSP0x0b
 
 #define INVALID_CHANNEL0
 
@@ -1477,10 +1477,10 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, 
u32 size)
}
if (buff[ACTION_CAT_ID] == PUB_ACTION_ATTR_ID) {
switch (buff[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
@@ -1666,10 +1666,10 @@ static int mgmt_tx(struct wiphy *wiphy,
curr_channel = chan->hw_value;
}
switch (buf[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
-- 
2.12.0

[PATCH] staging: wilc1000: fix incorrect copy of pmkid data

[Colin King]

From: Colin Ian King 

The pmkid data is meant be be copied to the previous item in the
pmkidlist, however the code is just copying the data to itself because
the src index into pmkidlist is the same as the dst index into pmkidlist.
Fix this with i + 1 instead of i.

Detected by CoverityScan,CID#13339465 ("Overlapping buffer in memory copy")

Signed-off-by: Colin Ian King 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a37896f..4034f40 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -1346,7 +1346,7 @@ static int del_pmksa(struct wiphy *wiphy, struct 
net_device *netdev,
   priv->pmkid_list.pmkidlist[i + 1].bssid,
   ETH_ALEN);
memcpy(priv->pmkid_list.pmkidlist[i].pmkid,
-  priv->pmkid_list.pmkidlist[i].pmkid,
+  priv->pmkid_list.pmkidlist[i + 1].pmkid,
   PMKID_LEN);
}
priv->pmkid_list.numpmkid--;
-- 
2.10.2

Re: netdev level filtering? perhaps pushing socket filters down?

[Ben Greear]

On 03/16/2017 03:33 PM, Johannes Berg wrote:

Hi all,

Occasionally - we just had another case - people want to hook into
packets received and processed by the mac80211 stack, but because they
don't need all of them (e.g. not data packets), even adding a monitor
interface and bringing it up has too high a cost because SKBs need to
be prepared to send them to the monitor interface, even if no socket is
consuming them.

Ideally, we'd be able to detect that there are filter programs attached
to the socket(s) that are looking at the frames coming in on the
monitor interface, and we could somehow magically run those before we
create a new SKB.
One problem here is that we wouldn't really want to prepare all the
radiotap header just to throw it away, so we'd have to be able to
analyse the filter program to make sure it doesn't access anything but
the radiotap header length, and that only in order to jump over it.
That seems ... difficult, but we don't even know the header length -
although we could fudge that and make a very long constant-size header,
which might make it possible to do such analysis, or handle it by
trapping on such access. But it seems rather difficult to implement
this.

The next best thing would be to install a filter program on the virtual
monitor *interface* (netdev), but say that it doesn't get frames with
radiotap, but pure 802.11 frames. We already have those in SKB format
at this point, so it'd be simple to run such a program and only pass
the SKB to the monitor netdev's RX when the program asked to do that.

This now seems a bit like XDP, but for XDP this header difference
doesn't seem appropriate either.

Anyone have any other thoughts?


Attach at just above the driver, before it ever gets to stations/vdevs,
and ignore radiotap headers and/or add special processing for metadata like
rx-info?

Thanks,
Ben



Thanks,
johannes




--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

netdev level filtering? perhaps pushing socket filters down?

[Johannes Berg]

Hi all,

Occasionally - we just had another case - people want to hook into
packets received and processed by the mac80211 stack, but because they
don't need all of them (e.g. not data packets), even adding a monitor
interface and bringing it up has too high a cost because SKBs need to
be prepared to send them to the monitor interface, even if no socket is
consuming them.

Ideally, we'd be able to detect that there are filter programs attached
to the socket(s) that are looking at the frames coming in on the
monitor interface, and we could somehow magically run those before we
create a new SKB.
One problem here is that we wouldn't really want to prepare all the
radiotap header just to throw it away, so we'd have to be able to
analyse the filter program to make sure it doesn't access anything but
the radiotap header length, and that only in order to jump over it.
That seems ... difficult, but we don't even know the header length -
although we could fudge that and make a very long constant-size header,
which might make it possible to do such analysis, or handle it by
trapping on such access. But it seems rather difficult to implement
this.

The next best thing would be to install a filter program on the virtual
monitor *interface* (netdev), but say that it doesn't get frames with
radiotap, but pure 802.11 frames. We already have those in SKB format
at this point, so it'd be simple to run such a program and only pass
the SKB to the monitor netdev's RX when the program asked to do that.

This now seems a bit like XDP, but for XDP this header difference
doesn't seem appropriate either.

Anyone have any other thoughts?

Thanks,
johannes

[PATCH] Staging: wilc1000: fix two typos in #define's

[Dylan Leggio]

Signed-off-by: Dylan Leggio 
---
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index a37896fcd683..1bb63702c623 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -29,8 +29,8 @@
 #define P2P_INV_REQ0x03
 #define P2P_INV_RSP0x04
 #define PUBLIC_ACT_VENDORSPEC  0x09
-#define GAS_INTIAL_REQ 0x0a
-#define GAS_INTIAL_RSP 0x0b
+#define GAS_INITIAL_REQ0x0a
+#define GAS_INITIAL_RSP0x0b
 
 #define INVALID_CHANNEL0
 
@@ -1477,10 +1477,10 @@ void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, 
u32 size)
}
if (buff[ACTION_CAT_ID] == PUB_ACTION_ATTR_ID) {
switch (buff[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
@@ -1666,10 +1666,10 @@ static int mgmt_tx(struct wiphy *wiphy,
curr_channel = chan->hw_value;
}
switch (buf[ACTION_SUBTYPE_ID]) {
-   case GAS_INTIAL_REQ:
+   case GAS_INITIAL_REQ:
break;
 
-   case GAS_INTIAL_RSP:
+   case GAS_INITIAL_RSP:
break;
 
case PUBLIC_ACT_VENDORSPEC:
-- 
2.12.0

Re: [RFT] brcmfmac: add support to move wiphy instance into network namespace

[Mark Asselstine]

On Tuesday, March 14, 2017 9:51:52 PM EDT Arend van Spriel wrote:
> To support network namespace the driver must assure all created
> network interfaces are in the same namespace as the wiphy instance.
> 
> Reported-by: Mark Asselstine 
> Signed-off-by: Arend van Spriel 
> ---
> Hi Mark,
> 
> Please check this patch. I can not say I am an expert when it comes
> to using namespaces. So let me know if it works and I can change
> Reported-by into Tested-by.

Seems to pass the tests I threw at it. Seems happy with namespaces.

Mark

> 
> Regards,
> Arend
> ---
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 3 ++-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c | 5 -
>  2 files changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index
> 3856de6..e0d65df 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
> @@ -6450,7 +6450,8 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy,
> struct brcmf_if *ifp) BIT(NL80211_BSS_SELECT_ATTR_BAND_PREF) |
>   BIT(NL80211_BSS_SELECT_ATTR_RSSI_ADJUST);
> 
> - wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
> + wiphy->flags |= WIPHY_FLAG_NETNS_OK |
> + WIPHY_FLAG_PS_ON_BY_DEFAULT |
>   WIPHY_FLAG_OFFCHAN_TX |
>   WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
>   if (brcmf_feat_is_enabled(ifp, BRCMF_FEAT_TDLS))
> diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c index
> 22b4883..74ede27 100644
> --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/core.c
> @@ -463,6 +463,7 @@ static int brcmf_netdev_open(struct net_device *ndev)
>  int brcmf_net_attach(struct brcmf_if *ifp, bool rtnl_locked)
>  {
>   struct brcmf_pub *drvr = ifp->drvr;
> + struct wiphy *wiphy;
>   struct net_device *ndev;
>   s32 err;
> 
> @@ -476,8 +477,10 @@ int brcmf_net_attach(struct brcmf_if *ifp, bool
> rtnl_locked) ndev->needed_headroom += drvr->hdrlen;
>   ndev->ethtool_ops = _ethtool_ops;
> 
> - /* set the mac address */
> + /* set the mac address & netns */
>   memcpy(ndev->dev_addr, ifp->mac_addr, ETH_ALEN);
> + wiphy = cfg_to_wiphy(drvr->config);
> + dev_net_set(ndev, wiphy_net(wiphy));
> 
>   INIT_WORK(>multicast_work, _brcmf_set_multicast_list);
>   INIT_WORK(>ndoffload_work, _brcmf_update_ndtable);

[PATCH v3] mwifiex: fix kernel crash after shutdown command timeout

[Brian Norris]

We observed a SHUTDOWN command timeout during reboot stress test due to
a corner case firmware bug. It can lead to either a use-after-free +
OOPS (on either the adapter structure, or the 'card' structure) or an
abort (where, e.g., the PCI device is "disabled" before we're done
dumping the FW).

We can avoid this by canceling/flushing the FW dump work:

(a) after we've terminated all other work queues (e.g., for processing
commands which could time out)
(b) after we've disabled all interrupts (which could also queue more
work for us)
(c) after we've unregistered the netdev and wiphy structures (and
implicitly, and debugfs entries which could manually trigger FW dumps)
(d) before we've actually disabled the device (e.g.,
pci_device_disable())

Altogether, this means no card->work will be scheduled if we sync at
a point that satisfies the above. This can be done at the beginning of
the .cleanup_if() callback.

Signed-off-by: Brian Norris 
---
v3:
 * rewrote Amit's patch, to ensure this work won't get *scheduled*
   again, pointed out by Dmitry

Amit's work:

v2:
 * New work_flag has been added to resolve the issue cleanly as per
   Brian's suggestion.
---
 drivers/net/wireless/marvell/mwifiex/pcie.c | 4 ++--
 drivers/net/wireless/marvell/mwifiex/sdio.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a0d918094889..bfe597837985 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -294,8 +294,6 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
 
-   cancel_work_sync(>work);
-
reg = card->pcie.reg;
if (reg)
ret = mwifiex_read_reg(adapter, reg->fw_status, _status);
@@ -2866,6 +2864,8 @@ static void mwifiex_cleanup_pcie(struct mwifiex_adapter 
*adapter)
int ret;
u32 fw_status;
 
+   cancel_work_sync(>work);
+
ret = mwifiex_read_reg(adapter, reg->fw_status, _status);
if (fw_status == FIRMWARE_READY_PCIE) {
mwifiex_dbg(adapter, INFO,
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index a4b356d267f9..3a52f02dc434 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -387,8 +387,6 @@ mwifiex_sdio_remove(struct sdio_func *func)
if (!adapter || !adapter->priv_num)
return;
 
-   cancel_work_sync(>work);
-
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
 
ret = mwifiex_sdio_read_fw_status(adapter, _stat);
@@ -2155,6 +2153,8 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter 
*adapter)
 {
struct sdio_mmc_card *card = adapter->card;
 
+   cancel_work_sync(>work);
+
kfree(card->mp_regs);
kfree(card->mpa_rx.skb_arr);
kfree(card->mpa_rx.len_arr);
-- 
2.12.0.367.g23dc2f6d3c-goog

Re: [PATCH v6 09/10] ath10k: different fw file names for usb and sdio

[Ryan Hsu]

On 03/15/2017 08:46 AM, Kalle Valo wrote:

> From: Erik Stromdahl 
>
> Since both SDIO and USB based chipsets will use different

nitpick, since the patch is separating the USB and SDIO support now, maybe you 
want to remove the "USB" from the patch title?

> firmware from the PCIe and AHB chipsets, the fw file name
> must be different depending on bus type.
>
> The new firmware names are:
>
> For PCIe and AHB:
> firmware-.bin (same as before)
>
> For SDIO:
> firmware-sdio-.bin
>
> Signed-off-by: Erik Stromdahl 
> Signed-off-by: Kalle Valo 
> ---
>  drivers/net/wireless/ath/ath10k/core.c |   13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/core.c 
> b/drivers/net/wireless/ath/ath10k/core.c
> index d7fb11107df4..d2648d09a772 100644
> --- a/drivers/net/wireless/ath/ath10k/core.c
> +++ b/drivers/net/wireless/ath/ath10k/core.c
> @@ -1398,7 +1398,18 @@ int ath10k_core_fetch_firmware_api_n(struct ath10k 
> *ar, const char *name,
>  static void ath10k_core_get_fw_name(struct ath10k *ar, char *fw_name,
>   size_t fw_name_len, int fw_api)
>  {
> - scnprintf(fw_name, fw_name_len, "%s-%d.bin", ATH10K_FW_FILE_BASE, 
> fw_api);
> + switch (ar->hif.bus) {
> + case ATH10K_BUS_SDIO:
> + scnprintf(fw_name, fw_name_len, "%s-%s-%d.bin",
> +   ATH10K_FW_FILE_BASE, ath10k_bus_str(ar->hif.bus),
> +   fw_api);
> + break;
> + case ATH10K_BUS_PCI:
> + case ATH10K_BUS_AHB:
> + scnprintf(fw_name, fw_name_len, "%s-%d.bin",
> +   ATH10K_FW_FILE_BASE, fw_api);
> + break;
> + }
>  }
>  
>  static int ath10k_core_fetch_firmware_files(struct ath10k *ar)
>
>
> ___
> ath10k mailing list
> ath...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k

Re: [PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

[Brian Norris]

On Thu, Mar 16, 2017 at 12:38:57PM -0700, Brian Norris wrote:
> On Thu, Mar 16, 2017 at 11:41:15AM -0700, Brian Norris wrote:
> > On Thu, Mar 16, 2017 at 11:33:17AM -0700, Dmitry Torokhov wrote:
> > > You need to check this flag before queueing firmware dump work, and
> > > make sure it is not racy with setting this flag in mwifiex_pcie_remove()
> > > (and sdio).
> > 
> > That's another approach that could work, but it's a little more
> > invasive.
> 
> Never mind, that isn't too invasive. There's only one schedule_work() in
> pcie.c and two in sdio.c. We could even factor out a helper, that knows
> how to check the appropriate MWIFIEX_IFACE_* flags, if we really wanted
> to...

OK, so I took a crack at implementing this, and after thinking about it,
the "make sure it is not racy with setting this flag" part is tougher
than it seems. In the end, I think the key is that to eliminate the
race between setting and checking the flag, we just want to halt all
sources of more work -- e.g., commands (which could time out), or
debugfs entries (which could trigger a FW dump manually) -- without
fiddling with extra flags. We do this already in the first half of
mwifiex_remove_card(), when we terminate the main workqueue(s) and
unregister the net and wiphy devices.

IOW, we can move the cancel_work_sync() into the .cleanup_if() callback,
which occurs after the above described teardown, but before the PCIe
driver has actually called things like pci_disable_device() [1]. Then we
don't need any DONT_RUN flag either.

I'll test the above a bit more here, then send a v3 myself, with the
above reasoning captured. I *think* that should eliminate all the races
we've discussed here.

Brian


[1] BTW, I think I previously blamed mwifiex_init_shutdown_fw() for
racing with the FW dumper; I think that is not actually the smoking
gun (it was an educated guess). Based on testing, I see aborts if
we're still accessing the PCIe device (e.g., in the FW dumper) after
mwifiex_cleanup_pcie() -> pci_disable_device().

Re: [PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

[Brian Norris]

Hi Dmitry and Amit,

On Thu, Mar 16, 2017 at 11:41:15AM -0700, Brian Norris wrote:
> On Thu, Mar 16, 2017 at 11:33:17AM -0700, Dmitry Torokhov wrote:
> > On Thu, Mar 16, 2017 at 03:58:52PM +0530, Amitkumar Karwar wrote:
> > > We observed a SHUTDOWN command timeout during reboot stress test
> > > due to a corner case firmware bug. It leads to use-after-free on
> > > adapter structure pointer and crash.
> > > 
> > > Let's add MWIFIEX_IFACE_WORK_DONT_RUN work flag to avoid executing

BTW, the 'DONT_RUN' suggestion was more of a pseudo-code suggestion than
a real name, but I guess it's not terrible :)

> > > any work scheduled after cancel_work_sync() call in teardown path
> > > to resolve the issue.
> > > 
> > > Signed-off-by: Amitkumar Karwar 
> > > ---
> > > v2: New work_flag has been added to resolve the issue cleanly as per
> > > Brian's suggestion.
> > > ---
> > >  drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> > >  drivers/net/wireless/marvell/mwifiex/pcie.c | 4 
> > >  drivers/net/wireless/marvell/mwifiex/sdio.c | 4 
> > >  3 files changed, 9 insertions(+)
> > > 
> > > diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
> > > b/drivers/net/wireless/marvell/mwifiex/main.h
> > > index 5c82972..d5b1fd6 100644
> > > --- a/drivers/net/wireless/marvell/mwifiex/main.h
> > > +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> > > @@ -510,6 +510,7 @@ struct mwifiex_roc_cfg {
> > >  enum mwifiex_iface_work_flags {
> > >   MWIFIEX_IFACE_WORK_DEVICE_DUMP,
> > >   MWIFIEX_IFACE_WORK_CARD_RESET,
> > > + MWIFIEX_IFACE_WORK_DONT_RUN,
> > >  };
> > >  
> > >  struct mwifiex_private {
> > > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> > > b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > > index a0d9180..bb3d798 100644
> > > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > > @@ -294,6 +294,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
> > >   if (!adapter || !adapter->priv_num)
> > >   return;
> > >  
> > > + set_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags);
> > >   cancel_work_sync(>work);
> > >  
> > >   reg = card->pcie.reg;
> > > @@ -2721,6 +2722,9 @@ static void mwifiex_pcie_work(struct work_struct 
> > > *work)
> > >   struct pcie_service_card *card =
> > >   container_of(work, struct pcie_service_card, work);
> > >  
> > > + if (test_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags))
> > > + return;
> > 
> > I do not see how this could possible prevent use-after-free, assuming
> > that the "card" memory is gone by the time mwifiex_pcie_work() gets to
> > run.
> 
> The 'card' memory isn't getting freed; it's the 'adapter' memory we're
> worried about. This is either already freed (because the FW init
> procedure failed), or else it's freed later in this function via
> mwifiex_remove_card().

I guess there was a slight miscommunication here: Dmitry pointed out to
me that he *was* actually talking about 'card' getting freed -- when it
gets freed after remove() finishes.

So the sequence would have to go like:

1. enter remove()
2. set DONT_RUN flag; cancel_work_sync()
3. begin to shutdown firmware
4. hit, e.g., a command timeout that schedules the work again
5. ** scheduler decides not to schedule the work for a while **
6. we finish mwifiex_remove_card(), and exit from remove() successfully
7. devm_* frees the pcie_service_card (and enclosed work_struct)
8. scheduler tries to run our work item
9. use-after-free!

However unlikely that the delay from 4 to 8 might be, this is indeed a
race condition.

> (We're also worried about having the FW dump race with the FW shutdown
> sequence, which can begin later in this function. This patch blocks both
> races AFAICT.)
> 
> > You need to check this flag before queueing firmware dump work, and
> > make sure it is not racy with setting this flag in mwifiex_pcie_remove()
> > (and sdio).
> 
> That's another approach that could work, but it's a little more
> invasive.

Never mind, that isn't too invasive. There's only one schedule_work() in
pcie.c and two in sdio.c. We could even factor out a helper, that knows
how to check the appropriate MWIFIEX_IFACE_* flags, if we really wanted
to...

Brian

Re: [PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

[Brian Norris]

Hi Dmitry,

On Thu, Mar 16, 2017 at 11:33:17AM -0700, Dmitry Torokhov wrote:
> On Thu, Mar 16, 2017 at 03:58:52PM +0530, Amitkumar Karwar wrote:
> > We observed a SHUTDOWN command timeout during reboot stress test
> > due to a corner case firmware bug. It leads to use-after-free on
> > adapter structure pointer and crash.
> > 
> > Let's add MWIFIEX_IFACE_WORK_DONT_RUN work flag to avoid executing
> > any work scheduled after cancel_work_sync() call in teardown path
> > to resolve the issue.
> > 
> > Signed-off-by: Amitkumar Karwar 
> > ---
> > v2: New work_flag has been added to resolve the issue cleanly as per
> > Brian's suggestion.
> > ---
> >  drivers/net/wireless/marvell/mwifiex/main.h | 1 +
> >  drivers/net/wireless/marvell/mwifiex/pcie.c | 4 
> >  drivers/net/wireless/marvell/mwifiex/sdio.c | 4 
> >  3 files changed, 9 insertions(+)
> > 
> > diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
> > b/drivers/net/wireless/marvell/mwifiex/main.h
> > index 5c82972..d5b1fd6 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/main.h
> > +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> > @@ -510,6 +510,7 @@ struct mwifiex_roc_cfg {
> >  enum mwifiex_iface_work_flags {
> > MWIFIEX_IFACE_WORK_DEVICE_DUMP,
> > MWIFIEX_IFACE_WORK_CARD_RESET,
> > +   MWIFIEX_IFACE_WORK_DONT_RUN,
> >  };
> >  
> >  struct mwifiex_private {
> > diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> > b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > index a0d9180..bb3d798 100644
> > --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> > +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> > @@ -294,6 +294,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
> > if (!adapter || !adapter->priv_num)
> > return;
> >  
> > +   set_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags);
> > cancel_work_sync(>work);
> >  
> > reg = card->pcie.reg;
> > @@ -2721,6 +2722,9 @@ static void mwifiex_pcie_work(struct work_struct 
> > *work)
> > struct pcie_service_card *card =
> > container_of(work, struct pcie_service_card, work);
> >  
> > +   if (test_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags))
> > +   return;
> 
> I do not see how this could possible prevent use-after-free, assuming
> that the "card" memory is gone by the time mwifiex_pcie_work() gets to
> run.

The 'card' memory isn't getting freed; it's the 'adapter' memory we're
worried about. This is either already freed (because the FW init
procedure failed), or else it's freed later in this function via
mwifiex_remove_card().

(We're also worried about having the FW dump race with the FW shutdown
sequence, which can begin later in this function. This patch blocks both
races AFAICT.)

> You need to check this flag before queueing firmware dump work, and
> make sure it is not racy with setting this flag in mwifiex_pcie_remove()
> (and sdio).

That's another approach that could work, but it's a little more
invasive.

I'm still reviewing and testing this, but I believe this is nearly
equivalent to my own draft version, which tested out fine.

Brian

Re: [PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

[Dmitry Torokhov]

On Thu, Mar 16, 2017 at 03:58:52PM +0530, Amitkumar Karwar wrote:
> We observed a SHUTDOWN command timeout during reboot stress test
> due to a corner case firmware bug. It leads to use-after-free on
> adapter structure pointer and crash.
> 
> Let's add MWIFIEX_IFACE_WORK_DONT_RUN work flag to avoid executing
> any work scheduled after cancel_work_sync() call in teardown path
> to resolve the issue.
> 
> Signed-off-by: Amitkumar Karwar 
> ---
> v2: New work_flag has been added to resolve the issue cleanly as per
> Brian's suggestion.
> ---
>  drivers/net/wireless/marvell/mwifiex/main.h | 1 +
>  drivers/net/wireless/marvell/mwifiex/pcie.c | 4 
>  drivers/net/wireless/marvell/mwifiex/sdio.c | 4 
>  3 files changed, 9 insertions(+)
> 
> diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
> b/drivers/net/wireless/marvell/mwifiex/main.h
> index 5c82972..d5b1fd6 100644
> --- a/drivers/net/wireless/marvell/mwifiex/main.h
> +++ b/drivers/net/wireless/marvell/mwifiex/main.h
> @@ -510,6 +510,7 @@ struct mwifiex_roc_cfg {
>  enum mwifiex_iface_work_flags {
>   MWIFIEX_IFACE_WORK_DEVICE_DUMP,
>   MWIFIEX_IFACE_WORK_CARD_RESET,
> + MWIFIEX_IFACE_WORK_DONT_RUN,
>  };
>  
>  struct mwifiex_private {
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index a0d9180..bb3d798 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -294,6 +294,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
>   if (!adapter || !adapter->priv_num)
>   return;
>  
> + set_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags);
>   cancel_work_sync(>work);
>  
>   reg = card->pcie.reg;
> @@ -2721,6 +2722,9 @@ static void mwifiex_pcie_work(struct work_struct *work)
>   struct pcie_service_card *card =
>   container_of(work, struct pcie_service_card, work);
>  
> + if (test_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags))
> + return;

I do not see how this could possible prevent use-after-free, assuming
that the "card" memory is gone by the time mwifiex_pcie_work() gets to
run. You need to check this flag before queueing firmware dump work, and
make sure it is not racy with setting this flag in mwifiex_pcie_remove()
(and sdio).

Thanks.

-- 
Dmitry

Re: pull-request: mac80211 2017-03-16

[David Miller]

From: Johannes Berg 
Date: Thu, 16 Mar 2017 10:51:55 +0100

> Here's the pull request you were waiting for. I went through all my
> pending patches but only this one is applicable for net.git at this
> time, so it's just a single one.
> 
> Since I didn't have a current base, I forwarded to net.git first
> and re-validated the patch there, but you might might have to be
> careful if you merge to not fast-fwd on your side (though, even
> if you do that, I don't think it matters much).
> 
> Please pull and let me know if there's any problem.

I was able to fast-forward pull this, so it should be fine.

Thanks!

Ralink - rt2800usb

[Nikita N.]

Hi All,
I'm addressing to the maintainers of Ralink driver rt2800usb (RT2870,
RT3070).
To who can I send my inquiry?
Thanks
-- 
  Nikita N.
  niki...@operamail.com

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
  love email again

ANNOUNCE: New Platinum sponsor - Facebook

[Jamal Hadi Salim]

The organizing committee would like to welcome back a repeat
platinum sponsor, Facebook!

Facebook has been a great supporter of the netdev community, we
thank them!

cheers,
jamal

Re: [PATCH v6 03/10] ath10k: htc: move htc ctrl ep connect to htc_init

[Erik Stromdahl]

On 2017-03-16 02:06, Ryan Hsu wrote:

On 03/15/2017 08:45 AM, Kalle Valo wrote:


From: Erik Stromdahl 

This patch moves the HTC ctrl service connect from
htc_wait_target to htc_init.

This is done in order to make sure the htc ctrl service
is setup properly before hif_start is called.

The reason for this is that we want the HTC ctrl service
callback to be initialized before the target sends the
HTC ready message.

The ready message will always be transmitted on endpoint 0
(which is always assigned to the HTC control service) so it
makes more sense if HTC control has been connected before the
ready message is received.

Since the service to pipe mapping is done as a part of
the service connect, the get_default_pipe call is redundant
and was removed.

Signed-off-by: Erik Stromdahl 
Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/htc.c |   39 ++---
 1 file changed, 17 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/htc.c 
b/drivers/net/wireless/ath/ath10k/htc.c
index fd5be4484984..92d5ac45327a 100644
--- a/drivers/net/wireless/ath/ath10k/htc.c
+++ b/drivers/net/wireless/ath/ath10k/htc.c
@@ -586,8 +586,6 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
struct ath10k *ar = htc->ar;
int i, status = 0;
unsigned long time_left;
-   struct ath10k_htc_svc_conn_req conn_req;
-   struct ath10k_htc_svc_conn_resp conn_resp;
struct ath10k_htc_msg *msg;
u16 message_id;
u16 credit_count;
@@ -650,22 +648,6 @@ int ath10k_htc_wait_target(struct ath10k_htc *htc)
return -ECOMM;
}

-   /* setup our pseudo HTC control endpoint connection */
-   memset(_req, 0, sizeof(conn_req));
-   memset(_resp, 0, sizeof(conn_resp));
-   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
-   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
-   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
-   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;
-
-   /* connect fake service */
-   status = ath10k_htc_connect_service(htc, _req, _resp);
-   if (status) {
-   ath10k_err(ar, "could not connect to htc service (%d)\n",
-  status);
-   return status;
-   }
-
return 0;
 }

@@ -875,8 +857,10 @@ int ath10k_htc_start(struct ath10k_htc *htc)
 /* registered target arrival callback from the HIF layer */
 int ath10k_htc_init(struct ath10k *ar)
 {
-   struct ath10k_htc_ep *ep = NULL;
+   int status;
struct ath10k_htc *htc = >htc;
+   struct ath10k_htc_svc_conn_req conn_req;
+   struct ath10k_htc_svc_conn_resp conn_resp;

spin_lock_init(>tx_lock);

@@ -884,10 +868,21 @@ int ath10k_htc_init(struct ath10k *ar)

htc->ar = ar;

-   /* Get HIF default pipe for HTC message exchange */
-   ep = >endpoint[ATH10K_HTC_EP_0];
+   /* setup our pseudo HTC control endpoint connection */
+   memset(_req, 0, sizeof(conn_req));
+   memset(_resp, 0, sizeof(conn_resp));
+   conn_req.ep_ops.ep_tx_complete = ath10k_htc_control_tx_complete;
+   conn_req.ep_ops.ep_rx_complete = ath10k_htc_control_rx_complete;
+   conn_req.max_send_queue_depth = ATH10K_NUM_CONTROL_TX_BUFFERS;
+   conn_req.service_id = ATH10K_HTC_SVC_ID_RSVD_CTRL;

-   ath10k_hif_get_default_pipe(ar, >ul_pipe_id, >dl_pipe_id);
+   /* connect fake service */
+   status = ath10k_htc_connect_service(htc, _req, _resp);
+   if (status) {
+   ath10k_err(ar, "could not connect to htc service (%d)\n",
+  status);
+   return status;
+   }



I haven't tracked down why, but just curious.
ath10K-htc_connect_service() will use ath10k_htc_send() and ath10k_hif_tx 
interface to send data down.
I am not sure if this is proper to just move it before ath10k_hif_init() is 
called, will have to check further...


The service connect of service 1 (ATH10K_HTC_SVC_ID_RSVD_CTRL) will not result 
in any bus
traffic (no ath10k_htc_send will be invoked).

ath10k_htc_connect_service has a special case for this service that assigns it 
to endpoint 0
always.

I initially had a comment about this in the commit log, but it "got lost" 
during some rebase...


init_completion(>ctl_resp);



ath10k_htc_connect_service() will expect to use htc->ctrl_resp to synchronize.
Though there is a reinit_completion() call inside that, but logically, you 
should still do the init_completion() before using it.


___
ath10k mailing list
ath...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

[PATCH 3/3] ath9k: add noise floor override option

[Simon Wunderlich]

Introduce a debugfs option to manually override the noise floor,
ignoring the automatically tuned noise floor of the driver/hw.

In my tests with a AR9580 based module and a tx99 5 MHz interferer,
I could tune the noisefloor to -95 dBm or above to allow communication
again. The automatic noise floor calibration sometimes could adapt to
the situation as well, but not reliably and permanently.

I would consider this "feature" experimental and interesting for people
debugging the noise floor calibration or other effects of the hardware.

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/calib.c |  5 ++-
 drivers/net/wireless/ath/ath9k/debug.c | 62 ++
 drivers/net/wireless/ath/ath9k/hw.h|  1 +
 3 files changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/calib.c 
b/drivers/net/wireless/ath/ath9k/calib.c
index 0f71146b781d..13ab6bc46775 100644
--- a/drivers/net/wireless/ath/ath9k/calib.c
+++ b/drivers/net/wireless/ath/ath9k/calib.c
@@ -254,7 +254,9 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
if ((i >= AR5416_MAX_CHAINS) && !IS_CHAN_HT40(chan))
continue;
 
-   if (h)
+   if (ah->nf_override)
+   nfval = ah->nf_override;
+   else if (h)
nfval = h[i].privNF;
else
nfval = default_nf;
@@ -348,6 +350,7 @@ int ath9k_hw_loadnf(struct ath_hw *ah, struct ath9k_channel 
*chan)
 
return 0;
 }
+EXPORT_SYMBOL(ath9k_hw_loadnf);
 
 
 static void ath9k_hw_nf_sanitize(struct ath_hw *ah, s16 *nf)
diff --git a/drivers/net/wireless/ath/ath9k/debug.c 
b/drivers/net/wireless/ath/ath9k/debug.c
index 43930c336987..2e64977a8ab6 100644
--- a/drivers/net/wireless/ath/ath9k/debug.c
+++ b/drivers/net/wireless/ath/ath9k/debug.c
@@ -1191,6 +1191,65 @@ static const struct file_operations fops_tpc = {
.llseek = default_llseek,
 };
 
+static ssize_t read_file_nf_override(struct file *file,
+char __user *user_buf,
+size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   char buf[32];
+   unsigned int len;
+
+   if (ah->nf_override == 0)
+   len = sprintf(buf, "off\n");
+   else
+   len = sprintf(buf, "%d\n", ah->nf_override);
+
+   return simple_read_from_buffer(user_buf, count, ppos, buf, len);
+}
+
+static ssize_t write_file_nf_override(struct file *file,
+ const char __user *user_buf,
+ size_t count, loff_t *ppos)
+{
+   struct ath_softc *sc = file->private_data;
+   struct ath_hw *ah = sc->sc_ah;
+   long val;
+   char buf[32];
+   ssize_t len;
+
+   len = min(count, sizeof(buf) - 1);
+   if (copy_from_user(buf, user_buf, len))
+   return -EFAULT;
+
+   buf[len] = '\0';
+   if (strncmp("off", buf, 3) == 0)
+   val = 0;
+   else if (kstrtol(buf, 0, ))
+   return -EINVAL;
+
+   if (val > 0)
+   return -EINVAL;
+
+   if (val < -120)
+   return -EINVAL;
+
+   ah->nf_override = val;
+
+   if (ah->curchan)
+   ath9k_hw_loadnf(ah, ah->curchan);
+
+   return count;
+}
+
+static const struct file_operations fops_nf_override = {
+   .read = read_file_nf_override,
+   .write = write_file_nf_override,
+   .open = simple_open,
+   .owner = THIS_MODULE,
+   .llseek = default_llseek,
+};
+
 /* Ethtool support for get-stats */
 
 #define AMKSTR(nm) #nm "_BE", #nm "_BK", #nm "_VI", #nm "_VO"
@@ -1402,5 +1461,8 @@ int ath9k_init_debug(struct ath_hw *ah)
debugfs_create_u16("airtime_flags", S_IRUSR | S_IWUSR,
   sc->debug.debugfs_phy, >airtime_flags);
 
+   debugfs_create_file("nf_override", S_IRUSR | S_IWUSR,
+   sc->debug.debugfs_phy, sc, _nf_override);
+
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath9k/hw.h 
b/drivers/net/wireless/ath/ath9k/hw.h
index 496e3cd1b509..eba478f052b9 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -803,6 +803,7 @@ struct ath_hw {
u32 rfkill_gpio;
u32 rfkill_polarity;
u32 ah_flags;
+   s16 nf_override;
 
bool reset_power_on;
bool htc_reset_init;
-- 
2.11.0

[PATCH 0/3] Channels in licensed bands, noise floor override

[Simon Wunderlich]

This series contains two patches to enable channels in licensed bands.
Note that there are quite a few requirements to enable those:

 * channels must be explicitly enabled using a licensed band kernel config
   which contains a warning
 * it depends on CFG80211_CERTIFICATION_ONUS
 * users must install a custom regdb, since channels in those licensed
   bands are not included in the standard regdb

The ath9k patch has been proposed two times and rejected, but it also
included some channels on fractional center frequencies, which is not
the case this time (this would require more changes in mac80211 and
also userspace). The other concern about useres accidently tuning
should not be a problem based on the requirements mentioned above. I've
added another patch doing the same thing for ath10k.

Here is some more info on our need/background:

"We are working on a project that involves the use of Public Safety 
channels (4.9x GHz). It is typical 'First Responder' scenario where a 
communication network infrastructure should be set up in catastrophe 
situations.

As this is a controlled and managed network, the organization setting up 
the network has control over the channels that are being used, when and 
for how long and in which geographical area.  The enforcement of such a 
temporary license is a major requirement in this project.

To reduce the cost for the equipment (compared to commercial offerings 
in the 4k USD range), the outdoor devices run on hardened, but standard 
embedded hardware with a recent linux kernel and use Atheros radios.

We believe, that driver support for 4.9GHz channels should be included 
in the Linux kernel, as the driver just exposes specified hardware 
features which are disabled by default via

a) a separate compile-time flag. This is similar to the code used for 
compliance testing.

b) The default CRDA should (and does) not enable such channels.

Those two safeguards seem sufficient to protect against accidental misuse."

The third patch is adding an experimental debug option to override
the noise floor level, which is usually calibrated automatically.

Cheers,
 Simon

Ben Greear (1):
  ath9k: Support channels in licensed bands

Simon Wunderlich (2):
  ath10k: add support for channels in licensed bands
  ath9k: add noise floor override option

 drivers/net/wireless/ath/ath10k/Kconfig  | 20 +
 drivers/net/wireless/ath/ath10k/core.h   |  4 ++
 drivers/net/wireless/ath/ath10k/mac.c|  9 
 drivers/net/wireless/ath/ath10k/wmi.c|  7 +++-
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 +
 drivers/net/wireless/ath/ath9k/ath9k.h   |  2 +-
 drivers/net/wireless/ath/ath9k/calib.c   |  5 ++-
 drivers/net/wireless/ath/ath9k/common-init.c | 35 
 drivers/net/wireless/ath/ath9k/debug.c   | 62 
 drivers/net/wireless/ath/ath9k/hw.h  |  5 ++-
 10 files changed, 155 insertions(+), 14 deletions(-)

-- 
2.11.0

[PATCH 1/3] ath9k: Support channels in licensed bands

[Simon Wunderlich]

From: Ben Greear 

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Ben Greear 
[Hide this support behind a Kconfig option]
Signed-off-by: Julian Calaby 
[only use the 20 mhz channels, add 5 ghz, change to 4.9ghz to licensed bands]
Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath9k/Kconfig   | 20 
 drivers/net/wireless/ath/ath9k/ath9k.h   |  2 +-
 drivers/net/wireless/ath/ath9k/common-init.c | 35 +---
 drivers/net/wireless/ath/ath9k/hw.h  |  4 ++--
 4 files changed, 50 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index 783a38f1a626..23b8abf4449a 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -116,6 +116,26 @@ config ATH9K_DFS_CERTIFIED
  developed. At this point enabling this option won't do anything
  except increase code size.
 
+config ATH9K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH9K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
+
 config ATH9K_DYNACK
bool "Atheros ath9k ACK timeout estimation algorithm (EXPERIMENTAL)"
depends on ATH9K
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index cf076719c27e..d215c3f968d4 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -996,7 +996,7 @@ struct ath_softc {
struct device *dev;
 
struct survey_info *cur_survey;
-   struct survey_info survey[ATH9K_NUM_CHANNELS];
+   struct survey_info survey[ATH9K_MAX_NUM_CHANNELS];
 
spinlock_t intr_lock;
struct tasklet_struct intr_tq;
diff --git a/drivers/net/wireless/ath/ath9k/common-init.c 
b/drivers/net/wireless/ath/ath9k/common-init.c
index 8b4f7fdabf58..0d632c22bc16 100644
--- a/drivers/net/wireless/ath/ath9k/common-init.c
+++ b/drivers/net/wireless/ath/ath9k/common-init.c
@@ -86,6 +86,22 @@ static const struct ieee80211_channel ath9k_5ghz_chantable[] 
= {
CHAN5G(5785, 35), /* Channel 157 */
CHAN5G(5805, 36), /* Channel 161 */
CHAN5G(5825, 37), /* Channel 165 */
+
+#ifdef CONFIG_ATH9K_LICENSED_CHAN
+   /* 4.9Ghz channels, public safety channels, license is required in US
+* and most other regulatory domains!
+*/
+   /* 802.11j 4.9 GHz (20 MHz) */
+   CHAN5G(4920, 38), /* channel 184 */
+   CHAN5G(4940, 39), /* channel 188 */
+   CHAN5G(4960, 40), /* channel 192 */
+   CHAN5G(4980, 41), /* channel 196 */
+   /* 802.11j 5.030 - 5.080 GHz (20 MHz) */
+   CHAN5G(5040, 42), /* channel 8 */
+   CHAN5G(5060, 43), /* channel 12 */
+   CHAN5G(5080, 44), /* channel 16 */
+#endif
+#define ATH9K_NUM_LICENSED_CHANNELS 7
 };
 
 /* Atheros hardware rate code addition for short premble */
@@ -126,10 +142,14 @@ int ath9k_cmn_init_channels_rates(struct ath_common 
*common)
 {
struct ath_hw *ah = (struct ath_hw *)common->ah;
void *channels;
+   int num_5ghz_chan = ARRAY_SIZE(ath9k_5ghz_chantable);
+
+   if (!IS_ENABLED(CONFIG_ATH9K_LICENSED_CHAN))
+   num_5ghz_chan -= ATH9K_NUM_LICENSED_CHANNELS;
 
BUILD_BUG_ON(ARRAY_SIZE(ath9k_2ghz_chantable) +
-ARRAY_SIZE(ath9k_5ghz_chantable) !=
-ATH9K_NUM_CHANNELS);
+ARRAY_SIZE(ath9k_5ghz_chantable) >
+ATH9K_MAX_NUM_CHANNELS);
 
if (ah->caps.hw_caps & ATH9K_HW_CAP_2GHZ) {
channels = devm_kzalloc(ah->dev,
@@ -149,17 +169,16 @@ int ath9k_cmn_init_channels_rates(struct ath_common 

[PATCH 2/3] ath10k: add support for channels in licensed bands

[Simon Wunderlich]

Many chips support channels in licensed bands. Add support for those,
along with a corresponding kernel config option to disable them by
default. Note that these channels are not selectable even if the
option has been compiled unless the user modifies the regulatory
database to explicitly enable the corresponding channels.

NOTE:  These channels must not be used in most regulatory
domains unless you have a license from the FCC or similar!

Signed-off-by: Simon Wunderlich 
Signed-off-by: Mathias Kretschmer 
---
 drivers/net/wireless/ath/ath10k/Kconfig | 20 
 drivers/net/wireless/ath/ath10k/core.h  |  4 
 drivers/net/wireless/ath/ath10k/mac.c   |  9 +
 drivers/net/wireless/ath/ath10k/wmi.c   |  7 +--
 4 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/Kconfig 
b/drivers/net/wireless/ath/ath10k/Kconfig
index b4241cf9b7ed..13a23ed33f91 100644
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
@@ -53,3 +53,23 @@ config ATH10K_DFS_CERTIFIED
---help---
This option enables DFS support for initiating radiation on
ath10k.
+
+config ATH10K_LICENSED_CHAN
+   bool "Support channels in licensed bands"
+   depends on ATH10K && CFG80211_CERTIFICATION_ONUS
+   default n
+   ---help---
+ This option enables support for licensed channels on such as
+  4.9 GHz (public safety).
+
+ These are PUBLIC SAFETY CHANNELS and MUST NOT BE USED in most
+ regulatory domains UNLESS YOU HAVE A FULL LICENSE for their use from
+ your local radio regulator, e.g. the FCC or equivalent. Using these
+ channels without proper authorisation may result in serious legal
+ consequences.
+
+ You will also have to build a regulatory database with these channels
+ enabled to actually use them.
+
+ If you are a distro kernel builder or have any doubt whatsoever about
+ your legal ability to use these channels, say N.
diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index d4b9a0ec1bdc..7674641537b4 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -46,7 +46,11 @@
 #define WMI_READY_TIMEOUT (5 * HZ)
 #define ATH10K_FLUSH_TIMEOUT_HZ (5 * HZ)
 #define ATH10K_CONNECTION_LOSS_HZ (3 * HZ)
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+#define ATH10K_NUM_CHANS 47
+#else
 #define ATH10K_NUM_CHANS 40
+#endif
 
 /* Antenna noise floor */
 #define ATH10K_DEFAULT_NOISE_FLOOR -95
diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a25f0ec15cf8..23895af0fc63 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7669,6 +7669,15 @@ static const struct ieee80211_channel 
ath10k_5ghz_channels[] = {
CHAN5G(161, 5805, 0),
CHAN5G(165, 5825, 0),
CHAN5G(169, 5845, 0),
+#ifdef CONFIG_ATH10K_LICENSED_CHAN
+   CHAN5G(184, 4920, 0),
+   CHAN5G(188, 4940, 0),
+   CHAN5G(192, 4960, 0),
+   CHAN5G(196, 4980, 0),
+   CHAN5G(8,   5040, 0),
+   CHAN5G(12,  5060, 0),
+   CHAN5G(16,  5080, 0),
+#endif
 };
 
 struct ath10k *ath10k_mac_create(size_t priv_size)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 4e60caec7ab4..de7a4fa9d347 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -2323,10 +2323,13 @@ int ath10k_wmi_event_mgmt_rx(struct ath10k *ar, struct 
sk_buff *skb)
/* Hardware can Rx CCK rates on 5GHz. In that case phy_mode is set to
 * MODE_11B. This means phy_mode is not a reliable source for the band
 * of mgmt rx.
+*
+* On the other hand, channel 8, 12 and 16 are defined in 5GHz as well
+* (5040 - 5080 MHz), therefore apply the override only for channels <=7
 */
-   if (channel >= 1 && channel <= 14) {
+   if (channel >= 1 && channel <= 7) {
status->band = NL80211_BAND_2GHZ;
-   } else if (channel >= 36 && channel <= 169) {
+   } else if (channel >= 8 && channel <= 196) {
status->band = NL80211_BAND_5GHZ;
} else {
/* Shouldn't happen unless list of advertised channels to
-- 
2.11.0

Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function

[Greg KH]

On Thu, Mar 16, 2017 at 02:55:09PM +0100, Rafał Miłecki wrote:
> On 02/23/2017 07:30 PM, Rafał Miłecki wrote:
> > From: Rafał Miłecki 
> > 
> > So far we got only one function for loading firmware asynchronously:
> > request_firmware_nowait. It didn't allow much customization of firmware
> > loading process - there is only one bool uevent argument. Moreover this
> > bool also controls user helper in an unclear way.
> > 
> > Resolve this problem by adding one internally shared  function that
> > allows specifying any flags manually.
> > 
> > This implementation:
> > 1) Allows keeping old request_firmware_nowait API unchanged
> > 2) Doesn't require adjusting / rewriting current drivers
> > 3) Minimizes risk of regressions
> > 4) Adds new function for drivers that need more control over loading a
> >firmware.
> > 
> > The new function takes options struct pointer as an argument to make
> > further improvements possible (without any big reworks).
> > 
> > Signed-off-by: Rafał Miłecki 
> > ---
> > V3: Don't expose all FW_OPT_* flags.
> > As Luis noted we want a struct so add struct firmware_opts for real
> > flexibility.
> > Thank you Luis for your review!
> > 
> > Ming/Luis/Greg: assuming this gets a positive review, could someone of you 
> > pick
> > this patchset?
> 
> Hi Ming,
> 
> It seems you changed e-mail address somewhere between V3 and V4 of this
> patchset. Could you review/comment/ack this, please?

Ming isn't the firmware maintainer anymore :(

> Luis: would you ack this patch now I followed your guidance?

It's up to Luis now :)

greg k-h

iwl3945 bug report (occasionally crashing after suspend)

[korgman]

Hello there,

I have the same problem as reported here.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1627828

and here
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1629603

If I understood correctly (form 2nd link) the latest good kernel was 4.4.4 
after 4.4.6 we have the problem. (see message #5)

I quote:
"Not a full bisection yet but I have narrowed it down:

I looked at all kernel versions that had changes committed to iwlwifi and 
tested between them.

I now have determined that I do not have this issue in the kernel version 4.4.4.

I do have the issue in 4.4.6 and that is the next kernel version that has changes to 
iwlwifi so I guess that is the first bad version."

I am on Slackware-14.2 64bit custom config kernel. I can try some things if you 
want.

If I modprobe -r iwl3945 | disable wifi (i have physical switch) | suspend to 
ram | power on | enable wifi (physical switch) | modrpobe iwl3945 the device is 
working again.

Thank you!

(excuse my bad English)

Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function

[Rafał Miłecki]

On 02/23/2017 07:30 PM, Rafał Miłecki wrote:

From: Rafał Miłecki 

So far we got only one function for loading firmware asynchronously:
request_firmware_nowait. It didn't allow much customization of firmware
loading process - there is only one bool uevent argument. Moreover this
bool also controls user helper in an unclear way.

Resolve this problem by adding one internally shared  function that
allows specifying any flags manually.

This implementation:
1) Allows keeping old request_firmware_nowait API unchanged
2) Doesn't require adjusting / rewriting current drivers
3) Minimizes risk of regressions
4) Adds new function for drivers that need more control over loading a
   firmware.

The new function takes options struct pointer as an argument to make
further improvements possible (without any big reworks).

Signed-off-by: Rafał Miłecki 
---
V3: Don't expose all FW_OPT_* flags.
As Luis noted we want a struct so add struct firmware_opts for real
flexibility.
Thank you Luis for your review!

Ming/Luis/Greg: assuming this gets a positive review, could someone of you pick
this patchset?


Hi Ming,

It seems you changed e-mail address somewhere between V3 and V4 of this
patchset. Could you review/comment/ack this, please?

Luis: would you ack this patch now I followed your guidance?



---
 drivers/base/firmware_class.c | 43 ++-
 include/linux/firmware.h  | 15 ++-
 2 files changed, 48 insertions(+), 10 deletions(-)

diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index d05be1732c8b..b67b294eb31a 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -1356,7 +1356,7 @@ static void request_firmware_work_func(struct work_struct 
*work)
_request_firmware(, fw_work->name, fw_work->device, NULL, 0,
  fw_work->opt_flags);
fw_work->cont(fw, fw_work->context);
-   put_device(fw_work->device); /* taken in request_firmware_nowait() */
+   put_device(fw_work->device); /* taken in __request_firmware_nowait() */

module_put(fw_work->module);
kfree_const(fw_work->name);
@@ -1364,10 +1364,9 @@ static void request_firmware_work_func(struct 
work_struct *work)
 }

 /**
- * request_firmware_nowait - asynchronous version of request_firmware
+ * __request_firmware_nowait - asynchronous version of request_firmware
  * @module: module requesting the firmware
- * @uevent: sends uevent to copy the firmware image if this flag
- * is non-zero else the firmware copy must be done manually.
+ * @opt_flags: flags that control firmware loading process, see FW_OPT_*
  * @name: name of firmware file
  * @device: device for which firmware is being loaded
  * @gfp: allocation flags
@@ -1386,9 +1385,9 @@ static void request_firmware_work_func(struct work_struct 
*work)
  *
  * - can't sleep at all if @gfp is GFP_ATOMIC.
  **/
-int
-request_firmware_nowait(
-   struct module *module, bool uevent,
+static int
+__request_firmware_nowait(
+   struct module *module, unsigned int opt_flags,
const char *name, struct device *device, gfp_t gfp, void *context,
void (*cont)(const struct firmware *fw, void *context))
 {
@@ -1407,8 +1406,7 @@ request_firmware_nowait(
fw_work->device = device;
fw_work->context = context;
fw_work->cont = cont;
-   fw_work->opt_flags = FW_OPT_NOWAIT | FW_OPT_FALLBACK |
-   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+   fw_work->opt_flags = FW_OPT_NOWAIT | opt_flags;

if (!try_module_get(module)) {
kfree_const(fw_work->name);
@@ -1421,8 +1419,35 @@ request_firmware_nowait(
schedule_work(_work->work);
return 0;
 }
+
+int request_firmware_nowait(struct module *module, bool uevent,
+   const char *name, struct device *device, gfp_t gfp,
+   void *context,
+   void (*cont)(const struct firmware *fw, void 
*context))
+{
+   unsigned int opt_flags = FW_OPT_FALLBACK |
+   (uevent ? FW_OPT_UEVENT : FW_OPT_USERHELPER);
+
+   return __request_firmware_nowait(module, opt_flags, name, device, gfp,
+context, cont);
+}
 EXPORT_SYMBOL(request_firmware_nowait);

+int __request_firmware_async(struct module *module, const char *name,
+struct firmware_opts *fw_opts, struct device *dev,
+void *context,
+void (*cont)(const struct firmware *fw, void 
*context))
+{
+   unsigned int opt_flags = FW_OPT_UEVENT;
+
+   if (fw_opts->optional)
+   opt_flags |= FW_OPT_NO_WARN;
+
+   return __request_firmware_nowait(module, opt_flags, name, dev,
+GFP_KERNEL, context, cont);
+}
+EXPORT_SYMBOL(__request_firmware_async);
+
 #ifdef 

Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function

[Greg KH]

On Thu, Mar 16, 2017 at 10:57:00AM +0100, Rafał Miłecki wrote:
> On 23 February 2017 at 19:30, Rafał Miłecki  wrote:
> > From: Rafał Miłecki 
> >
> > So far we got only one function for loading firmware asynchronously:
> > request_firmware_nowait. It didn't allow much customization of firmware
> > loading process - there is only one bool uevent argument. Moreover this
> > bool also controls user helper in an unclear way.
> >
> > Resolve this problem by adding one internally shared  function that
> > allows specifying any flags manually.
> >
> > This implementation:
> > 1) Allows keeping old request_firmware_nowait API unchanged
> > 2) Doesn't require adjusting / rewriting current drivers
> > 3) Minimizes risk of regressions
> > 4) Adds new function for drivers that need more control over loading a
> >firmware.
> >
> > The new function takes options struct pointer as an argument to make
> > further improvements possible (without any big reworks).
> >
> > Signed-off-by: Rafał Miłecki 
> > ---
> > V3: Don't expose all FW_OPT_* flags.
> > As Luis noted we want a struct so add struct firmware_opts for real
> > flexibility.
> > Thank you Luis for your review!
> >
> > Ming/Luis/Greg: assuming this gets a positive review, could someone of you 
> > pick
> > this patchset?
> 
> Ping. I hope it's relatively simple and non-intrusive change with a
> proper design now.
> 
> Is there some who could pick this small patchset?

It would be nice if the firmware maintainer could review it, I can't do
anything with this until then...

thanks,

greg k-h

[PATCH] mwifiex: send fewer channels to scan while connected

[Amitkumar Karwar]

Application triggers periodic background scans when device is connected.
We will scan less number of channels per scan command so that data
traffic won't get affected.

Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/scan.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/scan.c 
b/drivers/net/wireless/marvell/mwifiex/scan.c
index 1816916..8295a05 100644
--- a/drivers/net/wireless/marvell/mwifiex/scan.c
+++ b/drivers/net/wireless/marvell/mwifiex/scan.c
@@ -989,10 +989,15 @@ enum cipher_suite {
 *  If a specific BSSID or SSID is used, the number of channels in the
 *  scan command will be increased to the absolute maximum.
 */
-   if (*filtered_scan)
+   if (*filtered_scan) {
*max_chan_per_scan = MWIFIEX_MAX_CHANNELS_PER_SPECIFIC_SCAN;
-   else
-   *max_chan_per_scan = MWIFIEX_DEF_CHANNELS_PER_SCAN_CMD;
+   } else {
+   if (!priv->media_connected)
+   *max_chan_per_scan = MWIFIEX_DEF_CHANNELS_PER_SCAN_CMD;
+   else
+   *max_chan_per_scan =
+   MWIFIEX_DEF_CHANNELS_PER_SCAN_CMD / 2;
+   }
 
if (adapter->ext_scan) {
bss_mode = (struct mwifiex_ie_types_bss_mode *)tlv_pos;
-- 
1.9.1

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

[Johannes Berg]

Sorry - this is the other half of my reply that I accidentally deleted
before sending...
 
> +static void flush_tx_skbs(struct ieee80211_sub_if_data *sdata)
> +{
> + struct ieee80211_if_mesh *ifmsh = >u.mesh;
> + struct mesh_tx_queue *tx_node;
> +
> + spin_lock_bh(>mesh_tx_queue_lock);
> +
> + /* Note that this check is important because of the two-
> stage
> +  * way that ieee80211_if_mesh is initialized.
> +  */

I think you should fix that rather than work around it. If this is
called with iftype != mesh then this is super problematic anyway, since
ifmsh->tx_queue_len would alias some other variable (there's a union).

> + if (ifmsh->tx_queue_len > 0) {
> + mhwmp_dbg(sdata, "flushing %d skbs", ifmsh-
> >tx_queue_len);
> +
> + while (!list_empty(>tx_queue.list)) {
> + tx_node = list_last_entry(
> >tx_queue.list,
> +   struct
> mesh_tx_queue, list);
> + kfree_skb(tx_node->skb);
> + list_del(_node->list);
> + kfree(tx_node);
> + }
> + ifmsh->tx_queue_len = 0;
> + }
> +
> + spin_unlock_bh(>mesh_tx_queue_lock);
> +}

All of this also gets *vastly* simpler if it's just skb_queue_purge()
:)

> + spin_lock_bh(>mesh_tx_queue_lock);
> +
> + list_for_each_entry(tx_node, >tx_queue.list, list) {
> + ieee80211_tx_skb(sdata, tx_node->skb);
> + }

I don't think you should hold the lock across _tx_skb(), ISTR problems
with that - particularly with the STA lock, so this might be OK, but it
might also cause lock ordering issues. It's easy to avoid anyway, so
better not to do it.

johannes

[PATCH v2] mwifiex: fix kernel crash after shutdown command timeout

[Amitkumar Karwar]

We observed a SHUTDOWN command timeout during reboot stress test
due to a corner case firmware bug. It leads to use-after-free on
adapter structure pointer and crash.

Let's add MWIFIEX_IFACE_WORK_DONT_RUN work flag to avoid executing
any work scheduled after cancel_work_sync() call in teardown path
to resolve the issue.

Signed-off-by: Amitkumar Karwar 
---
v2: New work_flag has been added to resolve the issue cleanly as per
Brian's suggestion.
---
 drivers/net/wireless/marvell/mwifiex/main.h | 1 +
 drivers/net/wireless/marvell/mwifiex/pcie.c | 4 
 drivers/net/wireless/marvell/mwifiex/sdio.c | 4 
 3 files changed, 9 insertions(+)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index 5c82972..d5b1fd6 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -510,6 +510,7 @@ struct mwifiex_roc_cfg {
 enum mwifiex_iface_work_flags {
MWIFIEX_IFACE_WORK_DEVICE_DUMP,
MWIFIEX_IFACE_WORK_CARD_RESET,
+   MWIFIEX_IFACE_WORK_DONT_RUN,
 };
 
 struct mwifiex_private {
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index a0d9180..bb3d798 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -294,6 +294,7 @@ static void mwifiex_pcie_remove(struct pci_dev *pdev)
if (!adapter || !adapter->priv_num)
return;
 
+   set_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags);
cancel_work_sync(>work);
 
reg = card->pcie.reg;
@@ -2721,6 +2722,9 @@ static void mwifiex_pcie_work(struct work_struct *work)
struct pcie_service_card *card =
container_of(work, struct pcie_service_card, work);
 
+   if (test_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags))
+   return;
+
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP,
   >work_flags))
mwifiex_pcie_device_dump_work(card->adapter);
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index a4b356d..8140bb4 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -387,6 +387,7 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
 
+   set_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags);
cancel_work_sync(>work);
 
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
@@ -2514,6 +2515,9 @@ static void mwifiex_sdio_work(struct work_struct *work)
struct sdio_mmc_card *card =
container_of(work, struct sdio_mmc_card, work);
 
+   if (test_bit(MWIFIEX_IFACE_WORK_DONT_RUN, >work_flags))
+   return;
+
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP,
   >work_flags))
mwifiex_sdio_device_dump_work(card->adapter);
-- 
1.9.1

Re: [PATCH v2] mac80211: Jitter HWMP MPATH reply frames to reduce collision on dense networks.

[Johannes Berg]

Hi,

So I guess after all the discussion, you should amend the commit log a
bit, certainly at least to mention the hidden-node issue.

Regarding the patch itself, I'm not super happy with how big it is,
some additional comments below:

> +struct mesh_tx_queue {
> + struct list_head list;
> + struct sk_buff *skb;
> +};

This seems awkward, what's wrong with using an SKB list (struct
sk_buff_head, skb_queue_* etc)?

> + /* Spinlock for trasmitted MPATH frames */
> + spinlock_t mesh_tx_queue_lock;

That would also contain the extra spinlock.

> + struct mesh_tx_queue tx_queue;

This was always a bad idea, since you never need the skb pointer here -
should've just used struct list_head.

> + int tx_queue_len;

Also contained in the skb queue.

> + struct delayed_work tx_work;

I don't really see any value here for a delayed work - a pure timer
would work just as well?

Also, these fields should be in ifmsh, I think?

johannes

[RFC v3] cfg80211: add support for HE MCSs

[Johannes Berg]

From: Johannes Berg 

Add support for the HE MCSs in cfg80211 and also add userspace
API to nl80211 to send rate information out.

The bandwidth calculation is somewhat approximate to avoid all
the big tables that are otherwise necessary.

Signed-off-by: Johannes Berg 
---
 include/net/cfg80211.h   | 15 +++--
 include/uapi/linux/nl80211.h | 42 +++
 net/wireless/nl80211.c   | 16 +
 net/wireless/util.c  | 80 
 4 files changed, 151 insertions(+), 2 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index ffc08687b31d..ef558e46d3ef 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -986,12 +986,14 @@ int cfg80211_check_station_change(struct wiphy *wiphy,
  * @RATE_INFO_FLAGS_VHT_MCS: mcs field filled with VHT MCS
  * @RATE_INFO_FLAGS_SHORT_GI: 400ns guard interval
  * @RATE_INFO_FLAGS_60G: 60GHz MCS
+ * @RATE_INFO_FLAGS_HE_MCS: HE MCS information
  */
 enum rate_info_flags {
RATE_INFO_FLAGS_MCS = BIT(0),
RATE_INFO_FLAGS_VHT_MCS = BIT(1),
RATE_INFO_FLAGS_SHORT_GI= BIT(2),
RATE_INFO_FLAGS_60G = BIT(3),
+   RATE_INFO_FLAGS_HE_MCS  = BIT(4),
 };
 
 /**
@@ -1005,6 +1007,7 @@ enum rate_info_flags {
  * @RATE_INFO_BW_40: 40 MHz bandwidth
  * @RATE_INFO_BW_80: 80 MHz bandwidth
  * @RATE_INFO_BW_160: 160 MHz bandwidth
+ * @RATE_INFO_BW_HE_RU: bandwidth determined by HE RU allocation
  */
 enum rate_info_bw {
RATE_INFO_BW_5,
@@ -1013,6 +1016,7 @@ enum rate_info_bw {
RATE_INFO_BW_40,
RATE_INFO_BW_80,
RATE_INFO_BW_160,
+   RATE_INFO_BW_HE_RU,
 };
 
 /**
@@ -1021,10 +1025,14 @@ enum rate_info_bw {
  * Information about a receiving or transmitting bitrate
  *
  * @flags: bitflag of flags from  rate_info_flags
- * @mcs: mcs index if struct describes a 802.11n bitrate
+ * @mcs: mcs index if struct describes an HT/VHT/HE rate
  * @legacy: bitrate in 100kbit/s for 802.11abg
- * @nss: number of streams (VHT only)
+ * @nss: number of streams (VHT & HE only)
  * @bw: bandwidth (from  rate_info_bw)
+ * @he_gi: HE guard interval (from  nl80211_he_gi)
+ * @he_dcm: HE DCM value
+ * @he_ru_alloc: HE RU allocation (from  nl80211_he_ru_alloc,
+ * only valid if bw is %RATE_INFO_BW_HE_RU)
  */
 struct rate_info {
u8 flags;
@@ -1032,6 +1040,9 @@ struct rate_info {
u16 legacy;
u8 nss;
u8 bw;
+   u8 he_gi;
+   u8 he_dcm;
+   u8 he_ru_alloc;
 };
 
 /**
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 9a499b15cfbc..f2b577dbaca0 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2598,6 +2598,36 @@ struct nl80211_sta_flag_update {
 } __attribute__((packed));
 
 /**
+ * enum nl80211_he_gi - HE guard interval
+ * @NL80211_RATE_INFO_HE_GI_0_8: 0.8 usec
+ * @NL80211_RATE_INFO_HE_GI_1_6: 1.6 usec
+ * @NL80211_RATE_INFO_HE_GI_3_2: 3.2 usec
+ */
+enum nl80211_he_gi {
+   NL80211_RATE_INFO_HE_GI_0_8,
+   NL80211_RATE_INFO_HE_GI_1_6,
+   NL80211_RATE_INFO_HE_GI_3_2,
+};
+
+/**
+ * @enum nl80211_he_ru_alloc - HE RU allocation values
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_26: 26-tone RU allocation
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_52: 52-tone RU allocation
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_106: 106-tone RU allocation
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_242: 242-tone RU allocation
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_484: 484-tone RU allocation
+ * @NL80211_RATE_INFO_HE_RU_ALLOC_969: 969-tone RU allocation
+ */
+enum nl80211_he_ru_alloc {
+   NL80211_RATE_INFO_HE_RU_ALLOC_26,
+   NL80211_RATE_INFO_HE_RU_ALLOC_52,
+   NL80211_RATE_INFO_HE_RU_ALLOC_106,
+   NL80211_RATE_INFO_HE_RU_ALLOC_242,
+   NL80211_RATE_INFO_HE_RU_ALLOC_484,
+   NL80211_RATE_INFO_HE_RU_ALLOC_969,
+};
+
+/**
  * enum nl80211_rate_info - bitrate information
  *
  * These attribute types are used with %NL80211_STA_INFO_TXRATE
@@ -2629,6 +2659,13 @@ struct nl80211_sta_flag_update {
  * @NL80211_RATE_INFO_5_MHZ_WIDTH: 5 MHz width - note that this is
  * a legacy rate and will be reported as the actual bitrate, i.e.
  * a quarter of the base (20 MHz) rate
+ * @NL80211_RATE_INFO_HE_MCS: HE MCS index (u8, 0-11)
+ * @NL80211_RATE_INFO_HE_NSS: HE NSS value (u8, 1-8)
+ * @NL80211_RATE_INFO_HE_GI: HE guard interval identifier
+ * (u8, see  nl80211_he_gi)
+ * @NL80211_RATE_INFO_HE_DCM: HE DCM value (u8, 0/1)
+ * @NL80211_RATE_INFO_RU_ALLOC: HE RU allocation, if not present then
+ * non-OFDMA was used (u8, see  nl80211_he_ru_alloc)
  * @__NL80211_RATE_INFO_AFTER_LAST: internal use
  */
 enum nl80211_rate_info {
@@ -2645,6 +2682,11 @@ enum nl80211_rate_info {
NL80211_RATE_INFO_160_MHZ_WIDTH,
NL80211_RATE_INFO_10_MHZ_WIDTH,
NL80211_RATE_INFO_5_MHZ_WIDTH,
+   NL80211_RATE_INFO_HE_MCS,
+   

Re: Beacon interval for Mesh/AP in single interface

[Johannes Berg]

On Wed, 2017-03-15 at 16:25 +0800, Chun-Yeow Yeoh wrote:

> Yes, ath9k for mesh/AP running simultaneously in one single radio
> interface can do beaconing using different beacon interval. Mesh
> providing backhaul to user accessing via STA/AP mode.

Ok.

> > If that worked, then it'd be reasonable to add the appropriate
> > value to
> > the interface combinations to let it work as before.
> > 
> > If it didn't really work properly, then we can just fix the
> > defaults to
> > be compatible?
> 
> I try to put beacon_int_min_gcd in the interface combination with
> mesh/AP/adhoc but the patch "[PATCH] cfg80211: disallow
> beacon_int_min_gcd with IBSS" disables the mesh interface due to
> adhoc interface is there.

Can we split the combination? Or should we just work on fixing this
limitation? Perhaps we could say that if beacon_int_min_gcd is 1, then
that obviously means that there's no real restriction, and then we can
allow with IBSS? How would the hardware react if you had one interface
with beacon interval 99 TU and another with 100 TU? they can collide,
but if there's some kind of mitigation it wouldn't matter, just one of
them would come late after the TBTT...

If it seems reasonable for this hardware to advertise
beacon_int_min_gcd==1, then I think we can change cfg80211 to allow
IBSS in that case.

johannes

Re: [PATCH 2/2] mac80211: Drop new node with weak power

[Johannes Berg]

Hi,

On Thu, 2017-03-16 at 10:57 +0900, Masashi Honma wrote:
> On some practical cases, it is useful to drop new node in the
> distance.
> Because mesh metric is calculated with hop count and without RSSI
> information, a node far from local peer and near to destination node
> could be used as best path.
> 
> For example, the nodes are located in linear. Distance of 0 - 1 and
> 1 - 2 and 2 - 3 is 20meters. 0 to 3 signal is very weak.
> 
> 0 --- 1 --- 2 --- 3
> 
> Though most robust path from 0 to 3 is 0 -> 1 -> 2 -> 3,
> unfortunately, node 0 could recognize node 3 as neighbor. Then node 3
> could be next of node 0. This patch aims to avoid such a case.

I'm not really sure this is the right solution?

It seems to me that it should be a function of the path selection to
take this into account, not prohibiting the longer path entirely?

It seems that this is really what the meshcfg.rssi_threshold was
intended for, and the plink code *does* take it into account. Can you
explain where that's breaking down?

The documentation for this als talks about it being a plink threshold,
so I'm not really sure we should use it to kick out stations entirely.

johannes

Re: [PATCH V4 1/2] firmware: add more flexible request_firmware_async function

[Rafał Miłecki]

On 23 February 2017 at 19:30, Rafał Miłecki  wrote:
> From: Rafał Miłecki 
>
> So far we got only one function for loading firmware asynchronously:
> request_firmware_nowait. It didn't allow much customization of firmware
> loading process - there is only one bool uevent argument. Moreover this
> bool also controls user helper in an unclear way.
>
> Resolve this problem by adding one internally shared  function that
> allows specifying any flags manually.
>
> This implementation:
> 1) Allows keeping old request_firmware_nowait API unchanged
> 2) Doesn't require adjusting / rewriting current drivers
> 3) Minimizes risk of regressions
> 4) Adds new function for drivers that need more control over loading a
>firmware.
>
> The new function takes options struct pointer as an argument to make
> further improvements possible (without any big reworks).
>
> Signed-off-by: Rafał Miłecki 
> ---
> V3: Don't expose all FW_OPT_* flags.
> As Luis noted we want a struct so add struct firmware_opts for real
> flexibility.
> Thank you Luis for your review!
>
> Ming/Luis/Greg: assuming this gets a positive review, could someone of you 
> pick
> this patchset?

Ping. I hope it's relatively simple and non-intrusive change with a
proper design now.

Is there some who could pick this small patchset?

Re: [PATCH] mac80211: Use setup_timer instead of init_timer

[Johannes Berg]

On Thu, 2017-03-09 at 10:34 +0100, ondrej.lyso...@seznam.cz wrote:
> From: Ondřej Lysoněk 
> 
> Use setup_timer() and setup_deferrable_timer() to set the data and
> function timer fields. It makes the code cleaner and will allow for
> easier change of the timer struct internals.
> 
Applied, thanks.

johannes

Re: [PATCH 1/2] nl80211: Use signed function for a signed variable

[Johannes Berg]

On Thu, 2017-03-16 at 10:57 +0900, Masashi Honma wrote:
> The rssi_threshold is defined as s32.
> 
Doesn't really matter much, but does seem nicer - applied.

johannes

Re: ath6kl: Remove old 802.11a-only channels

[Rostyslav Khudolii]

On 16 March 2017 at 10:36, Kalle Valo  wrote:
> Rostyslav Khudolii  wrote:
>> Channels 34/38/42/46 can only be used for compatibility with
>> old devices sold in Japan. Modern products, such as AR6003/AR6004
>> don't support these channels.
>> Keeping them in the upstream is error prone and requires full
>> network stack support.
>> A custom patch should be used in case such compatibility is required.
>>
>> Signed-off-by: Rostyslav Khudolii 
>> Cc: Attila Sukosd 
>
> For some reason the patch didn't apply to ath.git, I had manually recreate it.
> Please review carefully that the patch is correct now:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending=cd63adf640e39c2ba013cba91b29700f3f593b9c
>
> Also I added your description of the bug to the commit log.
>
> --
> https://patchwork.kernel.org/patch/9615199/
>
> Documentation about submitting wireless patches and checking status
> from patchwork:
>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
>

It's correct.

pull-request: mac80211 2017-03-16

[Johannes Berg]

Hi Dave,

Here's the pull request you were waiting for. I went through all my
pending patches but only this one is applicable for net.git at this
time, so it's just a single one.

Since I didn't have a current base, I forwarded to net.git first
and re-validated the patch there, but you might might have to be
careful if you merge to not fast-fwd on your side (though, even
if you do that, I don't think it matters much).

Please pull and let me know if there's any problem.

Thanks,
johannes



The following changes since commit 22a0e18eac7a9e986fec76c60fa4a2926d1291e2:

  net: properly release sk_frag.page (2017-03-15 15:37:45 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2017-03-16

for you to fetch changes up to ea90e0dc8cecba6359b481e24d9c37160f6f524f:

  nl80211: fix dumpit error path RTNL deadlocks (2017-03-16 10:30:03 +0100)


Just a single fix, for the RTNL locking issues.


Johannes Berg (1):
  nl80211: fix dumpit error path RTNL deadlocks

 net/wireless/nl80211.c | 127 ++---
 1 file changed, 56 insertions(+), 71 deletions(-)

Re: ath6kl: Remove old 802.11a-only channels

[Kalle Valo]

Rostyslav Khudolii  wrote:
> Channels 34/38/42/46 can only be used for compatibility with
> old devices sold in Japan. Modern products, such as AR6003/AR6004
> don't support these channels.
> Keeping them in the upstream is error prone and requires full
> network stack support.
> A custom patch should be used in case such compatibility is required.
> 
> Signed-off-by: Rostyslav Khudolii 
> Cc: Attila Sukosd 

For some reason the patch didn't apply to ath.git, I had manually recreate it.
Please review carefully that the patch is correct now:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=pending=cd63adf640e39c2ba013cba91b29700f3f593b9c

Also I added your description of the bug to the commit log.

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [RFC v4 06/21] ath10k: sdio support

[Kalle Valo]

Erik Stromdahl  writes:

>> There seems to be same pattern for reading four bytes, what if we should
>> add a helper for that? Something like ath10k_sdio_read32()? It could
>> handle the kmalloc and switch endianess also.
>>
>> But please don't make any chances to sdio.c for the moment, let me
>> submit v5 first.
>>
> I notice that you have submitted v5 (and v6) of the sdio patches. Great!
>
> I assume you will add them to master-pending soon so I will try out
> everything (usb too) as soon as they are on master-pending.

v6 is now in master-pending.

-- 
Kalle Valo

[PATCH] ath10k: fix warnings from an earlier commit

[Kalle Valo]

I failed to notice that commit 523f6701dbab ("ath10k: update available channel
list for 5G radio") added two new warnings:

drivers/net/wireless/ath/ath10k/mac.c:3129:6: warning: symbol 
'ath10k_mac_update_channel_list' was not declared. Should it be static?
drivers/net/wireless/ath/ath10k/mac.c:3170: Alignment should match open 
parenthesis

Fix those.

Signed-off-by: Kalle Valo 
---
 drivers/net/wireless/ath/ath10k/mac.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index a25f0ec15cf8..d60086cdc584 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3126,8 +3126,8 @@ static void ath10k_regd_update(struct ath10k *ar)
ath10k_warn(ar, "failed to set pdev regdomain: %d\n", ret);
 }
 
-void ath10k_mac_update_channel_list(struct ath10k *ar,
-   struct ieee80211_supported_band *band)
+static void ath10k_mac_update_channel_list(struct ath10k *ar,
+  struct ieee80211_supported_band 
*band)
 {
int i;
 
@@ -3167,7 +3167,7 @@ static void ath10k_reg_notifier(struct wiphy *wiphy,
 
if (ar->phy_capability & WHAL_WLAN_11A_CAPABILITY)
ath10k_mac_update_channel_list(ar,
-   ar->hw->wiphy->bands[NL80211_BAND_5GHZ]);
+  
ar->hw->wiphy->bands[NL80211_BAND_5GHZ]);
 }
 
 /***/

Re: ath10k: Fix fetching channel during potential radar detection

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> Fetch target operating channel during potential radar detection when
> the interface is just brought up, but no channel is assigned from
> userspace. In this scenario rx_channel may not be having a valid pointer
> hence fetch the target operating channel to avoid warnings as below
> which can be triggered by the commands with DFS testing over longer run
> 
> comamnds:
> iw wlan1 set type mesh
> ifconfig wlan1 up (valid tgt_oper_chan only)
> iw wlan1 cac trigger freq 5260 HT20 (valid rx_channel, tgt_oper_chan)
> iw wlan1 cac trigger freq 5280 HT20
> iw wlan1 cac trigger freq 5300 HT20
> 
> Once the CAC expires, current channel context will be removed and
> we are only left with the fallback option of using 'target operating
> channel'
> 
> Firmware and driver log:
> ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
> count_false=4
> ath: phy1: DFS: radar found on freq=5260: id=5, pri=3151, count=6,
> count_false=11
> ath: phy1: DFS: radar found on freq=5280: id=1, pri=1351, count=6,
> count_false=4
> ath: phy1: DFS: radar found on freq=5300: id=1, pri=1125, count=5,
> count_false=4
> ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
> treating as radar
> ath10k_pci 0001:01:00.0: failed to derive channel for radar pulse,
> treating as radar
> 
> Call trace:
> 
> WARNING: CPU: 1 PID: 2145 at
> backports-20161201-3.14.77-9ab3068/net/wireless/chan.c:265
> cfg80211_set_dfs_state+0x3c/0x88 [cfg80211]()
> 
>  Workqueue: phy1 ieee80211_dfs_radar_detected_work
> [mac80211]
> [] (warn_slowpath_null) from []
> (cfg80211_set_dfs_state+0x3c/0x88 [cfg80211])
> [] (cfg80211_set_dfs_state [cfg80211]) from
> [] (cfg80211_radar_event+0xc4/0x140 [cfg80211])
> [] (cfg80211_radar_event [cfg80211]) from
> [] (ieee80211_dfs_radar_detected_work+0xa8/0xb4 [mac80211])
> [] (ieee80211_dfs_radar_detected_work
> [mac80211]) from [] (process_one_work+0x298/0x4a4)
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

a28f6f27a88f ath10k: fix fetching channel during potential radar detection

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: ath9k: don't trigger spectral scan when not enabled

[Kalle Valo]

Zefir Kurtisi  wrote:
> Doing so enables the FFT generation without prior
> configuration, leading to an IRQ storm caused by
> invalid (or at least unwanted) PHY errors.
> 
> Signed-off-by: Zefir Kurtisi 

Patch applied to ath-next branch of ath.git, thanks.

45c3d550b068 ath9k: don't trigger spectral scan when not enabled

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: ath10k: remove redundant error check

[Kalle Valo]

Colin Ian King  wrote:
> From: Colin Ian King 
> 
> The check on ret for an error is redundant because it is already been
> checked for non-zero earlier on and ret is never non-zero at this point.
> Fix this by removing the redundant check and error message.
> 
> Detected by CoverityScan, CID#1357170 ("Logically Dead Code")
> 
> Signed-off-by: Colin Ian King 

Patch applied to ath-next branch of ath.git, thanks.

51f60b8b6979 ath10k: remove redundant error check

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [PATCHv2] ath10k: Update available channel list for 5G radio

[Kalle Valo]

c_tr...@qti.qualcomm.com wrote:
> From: Tamizh chelvam 
> 
> If a 5 GHz radio is calibrated for operation in both
> the low band (channels 36 to 64) and high band(channels 100 to 169),
> hardware allows operations in all the listed channels. However,
> if the chip has been calibrated only for the low/high band and
> a high/low band channel is configured, due to lack of calibration
> there will be potentially invalid signal on those non calibrated channels.
> To avoid this problem this patch sets IEEE80211_CHAN_DISABLED flag for
> those non calibrated channels by using low_5ghz_chan and high_5ghz_chan
> values which we get from target through wmi service ready event.
> 
> Driver initialized flags are getting re initialized in handle_channel
> in cfg80211. So calling the function to disable the non supported channel
> from reg_notifier().
> 
> Signed-off-by: Tamizh chelvam 

Patch applied to ath-next branch of ath.git, thanks.

523f6701dbab ath10k: update available channel list for 5G radio

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: ath10k: Disallow DFS simulation if DFS channel is not enabled

[Kalle Valo]

Mohammed Shafi Shajakhan  wrote:
> From: Mohammed Shafi Shajakhan 
> 
> If DFS is not enabled in hostapd (ieee80211h=0) DFS channels shall
> not be available for use even though the hardware may have the capability
> to support DFS. With this configuration (DFS disabled in hostapd) trying to
> bring up ath10k device in DFS channel for AP mode fails and trying to
> simulate DFS in ath10k debugfs results in a warning in cfg80211 complaining
> invalid channel and this should be avoided in the driver itself rather than
> false propogating RADAR detection to mac80211/cfg80211. Fix this by
> checking for the first vif 'is_started' state(should work for client mode
> as well) as all the vifs shall be configured for the same channel
> 
> sys/kernel/debug/ieee80211/phy1/ath10k# echo 1 > dfs_simulate_radar
> 
> WARNING: at net/wireless/chan.c:265 cfg80211_radar_event+0x24/0x60
> Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
> [] (warn_slowpath_null) from
> [] (cfg80211_radar_event+0x24/0x60 [cfg80211])
> [] (cfg80211_radar_event [cfg80211]) from
> [] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
> [] (ieee80211_dfs_radar_detected_work [mac80211]) from
> [] (process_one_work+0x20c/0x32c)
> 
> WARNING: at net/wireless/nl80211.c:2488 nl80211_get_mpath+0x13c/0x4cc
>  Workqueue: phy0 ieee80211_dfs_radar_detected_work [mac80211]
> [] (warn_slowpath_null) from
> [] (cfg80211_radar_event+0x24/0x60 [cfg80211])
> [] (cfg80211_radar_event [cfg80211]) from
> [] (ieee80211_dfs_radar_detected_work+0x94/0xa0 [mac80211])
> [] (ieee80211_dfs_radar_detected_work [mac80211]) from
> [] (process_one_work+0x20c/0x32c)
> 
> Signed-off-by: Mohammed Shafi Shajakhan 

Patch applied to ath-next branch of ath.git, thanks.

ca07baab0b1e ath10k: disallow DFS simulation if DFS channel is not enabled

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: MAINTAINERS: update for mwifiex driver maintainers

[Kalle Valo]

Amitkumar Karwar  wrote:
> Ganapathi & Xinming are starting to take a more active role in the
> mwifiex driver maintainership here onwards on account of organizational
> changes.
> 
> CC: Xinming Hu 
> CC: Ganapathi Bhat 
> Signed-off-by: Amitkumar Karwar 
> Signed-off-by: Nishant Sarmukadam 
> Signed-off-by: Cathy Luo 

Patch applied to wireless-drivers.git, thanks.

cf8c44d42c4f MAINTAINERS: update for mwifiex driver maintainers

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [1/4] mwifiex: pcie: don't leak DMA buffers when removing

[Kalle Valo]

Brian Norris  wrote:
> When PCIe FLR support was added, much of the remove/release code for
> PCIe was migrated to ->down_dev(), but ->down_dev() is never called for
> device removal. Let's refactor the cleanup to be done in both cases.
> 
> Also, drop the comments above mwifiex_cleanup_pcie(), because they were
> clearly wrong, and it's better to have clear and obvious code than to
> detail the code steps in comments anyway.
> 
> Fixes: 4c5dae59d2e9 ("mwifiex: add PCIe function level reset support")
> Cc: 
> Signed-off-by: Brian Norris 

3 patches applied to wireless-drivers.git, thanks.

4e841d3eb929 mwifiex: pcie: don't leak DMA buffers when removing
ba1c7e45ec22 mwifiex: set adapter->dev before starting to use mwifiex_dbg()
36908c4e5b10 mwifiex: uninit wakeup info when removing device

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: mac80211: 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 

I'll remove the "mac80211:" prefix during commit, that should be only used with
mac80211 patches.

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [RESEND,4.11] iwlwifi: mvm: cleanup pending frames in DQA mode

[Kalle Valo]

Luciano Coelho  wrote:
> From: Sara Sharon 
> 
> When a station is asleep, the fw will set it as "asleep".
> All queues that are used only by one station will be stopped by
> the fw.
> 
> In pre-DQA mode this was relevant for aggregation queues. However,
> in DQA mode a queue is owned by one station only, so all queues
> will be stopped.
> As a result, we don't expect to get filtered frames back to
> mac80211 and don't have to maintain the entire pending_frames
> state logic, the same way as we do in aggregations.
> 
> The correct behavior is to align DQA behavior with the aggregation
> queue behaviour pre-DQA:
> - Don't count pending frames.
> - Let mac80211 know we have frames in these queues so that it can
> properly handle trigger frames.
> 
> When a trigger frame is received, mac80211 tells the driver to send
> frames from the queues using release_buffered_frames.
> The driver will tell the fw to let frames out even if the station
> is asleep. This is done by iwl_mvm_sta_modify_sleep_tx_count.
> 
> Reported-and-tested-by: Jens Axboe 
> Reported-by: Linus Torvalds 
> Signed-off-by: Sara Sharon 
> Signed-off-by: Luca Coelho 

Patch applied to wireless-drivers.git, thanks.

9a3fcf912ef7 iwlwifi: mvm: cleanup pending frames in DQA mode

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

Documentation about submitting wireless patches and checking status
from patchwork:

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

Re: [PATCH v4] qtnfmac: announcement of new FullMAC driver for Quantenna chipsets

[Kalle Valo]

Johannes Berg  writes:

>> 1. Modify cfg80211 driver patch to introduce ability to boot from
>> card's internal flash rather then over PCIe only. This will hopefully
>> unblock  driver itself.
>
> This is good, and I think that'll be OK for the driver.

I'm thinking the same.

>> 2. Work internally to provide access to SDK used to build firmware on
>> a public server, that has to be accessible for two years. Then submit
>> firmware to linux-firmware again.
>
> I'm not sure this will work, since it would fall on anyone
> redistributing to ensure it's still there after *they* distribute it,
> so anyone who has the linux-firmware repo... That's why it's most
> practical to simply combine the two, although that's not really the
> case here.

How can we find a solution to this? We already one another driver with a
similar problem with sources and I guess more to come. Should we bring
this up in TAB?

https://www.linuxfoundation.org/projects/linux/tab

-- 
Kalle Valo

Re: [PATCH] nl80211: fix dumpit error path RTNL deadlocks

[Johannes Berg]

On Wed, 2017-03-15 at 14:59 -0700, David Miller wrote:
> From: Johannes Berg 
> Date: Wed, 15 Mar 2017 14:29:13 +0100
> 
> > From: Johannes Berg 
> > 
> > Sowmini pointed out Dmitry's RTNL deadlock report to me, and it
> turns out
> > to be perfectly accurate - there are various error paths that miss
> unlock
> > of the RTNL.

> Johannes, I assume I will get this in a future pull request?

Sure, coming to a tree near you ... today I guess. Just didn't want to
send it out entirely unreviewed, although I checked it with sparse.

johannes