[PATCH] cfg80211: allow vendor commands to be sent to nan interface

[Luca Coelho]

From: Andrei Otcheretianski 

Allow vendor commands that require WIPHY_VENDOR_CMD_NEED_RUNNING flag, to
be sent to NAN interface.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
---
 net/wireless/nl80211.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index e48b9c3..fcf5b4f 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -11258,7 +11258,8 @@ static int nl80211_vendor_cmd(struct sk_buff *skb, 
struct genl_info *info)
if (wdev->netdev &&
!netif_running(wdev->netdev))
return -ENETDOWN;
-   if (!wdev->netdev && !wdev->p2p_started)
+   if (!wdev->netdev && !wdev->p2p_started &&
+   !wdev->nan_started)
return -ENETDOWN;
}
 
-- 
2.9.3

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

[Herbert Xu]

On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote:
>
> Annoyingly, all this complication with scatterlists etc is for doing
> asynchronous crypto via DMA capable crypto accelerators, and the
> networking code (ipsec as well as mac80211, afaik) only allow
> synchronous in the first place, given that they execute in softirq
> context.

I'm still thinking about the issue (in particular, whether we
should continue to rely on the request context being SG-capable
or allow it to be on the stack for AEAD).

But IPsec definitely supports async crypto.  In fact it was the
very first user of async crypto.

mac80211 on the other hand is currently sync-only.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH net-next 2/6] net: use core MTU range checking in wireless drivers

[Jarod Wilson]

- set max_mtu in wil6210 driver
- set max_mtu in atmel driver
- set min/max_mtu in cisco airo driver, remove airo_change_mtu
- set min/max_mtu in ipw2100/ipw2200 drivers, remove libipw_change_mtu
- set min/max_mtu in p80211netdev, remove wlan_change_mtu

CC: net...@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: Maya Erez 
CC: Simon Kelley 
CC: Stanislav Yakovlev 
Signed-off-by: Jarod Wilson 
---
 drivers/net/wireless/ath/wil6210/netdev.c  | 17 +
 drivers/net/wireless/atmel/atmel.c | 13 -
 drivers/net/wireless/cisco/airo.c  | 14 +++---
 drivers/net/wireless/intel/ipw2x00/ipw2100.c   |  3 ++-
 drivers/net/wireless/intel/ipw2x00/ipw2200.c   |  8 ++--
 drivers/net/wireless/intel/ipw2x00/libipw.h|  1 -
 drivers/net/wireless/intel/ipw2x00/libipw_module.c |  9 -
 drivers/staging/wlan-ng/p80211netdev.c | 18 +-
 8 files changed, 21 insertions(+), 62 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/netdev.c 
b/drivers/net/wireless/ath/wil6210/netdev.c
index 61de5e9..d18372c 100644
--- a/drivers/net/wireless/ath/wil6210/netdev.c
+++ b/drivers/net/wireless/ath/wil6210/netdev.c
@@ -41,21 +41,6 @@ static int wil_stop(struct net_device *ndev)
return wil_down(wil);
 }
 
-static int wil_change_mtu(struct net_device *ndev, int new_mtu)
-{
-   struct wil6210_priv *wil = ndev_to_wil(ndev);
-
-   if (new_mtu < 68 || new_mtu > mtu_max) {
-   wil_err(wil, "invalid MTU %d\n", new_mtu);
-   return -EINVAL;
-   }
-
-   wil_dbg_misc(wil, "change MTU %d -> %d\n", ndev->mtu, new_mtu);
-   ndev->mtu = new_mtu;
-
-   return 0;
-}
-
 static int wil_do_ioctl(struct net_device *ndev, struct ifreq *ifr, int cmd)
 {
struct wil6210_priv *wil = ndev_to_wil(ndev);
@@ -69,7 +54,6 @@ static const struct net_device_ops wil_netdev_ops = {
.ndo_start_xmit = wil_start_xmit,
.ndo_set_mac_address= eth_mac_addr,
.ndo_validate_addr  = eth_validate_addr,
-   .ndo_change_mtu = wil_change_mtu,
.ndo_do_ioctl   = wil_do_ioctl,
 };
 
@@ -126,6 +110,7 @@ static int wil6210_netdev_poll_tx(struct napi_struct *napi, 
int budget)
 static void wil_dev_setup(struct net_device *dev)
 {
ether_setup(dev);
+   dev->max_mtu = mtu_max;
dev->tx_queue_len = WIL_TX_Q_LEN_DEFAULT;
 }
 
diff --git a/drivers/net/wireless/atmel/atmel.c 
b/drivers/net/wireless/atmel/atmel.c
index bf2e9a0..eb92d5a 100644
--- a/drivers/net/wireless/atmel/atmel.c
+++ b/drivers/net/wireless/atmel/atmel.c
@@ -1295,14 +1295,6 @@ static struct iw_statistics 
*atmel_get_wireless_stats(struct net_device *dev)
return >wstats;
 }
 
-static int atmel_change_mtu(struct net_device *dev, int new_mtu)
-{
-   if ((new_mtu < 68) || (new_mtu > 2312))
-   return -EINVAL;
-   dev->mtu = new_mtu;
-   return 0;
-}
-
 static int atmel_set_mac_address(struct net_device *dev, void *p)
 {
struct sockaddr *addr = p;
@@ -1506,7 +1498,6 @@ static const struct file_operations atmel_proc_fops = {
 static const struct net_device_ops atmel_netdev_ops = {
.ndo_open   = atmel_open,
.ndo_stop   = atmel_close,
-   .ndo_change_mtu = atmel_change_mtu,
.ndo_set_mac_address= atmel_set_mac_address,
.ndo_start_xmit = start_tx,
.ndo_do_ioctl   = atmel_ioctl,
@@ -1600,6 +1591,10 @@ struct net_device *init_atmel_card(unsigned short irq, 
unsigned long port,
dev->irq = irq;
dev->base_addr = port;
 
+   /* MTU range: 68 - 2312 */
+   dev->min_mtu = 68;
+   dev->max_mtu = MAX_WIRELESS_BODY - ETH_FCS_LEN;
+
SET_NETDEV_DEV(dev, sys_dev);
 
if ((rc = request_irq(dev->irq, service_interrupt, IRQF_SHARED, 
dev->name, dev))) {
diff --git a/drivers/net/wireless/cisco/airo.c 
b/drivers/net/wireless/cisco/airo.c
index 69b826d..4b04045 100644
--- a/drivers/net/wireless/cisco/airo.c
+++ b/drivers/net/wireless/cisco/airo.c
@@ -2329,14 +2329,6 @@ static int airo_set_mac_address(struct net_device *dev, 
void *p)
return 0;
 }
 
-static int airo_change_mtu(struct net_device *dev, int new_mtu)
-{
-   if ((new_mtu < 68) || (new_mtu > 2400))
-   return -EINVAL;
-   dev->mtu = new_mtu;
-   return 0;
-}
-
 static LIST_HEAD(airo_devices);
 
 static void add_airo_dev(struct airo_info *ai)
@@ -2656,7 +2648,6 @@ static const struct net_device_ops airo11_netdev_ops = {
.ndo_get_stats  = airo_get_stats,
.ndo_set_mac_address= airo_set_mac_address,
.ndo_do_ioctl   = airo_ioctl,
-   .ndo_change_mtu = airo_change_mtu,
 };
 
 static void wifi_setup(struct net_device *dev)
@@ -2668,6 +2659,8 @@ static void wifi_setup(struct 

Re: sequence diagrams in rst documentation

[Jonathan Corbet]

On Tue, 18 Oct 2016 13:43:41 +0200
Johannes Berg  wrote:

> > Example here:
> > https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow 
> >  
> 
> Coming back to this - sadly, it appears that this software (blockdiag,
> seqdiag) is completely unmaintained, with open pull requests dating
> back to 2012 and the last commit dating back to 2015-08-22.
> 
> I'd want/need feature improvements in it too, but if I can't feed those
> back to upstream (since it appears dead), there's little point.
> 
> Perhaps we can ship plugins for this as part of the kernel sources?
> Shouldn't be too difficult to reimplement something like this, after
> all.

OK, I've read through all of this.  My thoughts, for whatever it's worth.

We already carry a few sphinx plugins in the kernel; there is room for
more if we *really* need them.  But...

 - Part of the idea behind switching over to sphinx was to be able to get
   away from maintaining our own formatting system.  Adding plugins to the
   kernel is a step away from that goal.  So I'd like to be sure that
   there's nothing that's part of standard sphinx that will do the job
   first.

That said, I think that requiring people to install plugins from contrib
sites or third-party repos may be even worse.  We don't want to put people
through misery just to format the docs.

In summary, I think we can consider taking on a module if it's what we
need to do the docs right.  And if somebody agrees to maintain it! :)

I've heard others say they would like better diagramming support.  Do you
think that, maybe, something like aafigure would do the trick?

https://pythonhosted.org/sphinxcontrib-aafig/

I've not actually played with it at all, but I like the idea that we'd
have readable diagrams in the source docs as well...

jon

[PATCH 6/7] mac80211: uapsd_queues is in QoS IE order

[Luca Coelho]

From: Emmanuel Grumbach 

The uapsd_queue field is in QoS IE order and not in
IEEE80211_AC_*'s order.
This means that mac80211 would get confused between
BK and BE which is certainly not such a big deal but
needs to be fixed.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 include/net/cfg80211.h |  3 ++-
 include/net/mac80211.h |  3 ++-
 net/mac80211/ieee80211_i.h |  2 ++
 net/mac80211/mlme.c|  2 +-
 net/mac80211/rx.c  |  3 ++-
 net/mac80211/sta_info.c| 13 -
 net/mac80211/util.c|  7 +++
 7 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 5000ec7..10a26f0 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -4574,7 +4574,8 @@ void cfg80211_auth_timeout(struct net_device *dev, const 
u8 *addr);
  * moves to cfg80211 in this call
  * @buf: authentication frame (header + body)
  * @len: length of the frame data
- * @uapsd_queues: bitmap of ACs configured to uapsd. -1 if n/a.
+ * @uapsd_queues: bitmap of queues configured for uapsd. Same format
+ * as the AC bitmap in the QoS info field
  *
  * After being asked to associate via cfg80211_ops::assoc() the driver must
  * call either this function or cfg80211_auth_timeout().
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index a1a2702..b9b24ab 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1745,7 +1745,8 @@ struct ieee80211_sta_rates {
  * @drv_priv: data area for driver use, will always be aligned to
  * sizeof(void *), size is determined in hw information.
  * @uapsd_queues: bitmap of queues configured for uapsd. Only valid
- * if wme is supported.
+ * if wme is supported. The bits order is like in
+ * IEEE80211_WMM_IE_STA_QOSINFO_AC_*.
  * @max_sp: max Service Period. Only valid if wme is supported.
  * @bandwidth: current bandwidth the station can receive with
  * @rx_nss: in HT/VHT, the maximum number of spatial streams the
diff --git a/net/mac80211/ieee80211_i.h b/net/mac80211/ieee80211_i.h
index 42d194a..b4e2b6c 100644
--- a/net/mac80211/ieee80211_i.h
+++ b/net/mac80211/ieee80211_i.h
@@ -84,6 +84,8 @@ struct ieee80211_local;
 #define IEEE80211_DEFAULT_MAX_SP_LEN   \
IEEE80211_WMM_IE_STA_QOSINFO_SP_ALL
 
+extern const u8 ieee80211_ac_to_qos_mask[IEEE80211_NUM_ACS];
+
 #define IEEE80211_DEAUTH_FRAME_LEN (24 /* hdr */ + 2 /* reason */)
 
 #define IEEE80211_MAX_NAN_INSTANCE_ID 255
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 7486f2d..c8d3a9b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -3193,7 +3193,7 @@ static void ieee80211_rx_mgmt_assoc_resp(struct 
ieee80211_sub_if_data *sdata,
uapsd_queues = 0;
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++)
if (sdata->tx_conf[ac].uapsd)
-   uapsd_queues |= BIT(ac);
+   uapsd_queues |= ieee80211_ac_to_qos_mask[ac];
}
 
cfg80211_rx_assoc_resp(sdata->dev, bss, (u8 *)mgmt, len, uapsd_queues);
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 837d562..21a8947 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1401,7 +1401,8 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta 
*pubsta, u8 tid)
 * enabled queues, but for now we only implement uAPSD w/o
 * TSPEC changes to the ACs, so they're always the same.
 */
-   if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS)
+   if (!(sta->sta.uapsd_queues & ieee80211_ac_to_qos_mask[ac]) &&
+   tid != IEEE80211_NUM_TIDS)
return;
 
/* if we are in a service period, do nothing */
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index ab91e1e..236d47e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -709,7 +709,7 @@ static void __sta_info_recalc_tim(struct sta_info *sta, 
bool ignore_pending)
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
unsigned long tids;
 
-   if (ignore_for_tim & BIT(ac))
+   if (ignore_for_tim & ieee80211_ac_to_qos_mask[ac])
continue;
 
indicate_tim |= !skb_queue_empty(>tx_filtered[ac]) ||
@@ -1389,7 +1389,7 @@ ieee80211_sta_ps_more_data(struct sta_info *sta, u8 
ignored_acs,
return true;
 
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
-   if (ignored_acs & BIT(ac))
+   if (ignored_acs & ieee80211_ac_to_qos_mask[ac])
continue;
 
if (!skb_queue_empty(>tx_filtered[ac]) ||
@@ -1414,7 +1414,7 @@ ieee80211_sta_ps_get_frames(struct sta_info *sta, int 
n_frames, u8 ignored_acs,
for (ac = 0; ac < IEEE80211_NUM_ACS; ac++) {
unsigned long tids;
 
-   if (ignored_acs & 

[PATCH 5/7] mac80211: add a HW flag for supporting HW TX fragmentation

[Luca Coelho]

From: Sara Sharon 

Currently mac80211 determines whether HW does fragmentation
by checking whether the set_frag_threshold callback is set
or not.
However, some drivers may want to set the HW fragmentation
capability depending on HW generation.
Allow this by checking a HW flag instead of checking the
callback.

Signed-off-by: Sara Sharon 
[added the flag to ath10k and wlcore]
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/ath/ath10k/mac.c |  1 +
 drivers/net/wireless/ti/wlcore/main.c |  1 +
 include/net/mac80211.h| 10 --
 net/mac80211/debugfs.c|  1 +
 net/mac80211/main.c   |  4 
 net/mac80211/tx.c |  4 ++--
 net/mac80211/wpa.c|  2 +-
 7 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 76297d6..e322b6d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7881,6 +7881,7 @@ int ath10k_mac_register(struct ath10k *ar)
ieee80211_hw_set(ar->hw, WANT_MONITOR_VIF);
ieee80211_hw_set(ar->hw, CHANCTX_STA_CSA);
ieee80211_hw_set(ar->hw, QUEUE_CONTROL);
+   ieee80211_hw_set(ar->hw, SUPPORTS_TX_FRAG);
 
if (!test_bit(ATH10K_FLAG_RAW_MODE, >dev_flags))
ieee80211_hw_set(ar->hw, SW_CRYPTO_CONTROL);
diff --git a/drivers/net/wireless/ti/wlcore/main.c 
b/drivers/net/wireless/ti/wlcore/main.c
index 471521a..9f39c6c 100644
--- a/drivers/net/wireless/ti/wlcore/main.c
+++ b/drivers/net/wireless/ti/wlcore/main.c
@@ -6086,6 +6086,7 @@ static int wl1271_init_ieee80211(struct wl1271 *wl)
ieee80211_hw_set(wl->hw, SUPPORTS_DYNAMIC_PS);
ieee80211_hw_set(wl->hw, SIGNAL_DBM);
ieee80211_hw_set(wl->hw, SUPPORTS_PS);
+   ieee80211_hw_set(wl->hw, SUPPORTS_TX_FRAG);
 
wl->hw->wiphy->cipher_suites = cipher_suites;
wl->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index f3dbada..a1a2702 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2025,6 +2025,10 @@ struct ieee80211_txq {
  * drivers, mac80211 packet loss mechanism will not be triggered and driver
  * is completely depending on firmware event for station kickout.
  *
+ * @IEEE80211_HW_SUPPORTS_TX_FRAG: Hardware does fragmentation by itself.
+ * The stack will not do fragmentation.
+ * The callback for @set_frag_threshold should be set as well.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2066,6 +2070,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_TX_AMSDU,
IEEE80211_HW_TX_FRAG_LIST,
IEEE80211_HW_REPORTS_LOW_ACK,
+   IEEE80211_HW_SUPPORTS_TX_FRAG,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -3093,8 +3098,9 @@ enum ieee80211_reconfig_type {
  * The callback must be atomic.
  *
  * @set_frag_threshold: Configuration of fragmentation threshold. Assign this
- * if the device does fragmentation by itself; if this callback is
- * implemented then the stack will not do fragmentation.
+ * if the device does fragmentation by itself. Note that to prevent the
+ * stack from doing fragmentation IEEE80211_HW_SUPPORTS_TX_FRAG
+ * should be set as well.
  * The callback can sleep.
  *
  * @set_rts_threshold: Configuration of RTS threshold (if device needs it)
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index f56e2f4..e02ba42 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -210,6 +210,7 @@ static const char *hw_flag_names[] = {
FLAG(TX_AMSDU),
FLAG(TX_FRAG_LIST),
FLAG(REPORTS_LOW_ACK),
+   FLAG(SUPPORTS_TX_FRAG),
 #undef FLAG
 };
 
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 1075ac2..0d9163c 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -821,6 +821,10 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 !local->ops->tdls_recv_channel_switch))
return -EOPNOTSUPP;
 
+   if (WARN_ON(ieee80211_hw_check(hw, SUPPORTS_TX_FRAG) &&
+   !local->ops->set_frag_threshold))
+   return -EINVAL;
+
if (WARN_ON(local->hw.wiphy->interface_modes &
BIT(NL80211_IFTYPE_NAN) &&
(!local->ops->start_nan || !local->ops->stop_nan)))
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 772e369..62ccaf6 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -934,7 +934,7 @@ ieee80211_tx_h_fragment(struct ieee80211_tx_data *tx)
if (info->flags & IEEE80211_TX_CTL_DONTFRAG)
return TX_CONTINUE;
 
-   if (tx->local->ops->set_frag_threshold)
+   if (ieee80211_hw_check(>local->hw, SUPPORTS_TX_FRAG))
return 

[PATCH 1/7] wireless: radiotap: fix timestamp sampling position values

[Luca Coelho]

From: Johannes Berg 

The values don't match the radiotap spec, corrected that.

Reported-by: Oz Shalev 
Signed-off-by: Johannes Berg 
---
 include/net/ieee80211_radiotap.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index ba07b9d..d0e7e3f 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -333,9 +333,9 @@ enum ieee80211_radiotap_type {
 #define IEEE80211_RADIOTAP_TIMESTAMP_UNIT_NS   0x0003
 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_MASK 0x00F0
 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_BEGIN_MDPU   0x
-#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU  0x0010
+#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0010
 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_PPDU  0x0020
-#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_PLCP_SIG_ACQ 0x0030
+#define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_EO_MPDU  0x0030
 #define IEEE80211_RADIOTAP_TIMESTAMP_SPOS_UNKNOWN  0x00F0
 
 #define IEEE80211_RADIOTAP_TIMESTAMP_FLAG_64BIT0x00
-- 
2.9.3

[PATCH 0/7] patches for mac80211/cfg80211 2016-10-18

[Luca Coelho]

From: Luca Coelho 

Hi Johannes,

Here are a few patches for mac80211/cfg80211 from our internal tree.
You're probably familiar with most of them, I'm just adding a cover
letter to make it easier for you to reply "Applied all" (hopefully).:)

Cheers,
Luca.


Emmanuel Grumbach (2):
  mac80211: allow the driver not to pass the tid to
ieee80211_sta_uapsd_trigger
  mac80211: uapsd_queues is in QoS IE order

Ilan Peer (1):
  cfg80211: Call rdev_disconnect() when connection is in progress

Johannes Berg (3):
  wireless: radiotap: fix timestamp sampling position values
  mac80211: fix tid_agg_rx NULL dereference
  mac80211: improve RX aggregation data in debugfs

Sara Sharon (1):
  mac80211: add a HW flag for supporting HW TX fragmentation

 drivers/net/wireless/ath/ath10k/mac.c |  1 +
 drivers/net/wireless/ti/wlcore/main.c |  1 +
 include/net/cfg80211.h| 10 ++
 include/net/ieee80211_radiotap.h  |  4 ++--
 include/net/mac80211.h| 17 ++---
 net/mac80211/agg-rx.c |  8 ++--
 net/mac80211/debugfs.c|  1 +
 net/mac80211/debugfs_sta.c|  9 +++--
 net/mac80211/ieee80211_i.h|  2 ++
 net/mac80211/main.c   |  4 
 net/mac80211/mlme.c   |  2 +-
 net/mac80211/rx.c |  6 --
 net/mac80211/sta_info.c   | 13 -
 net/mac80211/sta_info.h   |  4 ++--
 net/mac80211/tx.c |  4 ++--
 net/mac80211/util.c   |  7 +++
 net/mac80211/wpa.c|  2 +-
 net/wireless/sme.c|  2 +-
 18 files changed, 66 insertions(+), 31 deletions(-)

-- 
2.9.3

[PATCH 4/7] mac80211: allow the driver not to pass the tid to ieee80211_sta_uapsd_trigger

[Luca Coelho]

From: Emmanuel Grumbach 

iwlwifi will check internally that the tid maps to an AC
that is trigger enabled, but can't know what tid exactly.
Allow the driver to pass a generic tid and make mac80211
assume that a trigger frame was received.

Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Luca Coelho 
---
 include/net/mac80211.h | 4 
 net/mac80211/rx.c  | 5 +++--
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index e50c9e0..f3dbada 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -4087,6 +4087,10 @@ void ieee80211_sta_pspoll(struct ieee80211_sta *sta);
  * This must be used in conjunction with ieee80211_sta_ps_transition()
  * and possibly ieee80211_sta_pspoll(); calls to all three must be
  * serialized.
+ * %IEEE80211_NUM_TIDS can be passed as the tid if the tid is unknown.
+ * In this case, mac80211 will not check that this tid maps to an AC
+ * that is trigger enabled and assume that the caller did the proper
+ * checks.
  */
 void ieee80211_sta_uapsd_trigger(struct ieee80211_sta *sta, u8 tid);
 
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index fc08a50..837d562 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1394,13 +1394,14 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta 
*pubsta, u8 tid)
u8 ac = ieee802_1d_to_ac[tid & 7];
 
/*
-* If this AC is not trigger-enabled do nothing.
+* If this AC is not trigger-enabled do nothing unless the
+* driver is calling us after it already checked.
 *
 * NB: This could/should check a separate bitmap of trigger-
 * enabled queues, but for now we only implement uAPSD w/o
 * TSPEC changes to the ACs, so they're always the same.
 */
-   if (!(sta->sta.uapsd_queues & BIT(ac)))
+   if (!(sta->sta.uapsd_queues & BIT(ac)) && tid != IEEE80211_NUM_TIDS)
return;
 
/* if we are in a service period, do nothing */
-- 
2.9.3

[PATCH 2/7] mac80211: fix tid_agg_rx NULL dereference

[Luca Coelho]

From: Johannes Berg 

On drivers setting the SUPPORTS_REORDERING_BUFFER hardware flag,
we crash when the peer sends an AddBA request while we already
have a session open on the seame TID; this is because on those
drivers, the tid_agg_rx is left NULL even though the session is
valid, and the agg_session_valid bit is set.

To fix this, store the dialog tokens outside the tid_agg_rx to
be able to compare them to the received AddBA request.

Fixes: f89e07d4cf26 ("mac80211: agg-rx: refuse ADDBA Request with timeout 
update")
Reported-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
---
 net/mac80211/agg-rx.c  | 8 ++--
 net/mac80211/debugfs_sta.c | 2 +-
 net/mac80211/sta_info.h| 4 ++--
 3 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/net/mac80211/agg-rx.c b/net/mac80211/agg-rx.c
index f6749dc..3b5fd41 100644
--- a/net/mac80211/agg-rx.c
+++ b/net/mac80211/agg-rx.c
@@ -315,11 +315,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
mutex_lock(>ampdu_mlme.mtx);
 
if (test_bit(tid, sta->ampdu_mlme.agg_session_valid)) {
-   tid_agg_rx = rcu_dereference_protected(
-   sta->ampdu_mlme.tid_rx[tid],
-   lockdep_is_held(>ampdu_mlme.mtx));
-
-   if (tid_agg_rx->dialog_token == dialog_token) {
+   if (sta->ampdu_mlme.tid_rx_token[tid] == dialog_token) {
ht_dbg_ratelimited(sta->sdata,
   "updated AddBA Req from %pM on tid 
%u\n",
   sta->sta.addr, tid);
@@ -396,7 +392,6 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
}
 
/* update data */
-   tid_agg_rx->dialog_token = dialog_token;
tid_agg_rx->ssn = start_seq_num;
tid_agg_rx->head_seq_num = start_seq_num;
tid_agg_rx->buf_size = buf_size;
@@ -418,6 +413,7 @@ void __ieee80211_start_rx_ba_session(struct sta_info *sta,
if (status == WLAN_STATUS_SUCCESS) {
__set_bit(tid, sta->ampdu_mlme.agg_session_valid);
__clear_bit(tid, sta->ampdu_mlme.unexpected_agg);
+   sta->ampdu_mlme.tid_rx_token[tid] = dialog_token;
}
mutex_unlock(>ampdu_mlme.mtx);
 
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index a2fcdb4..14ec63a 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -205,7 +205,7 @@ static ssize_t sta_agg_status_read(struct file *file, char 
__user *userbuf,
p += scnprintf(p, sizeof(buf) + buf - p, "%02d", i);
p += scnprintf(p, sizeof(buf) + buf - p, "\t\t%x", !!tid_rx);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.2x",
-   tid_rx ? tid_rx->dialog_token : 0);
+   tid_rx ? sta->ampdu_mlme.tid_rx_token[i] : 0);
p += scnprintf(p, sizeof(buf) + buf - p, "\t%#.3x",
tid_rx ? tid_rx->ssn : 0);
 
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index ed5fcb9..dd06ef0 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -184,7 +184,6 @@ struct tid_ampdu_tx {
  * @ssn: Starting Sequence Number expected to be aggregated.
  * @buf_size: buffer size for incoming A-MPDUs
  * @timeout: reset timer value (in TUs).
- * @dialog_token: dialog token for aggregation session
  * @rcu_head: RCU head used for freeing this struct
  * @reorder_lock: serializes access to reorder buffer, see below.
  * @auto_seq: used for offloaded BA sessions to automatically pick head_seq_and
@@ -213,7 +212,6 @@ struct tid_ampdu_rx {
u16 ssn;
u16 buf_size;
u16 timeout;
-   u8 dialog_token;
bool auto_seq;
bool removed;
 };
@@ -225,6 +223,7 @@ struct tid_ampdu_rx {
  * to tid_tx[idx], which are protected by the sta spinlock)
  * tid_start_tx is also protected by sta->lock.
  * @tid_rx: aggregation info for Rx per TID -- RCU protected
+ * @tid_rx_token: dialog tokens for valid aggregation sessions
  * @tid_rx_timer_expired: bitmap indicating on which TIDs the
  * RX timer expired until the work for it runs
  * @tid_rx_stop_requested:  bitmap indicating which BA sessions per TID the
@@ -243,6 +242,7 @@ struct sta_ampdu_mlme {
struct mutex mtx;
/* rx */
struct tid_ampdu_rx __rcu *tid_rx[IEEE80211_NUM_TIDS];
+   u8 tid_rx_token[IEEE80211_NUM_TIDS];
unsigned long tid_rx_timer_expired[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
unsigned long tid_rx_stop_requested[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
unsigned long agg_session_valid[BITS_TO_LONGS(IEEE80211_NUM_TIDS)];
-- 
2.9.3

Re: Intel 7260 not working on 4.4.24 / armv7

[Johannes Berg]

On Tue, 2016-10-18 at 21:44 +0200, Oliver Zemann wrote:
> Is there some way to disable the bluetooth functionality?
> 

Not that I know of. It's kinda pointless though since you then wouldn't
have any functionality anyway?

I don't have the board you mentioned to Emmanuel, but I can try the
7260 on the Hummingboard.

I do know that, for example, on my old G5 powermac the newer Intel NICs
cause the system to be unable boot, so there sometimes are PCIe bus
incompatibilities.

johannes

(please quote properly)

Re: Intel 7260 not working on 4.4.24 / armv7

[Oliver Zemann]

I tried 2 of those wifi cards. Both behaved the same. Also on another 
clearfog pro. So i guess this is not a hardware fault. Also, the compex 
WLE600 works (unfortunately the WLE900 does not).



Am 18.10.2016 um 21:30 schrieb Emmanuel Grumbach:

On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann  wrote:

Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
wifi card. Unfortunately it is also not working.
I get tons of those messages:

[  175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
[  175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[  175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[  175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[  175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[  176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
activated
[  176.749831] usb 1-1: USB disconnect, device number 2
[  177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
[  177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[  177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0
[  177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
[  177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
[  177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
activated
[  178.046910] usb 1-1: USB disconnect, device number 3
[  178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
[  178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
[  178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
SerialNumber=0

Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
But that's the BT part.


some information about the card:
Bus 001 Device 011: ID 8087:07dc Intel Corp.
Couldn't open device, some information will be missing
Device Descriptor:
   bLength18
   bDescriptorType 1
   bcdUSB   2.00
   bDeviceClass  224 Wireless
   bDeviceSubClass 1 Radio Frequency
   bDeviceProtocol 1 Bluetooth
   bMaxPacketSize064
   idVendor   0x8087 Intel Corp.
   idProduct  0x07dc
   bcdDevice0.01
   iManufacturer   0
   iProduct0
   iSerial 0
   bNumConfigurations  1
   Configuration Descriptor:
 bLength 9
 bDescriptorType 2
 wTotalLength  177
 bNumInterfaces  2
 bConfigurationValue 1
 iConfiguration  0
 bmAttributes 0xe0
   Self Powered
   Remote Wakeup
 MaxPower  100mA
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber0
   bAlternateSetting   0
   bNumEndpoints   3
   bInterfaceClass   224 Wireless
   bInterfaceSubClass  1 Radio Frequency
   bInterfaceProtocol  1 Bluetooth
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x81  EP 1 IN
 bmAttributes3
   Transfer TypeInterrupt
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0040  1x 64 bytes
 bInterval   1
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x02  EP 2 OUT
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0040  1x 64 bytes
 bInterval   1
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x82  EP 2 IN
 bmAttributes2
   Transfer TypeBulk
   Synch Type   None
   Usage Type   Data
 wMaxPacketSize 0x0040  1x 64 bytes
 bInterval   1
 Interface Descriptor:
   bLength 9
   bDescriptorType 4
   bInterfaceNumber1
   bAlternateSetting   0
   bNumEndpoints   2
   bInterfaceClass   224 Wireless
   bInterfaceSubClass  1 Radio Frequency
   bInterfaceProtocol  1 Bluetooth
   iInterface  0
   Endpoint Descriptor:
 bLength 7
 bDescriptorType 5
 bEndpointAddress 0x03  EP 3 OUT
 bmAttributes1
   Transfer TypeIsochronous
   Synch Type   None

Re: Intel 7260 not working on 4.4.24 / armv7

[Emmanuel Grumbach]

On Tue, Oct 18, 2016 at 7:22 PM, Oliver Zemann  wrote:
> Because of the problems with the ath10 card, i bought an intel 7260 (mpcie)
> wifi card. Unfortunately it is also not working.
> I get tons of those messages:
>
> [  175.777030] usb 1-1: new full-speed USB device number 2 using orion-ehci
> [  175.933953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [  175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [  175.966954] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [  175.973313] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [  176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [  176.749831] usb 1-1: USB disconnect, device number 2
> [  177.076993] usb 1-1: new full-speed USB device number 3 using orion-ehci
> [  177.233953] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [  177.240682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [  177.266957] Bluetooth: hci0: read Intel version: 3707100180012d0d00
> [  177.273316] Bluetooth: hci0: Intel Bluetooth firmware file:
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [  177.482955] Bluetooth: hci0: Intel Bluetooth firmware patch completed and
> activated
> [  178.046910] usb 1-1: USB disconnect, device number 3
> [  178.376958] usb 1-1: new full-speed USB device number 4 using orion-ehci
> [  178.533954] usb 1-1: New USB device found, idVendor=8087, idProduct=07dc
> [  178.540682] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0

Hmm... bad connectors? USB seems to think that the device keeps disconnecting.
But that's the BT part.

> some information about the card:
> Bus 001 Device 011: ID 8087:07dc Intel Corp.
> Couldn't open device, some information will be missing
> Device Descriptor:
>   bLength18
>   bDescriptorType 1
>   bcdUSB   2.00
>   bDeviceClass  224 Wireless
>   bDeviceSubClass 1 Radio Frequency
>   bDeviceProtocol 1 Bluetooth
>   bMaxPacketSize064
>   idVendor   0x8087 Intel Corp.
>   idProduct  0x07dc
>   bcdDevice0.01
>   iManufacturer   0
>   iProduct0
>   iSerial 0
>   bNumConfigurations  1
>   Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength  177
> bNumInterfaces  2
> bConfigurationValue 1
> iConfiguration  0
> bmAttributes 0xe0
>   Self Powered
>   Remote Wakeup
> MaxPower  100mA
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber0
>   bAlternateSetting   0
>   bNumEndpoints   3
>   bInterfaceClass   224 Wireless
>   bInterfaceSubClass  1 Radio Frequency
>   bInterfaceProtocol  1 Bluetooth
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x81  EP 1 IN
> bmAttributes3
>   Transfer TypeInterrupt
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval   1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x02  EP 2 OUT
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval   1
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x82  EP 2 IN
> bmAttributes2
>   Transfer TypeBulk
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x0040  1x 64 bytes
> bInterval   1
> Interface Descriptor:
>   bLength 9
>   bDescriptorType 4
>   bInterfaceNumber1
>   bAlternateSetting   0
>   bNumEndpoints   2
>   bInterfaceClass   224 Wireless
>   bInterfaceSubClass  1 Radio Frequency
>   bInterfaceProtocol  1 Bluetooth
>   iInterface  0
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x03  EP 3 OUT
> bmAttributes1
>   Transfer TypeIsochronous
>   Synch Type   None
>   Usage Type   Data
> wMaxPacketSize 0x  1x 0 bytes
> bInterval

Re: sequence diagrams in rst documentation

[Johannes Berg]

> This could probably be argued either way...

Yeah, I guess it could :)

> My view has been all along that we should prefer to use existing
> extensions written and maintained by others. Perhaps we (the kind of
> royal "we" of which I'm personally really not part of) could take on
> maintainership of some extensions in the interest of improving kernel
> documentation, but I think the goal should be that the extensions are
> maintained outside of the kernel tree, that the extensions are
> generally usable, and have a chance of attracting attention and
> contributions from outside of the kernel community. (Note that this
> doesn't preclude us from shipping the extensions in the kernel tree,
> as long as it's updated from the upstream, not forked.)

Right. I tend to agree, though in the particular case I'm looking at
we'd probably have to fork outside the kernel, forming a new upstream,
and then ship that version (or perhaps rewrite it, forming a new
upstream, and then ship that - doesn't matter all that much)

> (This is one part of me being unhappy about making it easy to run
> arbitrary scripts to produce documentation; those will never be
> generic, and we'll never be able to offload their maintenance outside
> of the kernel. We should not think that we have some really special
> needs in the kernel.)

I agree that we don't necessarily have any special needs (*), but in
cases like this (**) it does seem more practical to just ship the
plugin with the kernel. Whether or not a separate "upstream" is formed
for it could be a secondary question, although it does seem better to
do so.

(*) although not wanting to ship binary files *is* kinda special :)

(**) where the upstream is essentially dead (for all I can tell) and
severely limited to the point where a rewrite will be a better choice.

Anyway, I'll have to see if we (Intel Linux WiFi team) actually want to
do things this way. Using the existing blockdiag/seqdiag is practical
since it all exists already. OTOH, a simpler and better-looking
solution would also be nice, so if we do go this way I'll investigate
more what we can do around this.

johannes

Re: Intel 7260 not working on 4.4.24 / armv7

[Johannes Berg]

On Tue, 2016-10-18 at 18:22 +0200, Oliver Zemann wrote:
> Because of the problems with the ath10 card, i bought an intel 7260 
> (mpcie) wifi card. Unfortunately it is also not working.
> I get tons of those messages:
> 
> [  175.777030] usb 1-1: new full-speed USB device number 2 using
> orion-ehci
> [  175.933953] usb 1-1: New USB device found, idVendor=8087,
> idProduct=07dc
> [  175.940681] usb 1-1: New USB device strings: Mfr=0, Product=0, 
> SerialNumber=0
> [  175.966954] Bluetooth: hci0: read Intel version:
> 3707100180012d0d00
> [  175.973313] Bluetooth: hci0: Intel Bluetooth firmware file: 
> intel/ibt-hw-37.7.10-fw-1.80.1.2d.d.bseq
> [  176.183954] Bluetooth: hci0: Intel Bluetooth firmware patch
> completed 
> and activated
> [  176.749831] usb 1-1: USB disconnect, device number 2

This is odd. However, it's entirely related to the NICs *Bluetooth*
function, which lives on USB.

> What's confusing me is that this device is connected through pcie,
> not usb. When i use lspci i get:
> [root@alarm log]# lspci
> 00:02.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 00:03.0 PCI bridge: Marvell Technology Group Ltd. Device 6828 (rev
> 04)
> 02:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac 
> Wireless Network Adapter (rev ff)
> 
> So the other card is seen as pci device, but the intel is not. I am 
> really lost now.

The NICs *WiFi* function should be a PCIe device, but the USB
connect/disconnect cycles suggest that there's something wrong with the
electrical connection, which presumably causes the PCIe part of the
device to never appear on the bus.

johannes

Re: sequence diagrams in rst documentation

[Jani Nikula]

On Tue, 18 Oct 2016, Johannes Berg  wrote:
> On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
>> Here are my thoughts ...
>> 
>> Every extension which is not a part of the sphinx distro brings new
>> external dependencies 
>
> I agree.
>
>> and the development of such extensions is IMO
>> far of kernel development's scope.
>
> Arguably, having good documentation *is* in the scope of kernel
> development.
>
> Also, it could be argued that shipping a module in the kernel sources
> would be more reliable than having to require it being externally
> installed, like the GCC plugins perhaps.

This could probably be argued either way...

My view has been all along that we should prefer to use existing
extensions written and maintained by others. Perhaps we (the kind of
royal "we" of which I'm personally really not part of) could take on
maintainership of some extensions in the interest of improving kernel
documentation, but I think the goal should be that the extensions are
maintained outside of the kernel tree, that the extensions are generally
usable, and have a chance of attracting attention and contributions from
outside of the kernel community. (Note that this doesn't preclude us
from shipping the extensions in the kernel tree, as long as it's updated
from the upstream, not forked.)

(This is one part of me being unhappy about making it easy to run
arbitrary scripts to produce documentation; those will never be generic,
and we'll never be able to offload their maintenance outside of the
kernel. We should not think that we have some really special needs in
the kernel.)

>> ATM, there are not many use cases for diagram generators, so why not
>> be KISS and creating diagrams with the favorite tool only adding the
>> resulting (e.g.) PNG to the Kernel's source?
>
> *Only* adding the PNG would be awful, I'd have to keep track of the
> corresponding source elsewhere, and perhaps couldn't even GPL it
> because then I couldn't distribute the PNG without corresponding
> source...
>
> Adding the source text would really be the only practical choice, but
> doing so makes it easy to mismatch things, and also very easy to use
> proprietary services for it that may go away at any time, etc.

Agreed. And there are other problems with attaching binaries (although
I'd say we should fix them too) [1].

BR,
Jani.


[1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b...@redhat.com


-- 
Jani Nikula, Intel Open Source Technology Center

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

[Ard Biesheuvel]

On 18 October 2016 at 15:24, Johannes Berg  wrote:
> On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
>>
>> > Hmm. Is it really worth having a per-CPU variable for each possible
>> > key? You could have a large number of those (typically three when
>> > you're a client on an AP, and 1 + 1 for each client when you're the
>> > AP).
>
> 2 + 1 for each client, actually, since you have 2 GTKs present in the
> "steady state"; not a big difference though.
>
>> > Would it be so bad to have to set the TFM every time (if that's
>> > even possible), and just have a single per-CPU cache?
>
>> That would be preferred, yes. The only snag here is that
>> crypto_alloc_aead() is not guaranteed to return the same algo every
>> time, which means the request size is not guaranteed to be the same
>> either. This is a rare corner case, of course, but it needs to be
>> dealt with regardless
>
> Ah, good point. Well I guess you could allocate a bigger one it if it's
> too small, but then we'd have to recalculate the size all the time
> (which we already did anyway, but saving something else would be good).
> Then we'd be close to just having a per-CPU memory block cache though.
>

Well, ideally we'd allocate the ccm(aes) crypto_alg a single time and
'spawn' the transforms for each key. This is how the crypto API
implements templates internally, but I don't think this functionality
is publicly accessible. Herbert?

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

[Johannes Berg]

On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote:
> 
> > Hmm. Is it really worth having a per-CPU variable for each possible
> > key? You could have a large number of those (typically three when
> > you're a client on an AP, and 1 + 1 for each client when you're the
> > AP).

2 + 1 for each client, actually, since you have 2 GTKs present in the
"steady state"; not a big difference though.

> > Would it be so bad to have to set the TFM every time (if that's
> > even possible), and just have a single per-CPU cache?

> That would be preferred, yes. The only snag here is that
> crypto_alloc_aead() is not guaranteed to return the same algo every
> time, which means the request size is not guaranteed to be the same
> either. This is a rare corner case, of course, but it needs to be
> dealt with regardless

Ah, good point. Well I guess you could allocate a bigger one it if it's
too small, but then we'd have to recalculate the size all the time
(which we already did anyway, but saving something else would be good).
Then we'd be close to just having a per-CPU memory block cache though.

johannes

Re: pull-request: mac80211 2016-10-18

[David Miller]

From: Johannes Berg 
Date: Tue, 18 Oct 2016 09:00:57 +0200

> As I mention in the tag message, the most urgent fix here is for
> the VMAP_STACK vs. software crypto usage. I ended up applying Ard's
> fix that dynamically allocates everything in one go, perhaps we'll
> find a better solution in the future, but in the meantime this will
> get things working again (rather than crashing or getting BUG_ON),
> and normally it's a rarely used code path since hardware crypto is
> used for almost all devices.
> 
> Please pull, or let me know if there's any problem.

Pulled, thanks Johannes.

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

[Ard Biesheuvel]

On 18 October 2016 at 15:16, Johannes Berg  wrote:
> On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote:
>>
>> + aead_req = *this_cpu_ptr(ccmp->reqs);
>> + if (!aead_req) {
>> + aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
>> + if (!aead_req)
>> + return -ENOMEM;
>> + *this_cpu_ptr(ccmp->reqs) = aead_req;
>> + aead_request_set_tfm(aead_req, ccmp->tfm);
>> + }
>
> Hmm. Is it really worth having a per-CPU variable for each possible
> key? You could have a large number of those (typically three when
> you're a client on an AP, and 1 + 1 for each client when you're the
> AP).
>
> Would it be so bad to have to set the TFM every time (if that's even
> possible), and just have a single per-CPU cache?
>

That would be preferred, yes. The only snag here is that
crypto_alloc_aead() is not guaranteed to return the same algo every
time, which means the request size is not guaranteed to be the same
either. This is a rare corner case, of course, but it needs to be
dealt with regardless

[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

[Ard Biesheuvel]

Now that we can no longer invoke AEAD transforms with the aead_request
structure allocated on the stack, we perform a kmalloc/kfree for every
packet, which is expensive.

Since the CCMP routines execute in softirq context, we know there can
never be more than one request in flight on each CPU, and so we can
simply keep a cached aead_request structure per CPU, and deallocate all
of them when deallocating the AEAD transform.

Signed-off-by: Ard Biesheuvel 
---
 net/mac80211/aes_ccm.c | 49 ++--
 net/mac80211/key.h |  1 +
 2 files changed, 36 insertions(+), 14 deletions(-)

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index 58e0338a2c34..2cb5ee4868ea 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -28,9 +28,14 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead 
*ccmp, u8 *b_0,
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
 
-   aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
-   if (!aead_req)
-   return -ENOMEM;
+   aead_req = *this_cpu_ptr(ccmp->reqs);
+   if (!aead_req) {
+   aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+   if (!aead_req)
+   return -ENOMEM;
+   *this_cpu_ptr(ccmp->reqs) = aead_req;
+   aead_request_set_tfm(aead_req, ccmp->tfm);
+   }
 
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -40,12 +45,10 @@ int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead 
*ccmp, u8 *b_0,
sg_set_buf([1], data, data_len);
sg_set_buf([2], mic, mic_len);
 
-   aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
 
crypto_aead_encrypt(aead_req);
-   kzfree(aead_req);
 
return 0;
 }
@@ -58,14 +61,18 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead 
*ccmp, u8 *b_0,
struct aead_request *aead_req;
int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
-   int err;
 
if (data_len == 0)
return -EINVAL;
 
-   aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
-   if (!aead_req)
-   return -ENOMEM;
+   aead_req = *this_cpu_ptr(ccmp->reqs);
+   if (!aead_req) {
+   aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
+   if (!aead_req)
+   return -ENOMEM;
+   *this_cpu_ptr(ccmp->reqs) = aead_req;
+   aead_request_set_tfm(aead_req, ccmp->tfm);
+   }
 
__aad = (u8 *)aead_req + reqsize;
memcpy(__aad, aad, CCM_AAD_LEN);
@@ -75,14 +82,10 @@ int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead 
*ccmp, u8 *b_0,
sg_set_buf([1], data, data_len);
sg_set_buf([2], mic, mic_len);
 
-   aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
 
-   err = crypto_aead_decrypt(aead_req);
-   kzfree(aead_req);
-
-   return err;
+   return crypto_aead_decrypt(aead_req);
 }
 
 int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
@@ -91,6 +94,7 @@ int ieee80211_aes_key_setup_encrypt(struct 
ieee80211_ccmp_aead *ccmp,
size_t mic_len)
 {
struct crypto_aead *tfm;
+   struct aead_request **r;
int err;
 
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
@@ -104,6 +108,14 @@ int ieee80211_aes_key_setup_encrypt(struct 
ieee80211_ccmp_aead *ccmp,
if (err)
goto free_aead;
 
+   /* allow a struct aead_request to be cached per cpu */
+   r = alloc_percpu(struct aead_request *);
+   if (!r) {
+   err = -ENOMEM;
+   goto free_aead;
+   }
+
+   ccmp->reqs = r;
ccmp->tfm = tfm;
return 0;
 
@@ -114,5 +126,14 @@ int ieee80211_aes_key_setup_encrypt(struct 
ieee80211_ccmp_aead *ccmp,
 
 void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
 {
+   struct aead_request *req;
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   req = *per_cpu_ptr(ccmp->reqs, cpu);
+   if (req)
+   kzfree(req);
+   }
+   free_percpu(ccmp->reqs);
crypto_free_aead(ccmp->tfm);
 }
diff --git a/net/mac80211/key.h b/net/mac80211/key.h
index 1ec7a737ab79..f99ec46dc08f 100644
--- a/net/mac80211/key.h
+++ b/net/mac80211/key.h
@@ -89,6 +89,7 @@ struct ieee80211_key {
 */
u8 rx_pn[IEEE80211_NUM_TIDS + 1][IEEE80211_CCMP_PN_LEN];
struct crypto_aead *tfm;
+   struct aead_request * __percpu *reqs;
u32 replays; /* dot11RSNAStatsCCMPReplays */

[RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU

[Ard Biesheuvel]

This RFC implements per CPU caching of AEAD request structures, which allows
us to get rid of the per-packet kzalloc/kzfree calls we were forced to
introduce to deal with SG API violations, both in the mac80211 and in the
core crypto API code.

Since mac80211 only executes the AEAD transforms in softirq context, only one
AEAD request can be in flight at the same time on any given CPU, and so, instead
of free the request, we can stash its address in a per CPU variable, and reuse
it for the next packet.

This RFC only addressess CCMP, but GCM and GMAC could be fixed in the same way
(and CMAC did not suffer from the API violation issue in the first place)

Ard Biesheuvel (2):
  mac80211: aes_ccm: prepare key struct for storing context data
  mac80211: aes_ccm: cache AEAD request structures per CPU

 net/mac80211/aes_ccm.c | 80 +---
 net/mac80211/aes_ccm.h | 16 ++--
 net/mac80211/key.c | 16 ++--
 net/mac80211/key.h |  3 +-
 net/mac80211/wpa.c |  4 +-
 5 files changed, 71 insertions(+), 48 deletions(-)

-- 
2.7.4

[RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data

[Ard Biesheuvel]

As a prepatory change to allow per CPU caching of request structures,
refactor the key allocation routine so we can access per key data
beyond the core AEAD transform easily.

Signed-off-by: Ard Biesheuvel 
---
 net/mac80211/aes_ccm.c | 35 +++-
 net/mac80211/aes_ccm.h | 16 -
 net/mac80211/key.c | 16 -
 net/mac80211/key.h |  2 +-
 net/mac80211/wpa.c |  4 +--
 5 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c
index a4e0d59a40dd..58e0338a2c34 100644
--- a/net/mac80211/aes_ccm.c
+++ b/net/mac80211/aes_ccm.c
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -18,13 +19,13 @@
 #include "key.h"
 #include "aes_ccm.h"
 
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_encrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
  size_t mic_len)
 {
struct scatterlist sg[3];
struct aead_request *aead_req;
-   int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+   int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
 
aead_req = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
@@ -39,7 +40,7 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
sg_set_buf([1], data, data_len);
sg_set_buf([2], mic, mic_len);
 
-   aead_request_set_tfm(aead_req, tfm);
+   aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
 
@@ -49,13 +50,13 @@ int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
return 0;
 }
 
-int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_ccm_decrypt(struct ieee80211_ccmp_aead *ccmp, u8 *b_0,
+ u8 *aad, u8 *data, size_t data_len, u8 *mic,
  size_t mic_len)
 {
struct scatterlist sg[3];
struct aead_request *aead_req;
-   int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(tfm);
+   int reqsize = sizeof(*aead_req) + crypto_aead_reqsize(ccmp->tfm);
u8 *__aad;
int err;
 
@@ -74,7 +75,7 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
sg_set_buf([1], data, data_len);
sg_set_buf([2], mic, mic_len);
 
-   aead_request_set_tfm(aead_req, tfm);
+   aead_request_set_tfm(aead_req, ccmp->tfm);
aead_request_set_crypt(aead_req, sg, sg, data_len + mic_len, b_0);
aead_request_set_ad(aead_req, sg[0].length);
 
@@ -84,16 +85,17 @@ int ieee80211_aes_ccm_decrypt(struct crypto_aead *tfm, u8 
*b_0, u8 *aad,
return err;
 }
 
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
-   size_t key_len,
-   size_t mic_len)
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+   const u8 key[],
+   size_t key_len,
+   size_t mic_len)
 {
struct crypto_aead *tfm;
int err;
 
tfm = crypto_alloc_aead("ccm(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(tfm))
-   return tfm;
+   return PTR_ERR(tfm);
 
err = crypto_aead_setkey(tfm, key, key_len);
if (err)
@@ -102,14 +104,15 @@ struct crypto_aead *ieee80211_aes_key_setup_encrypt(const 
u8 key[],
if (err)
goto free_aead;
 
-   return tfm;
+   ccmp->tfm = tfm;
+   return 0;
 
 free_aead:
crypto_free_aead(tfm);
-   return ERR_PTR(err);
+   return err;
 }
 
-void ieee80211_aes_key_free(struct crypto_aead *tfm)
+void ieee80211_aes_key_free(struct ieee80211_ccmp_aead *ccmp)
 {
-   crypto_free_aead(tfm);
+   crypto_free_aead(ccmp->tfm);
 }
diff --git a/net/mac80211/aes_ccm.h b/net/mac80211/aes_ccm.h
index fcd3254c5cf0..82e91c6ec41f 100644
--- a/net/mac80211/aes_ccm.h
+++ b/net/mac80211/aes_ccm.h
@@ -14,15 +14,15 @@
 
 #define CCM_AAD_LEN32
 
-struct crypto_aead *ieee80211_aes_key_setup_encrypt(const u8 key[],
-   size_t key_len,
-   size_t mic_len);
-int ieee80211_aes_ccm_encrypt(struct crypto_aead *tfm, u8 *b_0, u8 *aad,
- u8 *data, size_t data_len, u8 *mic,
+int ieee80211_aes_key_setup_encrypt(struct ieee80211_ccmp_aead *ccmp,
+   const u8 key[], size_t key_len,
+   size_t mic_len);

Re: sequence diagrams in rst documentation

[Johannes Berg]

On Tue, 2016-10-18 at 15:51 +0200, Markus Heiser wrote:
> Here are my thoughts ...
> 
> Every extension which is not a part of the sphinx distro brings new
> external dependencies 

I agree.

> and the development of such extensions is IMO
> far of kernel development's scope.

Arguably, having good documentation *is* in the scope of kernel
development.

Also, it could be argued that shipping a module in the kernel sources
would be more reliable than having to require it being externally
installed, like the GCC plugins perhaps.

> ATM, there are not many use cases for diagram generators, so why not
> be KISS and creating diagrams with the favorite tool only adding the
> resulting (e.g.) PNG to the Kernel's source?

*Only* adding the PNG would be awful, I'd have to keep track of the
corresponding source elsewhere, and perhaps couldn't even GPL it
because then I couldn't distribute the PNG without corresponding
source...

Adding the source text would really be the only practical choice, but
doing so makes it easy to mismatch things, and also very easy to use
proprietary services for it that may go away at any time, etc.

> Before we add new dependencies / complexity, we should get rid
> of the DocBook build.

That argument is ... completely bogus, politely said.

I'm not going to (be able to) do anything about all the docbooks that
exist, and have in fact converted the one docbook that I know anything
about. Holding back the development of documentation in one subsystem
because another subsystem hasn't converted is a garbage argument.

johannes

Re: sequence diagrams in rst documentation

[Markus Heiser]

Am 18.10.2016 um 13:43 schrieb Johannes Berg :

> On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
>>> 
>>> 
>>> Related question: I have some sequence diagrams, and just found the
>>> seqdiag sphinx plugin. How should we manage adding extensions? Or
>>> would you prefer not to add any at all?
>> 
>> Example here:
>> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow
> 
> Coming back to this - sadly, it appears that this software (blockdiag,
> seqdiag) is completely unmaintained, with open pull requests dating
> back to 2012 and the last commit dating back to 2015-08-22.
> 
> I'd want/need feature improvements in it too, but if I can't feed those
> back to upstream (since it appears dead), there's little point.
> 
> Perhaps we can ship plugins for this as part of the kernel sources?
> Shouldn't be too difficult to reimplement something like this, after
> all.

Here are my thoughts ...

Every extension which is not a part of the sphinx distro brings new
external dependencies and the development of such extensions is IMO
far of kernel development's scope.

ATM, there are not many use cases for diagram generators, so why not
be KISS and creating diagrams with the favorite tool only adding the
resulting (e.g.) PNG to the Kernel's source?

Before we add new dependencies / complexity, we should get rid
of the DocBook build.

-- Markus --


> johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

sequence diagrams in rst documentation

[Johannes Berg]

On Tue, 2016-10-11 at 15:53 +0200, Johannes Berg wrote:
> > 
> > 
> > Related question: I have some sequence diagrams, and just found the
> > seqdiag sphinx plugin. How should we manage adding extensions? Or
> > would you prefer not to add any at all?
> 
> Example here:
> https://johannes.sipsolutions.net/files/80211/mac80211.html#connection-flow

Coming back to this - sadly, it appears that this software (blockdiag,
seqdiag) is completely unmaintained, with open pull requests dating
back to 2012 and the last commit dating back to 2015-08-22.

I'd want/need feature improvements in it too, but if I can't feed those
back to upstream (since it appears dead), there's little point.

Perhaps we can ship plugins for this as part of the kernel sources?
Shouldn't be too difficult to reimplement something like this, after
all.

johannes

[PATCHv2 0/2] ath10k: add support for tx bitrate

[akolli]

From: Anilkumar Kolli 

This patch series adds support for tx bitrate using 
.sta_statistics callback.

tx bitrate tested on QCA4019 using iw.

Anilkumar Kolli (2):
  ath10k: add per peer htt tx stats support for 10.4
  ath10k: add support for per sta tx bitrate

 drivers/net/wireless/ath/ath10k/core.h|   17 
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   13 +++
 drivers/net/wireless/ath/ath10k/htt.c |2 +
 drivers/net/wireless/ath/ath10k/htt.h |   25 +
 drivers/net/wireless/ath/ath10k/htt_rx.c  |  125 +
 drivers/net/wireless/ath/ath10k/wmi.h |   10 +-
 6 files changed, 191 insertions(+), 1 deletion(-)

-- 
1.7.9.5

[PATCHv2 1/2] ath10k: add per peer htt tx stats support for 10.4

[akolli]

From: Anilkumar Kolli 

Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.

Parse peer stats and update the tx rate information per STA.

tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.

Signed-off-by: Anilkumar Kolli 
---
v2:
 * address Kalle's comments 
 * fix compilation warnings

 drivers/net/wireless/ath/ath10k/core.h   |   17 
 drivers/net/wireless/ath/ath10k/htt.c|2 +
 drivers/net/wireless/ath/ath10k/htt.h|   25 ++
 drivers/net/wireless/ath/ath10k/htt_rx.c |  125 ++
 drivers/net/wireless/ath/ath10k/wmi.h|   10 ++-
 5 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index dda49af1eb74..fc3d3bded265 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+   struct rate_info txrate;
 
struct work_struct update_wk;
 
@@ -694,6 +695,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
 };
 
+struct ath10k_per_peer_tx_stats {
+   u32 succ_bytes;
+   u32 retry_bytes;
+   u32 failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   u16 peer_id;
+   u16 succ_pkts;
+   u16 retry_pkts;
+   u16 failed_pkts;
+   u16 duration;
+   u32 reserved1;
+   u32 reserved2;
+};
+
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
 
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+   struct ath10k_per_peer_tx_stats peer_tx_stats;
 
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c 
b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@ static const enum htt_t2h_msg_type htt_10_4_t2h_msg_types[] 
= {
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+   HTT_T2H_MSG_TYPE_PEER_STATS,
 };
 
 int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+   HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
 };
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
 };
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
 } __packed;
 
+struct htt_per_peer_tx_stats_ind {
+   __le32  succ_bytes;
+   __le32  retry_bytes;
+   __le32  failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   __le16  peer_id;
+   __le16  succ_pkts;
+   __le16  retry_pkts;
+   __le16  failed_pkts;
+   __le16  tx_duration;
+   __le32  reserved1;
+   __le32  reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+   u8 num_ppdu;
+   u8 ppdu_len;
+   u8 version;
+   u8 payload[0];
+} __packed;
+
 union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+   struct htt_peer_tx_stats peer_tx_stats;
};
 } __packed;
 
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c1562420f..ef28b358cf5e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, 
struct sk_buff *skb)
dev_kfree_skb_any(skb);
 }
 
+static inline bool 

[PATCH 1/2] ath10k: add per peer htt tx stats support for 10.4

[akolli]

From: Anilkumar Kolli 

Per peer tx stats are part of 'HTT_10_4_T2H_MSG_TYPE_PEER_STATS'
event, Firmware sends one HTT event for every four PPDUs.
HTT payload has success pkts/bytes, failed pkts/bytes, retry
pkts/bytes and rate info per ppdu.
Peer stats are enabled through 'WMI_SERVICE_PEER_STATS',
which are nowadays enabled by default.

Parse peer stats and update the tx rate information per STA.

tx rate, Peer stats are tested on QCA4019 with Firmware version
10.4-3.2.1-00028.

Signed-off-by: Anilkumar Kolli 
---
v2:
 * address Kalle's comments 
 * fix compilation warnings

 drivers/net/wireless/ath/ath10k/core.h   |   17 
 drivers/net/wireless/ath/ath10k/htt.c|2 +
 drivers/net/wireless/ath/ath10k/htt.h|   25 ++
 drivers/net/wireless/ath/ath10k/htt_rx.c |  125 ++
 drivers/net/wireless/ath/ath10k/wmi.h|   10 ++-
 5 files changed, 178 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/core.h 
b/drivers/net/wireless/ath/ath10k/core.h
index dda49af1eb74..fc3d3bded265 100644
--- a/drivers/net/wireless/ath/ath10k/core.h
+++ b/drivers/net/wireless/ath/ath10k/core.h
@@ -337,6 +337,7 @@ struct ath10k_sta {
u32 nss;
u32 smps;
u16 peer_id;
+   struct rate_info txrate;
 
struct work_struct update_wk;
 
@@ -694,6 +695,21 @@ struct ath10k_fw_components {
struct ath10k_fw_file fw_file;
 };
 
+struct ath10k_per_peer_tx_stats {
+   u32 succ_bytes;
+   u32 retry_bytes;
+   u32 failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   u16 peer_id;
+   u16 succ_pkts;
+   u16 retry_pkts;
+   u16 failed_pkts;
+   u16 duration;
+   u32 reserved1;
+   u32 reserved2;
+};
+
 struct ath10k {
struct ath_common ath_common;
struct ieee80211_hw *hw;
@@ -906,6 +922,7 @@ struct ath10k {
 
struct ath10k_thermal thermal;
struct ath10k_wow wow;
+   struct ath10k_per_peer_tx_stats peer_tx_stats;
 
/* NAPI */
struct net_device napi_dev;
diff --git a/drivers/net/wireless/ath/ath10k/htt.c 
b/drivers/net/wireless/ath/ath10k/htt.c
index 130cd9502021..cd160b16db1e 100644
--- a/drivers/net/wireless/ath/ath10k/htt.c
+++ b/drivers/net/wireless/ath/ath10k/htt.c
@@ -137,6 +137,8 @@ static const enum htt_t2h_msg_type htt_10_4_t2h_msg_types[] 
= {
HTT_T2H_MSG_TYPE_STATS_NOUPLOAD,
[HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND] =
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   [HTT_10_4_T2H_MSG_TYPE_PEER_STATS] =
+   HTT_T2H_MSG_TYPE_PEER_STATS,
 };
 
 int ath10k_htt_connect(struct ath10k_htt *htt)
diff --git a/drivers/net/wireless/ath/ath10k/htt.h 
b/drivers/net/wireless/ath/ath10k/htt.h
index 0d2ed09f202b..164eb3a10566 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -419,6 +419,7 @@ enum htt_10_4_t2h_msg_type {
HTT_10_4_T2H_MSG_TYPE_STATS_NOUPLOAD = 0x18,
/* 0x19 to 0x2f are reserved */
HTT_10_4_T2H_MSG_TYPE_TX_MODE_SWITCH_IND = 0x30,
+   HTT_10_4_T2H_MSG_TYPE_PEER_STATS = 0x31,
/* keep this last */
HTT_10_4_T2H_NUM_MSGS
 };
@@ -453,6 +454,7 @@ enum htt_t2h_msg_type {
HTT_T2H_MSG_TYPE_TX_FETCH_IND,
HTT_T2H_MSG_TYPE_TX_FETCH_CONFIRM,
HTT_T2H_MSG_TYPE_TX_MODE_SWITCH_IND,
+   HTT_T2H_MSG_TYPE_PEER_STATS,
/* keep this last */
HTT_T2H_NUM_MSGS
 };
@@ -1470,6 +1472,28 @@ struct htt_channel_change {
__le32 phymode;
 } __packed;
 
+struct htt_per_peer_tx_stats_ind {
+   __le32  succ_bytes;
+   __le32  retry_bytes;
+   __le32  failed_bytes;
+   u8  ratecode;
+   u8  flags;
+   __le16  peer_id;
+   __le16  succ_pkts;
+   __le16  retry_pkts;
+   __le16  failed_pkts;
+   __le16  tx_duration;
+   __le32  reserved1;
+   __le32  reserved2;
+} __packed;
+
+struct htt_peer_tx_stats {
+   u8 num_ppdu;
+   u8 ppdu_len;
+   u8 version;
+   u8 payload[0];
+} __packed;
+
 union htt_rx_pn_t {
/* WEP: 24-bit PN */
u32 pn24;
@@ -1521,6 +1545,7 @@ struct htt_resp {
struct htt_tx_fetch_confirm tx_fetch_confirm;
struct htt_tx_mode_switch_ind tx_mode_switch_ind;
struct htt_channel_change chan_change;
+   struct htt_peer_tx_stats peer_tx_stats;
};
 } __packed;
 
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c 
b/drivers/net/wireless/ath/ath10k/htt_rx.c
index 0b4c1562420f..ef28b358cf5e 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2194,6 +2194,128 @@ void ath10k_htt_htc_t2h_msg_handler(struct ath10k *ar, 
struct sk_buff *skb)
dev_kfree_skb_any(skb);
 }
 
+static inline bool 

[PATCHv2 0/2] ath10k: add support for tx bitrate

[akolli]

From: Anilkumar Kolli 

This patch series adds support for tx bitrate using 
.sta_statistics callback.

tx bitrate tested on QCA4019 using iw.

Anilkumar Kolli (2):
  ath10k: add per peer htt tx stats support for 10.4
  ath10k: add support for per sta tx bitrate

 drivers/net/wireless/ath/ath10k/core.h|   17 
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   13 +++
 drivers/net/wireless/ath/ath10k/htt.c |2 +
 drivers/net/wireless/ath/ath10k/htt.h |   25 +
 drivers/net/wireless/ath/ath10k/htt_rx.c  |  125 +
 drivers/net/wireless/ath/ath10k/wmi.h |   10 +-
 6 files changed, 191 insertions(+), 1 deletion(-)

-- 
1.7.9.5

[PATCHv2 0/2] ath10k: add support for tx bitrate

[akolli]

From: Anilkumar Kolli 

This patch series adds support for tx bitrate using 
.sta_statistics callback.

tx bitrate tested on QCA4019 using iw.

Anilkumar Kolli (2):
  ath10k: add per peer htt tx stats support for 10.4
  ath10k: add support for per sta tx bitrate

 drivers/net/wireless/ath/ath10k/core.h|   17 
 drivers/net/wireless/ath/ath10k/debugfs_sta.c |   13 +++
 drivers/net/wireless/ath/ath10k/htt.c |2 +
 drivers/net/wireless/ath/ath10k/htt.h |   25 +
 drivers/net/wireless/ath/ath10k/htt_rx.c  |  125 +
 drivers/net/wireless/ath/ath10k/wmi.h |   10 +-
 6 files changed, 191 insertions(+), 1 deletion(-)

-- 
1.7.9.5

[NOT FOR MERGE] ath9k: work around key cache corruption

[Antonio Quartulli]

From: Antonio Quartulli 

This patch was crafted long time ago to work around a key cache
corruption problem on ath9k chipsets.

The workaround consists in periodically triggering a worker that
uploads all the keys to the HW cache. The worker is triggered also
when the vif detects 21 undecryptable packets.


This patch is based on top compat-wireless-2015-10-26.


I was asked to release this code to the public and, since it is
GPL, I am now doing it.


Signed-off-by: Antonio Quartulli 

---
 drivers/net/wireless/ath/ath.h |  11 +++
 drivers/net/wireless/ath/ath9k/ath9k.h |   7 ++
 drivers/net/wireless/ath/ath9k/init.c  |   1 +
 drivers/net/wireless/ath/ath9k/main.c  |  21 +
 drivers/net/wireless/ath/ath9k/recv.c  |  25 ++
 drivers/net/wireless/ath/key.c | 149 +
 include/net/mac80211.h |   4 +
 net/mac80211/key.c |  22 ++---
 net/mac80211/key.h |   1 +
 net/mac80211/sta_info.c|  13 +++
 10 files changed, 243 insertions(+), 11 deletions(-)

diff --git a/drivers/net/wireless/ath/ath.h b/drivers/net/wireless/ath/ath.h
index 91eeca5..85377bc 100644
--- a/drivers/net/wireless/ath/ath.h
+++ b/drivers/net/wireless/ath/ath.h
@@ -187,6 +187,13 @@ struct ath_common {
 
int last_rssi;
struct ieee80211_supported_band sbands[IEEE80211_NUM_BANDS];
+
+   struct {
+   struct mutex mtx;
+   atomic_t running;
+   void (*refresh_cb)(struct ieee80211_sta *sta);
+   struct work_struct refresh_work;
+   } key_cache;
 };
 
 static inline const struct ath_ps_ops *ath_ps_ops(struct ath_common *common)
@@ -201,10 +208,14 @@ bool ath_is_mybeacon(struct ath_common *common, struct 
ieee80211_hdr *hdr);
 
 void ath_hw_setbssidmask(struct ath_common *common);
 void ath_key_delete(struct ath_common *common, struct ieee80211_key_conf *key);
+void ath_keys_config(struct ath_common *common);
 int ath_key_config(struct ath_common *common,
  struct ieee80211_vif *vif,
  struct ieee80211_sta *sta,
  struct ieee80211_key_conf *key);
+void ath_key_refresher_init(struct ath_common *common,
+   void (*cb)(struct ieee80211_sta *sta));
+void ath_key_refresher_start(struct ath_common *common);
 bool ath_hw_keyreset(struct ath_common *common, u16 entry);
 void ath_hw_cycle_counters_update(struct ath_common *common);
 int32_t ath_hw_get_listen_time(struct ath_common *common);
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h 
b/drivers/net/wireless/ath/ath9k/ath9k.h
index 0aab323..3930962 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -23,6 +23,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "common.h"
 #include "debug.h"
@@ -38,6 +40,8 @@ extern int ath9k_led_blink;
 extern bool is_ath9k_unloaded;
 extern int ath9k_use_chanctx;
 
+#define ATH_RX_DEC_MAX_ERR 20
+
 /*/
 /* Descriptor Management */
 /*/
@@ -266,6 +270,8 @@ struct ath_node {
 #endif
u8 key_idx[4];
 
+   atomic_t decrypt_errors;
+
u32 ackto;
struct list_head list;
 };
@@ -584,6 +590,7 @@ void ath9k_release_buffered_frames(struct ieee80211_hw *hw,
   u16 tids, int nframes,
   enum ieee80211_frame_release_type reason,
   bool more_data);
+void ath9k_refresh_iter(struct ieee80211_sta *sta);
 
 //
 /* VIFs */
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index 1b57d12..adec135 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -612,6 +612,7 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc,
common->bt_ant_diversity = 1;
 
spin_lock_init(>cc_lock);
+   ath_key_refresher_init(common, ath9k_refresh_iter);
spin_lock_init(>sc_serial_rw);
spin_lock_init(>sc_pm_lock);
spin_lock_init(>chan_lock);
diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index 56520ac..8ddb0e0 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -16,6 +16,7 @@
 
 #include 
 #include 
+#include 
 #include "ath9k.h"
 #include "btcoex.h"
 
@@ -1690,6 +1691,9 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
if (sta)
an = (struct ath_node *)sta->drv_priv;
 
+   if (sta)
+   an = (struct ath_node *)sta->drv_priv;
+
switch (cmd) {
case SET_KEY:
if (sta)
@@ -1717,6 +1721,14 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
}
WARN_ON(i == ARRAY_SIZE(an->key_idx));
  

[PATCH] wireless: deprecate WDS and disable by default

[Johannes Berg]

From: Johannes Berg 

The old WDS 4-addr frame support is very limited, e.g.
 * no encryption is possible on such links
 * it cannot support rate/HT/VHT negotiation
 * management APIs are very restricted

These make the WDS legacy mode useless in practice.

All of these are resolved by the 4-addr AP/client support,
so there's also no reason to improve WDS in the future.

Therefore, add a Kconfig option to disable legacy WDS.
This gives people an "emergency valve" while they migrate
to the better-supported 4-addr AP/client option; we plan
to remove it (and the associated cfg80211/mac80211 code,
which is the ultimate goal) in the future.

Signed-off-by: Johannes Berg 
---
 drivers/net/wireless/Kconfig   | 13 +
 drivers/net/wireless/ath/ath9k/init.c  |  6 ++
 drivers/net/wireless/broadcom/b43/main.c   |  2 ++
 drivers/net/wireless/broadcom/b43legacy/main.c |  2 ++
 drivers/net/wireless/ralink/rt2x00/rt2x00dev.c |  6 --
 net/wireless/core.c| 10 ++
 6 files changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/Kconfig b/drivers/net/wireless/Kconfig
index 8c8edaf1bba6..fa9c4fa9477e 100644
--- a/drivers/net/wireless/Kconfig
+++ b/drivers/net/wireless/Kconfig
@@ -17,6 +17,19 @@ menuconfig WLAN
 
 if WLAN
 
+config WIRELESS_WDS
+   bool "mac80211-based legacy WDS support"
+   help
+ This option enables the deprecated WDS support, the newer
+ mac80211-based 4-addr AP/client support supersedes it with
+ a much better feature set (HT, VHT, ...)
+
+ We plan to remove this option and code, so if you find
+ that you have to enable it, please let us know on the
+ linux-wireless@vger.kernel.org mailing list, so we can
+ help you migrate to 4-addr AP/client (or, if it's really
+ necessary, give up on our plan of removing it).
+
 source "drivers/net/wireless/admtek/Kconfig"
 source "drivers/net/wireless/ath/Kconfig"
 source "drivers/net/wireless/atmel/Kconfig"
diff --git a/drivers/net/wireless/ath/ath9k/init.c 
b/drivers/net/wireless/ath/ath9k/init.c
index cfa3fe82ade3..368d9b313823 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -734,9 +734,11 @@ static const struct ieee80211_iface_limit if_limits[] = {
 BIT(NL80211_IFTYPE_P2P_GO) },
 };
 
+#ifdef CONFIG_WIRELESS_WDS
 static const struct ieee80211_iface_limit wds_limits[] = {
{ .max = 2048,  .types = BIT(NL80211_IFTYPE_WDS) },
 };
+#endif
 
 #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
 
@@ -774,6 +776,7 @@ static const struct ieee80211_iface_combination if_comb[] = 
{
BIT(NL80211_CHAN_WIDTH_40),
 #endif
},
+#ifdef CONFIG_WIRELESS_WDS
{
.limits = wds_limits,
.n_limits = ARRAY_SIZE(wds_limits),
@@ -781,6 +784,7 @@ static const struct ieee80211_iface_combination if_comb[] = 
{
.num_different_channels = 1,
.beacon_int_infra_match = true,
},
+#endif
 };
 
 #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
@@ -851,7 +855,9 @@ static void ath9k_set_hw_capab(struct ath_softc *sc, struct 
ieee80211_hw *hw)
BIT(NL80211_IFTYPE_STATION) |
BIT(NL80211_IFTYPE_ADHOC) |
BIT(NL80211_IFTYPE_MESH_POINT) |
+#ifdef CONFIG_WIRELESS_WDS
BIT(NL80211_IFTYPE_WDS) |
+#endif
BIT(NL80211_IFTYPE_OCB);
 
if (ath9k_is_chanctx_enabled())
diff --git a/drivers/net/wireless/broadcom/b43/main.c 
b/drivers/net/wireless/broadcom/b43/main.c
index 6e5d9095b195..52f3541ecbcf 100644
--- a/drivers/net/wireless/broadcom/b43/main.c
+++ b/drivers/net/wireless/broadcom/b43/main.c
@@ -5591,7 +5591,9 @@ static struct b43_wl *b43_wireless_init(struct 
b43_bus_dev *dev)
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_MESH_POINT) |
BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_WIRELESS_WDS
BIT(NL80211_IFTYPE_WDS) |
+#endif
BIT(NL80211_IFTYPE_ADHOC);
 
hw->wiphy->flags |= WIPHY_FLAG_IBSS_RSN;
diff --git a/drivers/net/wireless/broadcom/b43legacy/main.c 
b/drivers/net/wireless/broadcom/b43legacy/main.c
index 83770d2ea057..e97ab2b91663 100644
--- a/drivers/net/wireless/broadcom/b43legacy/main.c
+++ b/drivers/net/wireless/broadcom/b43legacy/main.c
@@ -3838,7 +3838,9 @@ static int b43legacy_wireless_init(struct ssb_device *dev)
hw->wiphy->interface_modes =
BIT(NL80211_IFTYPE_AP) |
BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_WIRELESS_WDS
BIT(NL80211_IFTYPE_WDS) |
+#endif
BIT(NL80211_IFTYPE_ADHOC);
hw->queues = 1; /* FIXME: hardware has more queues */
hw->max_rates = 2;
diff --git 

Re: [PATCH -next] cfg80211: fix possible memory leak in cfg80211_iter_combinations()

[Johannes Berg]

On Mon, 2016-10-17 at 15:25 +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> 'limits' is malloced in cfg80211_iter_combinations() and should be
> freed
> before leaving from the error handling cases, otherwise it will cause
> memory leak.

Yep, thanks; applied.

johannes