date:20180518

Luis hasn't worked on ath.ko for some time now.

Acked-by: Luis R. Rodriguez 
Signed-off-by: Kalle Valo 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4be9ff892ec0..5dace1734086 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2330,7 +2330,7 @@ F:drivers/gpio/gpio-ath79.c
 F: Documentation/devicetree/bindings/gpio/gpio-ath79.txt
 
 ATHEROS ATH GENERIC UTILITIES
-M: "Luis R. Rodriguez" 
+M: Kalle Valo 
 L: linux-wireless@vger.kernel.org
 S: Supported
 F: drivers/net/wireless/ath/*
-- 
2.7.4

[PATCH 1/3] MAINTAINERS: update Kalle's email address

I switched to use my codeaurora.org address.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6d21f2f74578..4be9ff892ec0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2345,7 +2345,7 @@ S:Maintained
 F: drivers/net/wireless/ath/ath5k/
 
 ATHEROS ATH6KL WIRELESS DRIVER
-M: Kalle Valo 
+M: Kalle Valo 
 L: linux-wireless@vger.kernel.org
 W: http://wireless.kernel.org/en/users/Drivers/ath6kl
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
@@ -11651,7 +11651,7 @@ S:  Maintained
 F: drivers/media/tuners/qt1010*
 
 QUALCOMM ATHEROS ATH10K WIRELESS DRIVER
-M: Kalle Valo 
+M: Kalle Valo 
 L: ath...@lists.infradead.org
 W: http://wireless.kernel.org/en/users/Drivers/ath10k
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git
-- 
2.7.4

[PATCH 3/3] MAINTAINERS: change Kalle as wcn36xx maintainer

Eugene hasn't worked on wcn36xx for some time now.

Signed-off-by: Kalle Valo 
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 5dace1734086..c1b15dde5a46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11702,7 +11702,7 @@ S:  Maintained
 F: drivers/media/platform/qcom/venus/
 
 QUALCOMM WCN36XX WIRELESS DRIVER
-M: Eugene Krasnikov 
+M: Kalle Valo 
 L: wcn3...@lists.infradead.org
 W: http://wireless.kernel.org/en/users/Drivers/wcn36xx
 T: git git://github.com/KrasnikovEugene/wcn36xx.git
-- 
2.7.4

Re: [PATCH v3] NFC: pn533: don't send USB data off of the stack

2018-05-18 Thread Johan Hovold

On Fri, May 18, 2018 at 12:38:11PM +0200, Greg Kroah-Hartman wrote:
> It's amazing that this driver ever worked, but now that x86 doesn't
> allow USB data to be sent off of the stack, it really does not work at
> all.  Fix this up by properly allocating the data for the small
> "commands" that get sent to the device.
> 
> The USB stack will free the buffer when the data has been transmitted,
> that is why there is no kfree() to mirror the call to kmalloc().

It looks like you're now leaking all but the final transfer buffer that
is allocated for outgoing commands, as the URBs themselves are not freed
until disconnect() (and that's when core would free the buffers along
with the URBs if URB_FREE_BUFFER is set).

Johan

[mac80211-next:master 20/20] net/wireless/nl80211.c:4802:48: sparse: incorrect type in argument 1 (different base types)

2018-05-18 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   7ea3e110f2f8ba23f330c2f702f556acd539bcb8
commit: 7ea3e110f2f8ba23f330c2f702f556acd539bcb8 [20/20] cfg80211: release 
station info tidstats where needed
reproduce:
# apt-get install sparse
git checkout 7ea3e110f2f8ba23f330c2f702f556acd539bcb8
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> net/wireless/nl80211.c:4802:48: sparse: incorrect type in argument 1 
>> (different base types) @@expected struct station_info *sinfo @@got 
>> struct statiostruct station_info *sinfo @@
   net/wireless/nl80211.c:4802:48:expected struct station_info *sinfo
   net/wireless/nl80211.c:4802:48:got struct station_info [addressable] 
sinfo
   net/wireless/nl80211.c:7587:33: sparse: expression using sizeof(void)
   net/wireless/nl80211.c:7587:33: sparse: expression using sizeof(void)
   net/wireless/nl80211.c: In function 'nl80211_get_station':
   net/wireless/nl80211.c:4802:34: error: incompatible type for argument 1 of 
'cfg80211_sinfo_release_content'
  cfg80211_sinfo_release_content(sinfo);
 ^
   In file included from net/wireless/nl80211.c:24:0:
   include/net/cfg80211.h:5721:20: note: expected 'struct station_info *' but 
argument is of type 'struct station_info'
static inline void cfg80211_sinfo_release_content(struct station_info 
*sinfo)
   ^~

vim +4802 net/wireless/nl80211.c

  4776  
  4777  static int nl80211_get_station(struct sk_buff *skb, struct genl_info 
*info)
  4778  {
  4779  struct cfg80211_registered_device *rdev = info->user_ptr[0];
  4780  struct net_device *dev = info->user_ptr[1];
  4781  struct station_info sinfo;
  4782  struct sk_buff *msg;
  4783  u8 *mac_addr = NULL;
  4784  int err;
  4785  
  4786  memset(, 0, sizeof(sinfo));
  4787  
  4788  if (!info->attrs[NL80211_ATTR_MAC])
  4789  return -EINVAL;
  4790  
  4791  mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
  4792  
  4793  if (!rdev->ops->get_station)
  4794  return -EOPNOTSUPP;
  4795  
  4796  err = rdev_get_station(rdev, dev, mac_addr, );
  4797  if (err)
  4798  return err;
  4799  
  4800  msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
  4801  if (!msg) {
> 4802  cfg80211_sinfo_release_content(sinfo);
  4803  return -ENOMEM;
  4804  }
  4805  
  4806  if (nl80211_send_station(msg, NL80211_CMD_NEW_STATION,
  4807   info->snd_portid, info->snd_seq, 0,
  4808   rdev, dev, mac_addr, ) < 0) {
  4809  nlmsg_free(msg);
  4810  return -ENOBUFS;
  4811  }
  4812  
  4813  return genlmsg_reply(msg, info);
  4814  }
  4815  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

[PATCH] wireless-regdb: Fix comparison of WmmRule with NoneType in python 3

2018-05-18 Thread Seth Forshee

Python 3 gives errors as a result of the changes to add wmm
rules since Permission.wmmrule can be set to None:

 TypeError: '<' not supported between instances of 'WmmRule' and 'NoneType'

To fix this, supply compairson methods for WmmRule instead of
using the ones provided by attrs. Doing this means we also need
to supply a __hash__ method.

Signed-off-by: Seth Forshee 
---
 dbparse.py | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/dbparse.py b/dbparse.py
index 5cb8b3f13266..5fe752b4ff31 100755
--- a/dbparse.py
+++ b/dbparse.py
@@ -32,7 +32,7 @@ dfs_regions = {
 
 @total_ordering
 
-@attr.s(frozen=True)
+@attr.s(frozen=True, cmp=False)
 class WmmRule(object):
 vo_c = attr.ib()
 vi_c = attr.ib()
@@ -47,6 +47,22 @@ class WmmRule(object):
 return (self.vo_c, self.vi_c, self.be_c, self.bk_c,
 self.vo_ap, self.vi_ap, self.be_ap, self.bk_ap)
 
+def __eq__(self, other):
+if other is None:
+return False
+return (self._as_tuple() == other._as_tuple())
+
+def __ne__(self, other):
+return not (self == other)
+
+def __lt__(self, other):
+if other is None:
+return False
+return (self._as_tuple() < other._as_tuple())
+
+def __hash__(self):
+return hash(self._as_tuple())
+
 class FreqBand(object):
 def __init__(self, start, end, bw, comments=None):
 self.start = start
-- 
2.17.0

[PATCH] wireless-regdb: Update rules for Panama (PA) and add 60 GHz rule

2018-05-18 Thread Seth Forshee

Updates are based on the information in
http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf.

Signed-off-by: Seth Forshee 
---
 db.txt | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/db.txt b/db.txt
index ed461a35b770..e3bbd374d096 100644
--- a/db.txt
+++ b/db.txt
@@ -963,11 +963,15 @@ country OM: DFS-ETSI
(5250 - 5330 @ 80), (20), DFS, AUTO-BW
(5490 - 5710 @ 160), (27), DFS
 
+# Source:
+# http://www.asep.gob.pa/images/telecomunicaciones/Anexos/PNAF-dic2015.pdf
 country PA: DFS-FCC
-   (2402 - 2472 @ 40), (30)
-   (5170 - 5250 @ 80), (17), AUTO-BW
-   (5250 - 5330 @ 80), (23), DFS, AUTO-BW
-   (5735 - 5835 @ 80), (30)
+   (2400 - 2483.5 @ 40), (36)
+   (5150 - 5250 @ 80), (36), AUTO-BW
+   (5250 - 5350 @ 80), (30), AUTO-BW
+   (5470 - 5725 @ 160), (30)
+   (5725 - 5850 @ 80), (36)
+   (57000 - 64000 @ 2160), (43)
 
 country PE: DFS-FCC
(2402 - 2482 @ 40), (20)
-- 
2.17.0

[RFC 2/3] radiotap: add structs for HE

From: Luca Coelho 

Add radiotap structures for HE.

Signed-off-by: Liad Kaufman 
Signed-off-by: Johannes Berg 
Signed-off-by: Ilan Peer 
Signed-off-by: Ido Yariv 
Signed-off-by: Luca Coelho 
---
 include/net/ieee80211_radiotap.h | 111 +++
 1 file changed, 111 insertions(+)

diff --git a/include/net/ieee80211_radiotap.h b/include/net/ieee80211_radiotap.h
index 960236fb1681..2117b2cea598 100644
--- a/include/net/ieee80211_radiotap.h
+++ b/include/net/ieee80211_radiotap.h
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2017  Intel Deutschland GmbH
+ * Copyright (c) 2018  Intel Corporation
  *
  * Permission to use, copy, modify, and/or distribute this software for any
  * purpose with or without fee is hereby granted, provided that the above
@@ -72,6 +73,8 @@ enum ieee80211_radiotap_presence {
IEEE80211_RADIOTAP_AMPDU_STATUS = 20,
IEEE80211_RADIOTAP_VHT = 21,
IEEE80211_RADIOTAP_TIMESTAMP = 22,
+   IEEE80211_RADIOTAP_HE = 23,
+   IEEE80211_RADIOTAP_HE_MU = 24,
 
/* valid in every it_present bitmap, even vendor namespaces */
IEEE80211_RADIOTAP_RADIOTAP_NAMESPACE = 29,
@@ -202,6 +205,114 @@ enum ieee80211_radiotap_timestamp_flags {
IEEE80211_RADIOTAP_TIMESTAMP_FLAG_ACCURACY = 0x02,
 };
 
+struct ieee80211_radiotap_he {
+   __le16 data1, data2, data3, data4, data5, data6;
+};
+
+enum ieee80211_radiotap_he_bits {
+   IEEE80211_RADIOTAP_HE_DATA1_FORMAT_MASK = 3,
+   IEEE80211_RADIOTAP_HE_DATA1_FORMAT_SU   = 0,
+   IEEE80211_RADIOTAP_HE_DATA1_FORMAT_EXT_SU   = 1,
+   IEEE80211_RADIOTAP_HE_DATA1_FORMAT_MU   = 2,
+   IEEE80211_RADIOTAP_HE_DATA1_FORMAT_TRIG = 3,
+
+   IEEE80211_RADIOTAP_HE_DATA1_BSS_COLOR_KNOWN = 0x0004,
+   IEEE80211_RADIOTAP_HE_DATA1_BEAM_CHANGE_KNOWN   = 0x0008,
+   IEEE80211_RADIOTAP_HE_DATA1_UL_DL_KNOWN = 0x0010,
+   IEEE80211_RADIOTAP_HE_DATA1_DATA_MCS_KNOWN  = 0x0020,
+   IEEE80211_RADIOTAP_HE_DATA1_DATA_DCM_KNOWN  = 0x0040,
+   IEEE80211_RADIOTAP_HE_DATA1_CODING_KNOWN= 0x0080,
+   IEEE80211_RADIOTAP_HE_DATA1_LDPC_XSYMSEG_KNOWN  = 0x0100,
+   IEEE80211_RADIOTAP_HE_DATA1_STBC_KNOWN  = 0x0200,
+   IEEE80211_RADIOTAP_HE_DATA1_SPTL_REUSE_KNOWN= 0x0400,
+   IEEE80211_RADIOTAP_HE_DATA1_SPTL_REUSE2_KNOWN   = 0x0800,
+   IEEE80211_RADIOTAP_HE_DATA1_SPTL_REUSE3_KNOWN   = 0x1000,
+   IEEE80211_RADIOTAP_HE_DATA1_SPTL_REUSE4_KNOWN   = 0x2000,
+   IEEE80211_RADIOTAP_HE_DATA1_BW_RU_ALLOC_KNOWN   = 0x4000,
+   IEEE80211_RADIOTAP_HE_DATA1_DOPPLER_KNOWN   = 0x8000,
+
+   IEEE80211_RADIOTAP_HE_DATA2_PRISEC_80_KNOWN = 0x0001,
+   IEEE80211_RADIOTAP_HE_DATA2_GI_KNOWN= 0x0002,
+   IEEE80211_RADIOTAP_HE_DATA2_NUM_LTF_SYMS_KNOWN  = 0x0004,
+   IEEE80211_RADIOTAP_HE_DATA2_PRE_FEC_PAD_KNOWN   = 0x0008,
+   IEEE80211_RADIOTAP_HE_DATA2_TXBF_KNOWN  = 0x0010,
+   IEEE80211_RADIOTAP_HE_DATA2_PE_DISAMBIG_KNOWN   = 0x0020,
+   IEEE80211_RADIOTAP_HE_DATA2_TXOP_KNOWN  = 0x0040,
+   IEEE80211_RADIOTAP_HE_DATA2_MIDAMBLE_KNOWN  = 0x0080,
+   IEEE80211_RADIOTAP_HE_DATA2_RU_OFFSET   = 0x3f00,
+   IEEE80211_RADIOTAP_HE_DATA2_RU_OFFSET_KNOWN = 0x4000,
+   IEEE80211_RADIOTAP_HE_DATA2_PRISEC_80_SEC   = 0x8000,
+
+   IEEE80211_RADIOTAP_HE_DATA3_BSS_COLOR   = 0x003f,
+   IEEE80211_RADIOTAP_HE_DATA3_BEAM_CHANGE = 0x0040,
+   IEEE80211_RADIOTAP_HE_DATA3_UL_DL   = 0x0080,
+   IEEE80211_RADIOTAP_HE_DATA3_DATA_MCS= 0x0f00,
+   IEEE80211_RADIOTAP_HE_DATA3_DATA_DCM= 0x1000,
+   IEEE80211_RADIOTAP_HE_DATA3_CODING  = 0x2000,
+   IEEE80211_RADIOTAP_HE_DATA3_LDPC_XSYMSEG= 0x4000,
+   IEEE80211_RADIOTAP_HE_DATA3_STBC= 0x8000,
+
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC= 0x000f,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_20MHZ  = 0,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_40MHZ  = 1,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_80MHZ  = 2,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_160MHZ = 3,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_26T= 4,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_52T= 5,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_106T   = 6,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_242T   = 7,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_484T   = 8,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_996T   = 9,
+   IEEE80211_RADIOTAP_HE_DATA5_DATA_BW_RU_ALLOC_2x996T = 10,
+
+

[RFC 3/3] mac80211: add support for HE

From: Luca Coelho 

Add support for HE in mac80211 conforming with P802.11ax_D1.4.

Signed-off-by: Liad Kaufman 
Signed-off-by: Johannes Berg 
Signed-off-by: Ilan Peer 
Signed-off-by: Ido Yariv 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/realtek/rtlwifi/base.c |   2 +-
 include/net/mac80211.h  |  64 -
 net/mac80211/Makefile   |   1 +
 net/mac80211/agg-rx.c   |   8 +-
 net/mac80211/agg-tx.c   |  19 +-
 net/mac80211/cfg.c  |   5 +
 net/mac80211/he.c   |  55 
 net/mac80211/ieee80211_i.h  |  16 ++
 net/mac80211/main.c |  19 +-
 net/mac80211/mlme.c | 277 +++-
 net/mac80211/rx.c   | 127 -
 net/mac80211/sta_info.c |  15 +-
 net/mac80211/sta_info.h |  20 +-
 net/mac80211/trace.h|   2 +-
 net/mac80211/util.c | 120 -
 15 files changed, 709 insertions(+), 41 deletions(-)
 create mode 100644 net/mac80211/he.c

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 762a29cdf7ad..32b5aa754c24 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1859,7 +1859,7 @@ void rtl_rx_ampdu_apply(struct rtl_priv *rtlpriv)
 reject_agg, ctrl_agg_size, agg_size);
 
rtlpriv->hw->max_rx_aggregation_subframes =
-   (ctrl_agg_size ? agg_size : IEEE80211_MAX_AMPDU_BUF);
+   (ctrl_agg_size ? agg_size : IEEE80211_MAX_AMPDU_BUF_HT);
 }
 EXPORT_SYMBOL(rtl_rx_ampdu_apply);
 
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 52f36c43f35f..55fd3a574682 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 /**
@@ -162,6 +163,8 @@ enum ieee80211_ac_numbers {
  * @txop: maximum burst time in units of 32 usecs, 0 meaning disabled
  * @acm: is mandatory admission control required for the access category
  * @uapsd: is U-APSD mode enabled for the queue
+ * @mu_edca: is the MU EDCA configured
+ * @mu_edca_param_rec: MU EDCA Parameter Record for HE
  */
 struct ieee80211_tx_queue_params {
u16 txop;
@@ -170,6 +173,8 @@ struct ieee80211_tx_queue_params {
u8 aifs;
bool acm;
bool uapsd;
+   bool mu_edca;
+   struct ieee80211_he_mu_edca_param_ac_rec mu_edca_param_rec;
 };
 
 struct ieee80211_low_level_stats {
@@ -463,6 +468,15 @@ struct ieee80211_mu_group_data {
  * This structure keeps information about a BSS (and an association
  * to that BSS) that can change during the lifetime of the BSS.
  *
+ * @bss_color: 6-bit value to mark inter-BSS frame, if BSS supports HE
+ * @htc_trig_based_pkt_ext: default PE in 4us units, if BSS supports HE
+ * @multi_sta_back_32bit: supports BA bitmap of 32-bits in Multi-STA BACK
+ * @uora_exists: is the UORA element advertised by AP
+ * @ack_enabled_multitid: indicates support to receive a multi-TID that 
solicits
+ * either ACK, BACK or both
+ * @uora_ocw_range: UORA element's OCW Range field
+ * @frame_time_rts_th: HE duration RTS threshold, in units of 32us
+ * @he_support: does this BSS support HE
  * @assoc: association status
  * @ibss_joined: indicates whether this station is part of an IBSS
  * or not
@@ -550,6 +564,14 @@ struct ieee80211_mu_group_data {
  */
 struct ieee80211_bss_conf {
const u8 *bssid;
+   u8 bss_color;
+   u8 htc_trig_based_pkt_ext;
+   bool multi_sta_back_32bit;
+   bool uora_exists;
+   bool ack_enabled_multitid;
+   u8 uora_ocw_range;
+   u16 frame_time_rts_th;
+   bool he_support;
/* association related data */
bool assoc, ibss_joined;
bool ibss_creator;
@@ -1106,6 +1128,18 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info 
*info)
  * @RX_FLAG_AMPDU_EOF_BIT: Value of the EOF bit in the A-MPDU delimiter for 
this
  * frame
  * @RX_FLAG_AMPDU_EOF_BIT_KNOWN: The EOF value is known
+ * @RX_FLAG_RADIOTAP_HE: HE radiotap data is present
+ * ( ieee80211_radiotap_he, mac80211 will fill in
+ *  - DATA3_DATA_MCS
+ *  - DATA3_DATA_DCM
+ *  - DATA3_CODING
+ *  - DATA5_GI
+ *  - DATA5_DATA_BW_RU_ALLOC
+ *  - DATA6_NSTS
+ *  - DATA3_STBC
+ * from the RX info data, so leave those zeroed when building this data)
+ * @RX_FLAG_RADIOTAP_HE_MU: HE MU radiotap data is present
+ * ( ieee80211_radiotap_he_mu)
  */
 enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR  = BIT(0),
@@ -1134,6 +1168,8 @@ enum mac80211_rx_flags {
RX_FLAG_ICV_STRIPPED= BIT(23),

[RFC 1/3] cfg80211: Add support for HE

From: Luca Coelho 

Add support for the HE in cfg80211 and also add userspace API to
nl80211 to send rate information out, conforming with P802.11ax_D1.4.

Additionally, remove the IEEE80211_MAX_AMPDU_BUF definition from some
realtek drivers in staging because they are now conflicting with the
new definitions and are not used anyway.

Signed-off-by: Liad Kaufman 
Signed-off-by: Johannes Berg 
Signed-off-by: Ilan Peer 
Signed-off-by: Ido Yariv 
Signed-off-by: Luca Coelho 
---
 drivers/staging/rtl8188eu/include/wifi.h |   1 -
 drivers/staging/rtl8712/wifi.h   |   1 -
 drivers/staging/rtl8723bs/include/wifi.h |   1 -
 include/linux/ieee80211.h| 431 ++-
 include/net/cfg80211.h   | 102 +-
 include/uapi/linux/nl80211.h |  87 -
 net/wireless/core.c  |  21 +-
 net/wireless/nl80211.c   |  99 +-
 net/wireless/util.c  |  82 +
 9 files changed, 813 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index 084a246eec19..6790b7c8cfb1 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -575,7 +575,6 @@ enum ht_cap_ampdu_factor {
  * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
  */
 #define IEEE80211_MIN_AMPDU_BUF 0x8
-#define IEEE80211_MAX_AMPDU_BUF 0x40
 
 
 #define OP_MODE_PURE0
diff --git a/drivers/staging/rtl8712/wifi.h b/drivers/staging/rtl8712/wifi.h
index 0ed2f44ab4e9..00a4302e9983 100644
--- a/drivers/staging/rtl8712/wifi.h
+++ b/drivers/staging/rtl8712/wifi.h
@@ -574,7 +574,6 @@ struct ieee80211_ht_addt_info {
  * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
  */
 #define IEEE80211_MIN_AMPDU_BUF 0x8
-#define IEEE80211_MAX_AMPDU_BUF 0x40
 
 
 /* Spatial Multiplexing Power Save Modes */
diff --git a/drivers/staging/rtl8723bs/include/wifi.h 
b/drivers/staging/rtl8723bs/include/wifi.h
index 530d698f50d9..e6477acfa961 100644
--- a/drivers/staging/rtl8723bs/include/wifi.h
+++ b/drivers/staging/rtl8723bs/include/wifi.h
@@ -807,7 +807,6 @@ enum HT_CAP_AMPDU_FACTOR {
  * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
  */
 #define IEEE80211_MIN_AMPDU_BUF 0x8
-#define IEEE80211_MAX_AMPDU_BUF 0x40
 
 
 /* Spatial Multiplexing Power Save Modes */
diff --git a/include/linux/ieee80211.h b/include/linux/ieee80211.h
index 8fe7e4306816..7e1a650be329 100644
--- a/include/linux/ieee80211.h
+++ b/include/linux/ieee80211.h
@@ -1433,11 +1433,13 @@ struct ieee80211_ht_operation {
 #define IEEE80211_DELBA_PARAM_INITIATOR_MASK 0x0800
 
 /*
- * A-PMDU buffer sizes
- * According to IEEE802.11n spec size varies from 8K to 64K (in powers of 2)
+ * A-MPDU buffer sizes
+ * According to HT size varies from 8 to 64 frames
+ * HE adds the ability to have up to 256 frames.
  */
-#define IEEE80211_MIN_AMPDU_BUF 0x8
-#define IEEE80211_MAX_AMPDU_BUF 0x40
+#define IEEE80211_MIN_AMPDU_BUF0x8
+#define IEEE80211_MAX_AMPDU_BUF_HT 0x40
+#define IEEE80211_MAX_AMPDU_BUF0x100
 
 
 /* Spatial Multiplexing Power Save Modes (for capability) */
@@ -1539,6 +1541,106 @@ struct ieee80211_vht_operation {
__le16 basic_mcs_set;
 } __packed;
 
+/**
+ * struct ieee80211_he_cap_elem - HE capabilities element
+ *
+ * This structure is the "HE capabilities element" fixed fields as
+ * described in P802.11ax_D1.4 section 9.4.2.237.1
+ */
+struct ieee80211_he_cap_elem {
+   u8 mac_cap_info[5];
+   u8 phy_cap_info[9];
+} __packed;
+
+#define IEEE80211_TX_RX_MCS_NSS_DESC_MAX_LEN   5
+
+/**
+ * enum ieee80211_he_mcs_support - HE MCS support definitions
+ * @IEEE80211_HE_MCS_SUPPORT_0_7: MCSes 0-7 are supported for the
+ * number of streams
+ * @IEEE80211_HE_MCS_SUPPORT_0_9: MCSes 0-9 are supported
+ * @IEEE80211_HE_MCS_SUPPORT_0_11: MCSes 0-11 are supported
+ * @IEEE80211_HE_MCS_NOT_SUPPORTED: This number of streams isn't supported
+ *
+ * These definitions are used in each 2-bit subfield of the rx_mcs_*
+ * and tx_mcs_* fields of  ieee80211_he_mcs_nss_supp, which are
+ * both split into 8 subfields by number of streams. These values indicate
+ * which MCSes are supported for the number of streams the value appears
+ * for.
+ */
+enum ieee80211_he_mcs_support {
+   IEEE80211_HE_MCS_SUPPORT_0_7= 0,
+   IEEE80211_HE_MCS_SUPPORT_0_9= 1,
+   IEEE80211_HE_MCS_SUPPORT_0_11   = 2,
+   IEEE80211_HE_MCS_NOT_SUPPORTED  = 3,
+};
+
+/**
+ * struct ieee80211_he_mcs_nss_supp - HE Tx/Rx HE MCS NSS Support Field
+ *
+ * This structure holds the data required for the Tx/Rx HE MCS NSS Support 
Field
+ * described in P802.11ax_D1.4 section 9.4.2.237.4
+ *
+ * @rx_msc_80: Rx MCS map 2 bits for each

[RFC 0/3] cfg80211/mac80211: add support for IEEE802.11ax

From: Luca Coelho 

Hi,

This series contain a squashed version of our internal series of
patches that add support for IEEE802.11ax draft v1.4.  It is a
combination of over 40 patches, so I may have made some mistakes when
squashing and splitting parts of to the right place, thus I'm sending
as an RFC.

I split it into 3 different patches, as you can see, one with cfg80211
changes, one with radiotap changes and one with mac80211 changes.

Please review them and let me know if anything needs to be changed.
I've been rather sparse in the commit logs, so suggestions for
improvements are welcome.

Cheers,
Luca.


Luca Coelho (3):
  cfg80211: Add support for HE
  radiotap: add structs for HE
  mac80211: add support for HE

 drivers/net/wireless/realtek/rtlwifi/base.c |   2 +-
 drivers/staging/rtl8188eu/include/wifi.h|   1 -
 drivers/staging/rtl8712/wifi.h  |   1 -
 drivers/staging/rtl8723bs/include/wifi.h|   1 -
 include/linux/ieee80211.h   | 431 +++-
 include/net/cfg80211.h  | 102 -
 include/net/ieee80211_radiotap.h| 111 +
 include/net/mac80211.h  |  64 ++-
 include/uapi/linux/nl80211.h|  87 +++-
 net/mac80211/Makefile   |   1 +
 net/mac80211/agg-rx.c   |   8 +-
 net/mac80211/agg-tx.c   |  19 +-
 net/mac80211/cfg.c  |   5 +
 net/mac80211/he.c   |  55 +++
 net/mac80211/ieee80211_i.h  |  16 +
 net/mac80211/main.c |  19 +-
 net/mac80211/mlme.c | 277 -
 net/mac80211/rx.c   | 127 +-
 net/mac80211/sta_info.c |  15 +-
 net/mac80211/sta_info.h |  20 +-
 net/mac80211/trace.h|   2 +-
 net/mac80211/util.c | 120 +-
 net/wireless/core.c |  21 +-
 net/wireless/nl80211.c  |  99 -
 net/wireless/util.c |  82 
 25 files changed, 1633 insertions(+), 53 deletions(-)
 create mode 100644 net/mac80211/he.c

-- 
2.17.0

[mac80211-next:master 20/20] net/wireless/nl80211.c:4802:34: error: incompatible type for argument 1 of 'cfg80211_sinfo_release_content'

2018-05-18 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git 
master
head:   7ea3e110f2f8ba23f330c2f702f556acd539bcb8
commit: 7ea3e110f2f8ba23f330c2f702f556acd539bcb8 [20/20] cfg80211: release 
station info tidstats where needed
config: x86_64-randconfig-x004-201819 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
git checkout 7ea3e110f2f8ba23f330c2f702f556acd539bcb8
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   net/wireless/nl80211.c: In function 'nl80211_get_station':
>> net/wireless/nl80211.c:4802:34: error: incompatible type for argument 1 of 
>> 'cfg80211_sinfo_release_content'
  cfg80211_sinfo_release_content(sinfo);
 ^
   In file included from net/wireless/nl80211.c:24:0:
   include/net/cfg80211.h:5721:20: note: expected 'struct station_info *' but 
argument is of type 'struct station_info'
static inline void cfg80211_sinfo_release_content(struct station_info 
*sinfo)
   ^~

vim +/cfg80211_sinfo_release_content +4802 net/wireless/nl80211.c

  4776  
  4777  static int nl80211_get_station(struct sk_buff *skb, struct genl_info 
*info)
  4778  {
  4779  struct cfg80211_registered_device *rdev = info->user_ptr[0];
  4780  struct net_device *dev = info->user_ptr[1];
  4781  struct station_info sinfo;
  4782  struct sk_buff *msg;
  4783  u8 *mac_addr = NULL;
  4784  int err;
  4785  
  4786  memset(, 0, sizeof(sinfo));
  4787  
  4788  if (!info->attrs[NL80211_ATTR_MAC])
  4789  return -EINVAL;
  4790  
  4791  mac_addr = nla_data(info->attrs[NL80211_ATTR_MAC]);
  4792  
  4793  if (!rdev->ops->get_station)
  4794  return -EOPNOTSUPP;
  4795  
  4796  err = rdev_get_station(rdev, dev, mac_addr, );
  4797  if (err)
  4798  return err;
  4799  
  4800  msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
  4801  if (!msg) {
> 4802  cfg80211_sinfo_release_content(sinfo);
  4803  return -ENOMEM;
  4804  }
  4805  
  4806  if (nl80211_send_station(msg, NL80211_CMD_NEW_STATION,
  4807   info->snd_portid, info->snd_seq, 0,
  4808   rdev, dev, mac_addr, ) < 0) {
  4809  nlmsg_free(msg);
  4810  return -ENOBUFS;
  4811  }
  4812  
  4813  return genlmsg_reply(msg, info);
  4814  }
  4815  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac

2018-05-18 Thread Pkshih

On Wed, 2018-05-16 at 15:36 +0300, Kalle Valo wrote:
> Pkshih  writes:
> 
> > On Mon, 2018-04-30 at 14:03 +0530, Krishna Chaitanya wrote:
> >> On Mon, Apr 30, 2018 at 8:10 AM, Pkshih  wrote:
> >> >
> >> >
> >> > > -Original Message-
> >> > > From: Barry Day [mailto:brise...@gmail.com]
> >> > > Sent: Saturday, April 28, 2018 6:42 AM
> >> > > To: Pkshih
> >> > > Cc: Kalle Valo; larry.fin...@lwfinger.net; 
> >> > > linux-wireless@vger.kernel.org
> >> > > Subject: Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac
> >> > >
> >> > > On Fri, Apr 27, 2018 at 05:44:16AM +, Pkshih wrote:
> >> > > >
> >> > > > The registers reside in driver causes error frequently, because MAC 
> >> > > > register
> >> > > > is maintained by Realtek's MAC team so they create this module to 
> >> > > > avoid mistakes.
> >> > > > Another benefit is to make it possible to become a thin driver, 
> >> > > > because many
> >> > > > common functions are provided, so duplicate code will be reduced.
> >> > >
> >> > > How is it possible to create a thin driver by adding lots more code 
> >> > > and layers
> >> > > of indirection ??? and writing it in a way that it won't compile 
> >> > > without the
> >> > > code for every type of bus interface even though most modules only use 
> >> > > one ?
> >> > >
> >> > As I mentioned in first paragraph "(I use 'driver' in this mail 
> >> > indicates part of
> >> > rtlwifi excluded from this module.)". If this module was seen as a 
> >> > 'lib', rtl8822be
> >> > would be a "thin driver". For bus interface code, I need to add a way to 
> >> > compile
> >> > type of bus interface according to selected chip.
> >> >
> >> > > It's a horrible pile of garbage slapped together by an inexperienced
> >> > > programmer. Its a major deterrent for anyone looking at working on one 
> >> > > of
> >> > > the latest realtek drivers.
> >> > >
> >> > This module is designed to support multiple OS including Windows and 
> >> > Linux, and
> >> > many products have used this module and worked well. We hope Linux user 
> >> > can also
> >> > use Realtek's WiFi without additional installation if driver was built.
> >> > In order to submit this module to kernel upstream, we take a lot of 
> >> > effort
> >> > to fit Linux coding conventions (e.g. coding style), and explicit
> >> > suggestions will be helpful for us to continuously improve this module.
> >> 
> >> IMHO, this is a common use case for most organizations. I understand
> >> that Linux cannot
> >> accommodate other OSes requirements but is there an approved/recommended 
> >> way
> >> to upstream an OS agnostic driver? Agnostic drivers are generally
> >> bulkier compared to
> >> Linux-only drivers and also code organization is also different (to
> >> handle other OSes).
> >> 
> >
> > Hi Kalle,
> >
> > The state of this patchset was changed to RFC in patchwork, and I look at 
> > RFC's
> > meaning in wireless wiki. Do you expect that I will send v4?
> 
> Yes, I was expecting that you will submit v4 with proper documentation.
> I was supposed to send an email but forgot, sorry.
> 
> > If so, what do I need to fix in v4? Or, you need more description
> > about this module, please let me know. 
> 
> The biggest problem is that rtlwifi patches are way too big and which I
> don't think are ready for upstream, most of the time code quality is
> closer to the infamous "vendor drivers". This is causing me too much
> burden, even just reviewing and providing initial comments to rtlwifi
> patches take too much of my time. For example, I still haven't been able
> to check the rtlwifi btcoex patches from a month ago.
> 
> In principle I can use a minute or two per patch, anything longer than
> that and I can't keep up with the incoming patch flow. And with huge
> rtlwifi patchsets I usually need something more like an hour than few
> minutes.
> 
> I have said this also before, but more and more I'm thinking that
> rtlwifi is not really a proper upstream driver. I think staging would be
> a much better place for it and maybe a proper upstream realtek driver
> would be something based on rtl8xxxu? I dunno.
> 
> But we really need to find a solution for this as the current way with
> rtlwifi patches won't work in the long run.
> 

If we remove unused code and do proper modification (e.g. remove abstraction 
layer)
and submit to staging, but still remain the directory levels.
Will you accept halmac and submit it into upstream after being reviewed in 
staging?
Or, the only way you can accept is to remove the halmac directory and rearrange
the code and split it into the top level directory?

Regards,
PK

Re: [PATCH 00/10] Some more patches for wcn36xx

Daniel Mack  writes:

> On Wednesday, May 16, 2018 04:08 PM, Daniel Mack wrote:
>> Hence I believe that some sort of firmware internal buffer is overrun if
>> too many SMD requests fly in in a short amount of time. The firmware
>> does, however, still ack all packets just fine on the SMD channels, and
>> also the DXE communication flows are all healthy. No errors are reported
>> anywhere, but nothing is being put on the ether anymore.
>
> And FTR, there is a commit in the prima repository that caught my
> attention a while back:
>
>   https://source.codeaurora.org/external/wlan/prima/commit/?id=93cd8f3c
>
> What this does (through an remarkable number of indirection layers) is
> sending the DUMP_COMMAND_REQ command with args = (274, 0, 0, 0, 0)
> when management frames get stuck, which smells pretty much like the
> issue I'm seeing. Doing the same with the mainline driver and the
> debugfs interface it exposes doesn't have any effect though.
>
> But even if it did work, I wouldn't see a way to detect the situation
> in which this is needed reliably.

The firmware version might make a difference so I recommend always
mentioning the firmware version as well. For example, what if your
firmware does not support that command or parameter?

Also I would recommend to file a bug to bugzilla.kernel.org so that all
the information is one place and it can be easily updated. Now it's
pretty difficult to get the big picture from various emails on the list.

-- 
Kalle Valo

Re: [PATCH] ath10k: add dynamic vlan support

2018-05-18 Thread Sebastian Gottschall



Am 18.05.2018 um 11:54 schrieb Johannes Berg:

On Fri, 2018-05-04 at 12:20 +0530, Manikanta Pubbisetty wrote:

Johannes,

It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on
crypto controlled devices") has broken 4-addr operation on crypto
controlled devices as reported by sebastian.
The commit was mainly focused in addressing the problem in supporting
VLANs on crypto controlled devices but since 4-addr mode is also
dependent on AP_VLAN interface, this commit breaks the 4-addr AP mode.

Ok.

Do you know why it actually broke it? I mean, we should've turned off
the strict requirement for sw crypto control only for the GTK, and that
shouldn't matter so much?


I have couple of ideas on how to address the problem,

1) Add a new hw_flag and based on the hardware flag, allow/disallow the
creation of AP_VLAN interface.

+ * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
+ * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
+ * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
+ * operations in the BSS.

Based on the name and initial description, this sounds equivalent to
just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
would need some renaming.


2) Allow mac80211 to call set_key for GTKs on AP_VLAN interfaces for
crypto controlled devices, let the driver decide whether to return '1'
or some error code based on their support for transmitting sw encrypted
frames. I am little skeptical with this approach as drivers are totally
unaware of AP_VLAN interfaces.

No, that won't work.

I'm unsure how 4-addr VLAN can work with ath10k either way?

Maybe it just doesn't normally need a GTK, so nothing broke before, but
your other patch changed things to remove VLAN and then of course it's
no longer available?

But then I don't understand the complaint that

So maybe the solution should be to add a separate flag for whether or
not 4-addr VLAN is supported?

johannes


let me explain. the vlan mode is used to create local interfaces in 
4addr mode


like wlan0.sta0, wlan0.sta1 per peer. this is required to put these 
peers into the local linux bridge since the local ap interface cannot


handle the bridging capabilities like correct forwarding, stp or even 
filtering. this is a long term behaviour since the beginning of ath9k.


so the ap_vlan feature is used to pass the frames per peer in a 
indepenened way. you may ask felix fietkau, since he developed it 
originally in madwifi


and later in mac80211 / ath9k. so ap_vlan capability is a requiredment 
for all 4addr capable wireless drivers.



example of a 4addr capable ap in ath10k with 2 connected 4addr stations

root@apreithalle:~# brctl show
bridge name bridge id   STP enabled interfaces
br0 8000.dcef09e4ce07   no  ath0
    ath0.1
    ath0.2
    ath0.sta1
    ath0.sta4
    ath1
    ath1.2
    eth0
    eth1

Re: [PATCH 00/10] Some more patches for wcn36xx

2018-05-18 Thread Daniel Mack


On Wednesday, May 16, 2018 04:08 PM, Daniel Mack wrote:

Hence I believe that some sort of firmware internal buffer is overrun if
too many SMD requests fly in in a short amount of time. The firmware
does, however, still ack all packets just fine on the SMD channels, and
also the DXE communication flows are all healthy. No errors are reported
anywhere, but nothing is being put on the ether anymore.


And FTR, there is a commit in the prima repository that caught my 
attention a while back:


  https://source.codeaurora.org/external/wlan/prima/commit/?id=93cd8f3c

What this does (through an remarkable number of indirection layers) is 
sending the DUMP_COMMAND_REQ command with args = (274, 0, 0, 0, 0) when 
management frames get stuck, which smells pretty much like the issue I'm 
seeing. Doing the same with the mainline driver and the debugfs 
interface it exposes doesn't have any effect though.


But even if it did work, I wouldn't see a way to detect the situation in 
which this is needed reliably.



Daniel

Re: [PATCH] ath10k: add dynamic vlan support

2018-05-18 Thread Sebastian Gottschall




Am 18.05.2018 um 11:53 schrieb Johannes Berg:

On Mon, 2018-04-23 at 21:18 +0200, Sebastian Gottschall wrote:

this patch makes no sense at some points. AP_VLAN must be enabled always
(it is enabled by mac80211 by default, but is now disabled in very
latest git version for drivers which announce sw_crypto support)
if its disabled wds ap / wds sta operation will not work anymore since
mac80211 uses AP_VLAN for the local wds sta interfaces

You'd do you well to learn the correct terminology used in Linux if you
try to communicate with us...

What you say there makes no sense, WDS is a separate mode. Maybe you
mean 4-addr mode?
yes 4-addr mode which is common known as WDS mode. (terminology used by 
all sorts of vendors)


Sebastian


johannes

[PATCH v3] NFC: pn533: don't send USB data off of the stack

2018-05-18 Thread Greg Kroah-Hartman

It's amazing that this driver ever worked, but now that x86 doesn't
allow USB data to be sent off of the stack, it really does not work at
all.  Fix this up by properly allocating the data for the small
"commands" that get sent to the device.

The USB stack will free the buffer when the data has been transmitted,
that is why there is no kfree() to mirror the call to kmalloc().

Reported-by: Carlos Manuel Santos 
Cc: Samuel Ortiz 
Cc: Stephen Hemminger 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman 
---
v3: actually use the correct buffer (thanks to Arend van Spriel)
use kmemdup (thanks to Johannes Berg and Julia Lawall)
v2: set the urb flags correctly

 drivers/nfc/pn533/usb.c |   17 +++--
 1 file changed, 15 insertions(+), 2 deletions(-)

--- a/drivers/nfc/pn533/usb.c
+++ b/drivers/nfc/pn533/usb.c
@@ -150,10 +150,16 @@ static int pn533_usb_send_ack(struct pn5
struct pn533_usb_phy *phy = dev->phy;
static const u8 ack[6] = {0x00, 0x00, 0xff, 0x00, 0xff, 0x00};
/* spec 7.1.1.3:  Preamble, SoPC (2), ACK Code (2), Postamble */
+   char *buffer;
int rc;
 
-   phy->out_urb->transfer_buffer = (u8 *)ack;
+   buffer = kmemdup(ack, sizeof(ack), GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
+   phy->out_urb->transfer_buffer = buffer;
phy->out_urb->transfer_buffer_length = sizeof(ack);
+   phy->out_urb->transfer_flags |= URB_FREE_BUFFER;
rc = usb_submit_urb(phy->out_urb, flags);
 
return rc;
@@ -170,6 +176,7 @@ static int pn533_usb_send_frame(struct p
 
phy->out_urb->transfer_buffer = out->data;
phy->out_urb->transfer_buffer_length = out->len;
+   phy->out_urb->transfer_flags &= ~URB_FREE_BUFFER;
 
print_hex_dump_debug("PN533 TX: ", DUMP_PREFIX_NONE, 16, 1,
 out->data, out->len, false);
@@ -375,20 +382,26 @@ static int pn533_acr122_poweron_rdr(stru
/* Power on th reader (CCID cmd) */
u8 cmd[10] = {PN533_ACR122_PC_TO_RDR_ICCPOWERON,
  0, 0, 0, 0, 0, 0, 3, 0, 0};
+   char *buffer;
int rc;
void *cntx;
struct pn533_acr122_poweron_rdr_arg arg;
 
dev_dbg(>udev->dev, "%s\n", __func__);
 
+   buffer = kmemdup(cmd, sizeof(cmd), GFP_KERNEL);
+   if (!buffer)
+   return -ENOMEM;
+
init_completion();
cntx = phy->in_urb->context;  /* backup context */
 
phy->in_urb->complete = pn533_acr122_poweron_rdr_resp;
phy->in_urb->context = 
 
-   phy->out_urb->transfer_buffer = cmd;
+   phy->out_urb->transfer_buffer = buffer;
phy->out_urb->transfer_buffer_length = sizeof(cmd);
+   phy->out_urb->transfer_flags |= URB_FREE_BUFFER;
 
print_hex_dump_debug("ACR122 TX: ", DUMP_PREFIX_NONE, 16, 1,
   cmd, sizeof(cmd), false);

Re: [PATCH 2/2] cfg80211: release station info tidstats where needed

On Fri, 2018-05-18 at 12:25 +0200, Arend van Spriel wrote:
> On 5/18/2018 11:47 AM, Johannes Berg wrote:
> > From: Johannes Berg 
> > 
> > This fixes memory leaks in cases where we got the station
> > info but failed sending it out properly.
> 
> Reviewed-by: Arend van Spriel 
> > Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for 
> > station info")
> > Signed-off-by: Johannes Berg 
> > ---
> >   include/net/cfg80211.h | 13 +
> >   net/wireless/nl80211.c | 11 ---
> >   2 files changed, 21 insertions(+), 3 deletions(-)
> > 
> > diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
> > index 8984d24d68b7..1c6364591856 100644
> > --- a/include/net/cfg80211.h
> > +++ b/include/net/cfg80211.h
> > @@ -5710,6 +5710,19 @@ void cfg80211_remain_on_channel_expired(struct 
> > wireless_dev *wdev, u64 cookie,
> >*/
> >   int cfg80211_sinfo_alloc_tid_stats(struct station_info *sinfo, gfp_t gfp);
> > 
> > +/**
> > + * cfg80211_sinfo_release_sinfo - release contents of station info
> 
> Maybe drop one '_sinfo' from the function name? Or 
> cfg80211_sinfo_release_contents?

Heh. I guess I wasn't paying attention, I like _content()

johannes

[PATCH v2] wcn36xx: Add support for Factory Test Mode (FTM)

2018-05-18 Thread Ramon Fried

From: Eyal Ilsar 

Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.

The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets

Signed-off-by: Eyal Ilsar 
Signed-off-by: Ramon Fried 
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.

 drivers/net/wireless/ath/wcn36xx/Makefile |   2 +
 drivers/net/wireless/ath/wcn36xx/hal.h|  16 ++
 drivers/net/wireless/ath/wcn36xx/main.c   |   3 +
 drivers/net/wireless/ath/wcn36xx/smd.c|  81 ++
 drivers/net/wireless/ath/wcn36xx/smd.h|   4 +
 drivers/net/wireless/ath/wcn36xx/testmode.c   | 151 ++
 drivers/net/wireless/ath/wcn36xx/testmode.h   |  46 ++
 drivers/net/wireless/ath/wcn36xx/testmode_i.h |  29 
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h|   2 +
 9 files changed, 334 insertions(+)
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
 create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h

diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile 
b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y +=   main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h 
b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
 
 } __packed;
 
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* Actual FTM Command body */
+   u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+   struct wcn36xx_hal_msg_header header;
+
+   /* FTM Command response status */
+   u32 ptt_msg_resp_status;
+   /* Actual FTM Command body */
+   u8 ptt_msg[0];
+} __packed;
+
 struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
 
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include "wcn36xx.h"
+#include "testmode.h"
 
 unsigned int wcn36xx_dbg_mask;
 module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add= wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action   = wcn36xx_ampdu_action,
+
+   CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
 };
 
 static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header 
*hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
 
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+   do { \
+   memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+   p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+   p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+   p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+   } while (0)
+
 #define PREPARE_HAL_BUF(send_buf, msg_body) \
do {\
memset(send_buf, 0, msg_body.header.len);   \
memcpy(send_buf, _body, sizeof(msg_body));  \
} while (0) \
 
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+   do {\
+   memset(send_buf, 0, p_msg_body->header.len); \
+   memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+   } while (0)
+
 static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)

Re: [PATCH 2/2] cfg80211: release station info tidstats where needed

2018-05-18 Thread Arend van Spriel


On 5/18/2018 11:47 AM, Johannes Berg wrote:

From: Johannes Berg 

This fixes memory leaks in cases where we got the station
info but failed sending it out properly.


Reviewed-by: Arend van Spriel 

Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station 
info")
Signed-off-by: Johannes Berg 
---
  include/net/cfg80211.h | 13 +
  net/wireless/nl80211.c | 11 ---
  2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8984d24d68b7..1c6364591856 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5710,6 +5710,19 @@ void cfg80211_remain_on_channel_expired(struct 
wireless_dev *wdev, u64 cookie,
   */
  int cfg80211_sinfo_alloc_tid_stats(struct station_info *sinfo, gfp_t gfp);

+/**
+ * cfg80211_sinfo_release_sinfo - release contents of station info


Maybe drop one '_sinfo' from the function name? Or 
cfg80211_sinfo_release_contents?


Regards,
Arend

Re: [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)

2018-05-18 Thread Ramon Fried

On 17 May 2018 at 21:37, Jeff Johnson  wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar 
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> +   struct ieee80211_vif *vif, void *ptt_msg,
>> size_t len,
>> +   void **ptt_rsp_msg)
>> +{
>> +   struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
>> +   int ret = 0;
>> +
>> +   mutex_lock(>hal_mutex);
>> +   p_msg_body = kmalloc(
>> +   sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
>> +   GFP_ATOMIC);
>
>
> NULL check required?
>
>> +   INIT_HAL_PTT_MSG(p_msg_body, len);
>> +

Thanks Jeff. will fix it and send again :)

Re: [PATCH] ath10k: add dynamic vlan support

On Fri, 2018-05-04 at 12:20 +0530, Manikanta Pubbisetty wrote:
> Johannes,
> 
> It seems like commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on 
> crypto controlled devices") has broken 4-addr operation on crypto 
> controlled devices as reported by sebastian.
> The commit was mainly focused in addressing the problem in supporting 
> VLANs on crypto controlled devices but since 4-addr mode is also 
> dependent on AP_VLAN interface, this commit breaks the 4-addr AP mode.

Ok.

Do you know why it actually broke it? I mean, we should've turned off
the strict requirement for sw crypto control only for the GTK, and that
shouldn't matter so much?

> I have couple of ideas on how to address the problem,
> 
> 1) Add a new hw_flag and based on the hardware flag, allow/disallow the 
> creation of AP_VLAN interface.
> 
> + * @IEEE80211_HW_SUPPORTS_SW_ENCRYPT: Device is capable of transmitting
> + * frames encrypted in software, only valid when SW_CRYPTO_CONTROL
> + * is enabled. Based on this flag, mac80211 can allow/disallow VLAN
> + * operations in the BSS.

Based on the name and initial description, this sounds equivalent to
just turning off SW_CRYPTO_CONTROL. I think that's not the intent, but
would need some renaming.

> 2) Allow mac80211 to call set_key for GTKs on AP_VLAN interfaces for 
> crypto controlled devices, let the driver decide whether to return '1' 
> or some error code based on their support for transmitting sw encrypted 
> frames. I am little skeptical with this approach as drivers are totally 
> unaware of AP_VLAN interfaces.

No, that won't work.

I'm unsure how 4-addr VLAN can work with ath10k either way?

Maybe it just doesn't normally need a GTK, so nothing broke before, but
your other patch changed things to remove VLAN and then of course it's
no longer available?

But then I don't understand the complaint that 

So maybe the solution should be to add a separate flag for whether or
not 4-addr VLAN is supported?

johannes

Re: [PATCH] ath10k: add dynamic vlan support

On Mon, 2018-04-23 at 21:18 +0200, Sebastian Gottschall wrote:
> this patch makes no sense at some points. AP_VLAN must be enabled always 
> (it is enabled by mac80211 by default, but is now disabled in very 
> latest git version for drivers which announce sw_crypto support)
> if its disabled wds ap / wds sta operation will not work anymore since 
> mac80211 uses AP_VLAN for the local wds sta interfaces

You'd do you well to learn the correct terminology used in Linux if you
try to communicate with us...

What you say there makes no sense, WDS is a separate mode. Maybe you
mean 4-addr mode?

johannes

[PATCH 1/2] mac80211: allocate and fill tidstats only when needed

From: Johannes Berg 

This fixes memory leaks in the case where we just have the
station info on the stack for internal usage without sending
it to cfg80211.

Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station 
info")
Signed-off-by: Johannes Berg 
---
 net/mac80211/cfg.c  | 4 ++--
 net/mac80211/ethtool.c  | 4 ++--
 net/mac80211/sta_info.c | 7 ---
 net/mac80211/sta_info.h | 3 ++-
 4 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 5ce9d121af2b..bdf6fa78d0d2 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -695,7 +695,7 @@ static int ieee80211_dump_station(struct wiphy *wiphy, 
struct net_device *dev,
if (sta) {
ret = 0;
memcpy(mac, sta->sta.addr, ETH_ALEN);
-   sta_set_sinfo(sta, sinfo);
+   sta_set_sinfo(sta, sinfo, true);
}
 
mutex_unlock(>sta_mtx);
@@ -724,7 +724,7 @@ static int ieee80211_get_station(struct wiphy *wiphy, 
struct net_device *dev,
sta = sta_info_get_bss(sdata, mac);
if (sta) {
ret = 0;
-   sta_set_sinfo(sta, sinfo);
+   sta_set_sinfo(sta, sinfo, true);
}
 
mutex_unlock(>sta_mtx);
diff --git a/net/mac80211/ethtool.c b/net/mac80211/ethtool.c
index 2ba5686cbcab..690c142a7a44 100644
--- a/net/mac80211/ethtool.c
+++ b/net/mac80211/ethtool.c
@@ -108,7 +108,7 @@ static void ieee80211_get_stats(struct net_device *dev,
goto do_survey;
 
memset(, 0, sizeof(sinfo));
-   sta_set_sinfo(sta, );
+   sta_set_sinfo(sta, , false);
 
i = 0;
ADD_STA_STATS(sta);
@@ -135,7 +135,7 @@ static void ieee80211_get_stats(struct net_device *dev,
continue;
 
memset(, 0, sizeof(sinfo));
-   sta_set_sinfo(sta, );
+   sta_set_sinfo(sta, , false);
i = 0;
ADD_STA_STATS(sta);
}
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 04d47689b557..6428f1ac37b6 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -1008,7 +1008,7 @@ static void __sta_info_destroy_part2(struct sta_info *sta)
 
sinfo = kzalloc(sizeof(*sinfo), GFP_KERNEL);
if (sinfo)
-   sta_set_sinfo(sta, sinfo);
+   sta_set_sinfo(sta, sinfo, true);
cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL);
kfree(sinfo);
 
@@ -2079,7 +2079,8 @@ static inline u64 sta_get_stats_bytes(struct 
ieee80211_sta_rx_stats *rxstats)
return value;
 }
 
-void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
+void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,
+  bool tidstats)
 {
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
@@ -2233,7 +2234,7 @@ void sta_set_sinfo(struct sta_info *sta, struct 
station_info *sinfo)
sinfo->filled |= BIT(NL80211_STA_INFO_RX_BITRATE);
}
 
-   if (!cfg80211_sinfo_alloc_tid_stats(sinfo, GFP_KERNEL)) {
+   if (tidstats && !cfg80211_sinfo_alloc_tid_stats(sinfo, GFP_KERNEL)) {
for (i = 0; i < IEEE80211_NUM_TIDS + 1; i++) {
struct cfg80211_tid_stats *tidstats = >pertid[i];
 
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index d79bd6eeb549..81b35f623792 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -744,7 +744,8 @@ static inline int sta_info_flush(struct 
ieee80211_sub_if_data *sdata)
 void sta_set_rate_info_tx(struct sta_info *sta,
  const struct ieee80211_tx_rate *rate,
  struct rate_info *rinfo);
-void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo);
+void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo,
+  bool tidstats);
 
 u32 sta_get_expected_throughput(struct sta_info *sta);
 
-- 
2.14.3

[PATCH 2/2] cfg80211: release station info tidstats where needed

From: Johannes Berg 

This fixes memory leaks in cases where we got the station
info but failed sending it out properly.

Fixes: 8689c051a201 ("cfg80211: dynamically allocate per-tid stats for station 
info")
Signed-off-by: Johannes Berg 
---
 include/net/cfg80211.h | 13 +
 net/wireless/nl80211.c | 11 ---
 2 files changed, 21 insertions(+), 3 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 8984d24d68b7..1c6364591856 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -5710,6 +5710,19 @@ void cfg80211_remain_on_channel_expired(struct 
wireless_dev *wdev, u64 cookie,
  */
 int cfg80211_sinfo_alloc_tid_stats(struct station_info *sinfo, gfp_t gfp);
 
+/**
+ * cfg80211_sinfo_release_sinfo - release contents of station info
+ * @sinfo: the station information
+ *
+ * Releases any potentially allocated sub-information of the station
+ * information, but not the struct itself (since it's typically on
+ * the stack.)
+ */
+static inline void cfg80211_sinfo_release_sinfo(struct station_info *sinfo)
+{
+   kfree(sinfo->pertid);
+}
+
 /**
  * cfg80211_new_sta - notify userspace about station
  *
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 7daceb1f253d..0996fdc002e0 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -4702,7 +4702,6 @@ static int nl80211_send_station(struct sk_buff *msg, u32 
cmd, u32 portid,
}
 
nla_nest_end(msg, tidsattr);
-   kfree(sinfo->pertid);
}
 
nla_nest_end(msg, sinfoattr);
@@ -4712,10 +4711,12 @@ static int nl80211_send_station(struct sk_buff *msg, 
u32 cmd, u32 portid,
sinfo->assoc_req_ies))
goto nla_put_failure;
 
+   cfg80211_sinfo_release_sinfo(sinfo);
genlmsg_end(msg, hdr);
return 0;
 
  nla_put_failure:
+   cfg80211_sinfo_release_sinfo(sinfo);
genlmsg_cancel(msg, hdr);
return -EMSGSIZE;
 }
@@ -4797,8 +4798,10 @@ static int nl80211_get_station(struct sk_buff *skb, 
struct genl_info *info)
return err;
 
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, GFP_KERNEL);
-   if (!msg)
+   if (!msg) {
+   cfg80211_sinfo_release_sinfo(sinfo);
return -ENOMEM;
+   }
 
if (nl80211_send_station(msg, NL80211_CMD_NEW_STATION,
 info->snd_portid, info->snd_seq, 0,
@@ -14624,8 +14627,10 @@ void cfg80211_del_sta_sinfo(struct net_device *dev, 
const u8 *mac_addr,
trace_cfg80211_del_sta(dev, mac_addr);
 
msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
-   if (!msg)
+   if (!msg) {
+   cfg80211_sinfo_release_sinfo(sinfo);
return;
+   }
 
if (nl80211_send_station(msg, NL80211_CMD_DEL_STATION, 0, 0, 0,
 rdev, dev, mac_addr, sinfo) < 0) {
-- 
2.14.3

Re: [PATCH V3 0/5] Update brcm firmware files

2018-05-18 Thread Hans de Goede

Hi,

On 18-05-18 11:00, Arend van Spriel wrote:

On 5/18/2018 9:04 AM, Hans de Goede wrote:

Hi,

On 15-05-18 10:43, Arend van Spriel wrote:

On 5/14/2018 2:05 PM, Josh Boyer wrote:

n Mon, May 14, 2018 at 6:11 AM Arend van Spriel <
arend.vanspr...@broadcom.com> wrote:

On 3/16/2018 3:08 PM, Chi-Hsien Lin wrote:

Update brcm firmware files and WHENCE accordingly.

Hi firmware-maintainers,

It seems this series somehow got lost. Can these still be applied. They
can be found in the linux-wireless patchwork database. I provided links
below.

All 5 of these move the respective firmware files under the Cypress
license. It has been pointed out that the Cypress license has some
questionable language in it and that people have been in touch to try
and
get this resolved. I'm personally waiting on applying them until the
licence issue is sorted out.

Thanks, Josh

I could not find any such response. Has it been taken off-list? Seems
like 2 months is quite some time, but maybe there are lawyers involved
;-)

Yes the discussion about this has been happening off-list. IANAL but
the gist of it is (AFAIK) that:

https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.cypress

has a clause which allows Cypress to retro-actively revoke the LICENSE:

"either party may terminate this Agreement at any time with or without
cause."
...
"Upon termination, you must destroy all copies of Software in your
possession or
control."

So upon revokation we would have to remove the files from linux-firmware
(rewrite git history?) and since distros get their redistribution rights
from this license too they would also need to remove it from their packages
including all mirrors and archives of older versions. Which simply is not
feasible and no other license in linux-firmware has such a clause.

Check again. From LICENCE.broadcom_bcm43xx:

"""
2. Restrictions. Licensee shall distribute Software with a copy of this
Agreement. Licensee shall not remove, efface or obscure any copyright or
trademark notices from the Software. Reproductions of the Broadcom copyright
notice shall be included with each copy of the Software, except where such
Software is embedded in a manner not readily accessible to the end user.
Licensee shall not: (i) use, license, sell or otherwise distribute the Software
except as provided in this Agreement; (ii) attempt to modify in any way,
reverse engineer, decompile or disassemble any portion of the Software; or
(iii) use the Software or other material in violation of any applicable law or
regulation, including but not limited to any regulatory agency. This Agreement
shall automatically terminate upon Licensee\u2019s failure to comply with any
of the
terms of this Agreement. In such event, Licensee will destroy all copies of the
Software and its component parts.
"""

That has the "destroy all copies of (the) Software" language, but the entire
file does not have anything equivalent to: "either party may terminate this
Agreement
at any time with or without cause.". So as long as we abide by the license
terms,
the LICENCE.broadcom_bcm43xx license will never terminate and the
"destroy all copies of (the) Software" language is not a problem.

The main problem is the "either party may terminate this Agreement at any time
with or without cause." language in the Cypress license. Note IANAL and TINLA.

Regards,

Hans

Re: [RESEND PATCH] cfg80211: dynamically allocate per-tid stats for station info