[PATCH] rfkill: fix rfkill_fop_read wait_event usage

[Johannes Berg]

From: Johannes Berg 

The code within wait_event_interruptible() is called with
!TASK_RUNNING, so mustn't call any functions that can sleep,
like mutex_lock().

Since we re-check the list_empty() in a loop after the wait,
it's safe to simply use list_empty() without locking.

This bug has existed forever, but was only discovered now
because all userspace implementations, including the default
'rfkill' tool, use poll() or select() to get a readable fd
before attempting to read.

Cc: sta...@vger.kernel.org
Fixes: c64fb01627e24 ("rfkill: create useful userspace interface")
Reported-by: Dmitry Vyukov 
Signed-off-by: Johannes Berg 
---
 net/rfkill/core.c | 16 
 1 file changed, 4 insertions(+), 12 deletions(-)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f53bf3b6558b..cf5b69ab1829 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1095,17 +1095,6 @@ static unsigned int rfkill_fop_poll(struct file *file, 
poll_table *wait)
return res;
 }
 
-static bool rfkill_readable(struct rfkill_data *data)
-{
-   bool r;
-
-   mutex_lock(>mtx);
-   r = !list_empty(>events);
-   mutex_unlock(>mtx);
-
-   return r;
-}
-
 static ssize_t rfkill_fop_read(struct file *file, char __user *buf,
   size_t count, loff_t *pos)
 {
@@ -1122,8 +,11 @@ static ssize_t rfkill_fop_read(struct file *file, char 
__user *buf,
goto out;
}
mutex_unlock(>mtx);
+   /* since we re-check and it just compares pointers,
+* using !list_empty() without locking isn't a problem
+*/
ret = wait_event_interruptible(data->read_wait,
-  rfkill_readable(data));
+  !list_empty(>events));
mutex_lock(>mtx);
 
if (ret)
-- 
2.6.2

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

[PATCH 2/5] iwlwifi: add device ID for 8265

[Emmanuel Grumbach]

From: Oren Givon 

Signed-off-by: Oren Givon 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
index 944e88a..00335ea 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c
@@ -478,6 +478,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = {
{IWL_PCI_DEVICE(0x24F3, 0x, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x0010, iwl8265_2ac_cfg)},
{IWL_PCI_DEVICE(0x24FD, 0x8010, iwl8265_2ac_cfg)},
+   {IWL_PCI_DEVICE(0x24FD, 0x0810, iwl8265_2ac_cfg)},
 
 /* 9000 Series */
{IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl5165_2ac_cfg)},
-- 
2.5.0

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

[PATCH 5/5] iwlwifi: mvm: rs: fix TPC statistics handling

[Emmanuel Grumbach]

From: Gregory Greenman 

FW behaviour changed and now updates driver about the used TPC
reduction in the following cases:
1. In tx response, which is used mostly for a single frame case
2. In BA notification

When tx aggregation fails with the initial rate, FW will send
to the driver BA notification and will try to transmit with the
next rate, but this time without tx power reduction. Thus, in case
of a failure with the initial rate, driver will get two BA notifications,
the first one with reduced tx power as in the LQ command and the second
one with 0 power reduction.

This patch adapts the TPC statistics according to the description above:
1. Use BA notifications instead of Tx response
2. For TPC only, drop the optimization which considers empty BA as one
MPDU. The reason is that with TPC we want to recover very quickly from
a bad power reduction and, therefore we'd like the success ratio to get
an immediate hit when failing to get a BA, so we'd switch back to a
lower or zero power reduction

Signed-off-by: Gregory Greenman 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h |  6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 74 ++
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  5 +-
 3 files changed, 56 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h 
b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
index 0036d18..ba3f0bb 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h
@@ -510,6 +510,9 @@ struct iwl_mvm_tx_resp {
  * @scd_ssn: the index of the last contiguously sent packet
  * @txed: number of Txed frames in this batch
  * @txed_2_done: number of Acked frames in this batch
+ * @reduced_txp: power reduced according to TPC. This is the actual value and
+ * not a copy from the LQ command. Thus, if not the first rate was used
+ * for Tx-ing then this value will be set to 0 by FW.
  */
 struct iwl_mvm_ba_notif {
__le32 sta_addr_lo32;
@@ -524,7 +527,8 @@ struct iwl_mvm_ba_notif {
__le16 scd_ssn;
u8 txed;
u8 txed_2_done;
-   __le16 reserved1;
+   u8 reduced_txp;
+   u8 reserved1;
 } __packed;
 
 /*
diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
index 7bb6fd0..94caa88 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c
@@ -2,6 +2,7 @@
  *
  * Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved.
  * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
+ * Copyright(c) 2016 Intel Deutschland GmbH
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms of version 2 of the GNU General Public License as
@@ -724,14 +725,28 @@ static int _rs_collect_tx_data(struct iwl_mvm *mvm,
return 0;
 }
 
-static int rs_collect_tx_data(struct iwl_mvm *mvm,
- struct iwl_lq_sta *lq_sta,
- struct iwl_scale_tbl_info *tbl,
- int scale_index, int attempts, int successes,
- u8 reduced_txp)
+static int rs_collect_tpc_data(struct iwl_mvm *mvm,
+  struct iwl_lq_sta *lq_sta,
+  struct iwl_scale_tbl_info *tbl,
+  int scale_index, int attempts, int successes,
+  u8 reduced_txp)
+{
+   struct iwl_rate_scale_data *window = NULL;
+
+   if (WARN_ON_ONCE(reduced_txp > TPC_MAX_REDUCTION))
+   return -EINVAL;
+
+   window = >tpc_win[reduced_txp];
+   return  _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes,
+   window);
+}
+
+static int rs_collect_tlc_data(struct iwl_mvm *mvm,
+  struct iwl_lq_sta *lq_sta,
+  struct iwl_scale_tbl_info *tbl,
+  int scale_index, int attempts, int successes)
 {
struct iwl_rate_scale_data *window = NULL;
-   int ret;
 
if (scale_index < 0 || scale_index >= IWL_RATE_COUNT)
return -EINVAL;
@@ -745,16 +760,6 @@ static int rs_collect_tx_data(struct iwl_mvm *mvm,
 
/* Select window for current tx bit rate */
window = &(tbl->win[scale_index]);
-
-   ret = _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes,
- window);
-   if (ret)
-   return ret;
-
-   if (WARN_ON_ONCE(reduced_txp > TPC_MAX_REDUCTION))
-   return -EINVAL;
-
-   window = >tpc_win[reduced_txp];
return _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes,
   window);
 }
@@ -1301,17 +1306,30 @@ 

[PATCH 4/5] iwlwifi: update support for 3168 series firmware and NVM

[Emmanuel Grumbach]

From: Oren Givon 

Update the struct which defines the support for 3168 cards.
Now it will search for a firmware of this format:
iwlwifi-3168-XX.ucode
Also, set the minimum version of the ucode to 20.
Update the minimum NVM version and minimum NVM calibrations
version of the 3168 series.

Signed-off-by: Oren Givon 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-7000.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-7000.c
index e60cf14..fa41a5e 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-7000.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-7000.c
@@ -74,16 +74,19 @@
 #define IWL7260_UCODE_API_MAX  17
 #define IWL7265_UCODE_API_MAX  17
 #define IWL7265D_UCODE_API_MAX 20
+#define IWL3168_UCODE_API_MAX  20
 
 /* Oldest version we won't warn about */
 #define IWL7260_UCODE_API_OK   13
 #define IWL7265_UCODE_API_OK   13
 #define IWL7265D_UCODE_API_OK  13
+#define IWL3168_UCODE_API_OK   20
 
 /* Lowest firmware API version supported */
 #define IWL7260_UCODE_API_MIN  13
 #define IWL7265_UCODE_API_MIN  13
 #define IWL7265D_UCODE_API_MIN 13
+#define IWL3168_UCODE_API_MIN  20
 
 /* NVM versions */
 #define IWL7260_NVM_VERSION0x0a1d
@@ -92,6 +95,8 @@
 #define IWL3160_TX_POWER_VERSION   0x /* meaningless */
 #define IWL3165_NVM_VERSION0x709
 #define IWL3165_TX_POWER_VERSION   0x /* meaningless */
+#define IWL3168_NVM_VERSION0xd01
+#define IWL3168_TX_POWER_VERSION   0x /* meaningless */
 #define IWL7265_NVM_VERSION0x0a1d
 #define IWL7265_TX_POWER_VERSION   0x /* meaningless */
 #define IWL7265D_NVM_VERSION   0x0c11
@@ -109,6 +114,9 @@
 #define IWL3160_FW_PRE "iwlwifi-3160-"
 #define IWL3160_MODULE_FIRMWARE(api) IWL3160_FW_PRE __stringify(api) ".ucode"
 
+#define IWL3168_FW_PRE "iwlwifi-3168-"
+#define IWL3168_MODULE_FIRMWARE(api) IWL3168_FW_PRE __stringify(api) ".ucode"
+
 #define IWL7265_FW_PRE "iwlwifi-7265-"
 #define IWL7265_MODULE_FIRMWARE(api) IWL7265_FW_PRE __stringify(api) ".ucode"
 
@@ -180,6 +188,12 @@ static const struct iwl_ht_params iwl7000_ht_params = {
.ucode_api_ok = IWL7265_UCODE_API_OK,   \
.ucode_api_min = IWL7265_UCODE_API_MIN
 
+#define IWL_DEVICE_3008\
+   IWL_DEVICE_7000_COMMON, \
+   .ucode_api_max = IWL3168_UCODE_API_MAX, \
+   .ucode_api_ok = IWL3168_UCODE_API_OK,   \
+   .ucode_api_min = IWL3168_UCODE_API_MIN
+
 #define IWL_DEVICE_7005D   \
IWL_DEVICE_7000_COMMON, \
.ucode_api_max = IWL7265D_UCODE_API_MAX,\
@@ -299,11 +313,11 @@ const struct iwl_cfg iwl3165_2ac_cfg = {
 
 const struct iwl_cfg iwl3168_2ac_cfg = {
.name = "Intel(R) Dual Band Wireless AC 3168",
-   .fw_name_pre = IWL7265D_FW_PRE,
-   IWL_DEVICE_7000,
+   .fw_name_pre = IWL3168_FW_PRE,
+   IWL_DEVICE_3008,
.ht_params = _ht_params,
-   .nvm_ver = IWL3165_NVM_VERSION,
-   .nvm_calib_ver = IWL3165_TX_POWER_VERSION,
+   .nvm_ver = IWL3168_NVM_VERSION,
+   .nvm_calib_ver = IWL3168_TX_POWER_VERSION,
.pwr_tx_backoffs = iwl7265_pwr_tx_backoffs,
.dccm_len = IWL7265_DCCM_LEN,
 };
@@ -376,5 +390,6 @@ const struct iwl_cfg iwl7265d_n_cfg = {
 
 MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
 MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL7260_UCODE_API_OK));
+MODULE_FIRMWARE(IWL3168_MODULE_FIRMWARE(IWL3168_UCODE_API_OK));
 MODULE_FIRMWARE(IWL7265_MODULE_FIRMWARE(IWL7265_UCODE_API_OK));
 MODULE_FIRMWARE(IWL7265D_MODULE_FIRMWARE(IWL7265D_UCODE_API_OK));
-- 
2.5.0

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

[PATCH 3/5] iwlwifi: dvm: calib.c: fix min() warning

[Emmanuel Grumbach]

From: Johannes Berg 

Depending on the system, kernel, architecture abs() might
return long or not - just use min_t(u8, ...) to avoid any
warnings.

Reported-by: Andrew Morton 
Signed-off-by: Johannes Berg 
Signed-off-by: Emmanuel Grumbach 
---
 drivers/net/wireless/intel/iwlwifi/dvm/calib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c 
b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
index 07a4c64..14949ef 100644
--- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
@@ -900,8 +900,8 @@ static void iwlagn_gain_computation(struct iwl_priv *priv,
 
/* bound gain by 2 bits value max, 3rd bit is sign */
data->delta_gain_code[i] =
-   min(abs(delta_g),
-   (long) CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
+   min_t(u8, abs(delta_g),
+ CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
 
if (delta_g < 0)
/*
-- 
2.5.0

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

Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

[Sjoerd Simons]

On Mon, 2016-01-25 at 21:07 +0100, Arend van Spriel wrote:
> On 25-1-2016 20:23, Doug Anderson wrote:
> > Kinda curious: do we get one or two really slow responses on every
> > bootup, or just some bootups?  Do we ever succeed even with a slow
> > (like 1.8 or 1.9 seconds) response, or is it always either "fast"
> > or
> > "2.1" seconds?
> 
> Now these are interesting questions that I should have spilled out in
> the first place. Thanks.

I would need to get a more data to really conclusively say, but what i
saw in testing thusfar was:

* The issue occurs on _some_ boots
* The issue seems to come up more often on warm reboots
* The likelyhood seemed to change depending on the kernel
  configuration (iotw when the initilisation order/timing changed?)
* Forcing the brcmfmac module to load later in boot seemed to make the 
  likelyhood of the issue showing up lower.
* The samples I have with traces showed either quick responses on 
  success or slow "2.1" seconds responses on failure.

I'll try to make some time to get some statistics over a series of
boots wrt. the response time(s) for control messages so we can get a
better idea how often this happens and its behaviour.


I guess one other thing to note is that both Doug and myself were
seeing this on Rockchip RK3288 based devices. It would ofcourse be
interesting to know if this has been seen on other types of devices..

-- 
Sjoerd Simons
Collabora Ltd.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC V3 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature

[Arend van Spriel]

Announce support for nl80211 feature BSS_SELECT and process
BSS selection behaviour provided in .connect() callback.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Lei Zhang 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 --
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 38 +++--
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 3 files changed, 84 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7b01e4d..d90378e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -238,6 +238,20 @@ struct parsed_vndr_ies {
struct parsed_vndr_ie_info ie_info[VNDR_IE_PARSE_LIMIT];
 };
 
+static u8 nl80211_band_to_fwil(enum nl80211_band band)
+{
+   switch (band) {
+   case NL80211_BAND_2GHZ:
+   return WLC_BAND_2G;
+   case NL80211_BAND_5GHZ:
+   return WLC_BAND_5G;
+   default:
+   WARN_ON(1);
+   break;
+   }
+   return 0;
+}
+
 static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
   struct cfg80211_chan_def *ch)
 {
@@ -1737,6 +1751,43 @@ enum nl80211_auth_type brcmf_war_auth_type(struct 
brcmf_if *ifp,
return type;
 }
 
+static void brcmf_set_join_pref(struct brcmf_if *ifp,
+   struct cfg80211_bss_selection *bss_select)
+{
+   struct brcmf_join_pref_params join_pref_params[2];
+   enum nl80211_band band;
+   int err, i = 0;
+
+   join_pref_params[i].len = 2;
+   join_pref_params[i].rssi_gain = 0;
+   switch (bss_select->behaviour) {
+   case NL80211_BSS_SELECT_ATTR_BAND_PREF:
+   join_pref_params[i].type = BRCMF_JOIN_PREF_BAND;
+   band = bss_select->param.band_pref;
+   join_pref_params[i].band = nl80211_band_to_fwil(band);
+   i++;
+   break;
+   case NL80211_BSS_SELECT_ATTR_RSSI_ADJUST:
+   join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI_DELTA;
+   band = bss_select->param.adjust.band;
+   join_pref_params[i].band = nl80211_band_to_fwil(band);
+   join_pref_params[i].rssi_gain = bss_select->param.adjust.delta;
+   i++;
+   break;
+   case NL80211_BSS_SELECT_ATTR_RSSI:
+   default:
+   break;
+   }
+   join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI;
+   join_pref_params[i].len = 2;
+   join_pref_params[i].rssi_gain = 0;
+   join_pref_params[i].band = 0;
+   err = brcmf_fil_iovar_data_set(ifp, "join_pref", join_pref_params,
+  sizeof(join_pref_params));
+   if (err)
+   brcmf_err("Set join_pref error (%d)\n", err);
+}
+
 static s32
 brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev,
   struct cfg80211_connect_params *sme)
@@ -1862,11 +1913,13 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct 
net_device *ndev,
ext_join_params->scan_le.scan_type = -1;
ext_join_params->scan_le.home_time = cpu_to_le32(-1);
 
-   if (sme->bssid)
+   if (sme->bssid) {
memcpy(_join_params->assoc_le.bssid, sme->bssid, ETH_ALEN);
-   else
+   brcmf_c_set_joinpref_default(ifp);
+   } else {
eth_broadcast_addr(ext_join_params->assoc_le.bssid);
-
+   brcmf_set_join_pref(ifp, >bss_select);
+   }
if (cfg->channel) {
ext_join_params->assoc_le.chanspec_num = cpu_to_le32(1);
 
@@ -6179,6 +6232,10 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
wiphy->cipher_suites = __wl_cipher_suites;
wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites);
+   wiphy->bss_select_support = BIT(NL80211_BSS_SELECT_ATTR_RSSI) |
+   BIT(NL80211_BSS_SELECT_ATTR_BAND_PREF) |
+   BIT(NL80211_BSS_SELECT_ATTR_RSSI_ADJUST);
+
wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
WIPHY_FLAG_OFFCHAN_TX |
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 4265b50..b9e81fb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -32,7 +32,7 @@ const u8 ALLFFMAC[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 
0xff };
 #define 

[RFC V3 0/2] nl80211: allow configuration of BSS selection

[Arend van Spriel]

This patch series adds support for configuration of BSS selection done by
the driver and/or firmware. It allows user-space to pass selection criteria
with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space
does provide this attribute and no explicit BSSID is provided it will pass
the BSS selection criteria to the driver if the driver supports it.

When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with
same SSID, the criteria can be used to select a BSS. The criteria defined are:

1. RSSI based selection.
2. Band selection, RSSI based selection.
3. RSSI adjustment in given band, RSSI based selection.

V2:
 - incorporate comments from Johannes Berg (may have missed some).
 - split nl80211 patch in two separate patches.

V3:
 - remove enum nl80211_bss_select_primitive.
 - reword documentation of nl80211_bss_select_attr enum values.

Arend van Spriel (3):
  nl80211: add extended feature for BSS selection support
  nl80211: add bss selection attribute to CONNECT command
  brcmfmac: add support for nl80211 BSS_SELECT feature

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 38 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 include/net/cfg80211.h | 34 ++
 include/uapi/linux/nl80211.h   | 42 
 net/wireless/core.c|  4 ++
 net/wireless/nl80211.c | 76 ++
 7 files changed, 240 insertions(+), 18 deletions(-)

-- 
1.9.1

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

pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

Hi Kalle,

This is the first round of fixes for 4.5.
Most of them are really trivial. The TPC stats one stands out a little bit.
It can fix traffic issues which are typically hard to debug.
Please pull and let me know if you have issues.

I also have a batch of patches for -next, but wireless-drivers-next.git doesn't
seem ready to accept new patches at this stage.

Thanks!

The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next 
(2016-01-12 18:57:02 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git 
tags/iwlwifi-for-kalle-2016-01-26

for you to fetch changes up to a0d792850af3257d9b4b1dbf4e3df57994a481e7:

  iwlwifi: mvm: rs: fix TPC statistics handling (2016-01-25 14:42:11 +0200)


* Fix support for 3168 device
+ NVM version
+ firmware file name
+ device IDs
* Fix a compilation warning in dvm calibration code
* Fix the TPC (reduced Tx Power) code. This fixes performance issues
* Device IDs for 8265


Gregory Greenman (1):
  iwlwifi: mvm: rs: fix TPC statistics handling

Johannes Berg (1):
  iwlwifi: dvm: calib.c: fix min() warning

Oren Givon (3):
  iwlwifi: add new 3168 series devices support
  iwlwifi: add device ID for 8265
  iwlwifi: update support for 3168 series firmware and NVM

 drivers/net/wireless/intel/iwlwifi/dvm/calib.c |  4 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-7000.c  | 23 +++
 drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h |  6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 74 
--
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c|  5 +++--
 drivers/net/wireless/intel/iwlwifi/pcie/drv.c  |  4 
 6 files changed, 81 insertions(+), 35 deletions(-)

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

UBSAN: Undefined behaviour in net/mac80211/rc80211_minstrel.h:47:34

[Chris Bainbridge]

4.5.0-rc1 with the new UBSAN checker:

[ 2624.978741] 

[ 2624.978749] UBSAN: Undefined behaviour in 
net/mac80211/rc80211_minstrel.h:47:34
[ 2624.978752] signed integer overflow:
[ 2624.978754] -32768 * 100 cannot be represented in type 'int'
[ 2624.978759] CPU: 1 PID: 5362 Comm: kworker/u16:2 Not tainted 4.5.0-rc1 #252
[ 2624.978762] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015
[ 2624.978770] Workqueue: phy1 rt2800usb_work_txdone
[ 2624.978773]    000f4240 
8801e5d23990
[ 2624.978778]  81b2e7d9 0007 8801e5d239c0 
8801e5d239a8
[ 2624.978782]  81bcb87d 850b928c 8801e5d23a30 
81bcbc4d
[ 2624.978785] Call Trace:
[ 2624.978792]  [] dump_stack+0x45/0x6c
[ 2624.978797]  [] ubsan_epilogue+0xd/0x40
[ 2624.978802]  [] handle_overflow+0xbd/0xe0
[ 2624.978807]  [] ? number+0x35f/0x600
[ 2624.978812]  [] __ubsan_handle_mul_overflow+0xe/0x10
[ 2624.978819]  [] minstrel_calc_rate_stats+0x58c/0x5f0
[ 2624.978823]  [] minstrel_ht_update_stats.isra.4+0x148/0xdd0
[ 2624.978827]  [] minstrel_ht_tx_status+0x683/0x1120
[ 2624.978832]  [] ieee80211_tx_status+0xff8/0x2d10
[ 2624.978836]  [] rt2x00lib_txdone+0x42c/0x11a0
[ 2624.978841]  [] ? update_curr+0x15a/0x400
[ 2624.978846]  [] rt2800_txdone_entry+0xc5/0x1b0
[ 2624.978850]  [] rt2800usb_work_txdone+0x6ff/0xbb0
[ 2624.978854]  [] process_one_work+0x266/0xc00
[ 2624.978857]  [] worker_thread+0x96/0xd40
[ 2624.978861]  [] ? process_scheduled_works+0x70/0x70
[ 2624.978865]  [] kthread+0x108/0x180
[ 2624.978869]  [] ? kthread_create_on_node+0x210/0x210
[ 2624.978874]  [] ret_from_fork+0x3f/0x70
[ 2624.978878]  [] ? kthread_create_on_node+0x210/0x210
[ 2624.978880] 

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

Re: [PATCH 16/26] libceph: Use skcipher

[Herbert Xu]

On Tue, Jan 26, 2016 at 12:29:57PM +0100, Ilya Dryomov wrote:
>
> LGTM.  You want to take it through crypto?

That's probably the easiest route since I'd like to take the first
patch through cryptodev.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers

[Michal Kazior]

On 26 January 2016 at 11:45, Felix Fietkau  wrote:
> On 2016-01-21 14:23, Michal Kazior wrote:
>> This will allow drivers to make more educated
>> decisions whether to defer transmission or not.
>>
>> Relying on wake_tx_queue() call count implicitly
>> was not possible because it could be called
>> without queued frame count actually changing on
>> software tx aggregation start/stop code paths.
>>
>> It was also not possible to know how long
>> byte-wise queue was without dequeueing.
>>
>> Signed-off-by: Michal Kazior 
> Instead of exposing these in the struct to the driver directly, please
> make a function to get them. Since the number of frames is already
> tracked in txqi->queue, you can avoid counter duplication that way.

Hmm, so you suggest to have something like:

 void
 ieee80211_get_txq_depth(struct ieee80211_txq *txq,
 unsigned int *frame_cnt,
 unsigned int *byte_count) {
   struct txq_info *txqi = txq_to_info(txq);

   if (frame_cnt)
 *frame_cnt = txqi->queue.qlen;

   if (byte_count)
 *byte_cnt = txqi->byte_cnt;
 }

Correct?

Sounds reasonable.


> Also, that way you can fix a race condition between accessing the number
> of frames counter and the bytes counter.

I don't see a point in maintaining coherency between the two counters
with regard to each other alone. Do you have a use-case that would
actually make use of that property?

I'd like to avoid any unnecessary spinlocks.


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

[RFC V3 1/2] nl80211: add feature for BSS selection support

[Arend van Spriel]

Introducing a new feature that the driver can use to
indicate the driver/firmware supports configuration of BSS
selection criteria upon CONNECT command. This can be useful
when multiple BSS-es are found belonging to the same ESS,
ie. Infra-BSS with same SSID. The criteria can then be used to
offload selection of a preferred BSS.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Lei Zhang 
Signed-off-by: Arend van Spriel 
---
 include/net/cfg80211.h   | 34 
 include/uapi/linux/nl80211.h | 42 
 net/wireless/core.c  |  4 +++
 net/wireless/nl80211.c   | 76 
 4 files changed, 156 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9bcaaf7..b4c1bf4 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1854,6 +1854,33 @@ struct cfg80211_ibss_params {
 };
 
 /**
+ * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment.
+ *
+ * @band: band of BSS which should match for RSSI level adjustment.
+ * @delta: value of RSSI level adjustment.
+ */
+struct cfg80211_bss_select_adjust {
+   enum nl80211_band band;
+   s8 delta;
+};
+
+/**
+ * struct cfg80211_bss_selection - connection parameters for BSS selection.
+ *
+ * @behaviour: requested BSS selection behaviour.
+ * @param: parameters for given primitive.
+ * @band_pref: preferred band for %BSS_SELECT_BAND_PREF primitive.
+ * @adjust: parameters for %BSS_SELECT_ADJUST_RSSI primitive.
+ */
+struct cfg80211_bss_selection {
+   enum nl80211_bss_select_attr behaviour;
+   union {
+   enum nl80211_band band_pref;
+   struct cfg80211_bss_select_adjust adjust;
+   } param;
+};
+
+/**
  * struct cfg80211_connect_params - Connection parameters
  *
  * This structure provides information needed to complete IEEE 802.11
@@ -1888,6 +1915,7 @@ struct cfg80211_ibss_params {
  * @ht_capa_mask:  The bits of ht_capa which are to be used.
  * @vht_capa:  VHT Capability overrides
  * @vht_capa_mask: The bits of vht_capa which are to be used.
+ * @bss_select: criteria to be used for BSS selection.
  */
 struct cfg80211_connect_params {
struct ieee80211_channel *channel;
@@ -1910,6 +1938,7 @@ struct cfg80211_connect_params {
struct ieee80211_ht_cap ht_capa_mask;
struct ieee80211_vht_cap vht_capa;
struct ieee80211_vht_cap vht_capa_mask;
+   struct cfg80211_bss_selection bss_select;
 };
 
 /**
@@ -3178,6 +3207,9 @@ struct wiphy_vendor_command {
  * low rssi when a frame is heard on different channel, then it should set
  * this variable to the maximal offset for which it can compensate.
  * This value should be set in MHz.
+ * @bss_select_support: bitmask indicating the BSS selection criteria supported
+ * by the driver in the .connect() callback. The bit position maps to the
+ * criteria defined in  nl80211_bss_select_primitive.
  */
 struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3300,6 +3332,8 @@ struct wiphy {
u8 max_num_csa_counters;
u8 max_adj_channel_rssi_comp;
 
+   u32 bss_select_support;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5b7b5eb..e9f5ae7 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1789,6 +1789,12 @@ enum nl80211_commands {
  * thus it must not specify the number of iterations, only the interval
  * between scans. The scan plans are executed sequentially.
  * Each scan plan is a nested attribute of  nl80211_sched_scan_plan.
+ * @NL80211_ATTR_BSS_SELECT: nested attribute for driver supporting the
+ * extended feature %NL80211_EXT_FEATURE_BSS_SELECT. When used with
+ * %NL80211_CMD_GET_WIPHY is contains NLA_FLAG type according
+ *  nl80211_bss_select_attr to indicate what primitives are
+ * supported. When used with %NL80211_CMD_CONNECT is contains the behaviour
+ * and parameters for BSS selection to be done by driver and/or firmware.
  *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
@@ -2164,6 +2170,8 @@ enum nl80211_attrs {
NL80211_ATTR_MAX_SCAN_PLAN_ITERATIONS,
NL80211_ATTR_SCHED_SCAN_PLANS,
 
+   NL80211_ATTR_BSS_SELECT,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
@@ -4651,4 +4659,38 @@ enum nl80211_sched_scan_plan {
__NL80211_SCHED_SCAN_PLAN_AFTER_LAST - 1
 };
 
+/**
+ * enum nl80211_bss_select_attr - attributes for bss selection.
+ *
+ * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved.
+ * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based BSS 

Re: net/rfkill: WARNING in rfkill_fop_read

[Johannes Berg]

On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote:
> Hello,
> 
> The following program triggers WARNING message in rfkill_fop_read:
> 
> [ cut here ]
> WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663
> __might_sleep+0x138/0x1a0()
> do not call blocking ops when !TASK_RUNNING; state=1 set at
> [] prepare_to_wait_event+0x141/0x410
> kernel/sched/wait.c:210

>  [< inline >] rfkill_readable net/rfkill/core.c:1102

Yeah, this should not acquire the mutex ... but luckily it's not a
problem not to anyway, so it's easy to fix. Thanks! I'll send out a fix
once I've tested it.

> // autogenerated by syzkaller (http://github.com/google/syzkaller)

gotta love the raw mmap etc. :)

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

Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers

[Felix Fietkau]

On 2016-01-21 14:23, Michal Kazior wrote:
> This will allow drivers to make more educated
> decisions whether to defer transmission or not.
> 
> Relying on wake_tx_queue() call count implicitly
> was not possible because it could be called
> without queued frame count actually changing on
> software tx aggregation start/stop code paths.
> 
> It was also not possible to know how long
> byte-wise queue was without dequeueing.
> 
> Signed-off-by: Michal Kazior 
Instead of exposing these in the struct to the driver directly, please
make a function to get them. Since the number of frames is already
tracked in txqi->queue, you can avoid counter duplication that way.
Also, that way you can fix a race condition between accessing the number
of frames counter and the bytes counter.

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

net/rfkill: WARNING in rfkill_fop_read

[Dmitry Vyukov]

Hello,

The following program triggers WARNING message in rfkill_fop_read:

[ cut here ]
WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663
__might_sleep+0x138/0x1a0()
do not call blocking ops when !TASK_RUNNING; state=1 set at
[] prepare_to_wait_event+0x141/0x410
kernel/sched/wait.c:210
Modules linked in:
CPU: 2 PID: 6975 Comm: a.out Not tainted 4.5.0-rc1+ #283
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  88003369f908 8299a06d 88003369f978
 8800338e 864453c0 88003369f948 8134fcf9
 813c9cf8 ed00066d3f2b 864453c0 1def
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_fmt+0xa9/0xd0 kernel/panic.c:494
 [] __might_sleep+0x138/0x1a0 kernel/sched/core.c:7658
 [] mutex_lock_nested+0x74/0xa50 kernel/locking/mutex.c:617
 [< inline >] rfkill_readable net/rfkill/core.c:1102
 [] rfkill_fop_read+0x23d/0x3e0 net/rfkill/core.c:1125
 [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719
 [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849
 [] vfs_readv+0x83/0xb0 fs/read_write.c:873
 [< inline >] SYSC_readv fs/read_write.c:899
 [] SyS_readv+0x111/0x2b0 fs/read_write.c:891
 [] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace 8fc3336c73e4219c ]---


// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

long r[8];

void* thr(void* arg)
{
  switch ((long)arg) {
  case 0:
r[0] = syscall(SYS_mmap, 0x2000ul, 0x5ul, 0x3ul, 0x32ul,
   0xul, 0x0ul);
break;
  case 1:
r[2] = open("/dev/rfkill", O_RDWR);
break;
  case 2:
*(uint64_t*)0x20042fe0 = (uint64_t)0x20042ff9;
*(uint64_t*)0x20042fe8 = (uint64_t)0x7;
*(uint64_t*)0x20042ff0 = (uint64_t)0x20032fa1;
*(uint64_t*)0x20042ff8 = (uint64_t)0xf4;
r[7] = syscall(SYS_readv, r[2], 0x20042fe0ul, 0x2ul, 0, 0, 0);
break;
  }
  return 0;
}

void worker()
{
  long i;
  pthread_t th[3];

  memset(r, -1, sizeof(r));
  for (i = 0; i < 3; i++) {
pthread_create([i], 0, thr, (void*)i);
usleep(1);
  }
  for (i = 0; i < 3; i++) {
pthread_create([i], 0, thr, (void*)i);
if (i % 2 == 0)
  usleep(1);
  }
  usleep(10);
}

int main()
{
  int i, status, pids[16];

  for (;;) {
for (i = 0; i < 16; i++) {
  if ((pids[i] = fork()) == 0) {
worker();
exit(0);
  }
}
for (i = 0; i < 16; i++) {
  while (waitpid(pids[i], , __WALL) != pids[i]) {
  }
}
  }
  return 0;
}

On commit 92e963f50fc74041b5e9e744c330dca48e04f08d (Jan 24).
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 16/26] libceph: Use skcipher

[Herbert Xu]

On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote:
> 
> Could you get rid of ivsize instead of assigning to it - see the
> attached diff?

How about an incremental patch like this? Thanks!

---8<---
From: Ilya Dryomov 
Subject: libceph: Remove unnecessary ivsize variables

This patch removes the unnecessary ivsize variabls as they always
have the value of AES_BLOCK_SIZE.

Signed-off-by: Ilya Dryomov 

diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
index fb9cb2b..db2847a 100644
--- a/net/ceph/crypto.c
+++ b/net/ceph/crypto.c
@@ -166,8 +166,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
-   int ivsize = AES_BLOCK_SIZE;
-   char iv[ivsize];
+   char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - (src_len & 0x0f));
char pad[16];
 
@@ -186,7 +185,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
goto out_tfm;
 
crypto_skcipher_setkey((void *)tfm, key, key_len);
-   memcpy(iv, aes_iv, ivsize);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
 
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);
@@ -229,8 +228,7 @@ static int ceph_aes_encrypt2(const void *key, int key_len, 
void *dst,
struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
SKCIPHER_REQUEST_ON_STACK(req, tfm);
int ret;
-   int ivsize = AES_BLOCK_SIZE;
-   char iv[ivsize];
+   char iv[AES_BLOCK_SIZE];
size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f));
char pad[16];
 
@@ -250,7 +248,7 @@ static int ceph_aes_encrypt2(const void *key, int key_len, 
void *dst,
goto out_tfm;
 
crypto_skcipher_setkey((void *)tfm, key, key_len);
-   memcpy(iv, aes_iv, ivsize);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
 
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);
@@ -294,8 +292,7 @@ static int ceph_aes_decrypt(const void *key, int key_len,
struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
SKCIPHER_REQUEST_ON_STACK(req, tfm);
char pad[16];
-   int ivsize = AES_BLOCK_SIZE;
-   char iv[16];
+   char iv[AES_BLOCK_SIZE];
int ret;
int last_byte;
 
@@ -310,7 +307,7 @@ static int ceph_aes_decrypt(const void *key, int key_len,
goto out_tfm;
 
crypto_skcipher_setkey((void *)tfm, key, key_len);
-   memcpy(iv, aes_iv, ivsize);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
 
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);
@@ -363,8 +360,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len,
struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
SKCIPHER_REQUEST_ON_STACK(req, tfm);
char pad[16];
-   int ivsize = AES_BLOCK_SIZE;
-   char iv[ivsize];
+   char iv[AES_BLOCK_SIZE];
int ret;
int last_byte;
 
@@ -380,7 +376,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len,
goto out_tfm;
 
crypto_skcipher_setkey((void *)tfm, key, key_len);
-   memcpy(iv, aes_iv, ivsize);
+   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
 
skcipher_request_set_tfm(req, tfm);
skcipher_request_set_callback(req, 0, NULL, NULL);

-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Johannes Berg]

On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote:

> --- a/include/uapi/linux/nl80211.h
> +++ b/include/uapi/linux/nl80211.h
> @@ -2130,6 +2130,8 @@ enum nl80211_attrs {
>  
>   NL80211_ATTR_REG_INDOOR,
>  
> + NL80211_ATTR_TX_ADVERT_RATEMASK,

First of all, this is missing documentation. It's a FLAG as far as I
can tell, but if it's set should it affect only the advertised or both?

I also think you added this because I had commented that we might not
want to do it unconditionally, but is there really a good reason not to
do it unconditionally? I was probably more thinking out loud what would
happen with P2P, but there we already say "no cck" for scanning so it
shouldn't really have any effect.

But given that we have NL80211_ATTR_SCAN_SUPP_RATES, where does your
patch even have an effect, other than this not handling HT/VHT?

I'm a bit wary that we're introducing two ways of achieving a very
similar thing.

Also, adding these overrides all over the code seems very complex.
Perhaps we can achieve the goal of being able to pretend to have
limited hardware capabilities by actually restricting hardware
capabilities instead? That would also avoid having to play whack-a-mole 
with code paths using the device capabilities.

I'd imagine an API along the lines of doing some kind of higher-layer
re-register of the wiphy in mac80211 with limited capabilites. At that
point you'd allocate a copy of the original capabilities (as far as the
new restricted ones overwrite the data), and remove the device from the
system as far as higher layers like cfg80211 are concerned.

Would something like that work for you?

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

Re: [PATCH-v2 2/2] mac80211: ensure association req uses configured ratemask.

[Johannes Berg]

On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote:
> From: Ben Greear 
> 
> When sending the association request, pay attention to the
> legacy rates configured by the user, and do not advertise support
> for any that are not configured.
> 
> This makes the assoc request packet look more correct when
> making modern hardware act like a /b mode station, for instance.
> 
This is what I meant by "playing whack-a-mole" :)

Next you'll have to fix TDLS too, etc. I feel that overall this is too
complex and we need to address this at a lower level, to actually get
the capabilities that all the code already looks at into the restricted
state you need for this kind of testing.

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

Re: [PATCH 2/2] mac80211: let unused MPP table entries timeout

[Johannes Berg]

On Tue, 2016-01-19 at 09:04 +0100, Henning Rogge wrote:

> +++ b/net/mac80211/mesh_pathtbl.c
> @@ -929,12 +929,55 @@ int mesh_path_del(struct ieee80211_sub_if_data
> *sdata, const u8 *addr)
>   if (mpath->sdata == sdata &&
>   ether_addr_equal(addr, mpath->dst)) {
>   __mesh_path_del(tbl, node);
> - goto enddel;
> + goto enddelpath;

C labels are scoped, why rename it?

>   }
>   }
>  
>   err = -ENXIO;
> -enddel:
> +enddelpath:
> + mesh_paths_generation++;
> + spin_unlock(>hashwlock[hash_idx]);
> + read_unlock_bh(_resize_lock);
> + return err;
> +}
> +
> +/**
> + * mpp_path_del - delete a mesh proxy path from the table
> + *
> + * @addr: addr address (ETH_ALEN length)
> + * @sdata: local subif
> + *
> + * Returns: 0 if successful
> + */
> +static int mpp_path_del(struct ieee80211_sub_if_data *sdata, const
> u8 *addr)
> +{
> + struct mesh_table *tbl;
> + struct mesh_path *mpath;
> + struct mpath_node *node;
> + struct hlist_head *bucket;
> + int hash_idx;
> + int err = 0;
> +
> + /* flush relevant mpp entries first */
> + mpp_flush_by_proxy(sdata, addr);
> +
> + read_lock_bh(_resize_lock);
> + tbl = resize_dereference_mpp_paths();
> + hash_idx = mesh_table_hash(addr, sdata, tbl);
> + bucket = >hash_buckets[hash_idx];
> +
> + spin_lock(>hashwlock[hash_idx]);
> + hlist_for_each_entry(node, bucket, list) {
> + mpath = node->mpath;
> + if (mpath->sdata == sdata &&
> + ether_addr_equal(addr, mpath->dst)) {
> + __mesh_path_del(tbl, node);
> + goto enddelmpp;

This has the same use-after-free, I'd say?
And another instance later in this file.


> + spin_lock_bh(
> >state_lock);
> + mppath->exp_time = jiffies;

That locking seems fairly pointless? You only write to this value here,
and it's an unsigned long, so in itself it's atomic and there's no
synchronisation against anything else needed.

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

[PATCH] staging: wilc1000: fix alignment for open parenthesis

[Chaehyun Lim]

This patch fixes the check found by checkpatch.pl
CHECK: Alignment should match open parenthesis

Signed-off-by: Chaehyun Lim 
---
 drivers/staging/wilc1000/host_interface.c | 90 +++
 1 file changed, 45 insertions(+), 45 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index 98627a6..716f359 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -303,7 +303,7 @@ static s32 handle_set_channel(struct wilc_vif *vif,
PRINT_D(HOSTINF_DBG, "Setting channel\n");
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
if (result) {
PRINT_ER("Failed to set channel\n");
@@ -350,7 +350,7 @@ static s32 handle_set_operation_mode(struct wilc_vif *vif,
wid.size = sizeof(u32);
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
if ((hif_op_mode->mode) == IDLE_MODE)
up(_sema_driver);
@@ -383,7 +383,7 @@ static s32 handle_set_ip_address(struct wilc_vif *vif, u8 
*ip_addr, u8 idx)
wid.size = IP_ALEN;
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
host_int_get_ipaddress(vif, firmware_ip_addr, idx);
 
@@ -408,7 +408,7 @@ static s32 handle_get_ip_address(struct wilc_vif *vif, u8 
idx)
wid.size = IP_ALEN;
 
result = wilc_send_config_pkt(vif->wilc, GET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
PRINT_INFO(HOSTINF_DBG, "%pI4\n", wid.val);
 
@@ -451,7 +451,7 @@ static s32 handle_set_mac_address(struct wilc_vif *vif,
PRINT_D(GENERIC_DBG, "mac addr = :%pM\n", wid.val);
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
if (result) {
PRINT_ER("Failed to set mac address\n");
result = -EFAULT;
@@ -473,7 +473,7 @@ static s32 handle_get_mac_address(struct wilc_vif *vif,
wid.size = ETH_ALEN;
 
result = wilc_send_config_pkt(vif->wilc, GET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
if (result) {
PRINT_ER("Failed to get mac address\n");
@@ -939,7 +939,7 @@ static s32 Handle_ScanDone(struct wilc_vif *vif,
wid.size = sizeof(char);
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
 
if (result) {
PRINT_ER("Failed to set abort running scan\n");
@@ -1356,7 +1356,7 @@ static s32 Handle_ConnectTimeout(struct wilc_vif *vif)
PRINT_D(HOSTINF_DBG, "Sending disconnect request\n");
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG, , 1,
-wilc_get_vif_idx(vif));
+ wilc_get_vif_idx(vif));
if (result)
PRINT_ER("Failed to send dissconect config packet\n");
 
@@ -1750,8 +1750,8 @@ static int Handle_Key(struct wilc_vif *vif,
strWIDList[3].val = (s8 *)pu8keybuf;
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG,
-   strWIDList, 4,
-   wilc_get_vif_idx(vif));
+ strWIDList, 4,
+ wilc_get_vif_idx(vif));
kfree(pu8keybuf);
} else if (pstrHostIFkeyAttr->action & ADDKEY) {
PRINT_D(HOSTINF_DBG, "Handling WEP key\n");
@@ -1772,8 +1772,8 @@ static int Handle_Key(struct wilc_vif *vif,
wid.size = pstrHostIFkeyAttr->attr.wep.key_len + 2;
 
result = wilc_send_config_pkt(vif->wilc, SET_CFG,
-   , 1,
-   wilc_get_vif_idx(vif));
+ , 1,
+ wilc_get_vif_idx(vif));
kfree(pu8keybuf);
} else if (pstrHostIFkeyAttr->action & REMOVEKEY) {
PRINT_D(HOSTINF_DBG, "Removing key\n");
@@ -1785,8 +1785,8 @@ static int 

pull-request: mac80211 2016-01-26

[Johannes Berg]

Hi Dave,

After split up the patches from the previous pull request that was
lost in the process, here's a new one with fixes for the current
cycle (I'll follow up with a -next one later.)

I've also scripted my pull-request sending process a bit more, so
hopefully the emails will no longer have any unexpected UTF-8 contents
that tripped up patchwork :)

Let me know if there's any problem.

Thanks,
johannes



The following changes since commit 701a0fd5231866db08cebcd502894699f49cb960:

  hip04_eth: fix missing error handle for build_skb failed (2016-01-13 15:48:14 
-0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git 
tags/mac80211-for-davem-2016-01-26

for you to fetch changes up to 6736fde9672ff6717ac576e9bba2fd5f3dfec822:

  rfkill: fix rfkill_fop_read wait_event usage (2016-01-26 11:32:05 +0100)


Here's a first set of fixes for the 4.5-rc cycle:
 * make regulatory messages much less verbose by default
 * various remain-on-channel fixes
 * scheduled scanning fixes with hardware restart
 * a PS-Poll handling fix; was broken just recently
 * bugfix to avoid buffering non-bufferable MMPDUs
 * world regulatory domain data fix
 * a fix for scanning causing other work to get stuck
 * hwsim: revert an older problematic patch that caused some
   userspace tools to have issues - not that big a deal as
   it's a debug only driver though


Bob Copeland (1):
  Revert "mac80211_hwsim: support any address in userspace"

Dave Young (1):
  wireless: change cfg80211 regulatory domain info as debug messages

Eliad Peller (3):
  mac80211: avoid ROC during hw restart
  mac80211: clear local->sched_scan_req properly on reconfig
  mac80211: handle sched_scan_stopped vs. hw restart race

Emmanuel Grumbach (1):
  mac80211: fix PS-Poll handling

Helmut Schaa (1):
  mac80211: Don't buffer non-bufferable MMPDUs

Johannes Berg (4):
  mac80211: recalculate SW ROC only when needed
  mac80211: fix remain-on-channel cancellation
  regulatory: fix world regulatory domain data
  rfkill: fix rfkill_fop_read wait_event usage

Sachin Kulkarni (1):
  mac80211: Requeue work after scan complete for all VIF types.

 drivers/net/wireless/mac80211_hwsim.c |  5 ++--
 net/mac80211/ibss.c   |  1 -
 net/mac80211/main.c   |  6 +
 net/mac80211/mesh.c   | 11 -
 net/mac80211/mesh.h   |  4 
 net/mac80211/mlme.c   |  2 --
 net/mac80211/offchannel.c | 16 +++--
 net/mac80211/scan.c   | 20 +++-
 net/mac80211/sta_info.c   |  2 +-
 net/mac80211/status.c |  5 
 net/mac80211/util.c   | 16 ++---
 net/rfkill/core.c | 16 -
 net/wireless/reg.c| 45 +++
 13 files changed, 85 insertions(+), 64 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/13] ath10k: implement push-pull tx

[Michal Kazior]

On 22 January 2016 at 08:47, Michal Kazior  wrote:
> On 21 January 2016 at 18:40, Peter Oh  wrote:
>> On 01/21/2016 05:46 AM, Michal Kazior wrote:
[...]
>>>   - /* TODO: apply configuration */
>>> +   rcu_read_unlock();
>>> +
>>> +   spin_lock_bh(>htt.tx_lock);
>>> +   ath10k_mac_tx_lock(ar, ATH10K_TX_PAUSE_Q_FLUSH_PENDING);
>>> +   spin_unlock_bh(>htt.tx_lock);
>>> +
>>
>> Isn't it proved it break Mesh from working?
>
> Yes, good point. I'm still working on this - I should've mentioned
> that in the cover letter.
>
> Nonetheless I wanted to get the review process going for this patchset.
>
> I'll address the mesh problem in v2.

For the record - the problem turned out to be a bug in mac80211 mesh
fwding, see:

  https://patchwork.kernel.org/patch/8108711/


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

Re: [PATCH] mac80211: Requeue work after scan complete for all VIF types.

[Johannes Berg]

On Tue, 2016-01-12 at 14:30 +0530, Sachin Kulkarni wrote:
> From: Sachin Kulkarni 
> 
> During a sw scan ieee80211_iface_work ignores work items for all
> vifs. 
> However after the scan complete work is requeued only for STA, ADHOC 
> and MESH iftypes.
> 
> This occasionally results in event processing getting delayed/not 
> processed for iftype AP when it coexists with a STA. This can result 
> in data halt and eventually disconnection on the AP interface.
> 
Applied.

I added a Cc stable tag - I don't think the commit message (hw vs. sw
scan) matters that much.

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

UBSAN: Undefined behaviour in net/mac80211/rx.c:924:18

[Chris Bainbridge]

4.5.0-rc1 another UBSAN error:

[ 4845.229441] 

[ 4845.229454] UBSAN: Undefined behaviour in net/mac80211/rx.c:924:18
[ 4845.229458] load of value 2 is not a valid value for type '_Bool'
[ 4845.229464] CPU: 1 PID: 6266 Comm: kworker/u16:8 Not tainted 4.5.0-rc1 #252
[ 4845.229468] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, 
BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015
[ 4845.229491] Workqueue: phy2 rt2x00usb_work_rxdone
[ 4845.229493]    0002 
8801b13c39f8
[ 4845.229496]  81b2e7d9 0007 8801b13c3a20 
8801b13c3a10
[ 4845.229498]  81bcb87d 85016890 8801b13c3a60 
81bcc279
[ 4845.229501] Call Trace:
[ 4845.229506]  [] dump_stack+0x45/0x6c
[ 4845.229510]  [] ubsan_epilogue+0xd/0x40
[ 4845.229513]  [] __ubsan_handle_load_invalid_value+0x69/0x80
[ 4845.229517]  [] ? 
xhci_setup_addressable_virt_dev+0xeb2/0x13b0
[ 4845.229520]  [] ? pick_next_entity+0xcb/0x280
[ 4845.229524]  [] 
ieee80211_sta_reorder_release.isra.15+0x7e3/0xad0
[ 4845.229527]  [] 
ieee80211_prepare_and_rx_handle+0x11a7/0x2ab0
[ 4845.229530]  [] ? xhci_urb_enqueue+0x394/0x1140
[ 4845.229533]  [] ? usb_hcd_map_urb_for_dma+0x94f/0x1140
[ 4845.229537]  [] ? skb_release_data+0x117/0x2f0
[ 4845.229539]  [] __ieee80211_rx_handle_packet+0x26a/0x9a0
[ 4845.229542]  [] ? __kmalloc_reserve.isra.11+0x2c/0x80
[ 4845.229545]  [] ieee80211_rx_napi+0x651/0x12b0
[ 4845.229549]  [] rt2x00lib_rxdone+0x402/0x1120
[ 4845.229552]  [] ? dequeue_task_fair+0x97f/0x41d0
[ 4845.229554]  [] rt2x00usb_work_rxdone+0xac/0x1f0
[ 4845.229558]  [] ? __schedule+0x5cd/0x1770
[ 4845.229561]  [] process_one_work+0x266/0xc00
[ 4845.229563]  [] worker_thread+0x96/0xd40
[ 4845.229565]  [] ? process_scheduled_works+0x70/0x70
[ 4845.229568]  [] kthread+0x108/0x180
[ 4845.229571]  [] ? kthread_create_on_node+0x210/0x210
[ 4845.229573]  [] ret_from_fork+0x3f/0x70
[ 4845.229576]  [] ? kthread_create_on_node+0x210/0x210
[ 4845.229577] 

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

Re: [PATCH 16/26] libceph: Use skcipher

[Ilya Dryomov]

On Tue, Jan 26, 2016 at 11:54 AM, Herbert Xu
 wrote:
> On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote:
>>
>> Could you get rid of ivsize instead of assigning to it - see the
>> attached diff?
>
> How about an incremental patch like this? Thanks!
>
> ---8<---
> From: Ilya Dryomov 
> Subject: libceph: Remove unnecessary ivsize variables
>
> This patch removes the unnecessary ivsize variabls as they always
> have the value of AES_BLOCK_SIZE.
>
> Signed-off-by: Ilya Dryomov 
>
> diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c
> index fb9cb2b..db2847a 100644
> --- a/net/ceph/crypto.c
> +++ b/net/ceph/crypto.c
> @@ -166,8 +166,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
> struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
> SKCIPHER_REQUEST_ON_STACK(req, tfm);
> int ret;
> -   int ivsize = AES_BLOCK_SIZE;
> -   char iv[ivsize];
> +   char iv[AES_BLOCK_SIZE];
> size_t zero_padding = (0x10 - (src_len & 0x0f));
> char pad[16];
>
> @@ -186,7 +185,7 @@ static int ceph_aes_encrypt(const void *key, int key_len,
> goto out_tfm;
>
> crypto_skcipher_setkey((void *)tfm, key, key_len);
> -   memcpy(iv, aes_iv, ivsize);
> +   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
>
> skcipher_request_set_tfm(req, tfm);
> skcipher_request_set_callback(req, 0, NULL, NULL);
> @@ -229,8 +228,7 @@ static int ceph_aes_encrypt2(const void *key, int 
> key_len, void *dst,
> struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
> SKCIPHER_REQUEST_ON_STACK(req, tfm);
> int ret;
> -   int ivsize = AES_BLOCK_SIZE;
> -   char iv[ivsize];
> +   char iv[AES_BLOCK_SIZE];
> size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f));
> char pad[16];
>
> @@ -250,7 +248,7 @@ static int ceph_aes_encrypt2(const void *key, int 
> key_len, void *dst,
> goto out_tfm;
>
> crypto_skcipher_setkey((void *)tfm, key, key_len);
> -   memcpy(iv, aes_iv, ivsize);
> +   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
>
> skcipher_request_set_tfm(req, tfm);
> skcipher_request_set_callback(req, 0, NULL, NULL);
> @@ -294,8 +292,7 @@ static int ceph_aes_decrypt(const void *key, int key_len,
> struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
> SKCIPHER_REQUEST_ON_STACK(req, tfm);
> char pad[16];
> -   int ivsize = AES_BLOCK_SIZE;
> -   char iv[16];
> +   char iv[AES_BLOCK_SIZE];
> int ret;
> int last_byte;
>
> @@ -310,7 +307,7 @@ static int ceph_aes_decrypt(const void *key, int key_len,
> goto out_tfm;
>
> crypto_skcipher_setkey((void *)tfm, key, key_len);
> -   memcpy(iv, aes_iv, ivsize);
> +   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
>
> skcipher_request_set_tfm(req, tfm);
> skcipher_request_set_callback(req, 0, NULL, NULL);
> @@ -363,8 +360,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len,
> struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher();
> SKCIPHER_REQUEST_ON_STACK(req, tfm);
> char pad[16];
> -   int ivsize = AES_BLOCK_SIZE;
> -   char iv[ivsize];
> +   char iv[AES_BLOCK_SIZE];
> int ret;
> int last_byte;
>
> @@ -380,7 +376,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len,
> goto out_tfm;
>
> crypto_skcipher_setkey((void *)tfm, key, key_len);
> -   memcpy(iv, aes_iv, ivsize);
> +   memcpy(iv, aes_iv, AES_BLOCK_SIZE);
>
> skcipher_request_set_tfm(req, tfm);
> skcipher_request_set_callback(req, 0, NULL, NULL);

LGTM.  You want to take it through crypto?

Thanks,

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

RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

> Hi
> 
> 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel
> :
> >
> >
> > On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
> >> It looks like sometimes firmware returns zero for chain noise and
> >> signal during calibration period. This seems to be a known problem
> >> and current implementation accounts for this by ignoring invalid data
> >> when all chains return zero signal and noise.
> >>
> >> The problem is that sometimes firmware returns zero for only one
> >> chain for some (not all) beacons used for calibration. This leads to
> >> perfectly valid chains be disabled and may cause invalid gain settings.
> >> For example this is calibration data taken on laptop with Intel 6300
> >> card with all three antennas attached:
> >>
> >> active_chains: 3
> >> chain_noise_a: 312
> >> chain_noise_b: 297
> >> chain_noise_c: 0
> >> chain_signal_a:549
> >> chain_signal_b:513
> >> chain_signal_c:0
> >> beacon_count:  16
> >> disconn_array: 0 0 1
> >> delta_gain_code:   4 0 0
> >> radio_write:   1
> >> state: 3
> >>
> >> This patch changes statistics gathering to make sure that zero noise
> >> results are ignored for valid rx chains. The rationale being that
> >> even if anntenna is not connected we should be able to see non zero
> >> noise if rx chain is present.
> >
> > But then the firmware will continue to send zero for signal and this
> > will impact lots of flows like roaming. If the driver allows the
> > firmware to use that antenna, the firmware may use this antenna for
> > scanning and roaming will be broken.
> > This seems to be a bug in the firmware, but there isn't much I can do
> > about it.
> > Sorry, I have to NACK this patch.
> 
>   Could you please elaborate on how this patch would affect roaming or other
> things. As far as I can see this patch doesn't change much behavior apart
> from ignoring invalid values from firmware.
> Disconnected antennas still get disabled (as before) connected antennas still
> work (more often than before). So I'm not sure I can see how this patch
> would change what firmware does at all. I really hope you could find a
> moment and explain this.
> 

What you are saying here is that there is a bug in the firmware which makes it 
report wrong
values for one of the antennas. But when you will have this antenna enabled 
(with your patch),
the firmware will keep sending bad signal / noise values for it. If the driver 
allows the firmware
to use this antenna (after your patch), the firmware will choose this antenna 
to receive beacons
or to scan. Then, the driver will look at the beacons' rssi (which will be 
wrong) and it will think that
an AP which is very close is in fact far away.

N�r��yb�X��ǧv�^�)޺{.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w���
���j:+v���w�j�mzZ+�ݢj"��!�i

Need direction to understand mac80211

[Sunil Shahu]

Hi,

I am currently working on an project that aims to provide multiple 802.11ac 
radio support on a single node for mesh network. In this both the radios will 
operate in different channel and will talk to different nodes in mesh network.

I need to work with kernel mac80211 driver subsystem for the same. I went 
through different documentation to understand the theories of 802.11s which can 
help during working on mac80211 driver. However I am not able to understand the 
source code properly. 

Can you please provide some guidance to understand mac80211 and related 
networking stack in Linux kernel.

I am looking for 
1) How to create bridge bridge for two Phy radios during initialization/packet 
forwarding?
2) Also, need some idea about how packets will be routed in mesh_hwmp.
3) How the path request and response should behave in this case?
4) Will there be any changes for mesh path table entries?

Any suggestion for document/book/blog will be great help.

I already went through following materials.
http://kernelnewbies.org/Documents/Kernel-Docbooks?action=AttachFile=get=mac80211_2.6.29.pdf
http://www.campsmur.cat/files/mac80211_intro.pdf
https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf
http://www.ieee802.org/802_tutorials/06-November/802.11s_Tutorial_r5.pdf

Any suggestion and directions will be great help.

Thanks,
Sunil Shahu.

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

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties withrfkill_gpio

[Johannes Berg]

On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote:
> 
> seems to work fine. I wish we could instantiate this from device-tree 
> so we can finially get rid of this file.

That'd be nice - anyone want to propose rfkill DT bindings? :)

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

Re: [PATCHv2 3/4] ARM: tegra: use build-in device properties with rfkill_gpio

[Johannes Berg]

On Mon, 2016-01-25 at 13:18 +0100, Thierry Reding wrote:
> 
> Johannes, I assume that you'll want to take this through your tree
> because of the dependency? In that case:
> 
> Acked-by: Thierry Reding 

I can, but I don't really care - perhaps you'd rather take the entire
series through your tree to get it into one place for Marc?

In which case, you have my

Acked-by: Johannes Berg 

for the other 3 patches.

Let me know which you prefer.

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

Re: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Grumbach, Emmanuel]

On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
> It looks like sometimes firmware returns zero for chain noise and signal
> during calibration period. This seems to be a known problem and current
> implementation accounts for this by ignoring invalid data when all chains
> return zero signal and noise.
>
> The problem is that sometimes firmware returns zero for only one chain for
> some (not all) beacons used for calibration. This leads to perfectly valid
> chains be disabled and may cause invalid gain settings.
> For example this is calibration data taken on laptop with Intel 6300 card
> with all three antennas attached:
>
> active_chains: 3
> chain_noise_a: 312
> chain_noise_b: 297
> chain_noise_c: 0
> chain_signal_a:549
> chain_signal_b:513
> chain_signal_c:0
> beacon_count:  16
> disconn_array: 0 0 1
> delta_gain_code:   4 0 0
> radio_write:   1
> state: 3
>
> This patch changes statistics gathering to make sure that zero noise
> results are ignored for valid rx chains. The rationale being that even if
> anntenna is not connected we should be able to see non zero noise if rx
> chain is present.

But then the firmware will continue to send zero for signal and this
will impact lots
of flows like roaming. If the driver allows the firmware to use that
antenna, the
firmware may use this antenna for scanning and roaming will be broken.
This seems to be a bug in the firmware, but there isn't much I can do
about it.
Sorry, I have to NACK this patch.

> This patch fixes the problem of disabling working chains on hardware I
> have (6300 and 5300). With three connected antennas statistics in
> chain_noise looks like this (6300):
>
> active_chains: 7
> chain_noise_a: 321
> chain_noise_b: 243
> chain_noise_c: 311
> chain_signal_a:559
> chain_signal_b:452
> chain_signal_c:512
> beacon_count:  16
> disconn_array: 0 0 0
> delta_gain_code:   4 3 0
> radio_write:   1
> state: 3
>
> It also works fine in case one 3-chain hardware has only two antennas
> attached (tested in 5300):
>
> active_chains: 3
> chain_noise_a: 238
> chain_noise_b: 234
> chain_noise_c: 219
> chain_signal_a:533
> chain_signal_b:514
> chain_signal_c:206
> beacon_count:  16
> disconn_array: 0 0 1
> delta_gain_code:   4 0 0
> radio_write:   1
> state: 3
>
> Signed-off-by: Nikolay Martynov 
> ---
>  drivers/net/wireless/iwlwifi/dvm/calib.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/net/wireless/iwlwifi/dvm/calib.c 
> b/drivers/net/wireless/iwlwifi/dvm/calib.c
> index 20e6aa9..cdaa88d 100644
> --- a/drivers/net/wireless/iwlwifi/dvm/calib.c
> +++ b/drivers/net/wireless/iwlwifi/dvm/calib.c
> @@ -1026,6 +1026,18 @@ void iwl_chain_noise_calibration(struct iwl_priv *priv)
>  
>   spin_unlock_bh(>statistics.lock);
>  
> + /* Sometimes firmware returns zero for chain noise and signal
> +  * even if chain is present and antenna is connected. This
> +  * often results in perfectly valid chains being disabled.
> +  * Ignore statistics if it contains zero noise for valid rx
> +  * chain: even with antenna disconnected we should hear some noise.
> +  */
> + if ((priv->nvm_data->valid_rx_ant & ANT_A && chain_noise_a == 0) ||
> + (priv->nvm_data->valid_rx_ant & ANT_B && chain_noise_b == 0) ||
> + (priv->nvm_data->valid_rx_ant & ANT_C && chain_noise_c == 0)) {
> + return;
> + }
> +
>   data->beacon_count++;
>  
>   data->chain_noise_a = (chain_noise_a + data->chain_noise_a);

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

Re: [PATCHv2 3/4] ARM: tegra: use build-in device propertieswithrfkill_gpio

[Marc Dietrich]

Am Dienstag, 26. Januar 2016, 09:46:56 CET schrieb Johannes Berg:
> On Mon, 2016-01-25 at 21:59 +0100, Marc Dietrich wrote:
> > 
> >
> > seems to work fine. I wish we could instantiate this from device-tree
> > so we can finially get rid of this file.
> 
> That'd be nice - anyone want to propose rfkill DT bindings? :)

There have been at least 5 attempts to do this in the past - all fail. You've 
been warned :-)

Marc



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

Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames

[Johannes Berg]

On Mon, 2016-01-25 at 13:59 +0100, Sven Eckelmann wrote:
> 
> The flag itself has to be set when the radiotap information is
> available+parsed and when the actual rate information calculation
> should
> happen. 
> 
> Afaik the ieee80211_tx_data is always a local variable on the stack.
> Either
> from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or
> ieee80211_get_buffered_bc. But the parsing of the radiotap header
> happens
> before that in ieee80211_monitor_start_xmit. And after that it calls
> ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not
> available when
> the radiotap header is parsed.

Fair enough. We could put that data elsewhere, but it's probably not
worth it for a simple flag.

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

Re: [RFC/RFT v4 2/2] mac80211: add NEED_ALIGNED4_SKBS hw flag

[Johannes Berg]

On Thu, 2016-01-21 at 10:30 +0100, Janusz Dziedzic wrote:
> 
> +static inline unsigned int
> +__ieee80211_hdrlen(struct ieee80211_hw *hw, __le16 fc) {

coding style - should have that brace on the next line

perhaps this really ought to be called

ieee80211_padded_hdrlen() or so instead of just the __.


> + unsigned int hdrlen;
> +
> + hdrlen = ieee80211_hdrlen(fc);
> + if (ieee80211_hw_check(hw, NEEDS_ALIGNED4_SKBS))
> + hdrlen += hdrlen & 3;

This needs a a comment, it only works because the hdrlen is guaranteed
to be a multiple of 2 already. Perhaps it should be & 2 ;-)

> - u8 hdr[30 + 2 + IEEE80211_FAST_XMIT_MAX_IV +
> -    sizeof(rfc1042_header)];
> + u8 hdr[round_up(30 + 2 + IEEE80211_FAST_XMIT_MAX_IV +
> + sizeof(rfc1042_header), 4)];

I'm still not sure this is right, given the position of the padding. It
probably works since MAX_IV and sizeof() are divisible by 4, but
shouldn't it really be

round_up(30 + 2, 4) + MAX_IV + sizeof()?

> + /* Remove padding if was added */
> + if (ieee80211_hw_check(>hw, NEEDS_ALIGNED4_SKBS)) {
> + hdrlen = ieee80211_hdrlen(hdr->frame_control);
> + padsize = hdrlen & 3;

same as above

> + /* Check if HW require skb to be aligned */
> + if (ieee80211_hw_check(>local->hw,
> NEEDS_ALIGNED4_SKBS))
> + padsize = hdrlen & 3;
> 

ditto

Perhaps also extract this if (...) padsize=... into a helper? Although
then the "hdrlen += 0" would remain for !ALIGNED4 drivers.

> + if (padsize)
> + skb_push(skb, padsize);

You should initialize the memory, imho, just in case it goes out
anywhere by accident.
 
> + /* Check if aligned skb required */
> + if (ieee80211_hw_check(>hw, NEEDS_ALIGNED4_SKBS))
> + build.hdr_len += build.hdr_len & 3;

As above.

You also need to clarify - IIRC the PN/IV fields are considered part of
the MAC header even if we don't really take them into account in
hdrlen(), so you should clearly document that the padding is before
those.

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

Re: pull request: iwlwifi 2016-01-26

[Kalle Valo]

"Grumbach, Emmanuel"  writes:

> This is the first round of fixes for 4.5. Most of them are really
> trivial. The TPC stats one stands out a little bit. It can fix traffic
> issues which are typically hard to debug. Please pull and let me know
> if you have issues.

There's a conflict due to 8f57e4d930d, how should I fix it?

diff --cc drivers/net/wireless/intel/iwlwifi/dvm/calib.c
index e9cef9de9ed8,14949efc4a35..
--- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
+++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
@@@ -900,8 -900,8 +900,13 @@@ static void iwlagn_gain_computation(str
  
/* bound gain by 2 bits value max, 3rd bit is sign */
data->delta_gain_code[i] =
++<<< HEAD
 +  min(abs(delta_g),
 +  (s32) CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
++===
+   min_t(u8, abs(delta_g),
+ CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
++>>> c3653efc57d9b3c51ee657a471578d2493b6e3f0
  
if (delta_g < 0)
/*


> I also have a batch of patches for -next, but
> wireless-drivers-next.git doesn't seem ready to accept new patches at
> this stage.

I'll open wireless-drivers-next once net-next is open, but AFAIK Dave
hasn't opened it yet.

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

Re: [RFC V4 1/2] nl80211: add feature for BSS selection support

[Johannes Berg]

On Tue, 2016-01-26 at 14:06 +0100, Arend van Spriel wrote:
> 
> + * @behaviour: requested BSS selection behaviour.
> + * @param: parameters for requestion behaviour.
> + * @band_pref: preferred band for
> %NL80211_BSS_SELECT_ATTR_BAND_PREF.
> + * @adjust: parameters for %NL80211_BSS_SELECT_ATTR_RSSI_ADJUST.

Sadly, I don't think this works with kernel-doc. You'd have to split it
out into a named union to get this working properly.

> +/**
> + * enum nl80211_bss_select_attr - attributes for bss selection.
> + *
> + * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved.
> + * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based BSS 
> selection
> + * is requested.
> + * @NL80211_BSS_SELECT_ATTR_BAND_PREF: attribute indicating BSS
> + *>  > selection should be done such that the specified band is preferred.
> + *>  > When there are multiple BSS-es in the preferred band, the driver
> + *>  > shall use RSSI-based BSS selection as a second step. The value of
> + *>  > this attribute is according to  nl80211_band (u32).
> + * @NL80211_BSS_SELECT_ATTR_RSSI_ADJUST: When present the RSSI level for
> + *>  > BSS-es in the specified band is to be adjusted before doing
> + *>  > RSSI-based BSS selection. The attribute value is a packed two-byte
> + *>  > value. The lower byte contains the adjustment value (s8) and the
> + *   high byte contains the band according  nl80211_band.

I think it might be nicer to define an explicit struct for this, then
you don't have to use u8 for the band in one attribute and u32 for the
band in the other attribute either.

As long as there's no u64 in the struct that's pretty much safe - if
u64 is needed use compat_u64 :)

> + * @NL80211_BSS_SELECT_ATTR_MAX: highest bss select attribute number.
> + *@__NL80211_BSS_SELECT_ATTR_AFTER_LAST: internal use.
> + *
> + * These attributes are found within %NL80211_ATTR_BSS_SELECT and
> + * indicate the required BSS selection behaviour which the driver
> + * should use.

You should probably indicate that only a single one can ever be
specified?

> +static const struct nla_policy
> +nl80211_bss_select_policy[NL80211_BSS_SELECT_ATTR_MAX + 1] = {
> + [NL80211_BSS_SELECT_ATTR_RSSI] = { .type = NLA_FLAG },
> + [NL80211_BSS_SELECT_ATTR_BAND_PREF] = { .type = NLA_U32 },
> + [NL80211_BSS_SELECT_ATTR_RSSI_ADJUST] = { .type = NLA_U8 },

The RSSI_ADJUST here seems wrong in any case? Should've been NLA_U16
now?

> @@ -5753,6 +5778,42 @@ static int validate_scan_freqs(struct nlattr
> *freqs)
>   return n_channels;
>  }
>  
> +static int parse_bss_select(struct nlattr *nla,
> + struct cfg80211_bss_selection
> *bss_select)
> +{
> + struct nlattr *attr[NL80211_BSS_SELECT_ATTR_MAX + 1];
> + u16 band_delta;
> + int err;

This should perhaps reject specification of multiple attributes, since
otherwise the order of the code here dictates which one "wins".


But these are small things - looks good!

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

Re: pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

Hi Kalle,

On 01/26/2016 03:51 PM, Kalle Valo wrote:
> "Grumbach, Emmanuel"  writes:
>
>> This is the first round of fixes for 4.5. Most of them are really
>> trivial. The TPC stats one stands out a little bit. It can fix traffic
>> issues which are typically hard to debug. Please pull and let me know
>> if you have issues.
> There's a conflict due to 8f57e4d930d, how should I fix it?
>
> diff --cc drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> index e9cef9de9ed8,14949efc4a35..
> --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c
> @@@ -900,8 -900,8 +900,13 @@@ static void iwlagn_gain_computation(str
>   
> /* bound gain by 2 bits value max, 3rd bit is sign */
> data->delta_gain_code[i] =
> ++<<< HEAD
>  +  min(abs(delta_g),
>  +  (s32) CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
> ++===
> +   min_t(u8, abs(delta_g),
> + CHAIN_NOISE_MAX_DELTA_GAIN_CODE);
> ++>>> c3653efc57d9b3c51ee657a471578d2493b6e3f0
>   
> if (delta_g < 0)
> /*
>
No, I'll rebase.
thanks.

>> I also have a batch of patches for -next, but
>> wireless-drivers-next.git doesn't seem ready to accept new patches at
>> this stage.
> I'll open wireless-drivers-next once net-next is open, but AFAIK Dave
> hasn't opened it yet.
>

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

Re: pull request: iwlwifi 2016-01-26

[Johannes Berg]

> > There's a conflict due to 8f57e4d930d, how should I fix it?

I think we can thus drop my patch - that commit fixes the issue that
Andrew had reported as well, and that I worked around by casting the
result... now that abs() has a consistent result, using s32 in both
sides of the min() is perfectly fine.

johannes

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

Re: pull request: iwlwifi 2016-01-26

[Grumbach, Emmanuel]

On 01/26/2016 04:01 PM, Johannes Berg wrote:
>>> There's a conflict due to 8f57e4d930d, how should I fix it?
> I think we can thus drop my patch - that commit fixes the issue that
> Andrew had reported as well, and that I worked around by casting the
> result... now that abs() has a consistent result, using s32 in both
> sides of the min() is perfectly fine.
>
> johannes
>
>

I did just that in my new tag: iwlwifi-for-kalle-2016-01-26_2
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values

[Nikolay Martynov]

Hi

2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel :
>
>
> On 01/26/2016 12:20 AM, Nikolay Martynov wrote:
>> It looks like sometimes firmware returns zero for chain noise and signal
>> during calibration period. This seems to be a known problem and current
>> implementation accounts for this by ignoring invalid data when all chains
>> return zero signal and noise.
>>
>> The problem is that sometimes firmware returns zero for only one chain for
>> some (not all) beacons used for calibration. This leads to perfectly valid
>> chains be disabled and may cause invalid gain settings.
>> For example this is calibration data taken on laptop with Intel 6300 card
>> with all three antennas attached:
>>
>> active_chains: 3
>> chain_noise_a: 312
>> chain_noise_b: 297
>> chain_noise_c: 0
>> chain_signal_a:549
>> chain_signal_b:513
>> chain_signal_c:0
>> beacon_count:  16
>> disconn_array: 0 0 1
>> delta_gain_code:   4 0 0
>> radio_write:   1
>> state: 3
>>
>> This patch changes statistics gathering to make sure that zero noise
>> results are ignored for valid rx chains. The rationale being that even if
>> anntenna is not connected we should be able to see non zero noise if rx
>> chain is present.
>
> But then the firmware will continue to send zero for signal and this
> will impact lots
> of flows like roaming. If the driver allows the firmware to use that
> antenna, the
> firmware may use this antenna for scanning and roaming will be broken.
> This seems to be a bug in the firmware, but there isn't much I can do
> about it.
> Sorry, I have to NACK this patch.

  Could you please elaborate on how this patch would affect roaming or
other things. As far as I can see this patch doesn't change much
behavior apart from ignoring invalid values from firmware.
Disconnected antennas still get disabled (as before) connected
antennas still work (more often than before). So I'm not sure I can
see how this patch would change what firmware does at all. I really
hope you could find a moment and explain this.

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

Re: [PATCH v3] dt: bindings: add bindings for ipq4019 wifi block

[Kalle Valo]

Raja Mani  writes:

> Add device tree binding documentation details for wifi block present
> in Qualcomm IPQ4019 SoC into "qcom,ath10k.txt".
>
> Right now, ath10k wireless driver has support for PCI based wlan devices.
> There is a plan to extend ath10k driver to support wifi devices which are
> connected over AHB as well (enumeration will happen via device tree node).
> For AHB based devices (ie, ipq4019), all wifi properties are supplied via
> device tree (including irq, reg addr, cal data,etc).
>
> Signed-off-by: Raja Mani 

Applied, thanks.

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

Re: [PATCH] ath10k: prevent txrx running for too long

[Kalle Valo]

Michal Kazior  writes:

> On multicore systems it was possible for the txrx
> tasklet to keep on running for long periods of
> time on a single CPU due to tx completion
> processing. Another CPU could feed the running
> tasklet for an indefinite amount of time.
>
> The tasklet is now guaranteed to run a finite
> amount of time and is limited by HTT CE Rx ring
> depth.
>
> This improves behavior when RPS is used on target
> system and might improve TCP handling as well.
>
> Signed-off-by: Michal Kazior 

Applied, thanks.

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

Re: [PATCH 0/7] Add support for Per STA Rx duration

[Kalle Valo]

Mohammed Shafi Shajakhan  writes:

> From: Mohammed Shafi Shajakhan 
>
> From: Mohammed Shafi Shajakhan 
>
> *Enable parsing of rx_duration as part of peer stats support
>  by the new 10.2.4 firmware
> *Add support to dump per STA rx_duration  (usecs)
> *Pre-requisite cleanups
> *For calculating total rx-duration in host, enable provision to
>  support periodic peer stats update.
> *Also enable mac80211 debugfs entry to track per STA rx duration(usecs)
>
> Mohammed Shafi Shajakhan (7):
>   ath10k: Add support for parsing per STA rx_duration for 10.2.4
>   ath10k: Fix naming Peer stats rssi_changed field in 10.2.4
>   ath10k: Cleanup setting pdev paramaters
>   ath10k: Rename few function names of firmware stats
>   ath10k: Provision to support periodic peer stats update
>   ath10k: Enable periodic peer stats update
>   ath10k: Add debugfs support for Per STA total rx duration

Applied, thanks.

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

Re: [PATCH] ath10k: Remove the p2p notice of absence info from 10.2.4 FW beacon info

[Kalle Valo]

Yanbo Li  writes:

> The p2p NOA never been supported at 10.2.4 FW, remove it to avoid SWBA
> event parse error for multi beacon interval case.
>
> Signed-off-by: Yanbo Li 

Applied, thanks.

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

Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.

[Ben Greear]

On 01/26/2016 03:16 AM, Johannes Berg wrote:

On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote:


--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -2130,6 +2130,8 @@ enum nl80211_attrs {

NL80211_ATTR_REG_INDOOR,

+   NL80211_ATTR_TX_ADVERT_RATEMASK,


First of all, this is missing documentation. It's a FLAG as far as I
can tell, but if it's set should it affect only the advertised or both?

I also think you added this because I had commented that we might not
want to do it unconditionally, but is there really a good reason not to
do it unconditionally? I was probably more thinking out loud what would
happen with P2P, but there we already say "no cck" for scanning so it
shouldn't really have any effect.


Turns out, I did want this flag.  The reason is that I might want to
advertise as a normal-ish /g station (ie, full /b/g rateset), but
actually fix the TX rate as 24Mbps (or whatever).

So, I do need a way to set an advertise ratemask vs a tx-rate-mask.

With my current patch, and my patches to supplicant, it seems to at least
mostly do what I want, but there is a user-space issue where if you set the 
ADVERT_RATEMASK
on kernels that do not support that flag, it will just set the tx rates 
instead.  Not
the end of the world, but possibly there needs to be a feature flag
that user-space could query for this feature.


But given that we have NL80211_ATTR_SCAN_SUPP_RATES, where does your
patch even have an effect, other than this not handling HT/VHT?

I'm a bit wary that we're introducing two ways of achieving a very
similar thing.

Also, adding these overrides all over the code seems very complex.
Perhaps we can achieve the goal of being able to pretend to have
limited hardware capabilities by actually restricting hardware
capabilities instead? That would also avoid having to play whack-a-mole
with code paths using the device capabilities.

I'd imagine an API along the lines of doing some kind of higher-layer
re-register of the wiphy in mac80211 with limited capabilites. At that
point you'd allocate a copy of the original capabilities (as far as the
new restricted ones overwrite the data), and remove the device from the
system as far as higher layers like cfg80211 are concerned.

Would something like that work for you?


As far as I can tell, that will not work, because I want to have multiple 
station devices
per radio, and have each of them be able to use a different configuration.  So,
one station may be /g, and another /n and another /AC.  Same with APs.  In 
addition,
some stations may want to use all available rates for their mode,
and others may want to use a fixed rate or subset of available rates.

Thanks,
Ben



johannes



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211: fix txq queue related crashes

[Ben Greear]

On 01/25/2016 10:35 PM, Michal Kazior wrote:

On 25 January 2016 at 18:59, Ben Greear  wrote:

On 01/21/2016 05:23 AM, Michal Kazior wrote:


The driver can access the queue simultanously
while mac80211 tears down the interface. Without
spinlock protection this could lead to corrupting
sk_buff_head and subsequently to an invalid
pointer dereference.


Hard to know for certain, but this *appears* to fix the unexpectedly large
amount of CE/AXI ath10k firmware crashes that we saw in the 4.2 kernel (4.0
previously
ran much better han 4.2 for us).


That's impossible.

Without wake_tx_queue() txqs aren't even allocated (sdata->vif.txq is NULL).


You are right.  But while testing, one of my guys did find a way to reproduce 
the
crash very quickly in 4.2.  Happens fastest when I use the HTT-MGT variant
of my firmware, but same firmware works good-ish in 4.0.  Seems I have something
to bisect now if I can get a minimal patch to apply each time to enable my
htt-mgt firmware feature...

The latest test case is to just to change the channel of the AP while station
is connected.  Station sends some null-funcs, firmware resets it's low-level
stuff a bunch because it doesn't get AKCs, then CE/AXI crashes.  Could be
my firmware or kernel modifications of course, though similar crash scenarios 
have been seen forever
in all sorts of firmwares and kernels.

Thanks,
Ben


--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142

[Rafał Miłecki]

It seems 14e4:4365 pattern is too generic as there are two devices:
1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset
2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset
The later one was found in D-Link DIR-885L router and we want to let
brcmfmac handle it.

Signed-off-by: Rafał Miłecki 
---
 drivers/bcma/host_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c
index 0856189..cae5385 100644
--- a/drivers/bcma/host_pci.c
+++ b/drivers/bcma/host_pci.c
@@ -294,7 +294,7 @@ static const struct pci_device_id bcma_pci_bridge_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4358) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4359) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) },
-   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4365) },
+   { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_DELL, 
0x0016) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a0) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) },
{ PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43aa) },
-- 
1.8.4.5

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

[PATCH v3] mac80211: Parse legacy and HT rate in injected frames

[Sven Eckelmann]

Drivers/devices without their own rate control algorithm can get the
information what rates they should use from either the radiotap header of
injected frames or from the rate control algorithm. But the parsing of the
legacy rate information from the radiotap header was removed in commit
e6a9854b05c1 ("mac80211/drivers: rewrite the rate control API").

The removal of this feature heavily reduced the usefulness of frame
injection when wanting to simulate specific transmission behavior. Having
rate parsing together with MCS rates and retry support allows a fine
grained selection of the tx behavior of injected frames for these kind of
tests.

Signed-off-by: Sven Eckelmann 
Cc: Simon Wunderlich 
---
v3:
 - switch order of arguments in ieee80211_parse_tx_radiotap
 - simplify selection of the retry counter
 - move IEEE80211_TX_CTRL_RATE_INJECT check inside ieee80211_tx_h_rate_ctrl
   to let it set use_rts, use_cts_prot, short_preamble
v2:
 - resent RFC as v2 because first patch was not correctly marked as RFC
 - removed check from ieee80211_xmit_fast because this one is never called
   for injected frames
---
 Documentation/networking/mac80211-injection.txt | 17 ++
 include/net/mac80211.h  |  2 +
 net/mac80211/tx.c   | 72 -
 3 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/Documentation/networking/mac80211-injection.txt 
b/Documentation/networking/mac80211-injection.txt
index 3a93007..ec8f934 100644
--- a/Documentation/networking/mac80211-injection.txt
+++ b/Documentation/networking/mac80211-injection.txt
@@ -28,6 +28,23 @@ radiotap headers and used to control injection:
IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for
  an ACK even if it is a unicast frame
 
+ * IEEE80211_RADIOTAP_RATE
+
+   legacy rate for the transmission (only for devices without own rate control)
+
+ * IEEE80211_RADIOTAP_MCS
+
+   HT rate for the transmission (only for devices without own rate control).
+   Also some flags are parsed
+
+   IEEE80211_TX_RC_SHORT_GI: use short guard interval
+   IEEE80211_TX_RC_40_MHZ_WIDTH: send in HT40 mode
+
+ * IEEE80211_RADIOTAP_DATA_RETRIES
+
+   number of retries when either IEEE80211_RADIOTAP_RATE or
+   IEEE80211_RADIOTAP_MCS was used
+
 The injection code can also skip all other currently defined radiotap fields
 facilitating replay of captured radiotap headers directly.
 
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 566df20..3c3c1f3 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -708,12 +708,14 @@ enum mac80211_tx_info_flags {
  * protocol frame (e.g. EAP)
  * @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll
  * frame (PS-Poll or uAPSD).
+ * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information
  *
  * These flags are used in tx_info->control.flags.
  */
 enum mac80211_tx_control_flags {
IEEE80211_TX_CTRL_PORT_CTRL_PROTO   = BIT(0),
IEEE80211_TX_CTRL_PS_RESPONSE   = BIT(1),
+   IEEE80211_TX_CTRL_RATE_INJECT   = BIT(2),
 };
 
 /*
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 3311ce0..723cd7a 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -710,6 +710,10 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx)
 
info->control.short_preamble = txrc.short_preamble;
 
+   /* don't ask rate control when rate already injected via radiotap */
+   if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)
+   return TX_CONTINUE;
+
if (tx->sta)
assoc = test_sta_flag(tx->sta, WLAN_STA_ASSOC);
 
@@ -1665,15 +1669,24 @@ void ieee80211_xmit(struct ieee80211_sub_if_data *sdata,
ieee80211_tx(sdata, sta, skb, false);
 }
 
-static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb)
+static bool ieee80211_parse_tx_radiotap(struct ieee80211_local *local,
+   struct sk_buff *skb)
 {
struct ieee80211_radiotap_iterator iterator;
struct ieee80211_radiotap_header *rthdr =
(struct ieee80211_radiotap_header *) skb->data;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
+   struct ieee80211_supported_band *sband =
+   local->hw.wiphy->bands[info->band];
int ret = ieee80211_radiotap_iterator_init(, rthdr, skb->len,
   NULL);
u16 txflags;
+   u16 rate = 0;
+   bool rate_found = false;
+   u8 rate_retries = 0;
+   u16 rate_flags = 0;
+   u8 mcs_known, mcs_flags;
+   int i;
 
info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT |
   IEEE80211_TX_CTL_DONTFRAG;
@@ -1724,6 +1737,35 @@ static bool ieee80211_parse_tx_radiotap(struct sk_buff 
*skb)
info->flags |= IEEE80211_TX_CTL_NO_ACK;
  

Re: [PATCH v2] mac80211: Parse legacy and HT rate in injected frames

[Sven Eckelmann]

On Tuesday 26 January 2016 14:27:20 Johannes Berg wrote:
> Hi,
> > CALL_TXH(ieee80211_tx_h_select_key);
> > -   if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL))
> > +   if (!ieee80211_hw_check(>local->hw, HAS_RATE_CONTROL) &&
> > +   !(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT))
> > CALL_TXH(ieee80211_tx_h_rate_ctrl);
> 
> This seems a bit problematic. ieee80211_tx_h_rate_ctrl() also sets up
> some protection, e.g.
> 
> info->control.use_rts = txrc.rts;
> info->control.use_cts_prot = tx->sdata->vif.bss_conf.use_cts_prot;
> 
> and preamble settings
> 
> info->control.short_preamble = txrc.short_preamble;
> 
> Are you sure you want to skip that entirely?

You are correct, these should be set but rate_control_get_rate should be 
skipped.

> 
> > +   info->control.rates[0].flags = rate_flags;
> > +   if (rate_retries + 1 > local->hw.max_rate_tries)
> > +   info->control.rates[0].count = local-
> > >hw.max_rate_tries;
> > +   else
> > +   info->control.rates[0].count = rate_retries
> > + 1;
> 
> max() or max_t()?

min_t - but yes, you are right.

Btw. we can also change it when you prefer that by default injected frames 
with rates but without DATA_RETRIES should get local->hw.max_rate_tries as 
retries.

> 
> > /* process and remove the injection radiotap header */
> > -   if (!ieee80211_parse_tx_radiotap(skb))
> > +   if (!ieee80211_parse_tx_radiotap(skb, local))
> > goto fail;
> 
> I'd prefer adding "local" as the first argument since that's far more
> commonly done in mac80211.

Ok, will be changed.

Kind regards,
Sven

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

Re: [PATCH 17/26] mac802154: Use skcipher

[Stefan Schmidt]

Hello.

On 24/01/16 14:18, Herbert Xu wrote:

This patch replaces uses of blkcipher with skcipher.

Signed-off-by: Herbert Xu 

---

  net/mac802154/llsec.c |   41 +++--
  net/mac802154/llsec.h |3 +--
  2 files changed, 24 insertions(+), 20 deletions(-)

diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c
index a13d02b..6a3e1c2 100644
--- a/net/mac802154/llsec.c
+++ b/net/mac802154/llsec.c
@@ -17,9 +17,9 @@
  #include 
  #include 
  #include 
-#include 
  #include 
  #include 
+#include 
  
  #include "ieee802154_i.h"

  #include "llsec.h"
@@ -144,18 +144,18 @@ llsec_key_alloc(const struct ieee802154_llsec_key 
*template)
goto err_tfm;
}
  
-	key->tfm0 = crypto_alloc_blkcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);

+   key->tfm0 = crypto_alloc_skcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC);
if (IS_ERR(key->tfm0))
goto err_tfm;
  
-	if (crypto_blkcipher_setkey(key->tfm0, template->key,

-   IEEE802154_LLSEC_KEY_SIZE))
+   if (crypto_skcipher_setkey(key->tfm0, template->key,
+  IEEE802154_LLSEC_KEY_SIZE))
goto err_tfm0;
  
  	return key;
  
  err_tfm0:

-   crypto_free_blkcipher(key->tfm0);
+   crypto_free_skcipher(key->tfm0);
  err_tfm:
for (i = 0; i < ARRAY_SIZE(key->tfm); i++)
if (key->tfm[i])
@@ -175,7 +175,7 @@ static void llsec_key_release(struct kref *ref)
for (i = 0; i < ARRAY_SIZE(key->tfm); i++)
crypto_free_aead(key->tfm[i]);
  
-	crypto_free_blkcipher(key->tfm0);

+   crypto_free_skcipher(key->tfm0);
kzfree(key);
  }
  
@@ -620,15 +620,17 @@ llsec_do_encrypt_unauth(struct sk_buff *skb, const struct mac802154_llsec *sec,

  {
u8 iv[16];
struct scatterlist src;
-   struct blkcipher_desc req = {
-   .tfm = key->tfm0,
-   .info = iv,
-   .flags = 0,
-   };
+   SKCIPHER_REQUEST_ON_STACK(req, key->tfm0);
+   int err;
  
  	llsec_geniv(iv, sec->params.hwaddr, >sec);

sg_init_one(, skb->data, skb->len);
-   return crypto_blkcipher_encrypt_iv(, , , skb->len);
+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , skb->len, iv);
+   err = crypto_skcipher_encrypt(req);
+   skcipher_request_zero(req);
+   return err;
  }
  
  static struct crypto_aead*

@@ -830,11 +832,8 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct 
mac802154_llsec *sec,
unsigned char *data;
int datalen;
struct scatterlist src;
-   struct blkcipher_desc req = {
-   .tfm = key->tfm0,
-   .info = iv,
-   .flags = 0,
-   };
+   SKCIPHER_REQUEST_ON_STACK(req, key->tfm0);
+   int err;
  
  	llsec_geniv(iv, dev_addr, >sec);

data = skb_mac_header(skb) + skb->mac_len;
@@ -842,7 +841,13 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct 
mac802154_llsec *sec,
  
  	sg_init_one(, data, datalen);
  
-	return crypto_blkcipher_decrypt_iv(, , , datalen);

+   skcipher_request_set_tfm(req, key->tfm0);
+   skcipher_request_set_callback(req, 0, NULL, NULL);
+   skcipher_request_set_crypt(req, , , datalen, iv);
+
+   err = crypto_skcipher_decrypt(req);
+   skcipher_request_zero(req);
+   return err;
  }
  
  static int

diff --git a/net/mac802154/llsec.h b/net/mac802154/llsec.h
index 950578e..6f3b658 100644
--- a/net/mac802154/llsec.h
+++ b/net/mac802154/llsec.h
@@ -19,7 +19,6 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  #include 
@@ -30,7 +29,7 @@ struct mac802154_llsec_key {
  
  	/* one tfm for each authsize (4/8/16) */

struct crypto_aead *tfm[3];
-   struct crypto_blkcipher *tfm0;
+   struct crypto_skcipher *tfm0;
  
  	struct kref ref;

  };


Reviewed-by: Stefan Schmidt 

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

[PATCH 2/5] brcmfmac: allow storing PMU core without wrapper address

[Rafał Miłecki]

Separated PMU core can be found in new devices and should be used for
accessing PMU registers (which were routed through ChipCommon so far).
This core is one of exceptions that doesn't have or need wrapper address
to be still safely accessible.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index e434e2a..55952d4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -883,7 +883,8 @@ int brcmf_chip_dmp_erom_scan(struct brcmf_chip_priv *ci)
rev = (val & DMP_COMP_REVISION) >> DMP_COMP_REVISION_S;
 
/* need core with ports */
-   if (nmw + nsw == 0)
+   if (nmw + nsw == 0 &&
+   id != BCMA_CORE_PMU)
continue;
 
/* try to obtain register address info */
-- 
1.8.4.5

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

[PATCH 0/5] brcmfmac: support for new 14e43:4365 card with BCM4366

[Rafał Miłecki]

I got D-Link DIR-885L with two 14e4:4365 PCI cards both using BCM4366 chipset.
It seems to have newer ChipCommon and separated PMU core so I needed these
patches on top of recent Broadcom's work.

Please note this patchset depends on:
[PATCH 2/2] bcma: support PMU present as separated bus core
as I had to use BCMA_CC_CAP_EXT_AOB_PRESENT.

Rafał Miłecki (5):
  brcmfmac: analyze descriptors of current component only
  brcmfmac: allow storing PMU core without wrapper address
  brcmfmac: read extended capabilities of ChipCommon core
  brcmfmac: access PMU registers using standalone PMU core if available
  brcmfmac: add support for 14e4:4365 PCI ID with BCM4366 chipset

 .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 45 ++
 .../wireless/broadcom/brcm80211/brcmfmac/chip.h|  3 ++
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c|  4 ++
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  9 ++---
 4 files changed, 49 insertions(+), 12 deletions(-)

-- 
1.8.4.5

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

[PATCH 4/5] brcmfmac: access PMU registers using standalone PMU core if available

[Rafał Miłecki]

On recent Broadcom chipsets PMU is present as separated core and it
can't be accessed using ChipCommon anymore as it fails with e.g.:
[   18.198412] Unhandled fault: imprecise external abort (0x1406) at 0xb6da200f

Add a new helper function that will return a proper core that should be
used for accessing PMU registers.

Signed-off-by: Rafał Miłecki 
---
 .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 30 ++
 .../wireless/broadcom/brcm80211/brcmfmac/chip.h|  1 +
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  9 +++
 3 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index f4a4d00..0e8f2a0 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1014,6 +1014,7 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip)
 {
struct brcmf_chip *pub;
struct brcmf_core_priv *cc;
+   struct brcmf_core *pmu;
u32 base;
u32 val;
int ret = 0;
@@ -1030,9 +1031,10 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip)
 capabilities_ext));
 
/* get pmu caps & rev */
+   pmu = brcmf_chip_get_pmu(pub); /* after reading cc_caps_ext */
if (pub->cc_caps & CC_CAP_PMU) {
val = chip->ops->read32(chip->ctx,
-   CORE_CC_REG(base, pmucapabilities));
+   CORE_CC_REG(pmu->base, 
pmucapabilities));
pub->pmurev = val & PCAP_REV_MASK;
pub->pmucaps = val;
}
@@ -1131,6 +1133,23 @@ struct brcmf_core *brcmf_chip_get_chipcommon(struct 
brcmf_chip *pub)
return >pub;
 }
 
+struct brcmf_core *brcmf_chip_get_pmu(struct brcmf_chip *pub)
+{
+   struct brcmf_core *cc = brcmf_chip_get_chipcommon(pub);
+   struct brcmf_core *pmu;
+
+   /* See if there is separated PMU core available */
+   if (cc->rev >= 35 &&
+   pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) {
+   pmu = brcmf_chip_get_core(pub, BCMA_CORE_PMU);
+   if (pmu)
+   return pmu;
+   }
+
+   /* Fallback to ChipCommon core for older hardware */
+   return cc;
+}
+
 bool brcmf_chip_iscoreup(struct brcmf_core *pub)
 {
struct brcmf_core_priv *core;
@@ -1301,6 +1320,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
 {
u32 base, addr, reg, pmu_cc3_mask = ~0;
struct brcmf_chip_priv *chip;
+   struct brcmf_core *pmu = brcmf_chip_get_pmu(pub);
 
brcmf_dbg(TRACE, "Enter\n");
 
@@ -1320,9 +1340,9 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
case BRCM_CC_4335_CHIP_ID:
case BRCM_CC_4339_CHIP_ID:
/* read PMU chipcontrol register 3 */
-   addr = CORE_CC_REG(base, chipcontrol_addr);
+   addr = CORE_CC_REG(pmu->base, chipcontrol_addr);
chip->ops->write32(chip->ctx, addr, 3);
-   addr = CORE_CC_REG(base, chipcontrol_data);
+   addr = CORE_CC_REG(pmu->base, chipcontrol_data);
reg = chip->ops->read32(chip->ctx, addr);
return (reg & pmu_cc3_mask) != 0;
case BRCM_CC_43430_CHIP_ID:
@@ -1330,12 +1350,12 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub)
reg = chip->ops->read32(chip->ctx, addr);
return reg != 0;
default:
-   addr = CORE_CC_REG(base, pmucapabilities_ext);
+   addr = CORE_CC_REG(pmu->base, pmucapabilities_ext);
reg = chip->ops->read32(chip->ctx, addr);
if ((reg & PCAPEXT_SR_SUPPORTED_MASK) == 0)
return false;
 
-   addr = CORE_CC_REG(base, retention_ctl);
+   addr = CORE_CC_REG(pmu->base, retention_ctl);
reg = chip->ops->read32(chip->ctx, addr);
return (reg & (PMU_RCTL_MACPHY_DISABLE_MASK |
   PMU_RCTL_LOGIC_DISABLE_MASK)) == 0;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
index cb9145f..dd0ec3e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
@@ -85,6 +85,7 @@ struct brcmf_chip *brcmf_chip_attach(void *ctx,
 void brcmf_chip_detach(struct brcmf_chip *chip);
 struct brcmf_core *brcmf_chip_get_core(struct brcmf_chip *chip, u16 coreid);
 struct brcmf_core *brcmf_chip_get_chipcommon(struct brcmf_chip *chip);
+struct brcmf_core *brcmf_chip_get_pmu(struct brcmf_chip *pub);
 bool brcmf_chip_iscoreup(struct brcmf_core *core);
 void brcmf_chip_coredisable(struct brcmf_core *core, u32 prereset, u32 reset);
 void brcmf_chip_resetcore(struct brcmf_core *core, u32 

[PATCH 5/5] brcmfmac: add support for 14e4:4365 PCI ID with BCM4366 chipset

[Rafał Miłecki]

On Broadcom ARM routers BCM4366 cards are available with 14e4:4365 ID.
Unfortunately this ID was already used by Broadcom for cards with
BCM43142, a totally different chipset requiring SoftMAC driver. To avoid
a conflict between brcmfmac and bcma use more specific ID entry with
subvendor and subdevice specified.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 0480b70..d5f9ef4 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -1951,6 +1951,9 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = {
 
 #define BRCMF_PCIE_DEVICE(dev_id)  { BRCM_PCIE_VENDOR_ID_BROADCOM, dev_id,\
PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_NETWORK_OTHER << 8, 0x00, 0 }
+#define BRCMF_PCIE_DEVICE_SUB(dev_id, subvend, subdev) { \
+   BRCM_PCIE_VENDOR_ID_BROADCOM, dev_id,\
+   subvend, subdev, PCI_CLASS_NETWORK_OTHER << 8, 0x00, 0 }
 
 static struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID),
@@ -1966,6 +1969,7 @@ static struct pci_device_id brcmf_pcie_devid_table[] = {
BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_5G_DEVICE_ID),
+   BRCMF_PCIE_DEVICE_SUB(0x4365, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4365),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_2G_DEVICE_ID),
BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID),
-- 
1.8.4.5

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

[PATCH 1/5] brcmfmac: analyze descriptors of current component only

[Rafał Miłecki]

So far we were looking for address descriptors without a check for
crossing current component border. In case of dealing with unsupported
descriptor or descriptor missing at all the code would incorrectly get
data from another component.

Consider this binary-described component from BCM4366 EROM:
4bf83b01TAG==CI CID==0x83b
20080201TAG==CI PORTS==0+1  WRAPPERS==0+1
18400035TAG==ADDR   SZ_SZD  TYPE_SLAVE
0005
18107085TAG==ADDR   SZ_4K   TYPE_SWRAP

Driver was assigning invalid base address to this core:
brcmfmac:  [6 ] core 0x83b:32 base 0x18109000 wrap 0x18107000
which came from totally different component defined in EROM:
43b36701TAG==CI CID==0x367
0201TAG==CI PORTS==0+1  WRAPPERS==0+0
18109005TAG==ADDR   SZ_4K   TYPE_SLAVE

This change will also allow us to support components without wrapper
address in the future.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 82e4382..e434e2a 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -803,7 +803,14 @@ static int brcmf_chip_dmp_get_regaddr(struct 
brcmf_chip_priv *ci, u32 *eromaddr,
*eromaddr -= 4;
return -EFAULT;
}
-   } while (desc != DMP_DESC_ADDRESS);
+   } while (desc != DMP_DESC_ADDRESS &&
+desc != DMP_DESC_COMPONENT);
+
+   /* stop if we crossed current component border */
+   if (desc == DMP_DESC_COMPONENT) {
+   *eromaddr -= 4;
+   return 0;
+   }
 
/* skip upper 32-bit address descriptor */
if (val & DMP_DESC_ADDRSIZE_GT32)
-- 
1.8.4.5

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

[PATCH 3/5] brcmfmac: read extended capabilities of ChipCommon core

[Rafał Miłecki]

This is an extra bitfield with info about some present hardware.

Signed-off-by: Rafał Miłecki 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 3 +++
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
index 55952d4..f4a4d00 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c
@@ -1025,6 +1025,9 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip)
/* get chipcommon capabilites */
pub->cc_caps = chip->ops->read32(chip->ctx,
 CORE_CC_REG(base, capabilities));
+   pub->cc_caps_ext = chip->ops->read32(chip->ctx,
+CORE_CC_REG(base,
+capabilities_ext));
 
/* get pmu caps & rev */
if (pub->cc_caps & CC_CAP_PMU) {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
index f6b5fee..cb9145f 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h
@@ -27,6 +27,7 @@
  * @chip: chip identifier.
  * @chiprev: chip revision.
  * @cc_caps: chipcommon core capabilities.
+ * @cc_caps_ext: chipcommon core extended capabilities.
  * @pmucaps: PMU capabilities.
  * @pmurev: PMU revision.
  * @rambase: RAM base address (only applicable for ARM CR4 chips).
@@ -38,6 +39,7 @@ struct brcmf_chip {
u32 chip;
u32 chiprev;
u32 cc_caps;
+   u32 cc_caps_ext;
u32 pmucaps;
u32 pmurev;
u32 rambase;
-- 
1.8.4.5

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

Re: [PATCH 4/5] brcmfmac: access PMU registers using standalone PMU core if available

[kbuild test robot]

Hi Rafał,

[auto build test ERROR on wireless-drivers/master]
[also build test ERROR on v4.5-rc1 next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-support-for-new-14e43-4365-card-with-BCM4366/20160127-010149
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
master
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function 
'brcmf_chip_get_pmu':
>> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1143:25: error: 
>> 'BCMA_CC_CAP_EXT_AOB_PRESENT' undeclared (first use in this function)
 pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) {
^
   drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1143:25: note: each 
undeclared identifier is reported only once for each function it appears in

vim +/BCMA_CC_CAP_EXT_AOB_PRESENT +1143 
drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c

  1137  {
  1138  struct brcmf_core *cc = brcmf_chip_get_chipcommon(pub);
  1139  struct brcmf_core *pmu;
  1140  
  1141  /* See if there is separated PMU core available */
  1142  if (cc->rev >= 35 &&
> 1143  pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) {
  1144  pmu = brcmf_chip_get_core(pub, BCMA_CORE_PMU);
  1145  if (pmu)
  1146  return pmu;

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


.config.gz
Description: Binary data

[PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

[Cong Wang]

Reported-by: Dmitry Vyukov 
Cc: Lauro Ramos Venancio 
Cc: Aloisio Almeida Jr 
Cc: Samuel Ortiz 
Signed-off-by: Cong Wang 
---
 net/nfc/llcp_commands.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 3621a90..5d94055 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -729,7 +729,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 
ssap, u8 dsap,
if (local == NULL)
return -ENODEV;
 
-   msg_data = kzalloc(len, GFP_KERNEL);
+   msg_data = kzalloc(len, GFP_USER | __GFP_NOWARN);
if (msg_data == NULL)
return -ENOMEM;
 
-- 
1.8.3.1

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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Bob Copeland]

On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote:
> > +   mpp = node->mpath;
> > +   if (ether_addr_equal(mpp->mpp, proxy)) {
> > +   spin_lock(>hashwlock[i]);
> > +   __mesh_path_del(tbl, node);
> > +   spin_unlock(>hashwlock[i]);
> 
> It also doesn't seem like for_each_mesh_entry() can deal with "node"
> getting deleted from underneath it? It accesses it through
> hlist_next_rcu() after the deletion, so you have a use-after-free here
> afaict.

But __mesh_path_del() doesn't free it immediately: it does:

hlist_del_rcu(>list);
call_rcu(>rcu, mesh_path_node_reclaim);

...so this should be ok if in an rcu read-side critical section, right?

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Henning Rogge]

On Tue, Jan 26, 2016 at 7:36 PM, Bob Copeland  wrote:
> On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote:
>> > +   mpp = node->mpath;
>> > +   if (ether_addr_equal(mpp->mpp, proxy)) {
>> > +   spin_lock(>hashwlock[i]);
>> > +   __mesh_path_del(tbl, node);
>> > +   spin_unlock(>hashwlock[i]);
>>
>> It also doesn't seem like for_each_mesh_entry() can deal with "node"
>> getting deleted from underneath it? It accesses it through
>> hlist_next_rcu() after the deletion, so you have a use-after-free here
>> afaict.
>
> But __mesh_path_del() doesn't free it immediately: it does:
>
> hlist_del_rcu(>list);
> call_rcu(>rcu, mesh_path_node_reclaim);
>
> ...so this should be ok if in an rcu read-side critical section, right?

The code is a direct copy what was going on the the cleanup path of
the mpath objects... just modified to run on the mpp objects.

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

Re: [PATCH 13/13] ath10k: implement push-pull tx

[Peter Oh]

On 01/26/2016 02:28 AM, Michal Kazior wrote:

On 22 January 2016 at 08:47, Michal Kazior  wrote:

On 21 January 2016 at 18:40, Peter Oh  wrote:

On 01/21/2016 05:46 AM, Michal Kazior wrote:

[...]

   - /* TODO: apply configuration */
+   rcu_read_unlock();
+
+   spin_lock_bh(>htt.tx_lock);
+   ath10k_mac_tx_lock(ar, ATH10K_TX_PAUSE_Q_FLUSH_PENDING);
+   spin_unlock_bh(>htt.tx_lock);
+

Isn't it proved it break Mesh from working?

Yes, good point. I'm still working on this - I should've mentioned
that in the cover letter.

Nonetheless I wanted to get the review process going for this patchset.

I'll address the mesh problem in v2.

For the record - the problem turned out to be a bug in mac80211 mesh
fwding, see:

   https://patchwork.kernel.org/patch/8108711/

I've verified that the patch fixed the mesh issue.
Thank you Michal.



Michał


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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Johannes Berg]

On Tue, 2016-01-26 at 13:36 -0500, Bob Copeland wrote:
> On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote:
> > > + mpp = node->mpath;
> > > + if (ether_addr_equal(mpp->mpp, proxy)) {
> > > + spin_lock(>hashwlock[i]);
> > > + __mesh_path_del(tbl, node);
> > > + spin_unlock(>hashwlock[i]);
> > 
> > It also doesn't seem like for_each_mesh_entry() can deal with
> > "node"
> > getting deleted from underneath it? It accesses it through
> > hlist_next_rcu() after the deletion, so you have a use-after-free
> > here
> > afaict.
> 
> But __mesh_path_del() doesn't free it immediately: it does:
> 
> hlist_del_rcu(>list);
> call_rcu(>rcu, mesh_path_node_reclaim);
> 
> ...so this should be ok if in an rcu read-side critical section,
> right?

Oh. Interesting. Yeah, I guess that should be OK then.

It's not *nice*, since that's pretty much unexpected, and you then do
need the rcu_read_lock() ... hmm.

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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Bob Copeland]

On Tue, Jan 26, 2016 at 09:53:33PM +0100, Johannes Berg wrote:
> Oh. Interesting. Yeah, I guess that should be OK then.
> 
> It's not *nice*, since that's pretty much unexpected, and you then do
> need the rcu_read_lock() ... hmm.

Yeah, I puzzled over that a bit last week as well -- I rewrote it like
this in the series I haven't posted yet:

void mesh_path_flush_by_nexthop(struct sta_info *sta)
{
[...]
rhashtable_walk_start();
while ((mpath = rhashtable_walk_next())) {
if (IS_ERR(mpath) && PTR_ERR(mpath) == -EAGAIN)
continue;
if (IS_ERR(mpath))
break;

if (rcu_access_pointer(mpath->next_hop) == sta)
__mesh_path_del(tbl, mpath);
}
rhashtable_walk_stop();
[...]
}

...this still relies on the rcu read lock inside _walk_start and _walk_stop,
though.

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Johannes Berg]

On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote:
> 
> void mesh_path_flush_by_nexthop(struct sta_info *sta)
> {
> [...]
>   rhashtable_walk_start();

It seems you need to check the return value here?

>   while ((mpath = rhashtable_walk_next())) {
>   if (IS_ERR(mpath) && PTR_ERR(mpath) == -EAGAIN)
>   continue;
>   if (IS_ERR(mpath))
>   break;
> 
>   if (rcu_access_pointer(mpath->next_hop) == sta)
>   __mesh_path_del(tbl, mpath);
>   }
>   rhashtable_walk_stop();
> [...]
> }
> 
> ...this still relies on the rcu read lock inside _walk_start and
> _walk_stop, though.

At least that's kinda hidden in walk_start/stop though ;-)

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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Johannes Berg]

On Tue, 2016-01-26 at 22:31 +0100, Johannes Berg wrote:
> On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote:
> >  
> > void mesh_path_flush_by_nexthop(struct sta_info *sta)
> > {
> > [...]
> > rhashtable_walk_start();
> 
> It seems you need to check the return value here?
> 

Actually, maybe not. Not sure I understand the return to beginning
though.

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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Bob Copeland]

On Tue, Jan 26, 2016 at 10:32:23PM +0100, Johannes Berg wrote:
> On Tue, 2016-01-26 at 22:31 +0100, Johannes Berg wrote:
> > On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote:
> > >  
> > > void mesh_path_flush_by_nexthop(struct sta_info *sta)
> > > {
> > > [...]
> > >   rhashtable_walk_start();
> > 
> > It seems you need to check the return value here?
> > 
> 
> Actually, maybe not. Not sure I understand the return to beginning
> though.

I'll RFC that patch, it doesn't work right now anyway as
rhashtable_walk_init() does a GFP_KERNEL allocation and we want to call
it from the RX path (maybe not a good idea, but that's what the code
currently does).

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] mac80211: avoid excessive stack usage in sta_info

[Arnd Bergmann]

When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish
function consumes more stack than normally, exceeding the
1024 byte limit on ARM:

net/mac80211/sta_info.c: In function 'sta_info_insert_finish':
net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger 
than 1024 bytes [-Werror=frame-larger-than=]

It turns out that there are two functions that put a 'struct station_info'
on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and
this structure alone requires up to 792 bytes.

Hoping that both are called rarely enough, this replaces the
on-stack structure with a dynamic allocation, which unfortunately
requires some suboptimal error handling for out-of-memory.

The __sta_info_destroy_part2 function is actually affected by the
stack usage twice because it calls cfg80211_del_sta_sinfo(), which
has another instance of struct station_info on its stack.

Signed-off-by: Arnd Bergmann 
Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events")
Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event")
---
 net/mac80211/sta_info.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 4402ad5b27d1..a29199ec4c3c 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -498,11 +498,17 @@ static int sta_info_insert_finish(struct sta_info *sta) 
__acquires(RCU)
 {
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
-   struct station_info sinfo;
+   struct station_info *sinfo;
int err = 0;
 
lockdep_assert_held(>sta_mtx);
 
+   sinfo = kzalloc(sizeof(struct station_info), GFP_KERNEL);
+   if (!sinfo) {
+   err = -ENOMEM;
+   goto out_err;
+   }
+
/* check if STA exists already */
if (sta_info_get_bss(sdata, sta->sta.addr)) {
err = -EEXIST;
@@ -534,10 +540,9 @@ static int sta_info_insert_finish(struct sta_info *sta) 
__acquires(RCU)
ieee80211_sta_debugfs_add(sta);
rate_control_add_sta_debugfs(sta);
 
-   memset(, 0, sizeof(sinfo));
-   sinfo.filled = 0;
-   sinfo.generation = local->sta_generation;
-   cfg80211_new_sta(sdata->dev, sta->sta.addr, , GFP_KERNEL);
+   sinfo->generation = local->sta_generation;
+   cfg80211_new_sta(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL);
+   kfree(sinfo);
 
sta_dbg(sdata, "Inserted STA %pM\n", sta->sta.addr);
 
@@ -898,7 +903,7 @@ static void __sta_info_destroy_part2(struct sta_info *sta)
 {
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
-   struct station_info sinfo = {};
+   struct station_info *sinfo;
int ret;
 
/*
@@ -936,8 +941,11 @@ static void __sta_info_destroy_part2(struct sta_info *sta)
 
sta_dbg(sdata, "Removed STA %pM\n", sta->sta.addr);
 
-   sta_set_sinfo(sta, );
-   cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, , GFP_KERNEL);
+   sinfo = kzalloc(sizeof(*sinfo), GFP_KERNEL);
+   if (sinfo)
+   sta_set_sinfo(sta, sinfo);
+   cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL);
+   kfree(sinfo);
 
rate_control_remove_sta_debugfs(sta);
ieee80211_sta_debugfs_remove(sta);
-- 
2.7.0

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

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

[Julian Calaby]

Hi Cong,

On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang  wrote:

A commit message would be nice. A brief rundown of how this is called
from userspace would be nice (I'm talking a single sentence here, e.g.
"this is allocated when submitting a nfc packet") and what issue
__GFP_NOWARN is fixing. (I'm guessing log spam due to allocation
failures.)

> Reported-by: Dmitry Vyukov 
> Cc: Lauro Ramos Venancio 
> Cc: Aloisio Almeida Jr 
> Cc: Samuel Ortiz 
> Signed-off-by: Cong Wang 
> ---
>  net/nfc/llcp_commands.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
> index 3621a90..5d94055 100644
> --- a/net/nfc/llcp_commands.c
> +++ b/net/nfc/llcp_commands.c
> @@ -729,7 +729,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 
> ssap, u8 dsap,
> if (local == NULL)
> return -ENODEV;
>
> -   msg_data = kzalloc(len, GFP_KERNEL);
> +   msg_data = kzalloc(len, GFP_USER | __GFP_NOWARN);
> if (msg_data == NULL)
> return -ENOMEM;

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

[Cong Wang]

On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby  wrote:
> Hi Cong,
>
> On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang  wrote:
>
> A commit message would be nice. A brief rundown of how this is called
> from userspace would be nice (I'm talking a single sentence here, e.g.
> "this is allocated when submitting a nfc packet") and what issue
> __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation
> failures.)
>

I thought it is obvious. ;) Keep in mind that $subject is one part of commit
message too, so there is a commit message although very short.

I will add it.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

[Julian Calaby]

Hi Cong,

On Wed, Jan 27, 2016 at 10:12 AM, Cong Wang  wrote:
> On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby  
> wrote:
>> Hi Cong,
>>
>> On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang  wrote:
>>
>> A commit message would be nice. A brief rundown of how this is called
>> from userspace would be nice (I'm talking a single sentence here, e.g.
>> "this is allocated when submitting a nfc packet") and what issue
>> __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation
>> failures.)
>>
>
> I thought it is obvious. ;) Keep in mind that $subject is one part of commit
> message too, so there is a commit message although very short.
>
> I will add it.

I know almost nothing about how the NFC subsystem works, and this
looks like a potential security issue, so more information is better
IMHO.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: let unused MPP table entries timeout

[Bob Copeland]

On Tue, Jan 19, 2016 at 09:04:32AM +0100, Henning Rogge wrote:
>   err = -ENXIO;
> -enddel:
> +enddelpath:

Concur about it being better to leave this label alone, also the diff looks
weird because it continues:

> + mesh_paths_generation++;
> + spin_unlock(>hashwlock[hash_idx]);
> + read_unlock_bh(_resize_lock);
> + return err;
> +}

[...]

> + err = -ENXIO;
> +enddelmpp:
>   mesh_paths_generation++;
>   spin_unlock(>hashwlock[hash_idx]);
>   read_unlock_bh(_resize_lock);

At first I wondered why the last half of the function was changed, but then
I saw that.  Shouldn't the above be "mpp_paths_generation++;"?

In general I'd like to merge these two into one function; the only thing
different is the initial table pointer that gets dereferenced and the
generation counter (and now the labels).  So something like this should
be doable:

static int mesh_table_delete(struct ieee80211_sub_if_data *sdata,
 struct mesh_table *tbl,
 const u8 *addr)
{
/* basically what mesh_path_del is today */
}

int mesh_path_del(...)
{
tbl = resize_dereference_mesh_paths();
ret = mesh_table_delete(sdata, tbl, addr);
mesh_paths_generation++;
return ret;
}

int mpp_path_del(...)
{
tbl = resize_dereference_mpp_paths();
ret = mesh_table_delete(sdata, tbl, addr);
mpp_paths_generation++;
return ret;
}

-- 
Bob Copeland %% http://bobcopeland.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc

[Eric Dumazet]

On Tue, 2016-01-26 at 15:12 -0800, Cong Wang wrote:
> On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby  
> wrote:
> > Hi Cong,
> >
> > On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang  wrote:
> >
> > A commit message would be nice. A brief rundown of how this is called
> > from userspace would be nice (I'm talking a single sentence here, e.g.
> > "this is allocated when submitting a nfc packet") and what issue
> > __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation
> > failures.)
> >
> 
> I thought it is obvious. ;) Keep in mind that $subject is one part of commit
> message too, so there is a commit message although very short.
> 
> I will add it.


BTW, kzalloc() is useless here, since it is followed by

if (memcpy_from_msg(msg_data, msg, len)) {

Also, this file seems to have two spots with the same problem,
in nfc_llcp_send_ui_frame() & nfc_llcp_send_i_frame()



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

[PATCH 01/13] staging: wilc1000: wilc_frmw_to_linux(): fixes null check

[Glen Lee]

From: Leo Kim 

Null checking wilc_netdev and skb->dev are already done in the begining of the
function and they are just print printing error log, so delete them.
Null checking wilc is needed before is used so add null ckeck before it is
used.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index ee779ee..db91a21 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1342,6 +1342,9 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 
size, u32 pkt_offset)
struct net_device *wilc_netdev;
struct wilc_vif *vif;
 
+   if (!wilc)
+   return;
+
wilc_netdev = get_if_handler(wilc, buff);
if (!wilc_netdev)
return;
@@ -1358,14 +1361,8 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 
size, u32 pkt_offset)
PRINT_ER("Low memory - packet droped\n");
return;
}
-
-   if (!wilc || !wilc_netdev)
-   PRINT_ER("wilc_netdev in wilc is NULL");
skb->dev = wilc_netdev;
 
-   if (!skb->dev)
-   PRINT_ER("skb->dev is NULL\n");
-
memcpy(skb_put(skb, frame_len), buff_to_send, frame_len);
 
skb->protocol = eth_type_trans(skb, wilc_netdev);
-- 
1.9.1

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

[PATCH 02/13] staging: wilc1000: fixes no space is necessary after a cast

[Glen Lee]

From: Leo Kim 

This patch fixes the check reported by checkpatch.pl
for 'no space is necessary after a cast'.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index db91a21..9552469 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1287,7 +1287,7 @@ static int mac_ioctl(struct net_device *ndev, struct 
ifreq *req, int cmd)
switch (cmd) {
case SIOCSIWPRIV:
{
-   struct iwreq *wrq = (struct iwreq *) req;
+   struct iwreq *wrq = (struct iwreq *)req;
 
size = wrq->u.data.length;
 
-- 
1.9.1

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

[PATCH 05/13] staging: wilc1000: rename Firmware_ver variable

[Glen Lee]

From: Leo Kim 

This patch renames Firmware_ver variable to firmware_ver to avoid camelcase.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 15 ---
 1 file changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 06c79dd..fd405b0 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -929,13 +929,14 @@ int wilc1000_wlan_init(struct net_device *dev, struct 
wilc_vif *vif)
 
if (wilc_wlan_cfg_get(vif, 1, WID_FIRMWARE_VERSION, 1, 0)) {
int size;
-   char Firmware_ver[20];
-
-   size = wilc_wlan_cfg_get_val(
-   WID_FIRMWARE_VERSION,
-   Firmware_ver, sizeof(Firmware_ver));
-   Firmware_ver[size] = '\0';
-   PRINT_D(INIT_DBG, "* Firmware Ver = %s  ***\n", 
Firmware_ver);
+   char firmware_ver[20];
+
+   size = wilc_wlan_cfg_get_val(WID_FIRMWARE_VERSION,
+firmware_ver,
+sizeof(firmware_ver));
+   firmware_ver[size] = '\0';
+   PRINT_D(INIT_DBG, " Firmware Ver = %s \n",
+   firmware_ver);
}
ret = linux_wlan_init_test_config(dev, vif);
 
-- 
1.9.1

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

[PATCH 03/13] staging: wilc1000: fixes add spaces required around

[Glen Lee]

From: Leo Kim 

This patch fixes the checks reported by checkpatch.pl
for spaces required around that '=' or '||' or '('.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 9552469..a3b4939 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -993,7 +993,7 @@ int wilc_mac_open(struct net_device *ndev)
vif = netdev_priv(ndev);
wl = vif->wilc;
 
-   if (!wl|| !wl->dev) {
+   if (!wl || !wl->dev) {
netdev_err(ndev, "wilc1000: SPI device not ready\n");
return -ENODEV;
}
@@ -1074,7 +1074,7 @@ int wilc_mac_open(struct net_device *ndev)
 
 static struct net_device_stats *mac_stats(struct net_device *dev)
 {
-   struct wilc_vif *vif= netdev_priv(dev);
+   struct wilc_vif *vif = netdev_priv(dev);
 
return >netstats;
 }
-- 
1.9.1

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

[PATCH 04/13] staging: wilc1000: rename hWILCWFIDrv of wilc_priv structure

[Glen Lee]

From: Leo Kim 

This patch renames hWILCWFIDrv pointer variable of wilc_priv structure
to hif_drv to avoid camelcase.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c |  8 
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 22 --
 drivers/staging/wilc1000/wilc_wfi_netdevice.h |  2 +-
 3 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index a3b4939..06c79dd 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -89,7 +89,7 @@ static int dev_state_ev_handler(struct notifier_block *this, 
unsigned long event
PRINT_D(GENERIC_DBG, "No Wireless Priv\n");
return NOTIFY_DONE;
}
-   hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   hif_drv = (struct host_if_drv *)priv->hif_drv;
vif = netdev_priv(dev);
if (!vif || !hif_drv) {
PRINT_D(GENERIC_DBG, "No Wireless Priv\n");
@@ -515,7 +515,7 @@ static int linux_wlan_init_test_config(struct net_device 
*dev,
 
PRINT_D(TX_DBG, "Start configuring Firmware\n");
priv = wiphy_priv(dev->ieee80211_ptr->wiphy);
-   hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   hif_drv = (struct host_if_drv *)priv->hif_drv;
PRINT_D(INIT_DBG, "Host = %p\n", hif_drv);
wilc_get_mac_address(vif, mac_add);
 
@@ -1089,7 +1089,7 @@ static void wilc_set_multicast_list(struct net_device 
*dev)
 
priv = wiphy_priv(dev->ieee80211_ptr->wiphy);
vif = netdev_priv(dev);
-   hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   hif_drv = (struct host_if_drv *)priv->hif_drv;
 
if (!dev)
return;
@@ -1228,7 +1228,7 @@ int wilc_mac_close(struct net_device *ndev)
return 0;
}
 
-   hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   hif_drv = (struct host_if_drv *)priv->hif_drv;
 
PRINT_D(GENERIC_DBG, "Mac close\n");
 
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 6e7f5d6..6626347 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -512,7 +512,7 @@ static void CfgConnectResult(enum conn_event 
enuConnDisconnEvent,
dev = priv->dev;
vif = netdev_priv(dev);
wl = vif->wilc;
-   pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   pstrWFIDrv = (struct host_if_drv *)priv->hif_drv;
 
if (enuConnDisconnEvent == CONN_DISCONN_EVENT_CONN_RESP) {
u16 u16ConnectStatus;
@@ -711,9 +711,11 @@ static int connect(struct wiphy *wiphy, struct net_device 
*dev,
wilc_connecting = 1;
priv = wiphy_priv(wiphy);
vif = netdev_priv(priv->dev);
-   pstrWFIDrv = (struct host_if_drv *)(priv->hWILCWFIDrv);
+   pstrWFIDrv = (struct host_if_drv *)priv->hif_drv;
 
-   PRINT_D(CFG80211_DBG, "Connecting to SSID [%s] on netdev [%p] host if 
[%p]\n", sme->ssid, dev, priv->hWILCWFIDrv);
+   PRINT_D(CFG80211_DBG,
+   "Connecting to SSID [%s] on netdev [%p] host if [%p]\n",
+   sme->ssid, dev, priv->hif_drv);
if (!(strncmp(sme->ssid, "DIRECT-", 7))) {
PRINT_D(CFG80211_DBG, "Connected to Direct network,OBSS 
disabled\n");
pstrWFIDrv->p2p_connect = 1;
@@ -928,7 +930,7 @@ static int disconnect(struct wiphy *wiphy, struct 
net_device *dev, u16 reason_co
priv = wiphy_priv(wiphy);
vif = netdev_priv(priv->dev);
 
-   pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   pstrWFIDrv = (struct host_if_drv *)priv->hif_drv;
if (!pstrWFIDrv->p2p_connect)
wlan_channel = INVALID_CHANNEL;
wilc_wlan_set_bssid(priv->dev, NullBssid, STATION_MODE);
@@ -1276,7 +1278,7 @@ static int del_key(struct wiphy *wiphy, struct net_device 
*netdev,
wilc_remove_wep_key(vif, key_index);
} else {
PRINT_D(CFG80211_DBG, "Removing all installed keys\n");
-   wilc_remove_key(priv->hWILCWFIDrv, mac_addr);
+   wilc_remove_key(priv->hif_drv, mac_addr);
}
 
return 0;
@@ -1632,7 +1634,7 @@ void WILC_WFI_p2p_rx (struct net_device *dev, u8 *buff, 
u32 size)
s32 s32Freq;
 
priv = wiphy_priv(dev->ieee80211_ptr->wiphy);
-   pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   pstrWFIDrv = (struct host_if_drv *)priv->hif_drv;
 
memcpy(, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET);
 
@@ -1844,7 +1846,7 @@ static int mgmt_tx(struct wiphy *wiphy,
 
vif = netdev_priv(wdev->netdev);
priv = wiphy_priv(wiphy);
-   pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv;
+   pstrWFIDrv = (struct host_if_drv 

[PATCH 06/13] staging: wilc1000: fixes missing a blank line after declarations

[Glen Lee]

From: Leo Kim 

This patch fixes the warnings reported by checkpatch.pl
for Missing a blank line after declarations.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index fd405b0..402f8ce 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -853,6 +853,7 @@ static void wlan_deinitialize_threads(struct net_device 
*dev)
 {
struct wilc_vif *vif;
struct wilc *wl;
+
vif = netdev_priv(dev);
wl = vif->wilc;
 
@@ -1473,6 +1474,7 @@ int wilc_netdev_init(struct wilc **wilc, struct device 
*dev, int io_type,
 
{
struct wireless_dev *wdev;
+
wdev = wilc_create_wiphy(ndev, dev);
 
if (dev)
-- 
1.9.1

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

[PATCH 07/13] staging: wilc1000: rename pBssid of tx_complete_data structure

[Glen Lee]

From: Leo Kim 

This patch renames pBssid variable of tx_complete_data structure to bssid
to avoid camelcase.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c   | 2 +-
 drivers/staging/wilc1000/wilc_wlan.c| 2 +-
 drivers/staging/wilc1000/wilc_wlan_if.h | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 402f8ce..4b544df 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1194,7 +1194,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device 
*ndev)
PRINT_D(TX_DBG, "Adding tx packet to TX Queue\n");
vif->netstats.tx_packets++;
vif->netstats.tx_bytes += tx_data->size;
-   tx_data->pBssid = wilc->vif[vif->u8IfIdx]->bssid;
+   tx_data->bssid = wilc->vif[vif->u8IfIdx]->bssid;
queue_count = wilc_wlan_txq_add_net_pkt(ndev, (void *)tx_data,
tx_data->buff, tx_data->size,
linux_wlan_tx_complete);
diff --git a/drivers/staging/wilc1000/wilc_wlan.c 
b/drivers/staging/wilc1000/wilc_wlan.c
index d7238e7..703dbe0 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -809,7 +809,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 
*txq_count)
if (tqe->type == WILC_CFG_PKT) {
buffer_offset = 
ETH_CONFIG_PKT_HDR_OFFSET;
} else if (tqe->type == WILC_NET_PKT) {
-   char *bssid = ((struct tx_complete_data 
*)(tqe->priv))->pBssid;
+   char *bssid = ((struct tx_complete_data 
*)(tqe->priv))->bssid;
 
buffer_offset = ETH_ETHERNET_HDR_OFFSET;
memcpy([offset + 4], bssid, 6);
diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h 
b/drivers/staging/wilc1000/wilc_wlan_if.h
index 455a98f..294552d 100644
--- a/drivers/staging/wilc1000/wilc_wlan_if.h
+++ b/drivers/staging/wilc1000/wilc_wlan_if.h
@@ -82,7 +82,7 @@ typedef struct {
 struct tx_complete_data {
int size;
void *buff;
-   u8 *pBssid;
+   u8 *bssid;
struct sk_buff *skb;
 };
 
-- 
1.9.1

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

[PATCH 08/13] staging: wilc1000: remove warnings line over 80 characters

[Glen Lee]

From: Leo Kim 

This patch removes the warnings reported by checkpatch.pl
for line over 80 characters.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 4b544df..f03daff 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -25,7 +25,8 @@
 
 #include 
 
-static int dev_state_ev_handler(struct notifier_block *this, unsigned long 
event, void *ptr);
+static int dev_state_ev_handler(struct notifier_block *this,
+   unsigned long event, void *ptr);
 
 static struct notifier_block g_dev_notifier = {
.notifier_call = dev_state_ev_handler
@@ -57,7 +58,8 @@ static const struct net_device_ops wilc_netdev_ops = {
 
 };
 
-static int dev_state_ev_handler(struct notifier_block *this, unsigned long 
event, void *ptr)
+static int dev_state_ev_handler(struct notifier_block *this,
+   unsigned long event, void *ptr)
 {
struct in_ifaddr *dev_iface = (struct in_ifaddr *)ptr;
struct wilc_priv *priv;
-- 
1.9.1

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

[PATCH 11/13] staging: wilc1000: removes void function return

[Glen Lee]

From: Leo Kim 

This patch removes the warning reported by checkpatch.pl
for void function return statements are not generally useful.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index c16cc40..5c87105 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -1047,8 +1047,6 @@ static void wilc_set_multicast_list(struct net_device 
*dev)
}
 
wilc_setup_multicast_filter(vif, true, (dev->mc.count));
-
-   return;
 }
 
 static void linux_wlan_tx_complete(void *priv, int status)
-- 
1.9.1

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

[PATCH 09/13] staging: wilc1000: removes unnecessary debug logs

[Glen Lee]

From: Leo Kim 

This patch removes unnecessary debug logs.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 154 ++
 1 file changed, 24 insertions(+), 130 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index f03daff..e8b4533 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -70,47 +70,32 @@ static int dev_state_ev_handler(struct notifier_block *this,
u8 null_ip[4] = {0};
char wlan_dev_name[5] = "wlan0";
 
-   if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev) {
-   PRINT_D(GENERIC_DBG, "dev_iface = NULL\n");
+   if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev)
return NOTIFY_DONE;
-   }
 
if (memcmp(dev_iface->ifa_label, "wlan0", 5) &&
-   memcmp(dev_iface->ifa_label, "p2p0", 4)) {
-   PRINT_D(GENERIC_DBG, "Interface is neither WLAN0 nor P2P0\n");
+   memcmp(dev_iface->ifa_label, "p2p0", 4))
return NOTIFY_DONE;
-   }
 
dev  = (struct net_device *)dev_iface->ifa_dev->dev;
-   if (!dev->ieee80211_ptr || !dev->ieee80211_ptr->wiphy) {
-   PRINT_D(GENERIC_DBG, "No Wireless registerd\n");
+   if (!dev->ieee80211_ptr || !dev->ieee80211_ptr->wiphy)
return NOTIFY_DONE;
-   }
+
priv = wiphy_priv(dev->ieee80211_ptr->wiphy);
-   if (!priv) {
-   PRINT_D(GENERIC_DBG, "No Wireless Priv\n");
+   if (!priv)
return NOTIFY_DONE;
-   }
+
hif_drv = (struct host_if_drv *)priv->hif_drv;
vif = netdev_priv(dev);
-   if (!vif || !hif_drv) {
-   PRINT_D(GENERIC_DBG, "No Wireless Priv\n");
+   if (!vif || !hif_drv)
return NOTIFY_DONE;
-   }
-
-   PRINT_INFO(GENERIC_DBG, "dev_state_ev_handler +++\n");
 
switch (event) {
case NETDEV_UP:
-   PRINT_D(GENERIC_DBG, "dev_state_ev_handler event=NETDEV_UP 
%p\n", dev);
-
-   PRINT_INFO(GENERIC_DBG, "\n == IP Address Obtained 
===\n\n");
-
if (vif->iftype == STATION_MODE || vif->iftype == CLIENT_MODE) {
hif_drv->IFC_UP = 1;
wilc_optaining_ip = false;
del_timer(_during_ip_timer);
-   PRINT_D(GENERIC_DBG, "IP obtained , enable scan\n");
}
 
if (wilc_enable_ps)
@@ -127,9 +112,6 @@ static int dev_state_ev_handler(struct notifier_block *this,
break;
 
case NETDEV_DOWN:
-   PRINT_D(GENERIC_DBG, "dev_state_ev_handler event=NETDEV_DOWN 
%p\n", dev);
-
-   PRINT_INFO(GENERIC_DBG, "\n == IP Address Released 
===\n\n");
if (vif->iftype == STATION_MODE || vif->iftype == CLIENT_MODE) {
hif_drv->IFC_UP = 0;
wilc_optaining_ip = false;
@@ -152,9 +134,6 @@ static int dev_state_ev_handler(struct notifier_block *this,
break;
 
default:
-   PRINT_INFO(GENERIC_DBG, "dev_state_ev_handler event=default\n");
-   PRINT_INFO(GENERIC_DBG, "[%s] unknown dev event: %lu\n", 
dev_iface->ifa_label, event);
-
break;
}
 
@@ -169,7 +148,6 @@ static irqreturn_t isr_uh_routine(int irq, void *user_data)
 
vif = netdev_priv(dev);
wilc = vif->wilc;
-   PRINT_D(INT_DBG, "Interrupt received UH\n");
 
if (wilc->close) {
PRINT_ER("Driver is CLOSING: Can't handle UH interrupt\n");
@@ -191,7 +169,6 @@ static irqreturn_t isr_bh_routine(int irq, void *userdata)
return IRQ_HANDLED;
}
 
-   PRINT_D(INT_DBG, "Interrupt received BH\n");
wilc_handle_isr(wilc);
 
return IRQ_HANDLED;
@@ -255,12 +232,9 @@ int wilc_lock_timeout(struct wilc *nic, void *vp, u32 
timeout)
/* FIXME: replace with mutex_lock or wait_for_completion */
int error = -1;
 
-   PRINT_D(LOCK_DBG, "Locking %p\n", vp);
if (vp)
error = down_timeout((struct semaphore *)vp,
 msecs_to_jiffies(timeout));
-   else
-   PRINT_ER("Failed, mutex is NULL\n");
return error;
 }
 
@@ -358,28 +332,21 @@ static int linux_wlan_txq_task(void *vp)
 
up(>txq_thread_started);
while (1) {
-   PRINT_D(TX_DBG, "txq_task Taking a nap :)\n");
down(>txq_event);
-   PRINT_D(TX_DBG, "txq_task Who waked me up :$\n");
 
if (wl->close) {
up(>txq_thread_started);
 
while (!kthread_should_stop())
schedule();
-
-   

[PATCH 12/13] staging: wilc1000: renames u8IfIdx of wilc_vif structure

[Glen Lee]

From: Leo Kim 

This patch renames u8IfIdx variable of wilc_vif structure to idx
to avoid camelcase.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/host_interface.c | 2 +-
 drivers/staging/wilc1000/linux_wlan.c | 8 
 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +-
 drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +-
 4 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/wilc1000/host_interface.c 
b/drivers/staging/wilc1000/host_interface.c
index a425b09..ad54db2 100644
--- a/drivers/staging/wilc1000/host_interface.c
+++ b/drivers/staging/wilc1000/host_interface.c
@@ -280,7 +280,7 @@ static void *host_int_ParseJoinBssParam(tstrNetworkInfo 
*ptstrNetworkInfo);
  */
 int wilc_get_vif_idx(struct wilc_vif *vif)
 {
-   return vif->u8IfIdx + 1;
+   return vif->idx + 1;
 }
 
 /* We need to minus 1 from idx which is from wilc device to get real index
diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 5c87105..9ca33536 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -107,7 +107,7 @@ static int dev_state_ev_handler(struct notifier_block *this,
netdev_dbg(dev, "IP add=%d:%d:%d:%d\n",
   ip_addr_buf[0], ip_addr_buf[1],
   ip_addr_buf[2], ip_addr_buf[3]);
-   wilc_setup_ipaddress(vif, ip_addr_buf, vif->u8IfIdx);
+   wilc_setup_ipaddress(vif, ip_addr_buf, vif->idx);
 
break;
 
@@ -129,7 +129,7 @@ static int dev_state_ev_handler(struct notifier_block *this,
   ip_addr_buf[0], ip_addr_buf[1],
   ip_addr_buf[2], ip_addr_buf[3]);
 
-   wilc_setup_ipaddress(vif, ip_addr_buf, vif->u8IfIdx);
+   wilc_setup_ipaddress(vif, ip_addr_buf, vif->idx);
 
break;
 
@@ -1104,7 +1104,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device 
*ndev)
 
vif->netstats.tx_packets++;
vif->netstats.tx_bytes += tx_data->size;
-   tx_data->bssid = wilc->vif[vif->u8IfIdx]->bssid;
+   tx_data->bssid = wilc->vif[vif->idx]->bssid;
queue_count = wilc_wlan_txq_add_net_pkt(ndev, (void *)tx_data,
tx_data->buff, tx_data->size,
linux_wlan_tx_complete);
@@ -1360,7 +1360,7 @@ int wilc_netdev_init(struct wilc **wilc, struct device 
*dev, int io_type,
else
strcpy(ndev->name, "p2p%d");
 
-   vif->u8IfIdx = wl->vif_num;
+   vif->idx = wl->vif_num;
vif->wilc = *wilc;
wl->vif[i] = vif;
wl->vif[wl->vif_num]->ndev = ndev;
diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c 
b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
index 6626347..ccfd26a 100644
--- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
+++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c
@@ -2197,7 +2197,7 @@ static int start_ap(struct wiphy *wiphy, struct 
net_device *dev,
if (s32Error != 0)
PRINT_ER("Error in setting channel\n");
 
-   wilc_wlan_set_bssid(dev, wl->vif[vif->u8IfIdx]->src_addr, AP_MODE);
+   wilc_wlan_set_bssid(dev, wl->vif[vif->idx]->src_addr, AP_MODE);
wilc_set_power_mgmt(vif, 0, 0);
 
s32Error = wilc_add_beacon(vif, settings->beacon_interval,
diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h 
b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
index 64fcb77..07a4ff1 100644
--- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h
+++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h
@@ -148,7 +148,7 @@ typedef struct {
 } struct_frame_reg;
 
 struct wilc_vif {
-   u8 u8IfIdx;
+   u8 idx;
u8 iftype;
int monitor_flag;
int mac_opened;
-- 
1.9.1

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

[PATCH 13/13] staging: wilc1000: fixes variable dereferenced before check

[Glen Lee]

From: Leo Kim 

This patch fixes the warning reported by smatch.
 - wilc_wlan_get_firmware() warn: variable dereferenced before check 'vif'
 - wilc_set_multicast_list() warn: variable dereferenced before check 'dev'

Just delete them and no need add null check since they are net_device from
ndo_set_rx_mode of net_device_ops and vif of netdev_priv.

Signed-off-by: Leo Kim 
Signed-off-by: Glen Lee 
---
 drivers/staging/wilc1000/linux_wlan.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 9ca33536..22a2f98 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -397,9 +397,6 @@ int wilc_wlan_get_firmware(struct net_device *dev)
 
netdev_info(dev, "loading firmware %s\n", firmware);
 
-   if (!vif)
-   goto _fail_;
-
if (!(>ndev->dev))
goto _fail_;
 
@@ -1017,9 +1014,6 @@ static void wilc_set_multicast_list(struct net_device 
*dev)
vif = netdev_priv(dev);
hif_drv = (struct host_if_drv *)priv->hif_drv;
 
-   if (!dev)
-   return;
-
if (dev->flags & IFF_PROMISC)
return;
 
-- 
1.9.1

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

Re: [PATCH] cfg80211: Fix some linguistics in Kconfig

[Johannes Berg]

Applied, thanks!

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

Re: [PATCH] cfg80211: basic support for PBSS network type

[Johannes Berg]

On Wed, 2016-01-13 at 11:04 +0200, Lior David wrote:
> 
> + * @NL80211_ATTR_PBSS: flag attribute. If set it means operate
> + *   in a PBSS. Specified in %NL80211_CMD_CONNECT to request
> + *   connecting to a PCP, and in %NL80211_CMD_START_AP to start
> + *   a PCP instead of AP. Relevant for DMG networks only.

I'm continually confused by this; is it possible for DMG devices to be
a "real" AP rather than a PCP?

> @@ -3461,6 +3462,8 @@  static int nl80211_start_ap(struct sk_buff *skb, 
> struct genl_info *info)
>   return PTR_ERR(params.acl);
>   }
>  
> + params.pbss = nla_get_flag(info->attrs[NL80211_ATTR_PBSS]);
> +
>   wdev_lock(wdev);
>   err = rdev_start_ap(rdev, dev, );
>   if (!err) {

This, and the corresponding code in nl80211_connect, really ought to
check that the device is a DMG device and able to do this.

Perhaps this even needs a capability check, or do we assume that all
devices/drivers will be able to do this (or should reject it?)

If you want to rely on drivers though you need to have (in this patch!)
a small change to the existing driver to reject the operations if
pbss==true since obviously it cannot be doing the right thing right now
without further changes. That reject would then of course be removed
again with the driver update.

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

Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath

[Johannes Berg]

On Tue, 2016-01-19 at 09:04 +0100, Henning Rogge wrote:
> 
> +static void mpp_flush_by_proxy(struct ieee80211_sub_if_data *sdata,
> +    const u8 *proxy)
> +{
> + struct mesh_table *tbl;
> + struct mesh_path *mpp;
> + struct mpath_node *node;
> + int i;
> +
> + rcu_read_lock();
> + read_lock_bh(_resize_lock);
> + tbl = resize_dereference_mpp_paths();
> + for_each_mesh_entry(tbl, node, i) {

It does not seem to me that the rcu_read_lock() above is necessary or
correct, though it's probably not hurting it should be removed to avoid
having misleading code.

> + mpp = node->mpath;
> + if (ether_addr_equal(mpp->mpp, proxy)) {
> + spin_lock(>hashwlock[i]);
> + __mesh_path_del(tbl, node);
> + spin_unlock(>hashwlock[i]);

It also doesn't seem like for_each_mesh_entry() can deal with "node"
getting deleted from underneath it? It accesses it through
hlist_next_rcu() after the deletion, so you have a use-after-free here
afaict.

johannes

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

Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers

[Felix Fietkau]

On 2016-01-26 12:56, Michal Kazior wrote:
> On 26 January 2016 at 11:45, Felix Fietkau  wrote:
>> On 2016-01-21 14:23, Michal Kazior wrote:
>>> This will allow drivers to make more educated
>>> decisions whether to defer transmission or not.
>>>
>>> Relying on wake_tx_queue() call count implicitly
>>> was not possible because it could be called
>>> without queued frame count actually changing on
>>> software tx aggregation start/stop code paths.
>>>
>>> It was also not possible to know how long
>>> byte-wise queue was without dequeueing.
>>>
>>> Signed-off-by: Michal Kazior 
>> Instead of exposing these in the struct to the driver directly, please
>> make a function to get them. Since the number of frames is already
>> tracked in txqi->queue, you can avoid counter duplication that way.
> 
> Hmm, so you suggest to have something like:
> 
>  void
>  ieee80211_get_txq_depth(struct ieee80211_txq *txq,
>  unsigned int *frame_cnt,
>  unsigned int *byte_count) {
>struct txq_info *txqi = txq_to_info(txq);
> 
>if (frame_cnt)
>  *frame_cnt = txqi->queue.qlen;
> 
>if (byte_count)
>  *byte_cnt = txqi->byte_cnt;
>  }
> 
> Correct?
> 
> Sounds reasonable.
Right.

>> Also, that way you can fix a race condition between accessing the number
>> of frames counter and the bytes counter.
> 
> I don't see a point in maintaining coherency between the two counters
> with regard to each other alone. Do you have a use-case that would
> actually make use of that property?
> 
> I'd like to avoid any unnecessary spinlocks.
OK. I guess we can leave them out for now. How frequently are you going
to call this function?

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

Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers

[Johannes Berg]

> I don't see a point in maintaining coherency between the two counters
> with regard to each other alone. Do you have a use-case that would
> actually make use of that property?
> 
> I'd like to avoid any unnecessary spinlocks.
> 

Make sure you document the lack of consistency between the two values
then, please.

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

Re: [PATCH] net:mac80211:mesh_plink: remove redundant sta_info check

[Johannes Berg]

On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote:
> Remove unnecessory "if" statement and club it with previos "if"
> block.
> 
Applied.

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

Re: [PATCH] cfg80211: basic support for PBSS network type

[Lior David]

On 1/26/2016 1:22 PM, Johannes Berg wrote:
> On Wed, 2016-01-13 at 11:04 +0200, Lior David wrote:
>>  
>> + * @NL80211_ATTR_PBSS: flag attribute. If set it means operate
>> + *  in a PBSS. Specified in %NL80211_CMD_CONNECT to request
>> + *  connecting to a PCP, and in %NL80211_CMD_START_AP to start
>> + *  a PCP instead of AP. Relevant for DMG networks only.
> 
> I'm continually confused by this; is it possible for DMG devices to be
> a "real" AP rather than a PCP?
> 
Yes, DMG devices can function as a full AP in addition to PCP.

>> @@ -3461,6 +3462,8 @@  static int nl80211_start_ap(struct sk_buff *skb, 
>> struct genl_info *info)
>>  return PTR_ERR(params.acl);
>>  }
>>  
>> +params.pbss = nla_get_flag(info->attrs[NL80211_ATTR_PBSS]);
>> +
>>  wdev_lock(wdev);
>>  err = rdev_start_ap(rdev, dev, );
>>  if (!err) {
> 
> This, and the corresponding code in nl80211_connect, really ought to
> check that the device is a DMG device and able to do this.
> 
> Perhaps this even needs a capability check, or do we assume that all
> devices/drivers will be able to do this (or should reject it?)
> 
Certified 11ad devices must support PBSS, but in theory you can have
11ad drivers that do not support it. 11ac devices cannot support
it and currently will just ignore this flag, so I think I will add a
feature flag (something like NL80211_EXT_FEATURE_PBSS) and return an
error if the driver does not support this feature.

> If you want to rely on drivers though you need to have (in this patch!)
> a small change to the existing driver to reject the operations if
> pbss==true since obviously it cannot be doing the right thing right now
> without further changes. That reject would then of course be removed
> again with the driver update.
I have a patch for the wil6210 driver that uses this feature. Do you prefer
that I add the wil6210 driver changes to this patch?

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

Re: [RFC V3 0/2] nl80211: allow configuration of BSS selection

[Arend van Spriel]

On 26-1-2016 11:01, Arend van Spriel wrote:
> This patch series adds support for configuration of BSS selection done by
> the driver and/or firmware. It allows user-space to pass selection criteria
> with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space
> does provide this attribute and no explicit BSSID is provided it will pass
> the BSS selection criteria to the driver if the driver supports it.
> 
> When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with
> same SSID, the criteria can be used to select a BSS. The criteria defined are:
> 
> 1. RSSI based selection.
> 2. Band selection, RSSI based selection.
> 3. RSSI adjustment in given band, RSSI based selection.
> 
> V2:
>  - incorporate comments from Johannes Berg (may have missed some).
>  - split nl80211 patch in two separate patches.
> 
> V3:
>  - remove enum nl80211_bss_select_primitive.
>  - reword documentation of nl80211_bss_select_attr enum values.
> 
> Arend van Spriel (3):
>   nl80211: add extended feature for BSS selection support
>   nl80211: add bss selection attribute to CONNECT command
>   brcmfmac: add support for nl80211 BSS_SELECT feature

Hmmm. Made a bit of a mess with this version. Let's go to V4.

Regards,
Arend

>  .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +-
>  .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 38 ++-
>  .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
>  include/net/cfg80211.h | 34 ++
>  include/uapi/linux/nl80211.h   | 42 
>  net/wireless/core.c|  4 ++
>  net/wireless/nl80211.c | 76 
> ++
>  7 files changed, 240 insertions(+), 18 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers

[Michal Kazior]

On 26 January 2016 at 13:04, Felix Fietkau  wrote:
> On 2016-01-26 12:56, Michal Kazior wrote:
>> On 26 January 2016 at 11:45, Felix Fietkau  wrote:
>>> On 2016-01-21 14:23, Michal Kazior wrote:
 This will allow drivers to make more educated
 decisions whether to defer transmission or not.

 Relying on wake_tx_queue() call count implicitly
 was not possible because it could be called
 without queued frame count actually changing on
 software tx aggregation start/stop code paths.

 It was also not possible to know how long
 byte-wise queue was without dequeueing.

 Signed-off-by: Michal Kazior 
>>> Instead of exposing these in the struct to the driver directly, please
>>> make a function to get them. Since the number of frames is already
>>> tracked in txqi->queue, you can avoid counter duplication that way.
>>
>> Hmm, so you suggest to have something like:
[...]
>>> Also, that way you can fix a race condition between accessing the number
>>> of frames counter and the bytes counter.
>>
>> I don't see a point in maintaining coherency between the two counters
>> with regard to each other alone. Do you have a use-case that would
>> actually make use of that property?
>>
>> I'd like to avoid any unnecessary spinlocks.
> OK. I guess we can leave them out for now. How frequently are you going
> to call this function?

Depends, but with new data path in ath10k[1][2] it'll be at least once
for each wake_tx_queue() + once for each txq in each fetch-ind event.


Michał

[1]: https://patchwork.kernel.org/patch/8081301/
[2]: https://patchwork.kernel.org/patch/8081331/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC V4 1/2] nl80211: add feature for BSS selection support

[Arend van Spriel]

Introducing a new feature that the driver can use to
indicate the driver/firmware supports configuration of BSS
selection criteria upon CONNECT command. This can be useful
when multiple BSS-es are found belonging to the same ESS,
ie. Infra-BSS with same SSID. The criteria can then be used to
offload selection of a preferred BSS.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Lei Zhang 
Signed-off-by: Arend van Spriel 
---
 include/net/cfg80211.h   | 34 
 include/uapi/linux/nl80211.h | 42 
 net/wireless/core.c  |  4 +++
 net/wireless/nl80211.c   | 76 
 4 files changed, 156 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 9bcaaf7..f571f4a 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -1854,6 +1854,33 @@ struct cfg80211_ibss_params {
 };
 
 /**
+ * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment.
+ *
+ * @band: band of BSS which should match for RSSI level adjustment.
+ * @delta: value of RSSI level adjustment.
+ */
+struct cfg80211_bss_select_adjust {
+   enum nl80211_band band;
+   s8 delta;
+};
+
+/**
+ * struct cfg80211_bss_selection - connection parameters for BSS selection.
+ *
+ * @behaviour: requested BSS selection behaviour.
+ * @param: parameters for requestion behaviour.
+ * @band_pref: preferred band for %NL80211_BSS_SELECT_ATTR_BAND_PREF.
+ * @adjust: parameters for %NL80211_BSS_SELECT_ATTR_RSSI_ADJUST.
+ */
+struct cfg80211_bss_selection {
+   enum nl80211_bss_select_attr behaviour;
+   union {
+   enum nl80211_band band_pref;
+   struct cfg80211_bss_select_adjust adjust;
+   } param;
+};
+
+/**
  * struct cfg80211_connect_params - Connection parameters
  *
  * This structure provides information needed to complete IEEE 802.11
@@ -1888,6 +1915,7 @@ struct cfg80211_ibss_params {
  * @ht_capa_mask:  The bits of ht_capa which are to be used.
  * @vht_capa:  VHT Capability overrides
  * @vht_capa_mask: The bits of vht_capa which are to be used.
+ * @bss_select: criteria to be used for BSS selection.
  */
 struct cfg80211_connect_params {
struct ieee80211_channel *channel;
@@ -1910,6 +1938,7 @@ struct cfg80211_connect_params {
struct ieee80211_ht_cap ht_capa_mask;
struct ieee80211_vht_cap vht_capa;
struct ieee80211_vht_cap vht_capa_mask;
+   struct cfg80211_bss_selection bss_select;
 };
 
 /**
@@ -3178,6 +3207,9 @@ struct wiphy_vendor_command {
  * low rssi when a frame is heard on different channel, then it should set
  * this variable to the maximal offset for which it can compensate.
  * This value should be set in MHz.
+ * @bss_select_support: bitmask indicating the BSS selection criteria supported
+ * by the driver in the .connect() callback. The bit position maps to the
+ * attribute indices defined in  nl80211_bss_select_attr.
  */
 struct wiphy {
/* assign these fields before you register the wiphy */
@@ -3300,6 +3332,8 @@ struct wiphy {
u8 max_num_csa_counters;
u8 max_adj_channel_rssi_comp;
 
+   u32 bss_select_support;
+
char priv[0] __aligned(NETDEV_ALIGN);
 };
 
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 5b7b5eb..f3ece95 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1789,6 +1789,12 @@ enum nl80211_commands {
  * thus it must not specify the number of iterations, only the interval
  * between scans. The scan plans are executed sequentially.
  * Each scan plan is a nested attribute of  nl80211_sched_scan_plan.
+ * @NL80211_ATTR_BSS_SELECT: nested attribute for driver supporting the
+ * BSS selection feature. When used with %NL80211_CMD_GET_WIPHY it contains
+ * NLA_FLAG type according  nl80211_bss_select_attr to indicate what
+ * BSS selection behaviours are supported. When used with 
%NL80211_CMD_CONNECT
+ * it contains the behaviour and parameters for BSS selection to be done by
+ * driver and/or firmware.
  *
  * @NUM_NL80211_ATTR: total number of nl80211_attrs available
  * @NL80211_ATTR_MAX: highest attribute number currently defined
@@ -2164,6 +2170,8 @@ enum nl80211_attrs {
NL80211_ATTR_MAX_SCAN_PLAN_ITERATIONS,
NL80211_ATTR_SCHED_SCAN_PLANS,
 
+   NL80211_ATTR_BSS_SELECT,
+
/* add attributes here, update the policy in nl80211.c */
 
__NL80211_ATTR_AFTER_LAST,
@@ -4651,4 +4659,38 @@ enum nl80211_sched_scan_plan {
__NL80211_SCHED_SCAN_PLAN_AFTER_LAST - 1
 };
 
+/**
+ * enum nl80211_bss_select_attr - attributes for bss selection.
+ *
+ * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved.
+ * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based 

Re: [PATCH] mac80211: fix unnecessary frame drops in mesh fwding

[Johannes Berg]

On Mon, 2016-01-25 at 14:43 +0100, Michal Kazior wrote:
> The ieee80211_queue_stopped() expects hw queue
> number but it was given raw WMM AC number instead.
> 
> This could cause frame drops and problems with
> traffic in some cases - most notably if driver
> doesn't map AC numbers to queue numbers 1:1 and
> uses ieee80211_stop_queues() and
> ieee80211_wake_queue() only without ever calling
> ieee80211_wake_queues().
> 
[...]

Yeah, this seems right - applied.

I put it into mac80211-next since you nobody complained before so it's
likely not relevant without your other ath10k patches.

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

[RFC V4 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature

[Arend van Spriel]

Announce support for nl80211 feature BSS_SELECT and process
BSS selection behaviour provided in .connect() callback.

Reviewed-by: Hante Meuleman 
Reviewed-by: Franky (Zhenhui) Lin 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Lei Zhang 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 --
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 38 +++--
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 3 files changed, 84 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 7b01e4d..d90378e 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -238,6 +238,20 @@ struct parsed_vndr_ies {
struct parsed_vndr_ie_info ie_info[VNDR_IE_PARSE_LIMIT];
 };
 
+static u8 nl80211_band_to_fwil(enum nl80211_band band)
+{
+   switch (band) {
+   case NL80211_BAND_2GHZ:
+   return WLC_BAND_2G;
+   case NL80211_BAND_5GHZ:
+   return WLC_BAND_5G;
+   default:
+   WARN_ON(1);
+   break;
+   }
+   return 0;
+}
+
 static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf,
   struct cfg80211_chan_def *ch)
 {
@@ -1737,6 +1751,43 @@ enum nl80211_auth_type brcmf_war_auth_type(struct 
brcmf_if *ifp,
return type;
 }
 
+static void brcmf_set_join_pref(struct brcmf_if *ifp,
+   struct cfg80211_bss_selection *bss_select)
+{
+   struct brcmf_join_pref_params join_pref_params[2];
+   enum nl80211_band band;
+   int err, i = 0;
+
+   join_pref_params[i].len = 2;
+   join_pref_params[i].rssi_gain = 0;
+   switch (bss_select->behaviour) {
+   case NL80211_BSS_SELECT_ATTR_BAND_PREF:
+   join_pref_params[i].type = BRCMF_JOIN_PREF_BAND;
+   band = bss_select->param.band_pref;
+   join_pref_params[i].band = nl80211_band_to_fwil(band);
+   i++;
+   break;
+   case NL80211_BSS_SELECT_ATTR_RSSI_ADJUST:
+   join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI_DELTA;
+   band = bss_select->param.adjust.band;
+   join_pref_params[i].band = nl80211_band_to_fwil(band);
+   join_pref_params[i].rssi_gain = bss_select->param.adjust.delta;
+   i++;
+   break;
+   case NL80211_BSS_SELECT_ATTR_RSSI:
+   default:
+   break;
+   }
+   join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI;
+   join_pref_params[i].len = 2;
+   join_pref_params[i].rssi_gain = 0;
+   join_pref_params[i].band = 0;
+   err = brcmf_fil_iovar_data_set(ifp, "join_pref", join_pref_params,
+  sizeof(join_pref_params));
+   if (err)
+   brcmf_err("Set join_pref error (%d)\n", err);
+}
+
 static s32
 brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev,
   struct cfg80211_connect_params *sme)
@@ -1862,11 +1913,13 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct 
net_device *ndev,
ext_join_params->scan_le.scan_type = -1;
ext_join_params->scan_le.home_time = cpu_to_le32(-1);
 
-   if (sme->bssid)
+   if (sme->bssid) {
memcpy(_join_params->assoc_le.bssid, sme->bssid, ETH_ALEN);
-   else
+   brcmf_c_set_joinpref_default(ifp);
+   } else {
eth_broadcast_addr(ext_join_params->assoc_le.bssid);
-
+   brcmf_set_join_pref(ifp, >bss_select);
+   }
if (cfg->channel) {
ext_join_params->assoc_le.chanspec_num = cpu_to_le32(1);
 
@@ -6179,6 +6232,10 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct 
brcmf_if *ifp)
wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM;
wiphy->cipher_suites = __wl_cipher_suites;
wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites);
+   wiphy->bss_select_support = BIT(NL80211_BSS_SELECT_ATTR_RSSI) |
+   BIT(NL80211_BSS_SELECT_ATTR_BAND_PREF) |
+   BIT(NL80211_BSS_SELECT_ATTR_RSSI_ADJUST);
+
wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT |
WIPHY_FLAG_OFFCHAN_TX |
WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL;
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
index 4265b50..b9e81fb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c
@@ -32,7 +32,7 @@ const u8 ALLFFMAC[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 
0xff };
 #define 

[RFC V4 0/2] nl80211: allow configuration of BSS selection

[Arend van Spriel]

This patch series adds support for configuration of BSS selection done by
the driver and/or firmware. It allows user-space to pass selection behaviour
with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space
does provide this attribute and no explicit BSSID is provided it will pass
the BSS selection behaviour to the driver if the driver supports it.

When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with
same SSID, this can be used to select a BSS. The behaviours defined are:

1. RSSI based selection.
2. Band selection, RSSI based selection.
3. RSSI adjustment in given band, RSSI based selection.

V2:
 - incorporate comments from Johannes Berg (may have missed some).
 - split nl80211 patch in two separate patches.

V3:
 - remove enum nl80211_bss_select_primitive.
 - reword documentation of nl80211_bss_select_attr enum values.

V4:
 - remove documentation reference to removed primitive.

Arend van Spriel (2):
  nl80211: add feature for BSS selection support
  brcmfmac: add support for nl80211 BSS_SELECT feature

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +-
 .../wireless/broadcom/brcm80211/brcmfmac/common.c  | 38 ++-
 .../wireless/broadcom/brcm80211/brcmfmac/core.h|  1 +
 include/net/cfg80211.h | 34 ++
 include/uapi/linux/nl80211.h   | 42 
 net/wireless/core.c|  4 ++
 net/wireless/nl80211.c | 76 ++
 7 files changed, 240 insertions(+), 18 deletions(-)

-- 
1.9.1

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

Re: [PATCH 1/3] mac80211: add RX_FLAG_MACTIME_PLCP_START

[Johannes Berg]

All three applied.

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

Re: [PATCH 0/8] General RFKill improvements

[Johannes Berg]

Hi,

On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote:
> This series contains a few general improvements to the RFKill code,
> found while
> I was writing the rfkill-all / airplane mode LED trigger. All were
> points where
> I had to read twice or do some other kind of extra effort to fully
> understand
> it, so I think merging these changes will benefit someone trying to
> understand
> the RFKill subsystem in the future.

I applied some of this. I think we need to keep the "state" sysfs
interface, perhaps you want to document it more clearly. I also didn't
apply the first patch since I'd fixed the suspend/pause issue, please
see if any of your patches remain relevant and resend that.

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

Re: [PATCH] cfg80211: basic support for PBSS network type

[Johannes Berg]

> Yes, DMG devices can function as a full AP in addition to PCP.

Ok. I'll try to remember :)

> Certified 11ad devices must support PBSS, but in theory you can have
> 11ad drivers that do not support it. 11ac devices cannot support
> it and currently will just ignore this flag, so I think I will add a
> feature flag (something like NL80211_EXT_FEATURE_PBSS) and return an
> error if the driver does not support this feature.

I'd rather return an error when the device isn't 11ad.

If it's basically a requirement then I don't think we really need a
feature flag, but can just have the driver reject the flag in the
meantime. I do want to avoid having a situation where userspace
specified PBSS and it gets ignored entirely though.

> I have a patch for the wil6210 driver that uses this feature. Do you
> prefer that I add the wil6210 driver changes to this patch?

Great. No, I don't want bigger wil6210 changes in this patch, so I'd
prefer you add a few lines to this patch that make wil6210 reject the
configuration with PBSS, and then obviously in the real wil6210 patch
remove that again.

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