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

2018-04-26 Thread Pkshih

> -Original Message-
> From: Kalle Valo [mailto:kv...@codeaurora.org]
> Sent: Wednesday, April 25, 2018 3:36 PM
> To: Pkshih
> Cc: larry.fin...@lwfinger.net; linux-wireless@vger.kernel.org
> Subject: Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac
> 
>  writes:
> 
> > From: Ping-Ke Shih 
> >
> > v3: patch 06/17 in v2 is too big, so mail server may block the mail.
> > In this patchset, I decompose the patch into three patches 06/19-08/19,
> > so in patchset view v2 and v3 are identical.
> 
> I can confirm, all patches made it to patchwork now.
> 
> > v2: remove indirection to get halmac ops
> > Only patches 1/17 and 11/17 are changed.
> >
> > Patches 1/19-3/19 are added structure to support this module.
> > Patches 4/19-18/19 add new files.
> > Patch 19/19 add this module to Makefile and Kconfig.
> >
> > Ping-Ke Shih (19):
> >   rtlwifi: add halmac structure to wifi.h
> >   rtlwifi: add debug ID COMP_HALMAC
> >   rtlwifi: add dmdef.h to share with driver and other modules
> >   rtlwifi: halmac: add main definition used by halmac
> >   rtlwifi: halmac: describe number and size of chip functions
> >   rtlwifi: halmac: add register definitions
> >   rtlwifi: halmac: add bit field definitions
> >   rtlwifi: halmac: add bit field definitions of rtl8822b
> >   rtlwifi: halmac: add definition of TX/RX descriptor
> >   rtlwifi: halmac: add GPIO pin/pinmux definitions
> >   rtlwifi: halmac: add power sequence to turn on/off wifi card
> >   rtlwifi: halmac: access efuse through halmac helper functions
> >   rtlwifi: halmac: add files to implement halmac ops
> >   rtlwifi: halmac: add halmac init/deinit functions
> >   rtlwifi: halmac: add firmware related functions and definitions
> >   rtlwifi: halmac: add bus interface commands
> >   rtlwifi: halmac: add to control WiFi mac functions and registers
> >   rtlwifi: halmac: add to support BB and RF functions
> >   rtlwifi: add halmac to Makefile and Kconfig
> 
> You are adding a new component to rtlwifi but there's no introduction in
> the cover letter. Why is this needed? For what hardware is it for? What
> new features does it bring?
> 
> >  77 files changed, 64201 insertions(+)
> 
> This is a huge patchset, I'm not even sure if I want to start reviewing
> this. Especially when I have no clue about the big picture (which should
> be described in the cover letter).
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches#too_many_patches
> 
I know the number of patches in a patchset should be within 10-12, but I
think that all files are new and full source can give you whole picture
if you want to know code flow between them.

> And I even read all 19 commit logs and there was no mention of why this
> is needed either. I cannot just blindly apply patches without knowing
> what they do.
> 

This new module halmac is an abstract layer for Realtek WiFi MAC to provide
common interfaces to access WiFi MAC and register set. If driver (I use 'driver'
in this mail indicates part of rtlwifi excluded from this module.) uses the API,
it's not necessary to control related register directly. If API isn't 
implemented,
driver can use the registers defined by halmac to manipulate MAC function.

The registers reside in driver causes error frequently, because MAC register
is maintained by Realtek's MAC team so they create this module to avoid 
mistakes.
Another benefit is to make it possible to become a thin driver, because many
common functions are provided, so duplicate code will be reduced.

Currently, this module is aim to rtl8822be, and it will extend to support
more chips so hierarchical directory is adopted. It looks like
   rtlwifi/halmac/halmac_88xx
   rtlwifi/halmac/halmac_88xx/halmac_8822b
   rtlwifi/halmac/halmac_88xx/halmac_8821c (future chip)
The directory halmac_88xx puts common functions of rtl8822b and rtl8821c, and
halmac_88xx/halmac_8822b puts rtl8822b specific functions.
To access API abstractly, it provides hook pointers to specific chip during
initialization.


In order to illustrate the functions, I list *.c files and short description:

   halmac/rtl_halmac.c
 We implement a facade-like (facade is a term in design pattern) by
 halmac_ops in this file, so we can check halmac_ops to know halmac 
functions.
 The functions, for examples, are init/deinit, power on/off, read efuse,
 c2h handler, iqk assistant function etc. Each function may call one or 
more 
 halmac API to achieve.
  
   halmac/halmac_api.c
   halmac/halmac_88xx/halmac_init_88xx.c
   halmac/halmac_88xx/halmac_8822b/halmac_init_8822b.c
 The init/deinit and mount hook pointers are existing in these files.

   halmac/halmac_88xx/halmac_usb_88xx.c
   halmac/halmac_88xx/halmac_sdio_88xx.c
   halmac/halmac_88xx/halmac_pcie_88xx.c
   halmac/halmac_88xx/halmac_8822b/halmac_usb_8822b.c
   halmac/halmac_88xx/halmac_8822b/halmac_sdio_8822b.c
   

[PATCH v3] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread s . gottschall
From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
v3: apply some cosmetics, update documentation
---
 drivers/net/wireless/ath/ath10k/mac.c | 38 +--
 drivers/net/wireless/ath/ath10k/wmi.c |  7 +--
 drivers/net/wireless/ath/ath10k/wmi.h | 14 -
 3 files changed, 37 insertions(+), 22 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..594db0713186 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,31 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
__le16_to_cpu(vht_cap->vht_mcs.tx_highest);
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+   arg->peer_bw_rxnss_override = 0;
 
-   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
-  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
-
-   if (arg->peer_vht_rates.rx_max_rate &&
-   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-   switch (arg->peer_vht_rates.rx_max_rate) {
-   case 1560:
-   /* Must be 2x2 at 160Mhz is all it can do. */
-   arg->peer_bw_rxnss_override = 2;
-   break;
-   case 780:
-   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-   arg->peer_bw_rxnss_override = 1;
-   break;
+   if (arg->peer_num_spatial_streams) {
+   /* in case if peer is connected with vht160 or vht80+80, we 
need to properly adjust rxnss parameters */
+   switch(arg->peer_phymode) {
+   case MODE_11AC_VHT80_80:
+   arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);
+   /* fall through */
+   case MODE_11AC_VHT160:
+   arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+   break;
}
}
+
+   /* in case peer has no nss properties for some reasons, we set local 
nss to minimum (1x1) to avoid a 
+* firmware assert / crash. this applies only to VHT160 or VHT80+80 and 
is a WAR for clients breaking
+* the spec.
+*/
+
+   if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
+  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
 }
 
 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2704,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..3797dca317ff 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7211,12 +7211,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void 
*buf,
struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;
 
ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
-   if (arg->peer_bw_rxnss_override)
-   cmd->peer_bw_rxnss_override =
-   __cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
- BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
-   else
-   cmd->peer_bw_rxnss_override = 0;
+   cmd->peer_bw_rxnss_override = 
__cpu_to_le32(arg->peer_bw_rxnss_override);
 }
 
 static int
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h 

[RFCv2 2/6] mac80211: Add support to configure rssi threshold for AP mode

2018-04-26 Thread Tamizh chelvam
This patch add support to configure station specific single or
multi rssi thresholds using ieee80211_set_sta_mon_rssi_config and
ieee80211_set_sta_mon_rssi_range_confg APIs. This configuration
is used for tracking the connected station's signal strength.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/cfg.c  | 75 +
 net/mac80211/sta_info.h | 18 
 2 files changed, 93 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 85dbaa8..0e2047c 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3705,6 +3705,79 @@ static int ieee80211_set_multicast_to_unicast(struct 
wiphy *wiphy,
return 0;
 }
 
+static int ieee80211_set_sta_mon_rssi_config(struct wiphy *wiphy,
+struct net_device *dev,
+const u8 *peer, s32 rssi_thold,
+u32 rssi_hyst)
+{
+   struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+   struct sta_info *sta;
+
+   if (sdata->vif.type == NL80211_IFTYPE_AP &&
+   (!sdata->vif.bss_conf.enable_beacon ||
+   !wiphy_ext_feature_isset(sdata->local->hw.wiphy,
+   NL80211_EXT_FEATURE_STA_MON_RSSI_CONFIG)))
+   return -EOPNOTSUPP;
+
+   mutex_lock(>local->sta_mtx);
+
+   sta = sta_info_get_bss(sdata, peer);
+   if (!sta) {
+   mutex_unlock(>local->sta_mtx);
+   return -ENOENT;
+   }
+
+   if (sta->rssi_thold == rssi_thold &&
+   sta->rssi_hyst == rssi_hyst)
+   goto unlock;
+
+   sta->rssi_thold = rssi_thold;
+   sta->rssi_hyst = rssi_hyst;
+   sta->rssi_low = 0;
+   sta->rssi_high = 0;
+   sta->last_sta_mon_event_signal = 0;
+unlock:
+   mutex_unlock(>local->sta_mtx);
+   return 0;
+}
+
+static int ieee80211_set_sta_mon_rssi_range_confg(struct wiphy *wiphy,
+ struct net_device *dev,
+ const u8 *peer,
+ s32 rssi_low, s32 rssi_high)
+{
+   struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+   struct sta_info *sta;
+
+   if (sdata->vif.type == NL80211_IFTYPE_AP &&
+   (!sdata->vif.bss_conf.enable_beacon ||
+   !wiphy_ext_feature_isset(sdata->local->hw.wiphy,
+   NL80211_EXT_FEATURE_STA_MON_RSSI_LIST)))
+   return -EOPNOTSUPP;
+
+   mutex_lock(>local->sta_mtx);
+
+   sta = sta_info_get_bss(sdata, peer);
+   if (!sta) {
+   mutex_unlock(>local->sta_mtx);
+   return -ENOENT;
+   }
+
+   if (sta->rssi_low == rssi_low &&
+   sta->rssi_high == rssi_high)
+   goto unlock;
+
+   sta->rssi_thold = 0;
+   sta->rssi_hyst = 0;
+   sta->rssi_low = rssi_low;
+   sta->rssi_high = rssi_high;
+   sta->last_sta_mon_event_signal = 0;
+
+unlock:
+   mutex_unlock(>local->sta_mtx);
+   return 0;
+}
+
 const struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -3798,4 +3871,6 @@ static int ieee80211_set_multicast_to_unicast(struct 
wiphy *wiphy,
.del_nan_func = ieee80211_del_nan_func,
.set_multicast_to_unicast = ieee80211_set_multicast_to_unicast,
.tx_control_port = ieee80211_tx_control_port,
+   .set_sta_mon_rssi_config = ieee80211_set_sta_mon_rssi_config,
+   .set_sta_mon_rssi_range_config = ieee80211_set_sta_mon_rssi_range_confg,
 };
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index f64eb86..701eb37 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -481,6 +481,18 @@ struct ieee80211_sta_rx_stats {
  * @pcpu_rx_stats: per-CPU RX statistics, assigned only if the driver needs
  * this (by advertising the USES_RSS hw flag)
  * @status_stats: TX status statistics
+ * @rssi_thold: RSSI threshold to monitor station's signal strength, a zero
+ * value implies disabled. As with the cfg80211 callback, a change here
+ * should cause an event to be sent indicating where the current value
+ * is in relation to the newly configured threshold
+ * @rssi_hyst: Station's RSSI hysteresis
+ * @rssi_low: RSSI lower threshold to monitor station's signal strength, a zero
+ * value implies disabled.  This is an alternative mechanism to the single
+ * threshold event and can't be enabled simultaneously with it
+ * @rssi_high: RSSI upper threshold for station
+ * @last_sta_mon_event_signal: Last signal strength average for a station
+ * that triggered a sta_mon event. 0 indicates that no event has been
+ * generated for the current association
  */
 struct sta_info {
/* General information, mostly static */
@@ -581,6 +593,12 @@ struct 

[RFCv2 4/6] cfg80211: Add support to configure station specific txrate threshold for AP mode

2018-04-26 Thread Tamizh chelvam
This patch add support to configure station specific txrate threshold
to monitor change in txrate for stations. This will be useful
for the user application like steering to configure and monitor the
change event of txrate for the station.

NL80211_ATTR_STA_MON_LOW_TXRATE_THOLD and NL80211_ATTR_STA_MON_HIGH_TXRATE_THOLD
used with NL80211_CMD_STA_MON command to configure the txrate threshold and
the configuration will be represented in 100kbps.

cfg80211_sta_mon_txrate_notify introduce to notify txrate for a station
goes out of range using NL80211_CMD_NOTIFY_STA_MON command.

NL80211_EXT_FEATURE_STA_MON_TXRATE_CONFIG flag needs to be advertised by the
drvier to allow and monitor txrate threshold configuration.

Signed-off-by: Tamizh chelvam 
---
 include/net/cfg80211.h   | 26 
 include/uapi/linux/nl80211.h | 34 
 net/wireless/nl80211.c   | 74 
 net/wireless/rdev-ops.h  | 17 ++
 net/wireless/trace.h | 49 +
 5 files changed, 200 insertions(+)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7e7a0bf..4456e2e 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2984,6 +2984,10 @@ struct cfg80211_external_auth_params {
  * The driver should set %NL80211_EXT_FEATURE_STA_MON_RSSI_LIST if this
  * method is implemented. If it is provided then there's no point providing
  * @set_sta_mon_rssi_config.
+ * @set_sta_mon_txrate_config: Configure low and high TXRATE threshold in 
100kbs
+ * for a connected station. The driver should(soon) send an event
+ * indicating the current attempted frame txrate level is above/below the
+ * configured threshold.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -3293,6 +3297,11 @@ struct cfg80211_ops {
 struct net_device *dev,
 const u8 *addr,
 s32 rssi_low, s32 rssi_high);
+   int (*set_sta_mon_txrate_config)(struct wiphy *wiphy,
+struct net_device *dev,
+const u8 *addr,
+u32 low_txrate_thold,
+u32 high_txrate_thold);
 };
 
 /*
@@ -5813,6 +5822,23 @@ void cfg80211_cqm_rssi_notify(struct net_device *dev,
 s32 rssi_level, gfp_t gfp);
 
 /**
+ * cfg80211_sta_mon_txrate_notify - txrate event for connected stations
+ * @dev: network device
+ * @peer: peer's MAC address
+ * @txrate_event: the triggered TX RATE event
+ * @txrate_level: new TX RATE level value or 0 if not available
+ * @gfp: context flags
+ *
+ * This function is called when a average of attempted frame txrate crossed
+ * above configured high txrate or below configured low txrate event
+ * occurs for a station.
+ */
+void
+cfg80211_sta_mon_txrate_notify(struct net_device *dev, const u8 *peer,
+   enum nl80211_sta_mon_txrate_threshold_event txrate_event,
+   u32 txrate_level, gfp_t gfp);
+
+/**
  * cfg80211_cqm_pktloss_notify - notify userspace about packetloss to peer
  * @dev: network device
  * @peer: peer's MAC address
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index fa1fed1..a8b5e3d 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -4266,6 +4266,15 @@ enum nl80211_attr_cqm {
  * @NL80211_ATTR_STA_MON_RSSI_THRESHOLD_EVENT: RSSI threshold event
  * @NL80211_ATTR_STA_MON_RSSI_LEVEL: the RSSI value in dBm that triggered the
  * RSSI threshold event.
+ * @NL80211_ATTR_STA_MON_LOW_TXRATE_THOLD: TX_RATE threshold in 100kbps. This
+ * u32 attribute specifies the low txrate threshold. Event will be sent
+ * if the txrate for a station goes lesser than this threshold.
+ * @NL80211_ATTR_STA_MON_HIGH_TXRATE_THOLD: TX_RATE threshold in 100kbps. This
+ * u32 attribute specifies the upper txrate threshold. Event will be sent
+ * if the txrate for a station goes greater than this threshold.
+ * @NL80211_ATTR_STA_MON_TXRATE_THRESHOLD_EVENT: TX_RATE threshold cross event
+ * @NL80211_ATTR_STA_MON_TXRATE_LEVEL: TXRATE for a station in 100kbps that
+ * triggered the TX_RATE threshold cross event.
  */
 enum nl80211_attr_sta_mon {
__NL80211_ATTR_STA_MON_INVALID,
@@ -4273,6 +4282,10 @@ enum nl80211_attr_sta_mon {
NL80211_ATTR_STA_MON_RSSI_HYST,
NL80211_ATTR_STA_MON_RSSI_THRESHOLD_EVENT,
NL80211_ATTR_STA_MON_RSSI_LEVEL,
+   NL80211_ATTR_STA_MON_LOW_TXRATE_THOLD,
+   NL80211_ATTR_STA_MON_HIGH_TXRATE_THOLD,
+   NL80211_ATTR_STA_MON_TXRATE_THRESHOLD_EVENT,
+   NL80211_ATTR_STA_MON_TXRATE_LEVEL,
 
/* keep last */
__NL80211_ATTR_STA_MON_AFTER_LAST,
@@ -4305,6 

[RFCv2 3/6] mac80211: Implement functionality to monitor station's rssi threshold cross

2018-04-26 Thread Tamizh chelvam
Triggers cfg80211_sta_mon_rssi_notify with the corresponding event when
station signal goes out of configured threshold. It uses rx data signal
to check against rssi threshold configured by the user.
This event will be useful for the application like steering to take
decision on any station depends on its current capability.

Signed-off-by: Tamizh chelvam 
---
 include/net/mac80211.h  |  7 ++
 net/mac80211/rx.c   | 65 -
 net/mac80211/sta_info.h |  4 +++
 3 files changed, 75 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index d2279b2..7b3d505 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -803,6 +803,13 @@ enum mac80211_rate_control_flags {
 };
 
 
+/*
+ * How many frames need to have been used in average station's
+ * signal strength before checking against the threshold
+ */
+#define IEEE80211_STA_SIGNAL_AVE_MIN_COUNT 4
+
+
 /* there are 40 bytes if you don't need the rateset to be kept */
 #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE 40
 
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 03102af..d21f5b1 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1536,6 +1536,66 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta 
*pubsta, u8 tid)
return RX_CONTINUE;
 }
 
+static void ieee80211_sta_rx_signal_thold_check(struct ieee80211_rx_data *rx)
+{
+   struct sta_info *sta = rx->sta;
+   struct ieee80211_bss_conf *bss_conf = >sdata->vif.bss_conf;
+
+   if (!wiphy_ext_feature_isset(rx->local->hw.wiphy,
+   NL80211_EXT_FEATURE_STA_MON_RSSI_CONFIG))
+   return;
+
+   sta->count_rx_signal++;
+   if (sta->count_rx_signal < IEEE80211_STA_SIGNAL_AVE_MIN_COUNT)
+   return;
+
+   if (sta->rssi_thold && bss_conf->enable_beacon) {
+   int last_event = sta->last_sta_mon_event_signal;
+   int thold = sta->rssi_thold;
+   int hyst = sta->rssi_hyst;
+   int sig = -ewma_signal_read(>rx_stats_avg.signal);
+
+   if (sig < thold &&
+   (last_event == 0 || sig < last_event - hyst)) {
+   sta->last_sta_mon_event_signal = sig;
+   cfg80211_sta_mon_rssi_notify(
+   rx->sdata->dev, sta->addr,
+   NL80211_STA_MON_RSSI_THRESHOLD_EVENT_LOW,
+   sig, GFP_ATOMIC);
+   } else if (sig > thold &&
+  (last_event == 0 || sig > last_event + hyst)) {
+   sta->last_sta_mon_event_signal = sig;
+   cfg80211_sta_mon_rssi_notify(
+   rx->sdata->dev, sta->addr,
+   NL80211_STA_MON_RSSI_THRESHOLD_EVENT_HIGH,
+   sig, GFP_ATOMIC);
+   }
+   }
+
+   if (sta->rssi_low) {
+   int last_event = sta->last_sta_mon_event_signal;
+   int sig = -ewma_signal_read(>rx_stats_avg.signal);
+   int low = sta->rssi_low;
+   int high = sta->rssi_high;
+
+   if (sig < low &&
+   (last_event == 0 || last_event >= low)) {
+   sta->last_sta_mon_event_signal = sig;
+   cfg80211_sta_mon_rssi_notify(
+   rx->sdata->dev, sta->addr,
+   NL80211_STA_MON_RSSI_THRESHOLD_EVENT_LOW,
+   sig, GFP_ATOMIC);
+   } else if (sig > high &&
+  (last_event == 0 || last_event <= high)) {
+   sta->last_sta_mon_event_signal = sig;
+   cfg80211_sta_mon_rssi_notify(
+   rx->sdata->dev, sta->addr,
+   NL80211_STA_MON_RSSI_THRESHOLD_EVENT_HIGH,
+   sig, GFP_ATOMIC);
+   }
+   }
+}
+
 static ieee80211_rx_result debug_noinline
 ieee80211_rx_h_sta_process(struct ieee80211_rx_data *rx)
 {
@@ -1591,6 +1651,7 @@ void ieee80211_sta_uapsd_trigger(struct ieee80211_sta 
*pubsta, u8 tid)
if (!(status->flag & RX_FLAG_NO_SIGNAL_VAL)) {
sta->rx_stats.last_signal = status->signal;
ewma_signal_add(>rx_stats_avg.signal, -status->signal);
+   ieee80211_sta_rx_signal_thold_check(rx);
}
 
if (status->chains) {
@@ -4032,9 +4093,11 @@ static bool ieee80211_invoke_fast_rx(struct 
ieee80211_rx_data *rx,
/* statistics part of ieee80211_rx_h_sta_process() */
if (!(status->flag & RX_FLAG_NO_SIGNAL_VAL)) {
stats->last_signal = status->signal;
-   if (!fast_rx->uses_rss)
+   if (!fast_rx->uses_rss) {
ewma_signal_add(>rx_stats_avg.signal,

[RFCv2 1/6] cfg80211: Add support to configure station specific rssi threshold for AP mode

2018-04-26 Thread Tamizh chelvam
This patch add support to configure station specific rssi threshold
to monitor station's signal strength modification. This will be useful
for the user application like steering to configure and monitor the station's
signal strength change event.

New NL80211_CMD_STA_MON command introduced to cofigure single or multi
rssi thresholds using NL80211_ATTR_STA_MON_RSSI_THOLD and
NL80211_ATTR_STA_MON_RSSI_HYST.

cfg80211_sta_mon_rssi_notify introduce to notify station's signal strength
goes out of range using NL80211_CMD_NOTIFY_STA_MON command.

NL80211_EXT_FEATURE_STA_MON_RSSI_CONFIG flag needs to be advertised by the
drvier to allow single rssi threshold and hysteresis configuration.
NL80211_EXT_FEATURE_STA_MON_RSSI_LIST needs to be advertised to allow
multi rssi thresholds.

Signed-off-by: Tamizh chelvam 
---
 include/net/cfg80211.h   |  43 -
 include/uapi/linux/nl80211.h |  62 +++
 net/wireless/core.c  |  26 ++-
 net/wireless/core.h  |   6 +-
 net/wireless/nl80211.c   | 388 +--
 net/wireless/rdev-ops.h  |  31 
 net/wireless/trace.h |  74 +
 7 files changed, 567 insertions(+), 63 deletions(-)

diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 250dac3..7e7a0bf 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -2973,6 +2973,17 @@ struct cfg80211_external_auth_params {
  *
  * @tx_control_port: TX a control port frame (EAPoL).  The noencrypt parameter
  * tells the driver that the frame should not be encrypted.
+ * @set_sta_mon_rssi_config: Configure  RSSI threshold for a station.
+ * After configuration, the driver should (soon) send an event indicating
+ * the current level of a station is above/below the configured threshold;
+ * this may need some care when the configuration is changed
+ * (without first being disabled.)
+ * @set_sta_mon_rssi_range_config: Configure two RSSI thresholds in the
+ * station's rssi monitor.  An event is to be sent only when the
+ * signal level of a station is found to be outside the two values.
+ * The driver should set %NL80211_EXT_FEATURE_STA_MON_RSSI_LIST if this
+ * method is implemented. If it is provided then there's no point providing
+ * @set_sta_mon_rssi_config.
  */
 struct cfg80211_ops {
int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow);
@@ -3274,6 +3285,14 @@ struct cfg80211_ops {
   const u8 *buf, size_t len,
   const u8 *dest, const __be16 proto,
   const bool noencrypt);
+   int (*set_sta_mon_rssi_config)(struct wiphy *wiphy,
+   struct net_device *dev,
+   const u8 *addr,
+   s32 rssi_thold, u32 rssi_hyst);
+   int (*set_sta_mon_rssi_range_config)(struct wiphy *wiphy,
+struct net_device *dev,
+const u8 *addr,
+s32 rssi_low, s32 rssi_high);
 };
 
 /*
@@ -4076,7 +4095,7 @@ static inline struct wiphy *wiphy_new(const struct 
cfg80211_ops *ops,
 struct cfg80211_conn;
 struct cfg80211_internal_bss;
 struct cfg80211_cached_keys;
-struct cfg80211_cqm_config;
+struct cfg80211_rssi_config;
 
 /**
  * struct wireless_dev - wireless device state
@@ -4141,7 +4160,8 @@ static inline struct wiphy *wiphy_new(const struct 
cfg80211_ops *ops,
  * @event_lock: (private) lock for event list
  * @owner_nlportid: (private) owner socket port ID
  * @nl_owner_dead: (private) owner socket went away
- * @cqm_config: (private) nl80211 RSSI monitor state
+ * @rssi_config: (private) nl80211 RSSI monitor state
+ * @rssi_config_list: list of peer address based rssi configuration
  */
 struct wireless_dev {
struct wiphy *wiphy;
@@ -4212,7 +4232,8 @@ struct wireless_dev {
} wext;
 #endif
 
-   struct cfg80211_cqm_config *cqm_config;
+   struct cfg80211_rssi_config *rssi_config;
+   struct list_head rssi_config_list;
 };
 
 static inline u8 *wdev_address(struct wireless_dev *wdev)
@@ -5776,6 +5797,22 @@ void cfg80211_cqm_rssi_notify(struct net_device *dev,
  s32 rssi_level, gfp_t gfp);
 
 /**
+ * cfg80211_sta_mon_rssi_notify - Station's rssi out of range event
+ * @dev: network device
+ * @peer: Station's mac address
+ * @rssi_event: the triggered RSSI event
+ * @rssi_level: new RSSI level value or 0 if not available
+ * @gfp: context flags
+ *
+ * This function is called when a configured rssi threshold reached event
+ * occurs for a station.
+ */
+void
+cfg80211_sta_mon_rssi_notify(struct net_device *dev, const u8 *peer,
+enum nl80211_sta_mon_rssi_threshold_event rssi_event,
+s32 rssi_level, gfp_t gfp);
+
+/**
 

[RFCv2 5/6] mac80211: Add support to configure txrate threshold for station

2018-04-26 Thread Tamizh chelvam
This patch add support to configure station specific low and high
txrate thresholds using ieee80211_set_sta_mon_txrate_config API.
This configuration is used for tracking the txrate for connected
stations.

Signed-off-by: Tamizh chelvam 
---
 net/mac80211/cfg.c  | 35 +++
 net/mac80211/sta_info.h |  5 +
 2 files changed, 40 insertions(+)

diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 0e2047c..ba2555d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3778,6 +3778,40 @@ static int ieee80211_set_sta_mon_rssi_range_confg(struct 
wiphy *wiphy,
return 0;
 }
 
+static int ieee80211_set_sta_mon_txrate_config(struct wiphy *wiphy,
+  struct net_device *dev,
+  const u8 *peer,
+  u32 low_txrate_thold,
+  u32 high_txrate_thold)
+{
+   struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev);
+   struct sta_info *sta;
+
+   if (sdata->vif.type == NL80211_IFTYPE_AP &&
+   !wiphy_ext_feature_isset(sdata->local->hw.wiphy,
+   NL80211_EXT_FEATURE_STA_MON_TXRATE_CONFIG))
+   return -EOPNOTSUPP;
+
+   mutex_lock(>local->sta_mtx);
+
+   sta = sta_info_get_bss(sdata, peer);
+   if (!sta) {
+   mutex_unlock(>local->sta_mtx);
+   return -ENOENT;
+   }
+
+   if (sta->txrate_low == low_txrate_thold &&
+   sta->txrate_high == high_txrate_thold)
+   goto unlock;
+
+   sta->txrate_low = low_txrate_thold;
+   sta->txrate_high = high_txrate_thold;
+
+unlock:
+   mutex_unlock(>local->sta_mtx);
+   return 0;
+}
+
 const struct cfg80211_ops mac80211_config_ops = {
.add_virtual_intf = ieee80211_add_iface,
.del_virtual_intf = ieee80211_del_iface,
@@ -3873,4 +3907,5 @@ static int ieee80211_set_sta_mon_rssi_range_confg(struct 
wiphy *wiphy,
.tx_control_port = ieee80211_tx_control_port,
.set_sta_mon_rssi_config = ieee80211_set_sta_mon_rssi_config,
.set_sta_mon_rssi_range_config = ieee80211_set_sta_mon_rssi_range_confg,
+   .set_sta_mon_txrate_config = ieee80211_set_sta_mon_txrate_config,
 };
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index 1599973..c73d010 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -496,6 +496,8 @@ struct ieee80211_sta_rx_stats {
  * @count_rx_signal: Number of data frames used in averaging station signal.
  * This can be used to avoid generating less reliable station rssi cross
  * events that would be based only on couple of received frames.
+ * @txrate_low: TXRATE lower threshold for a station to monitor
+ * @txrate_high: TXRATE upper threshold for a station to monitor
  */
 struct sta_info {
/* General information, mostly static */
@@ -603,6 +605,9 @@ struct sta_info {
int last_sta_mon_event_signal;
unsigned int count_rx_signal;
 
+   u32 txrate_low;
+   u32 txrate_high;
+
/* keep last! */
struct ieee80211_sta sta;
 };
-- 
1.9.1



[RFCv2 6/6] mac80211: Implement functionality to monitor txrate cross event for station

2018-04-26 Thread Tamizh chelvam
Trigger cfg80211_sta_mon_txrate_notify with the corresponding txrate
event when the txrate for a station goes out of configured range.
This event will be useful for the application like steering to take
decision on any station depends on its current capability.

Signed-off-by: Tamizh chelvam 
---
 include/net/mac80211.h  |  5 +
 net/mac80211/cfg.c  |  1 +
 net/mac80211/sta_info.h | 10 ++
 net/mac80211/status.c   | 40 +++-
 4 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 7b3d505..7023f40 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -809,6 +809,11 @@ enum mac80211_rate_control_flags {
  */
 #define IEEE80211_STA_SIGNAL_AVE_MIN_COUNT 4
 
+/* Number of txrate count need to have been used in average station's
+ * txrate before checking against the threshold
+ */
+#define IEEE80211_STA_TXRATE_AVE_MIN_COUNT 4
+
 
 /* there are 40 bytes if you don't need the rateset to be kept */
 #define IEEE80211_TX_INFO_DRIVER_DATA_SIZE 40
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index ba2555d..0f06b0b 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -3806,6 +3806,7 @@ static int ieee80211_set_sta_mon_txrate_config(struct 
wiphy *wiphy,
 
sta->txrate_low = low_txrate_thold;
sta->txrate_high = high_txrate_thold;
+   sta->last_txrate_event = 0;
 
 unlock:
mutex_unlock(>local->sta_mtx);
diff --git a/net/mac80211/sta_info.h b/net/mac80211/sta_info.h
index c73d010..e23d916 100644
--- a/net/mac80211/sta_info.h
+++ b/net/mac80211/sta_info.h
@@ -418,6 +418,8 @@ struct ieee80211_sta_rx_stats {
  */
 #define STA_SLOW_THRESHOLD 6000 /* 6 Mbps */
 
+DECLARE_EWMA(sta_txrate, 4, 4)
+
 /**
  * struct sta_info - STA information
  *
@@ -498,6 +500,11 @@ struct ieee80211_sta_rx_stats {
  * events that would be based only on couple of received frames.
  * @txrate_low: TXRATE lower threshold for a station to monitor
  * @txrate_high: TXRATE upper threshold for a station to monitor
+ * @count_sta_txrate: Number of transmitted data frames used in ave_sta_txrate
+ * @last_txrate_event: Last txrate event that triggered sta_mon event for a
+ * station
+ * @ave_sta_txrate: Average txrate to check against the txrate_low and
+ * txrate_high. Values expressed in 100kbps
  */
 struct sta_info {
/* General information, mostly static */
@@ -608,6 +615,9 @@ struct sta_info {
u32 txrate_low;
u32 txrate_high;
 
+   unsigned int count_sta_txrate;
+   enum nl80211_sta_mon_txrate_threshold_event last_txrate_event;
+   struct ewma_sta_txrate ave_sta_txrate;
/* keep last! */
struct ieee80211_sta sta;
 };
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 743e89c..6656b04 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -699,6 +699,40 @@ void ieee80211_tx_monitor(struct ieee80211_local *local, 
struct sk_buff *skb,
dev_kfree_skb(skb);
 }
 
+static void ieee80211_sta_mon_txrate_thold_check(struct sta_info *sta)
+{
+   struct rate_info rinfo;
+   enum nl80211_sta_mon_txrate_threshold_event sta_txrate_event;
+   int txrate;
+
+   if (!sta->txrate_high)
+   return;
+
+   sta_set_rate_info_tx(sta, >tx_stats.last_rate, );
+   txrate = cfg80211_calculate_bitrate();
+   ewma_sta_txrate_add(>ave_sta_txrate, txrate);
+   sta->count_sta_txrate++;
+
+   if (sta->count_sta_txrate < IEEE80211_STA_TXRATE_AVE_MIN_COUNT)
+   return;
+
+   txrate = ewma_sta_txrate_read(>ave_sta_txrate);
+
+   if (txrate < sta->txrate_low)
+   sta_txrate_event = NL80211_STA_MON_TXRATE_THRESHOLD_EVENT_LOW;
+   else if (txrate > sta->txrate_high)
+   sta_txrate_event = NL80211_STA_MON_TXRATE_THRESHOLD_EVENT_HIGH;
+   else
+   sta_txrate_event = NL80211_STA_MON_TXRATE_THRESHOLD_IN_RANGE;
+
+   if (sta_txrate_event != sta->last_txrate_event) {
+   cfg80211_sta_mon_txrate_notify(sta->sdata->dev, sta->addr,
+  sta_txrate_event, txrate,
+  GFP_ATOMIC);
+   sta->last_txrate_event = sta_txrate_event;
+   }
+}
+
 static void __ieee80211_tx_status(struct ieee80211_hw *hw,
  struct ieee80211_tx_status *status)
 {
@@ -748,9 +782,13 @@ static void __ieee80211_tx_status(struct ieee80211_hw *hw,
 
if (ieee80211_hw_check(>hw, HAS_RATE_CONTROL) &&
(ieee80211_is_data(hdr->frame_control)) &&
-   (rates_idx != -1))
+   (rates_idx != -1)) {
sta->tx_stats.last_rate =
info->status.rates[rates_idx];
+   if (wiphy_ext_feature_isset(hw->wiphy,
+   

[RFCv2 0/6] cfg80211/mac80211: Add support to configure and monitor rssi/txrate threshold

2018-04-26 Thread Tamizh chelvam
This patchsets introduced new NL command and api to support
configuring rssi and txrate for the connected stations.
And implemented new api to notify the threshold cross event.
This will be useful/requires for the user application like steering
to monitor station's activity change.

Tamizh chelvam (6):
  cfg80211: Add support to configure station specific rssi threshold for
AP mode
  mac80211: Add support to configure rssi threshold for AP mode
  mac80211: Implement functionality to monitor station's rssi threshold
cross
  cfg80211: Add support to configure station specific txrate threshold
for AP mode
  mac80211: Add support to configure txrate threshold for station
  mac80211: Implement functionality to monitor txrate cross event for
station

v2:
  * fixed kbuild warnings
  * updated commit log

 include/net/cfg80211.h   |  69 ++-
 include/net/mac80211.h   |  12 ++
 include/uapi/linux/nl80211.h |  96 +
 net/mac80211/cfg.c   | 111 +++
 net/mac80211/rx.c|  65 +-
 net/mac80211/sta_info.h  |  37 
 net/mac80211/status.c|  40 +++-
 net/wireless/core.c  |  26 ++-
 net/wireless/core.h  |   6 +-
 net/wireless/nl80211.c   | 462 ++-
 net/wireless/rdev-ops.h  |  48 +
 net/wireless/trace.h | 123 
 12 files changed, 1030 insertions(+), 65 deletions(-)

-- 
1.9.1



Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread Sebastian Gottschall

Am 26.04.2018 um 22:35 schrieb Ben Greear:

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and 
may lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks 
in addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for 
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. 
From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if 
peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams 
here.
no? rxnss_override is only taked if peer phymode is vht160 or 
vht80_80. vht80 is not considered in that code PEER phy_mode, not 
HOST phy_mode

this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.


From what I can tell, this feature is supposed to configure the 
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can 
send at higher NSS if it sends

at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is 
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is 
used if available. if not ,it uses the fallback.


If a 2x2 peer connects to the AP, will it have 
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer does 
transmit his own nss capabilities.

If so,
then your code will configure the peer_bw_rxnss_override to indicate 
it can send at 160Mhz

2x2 as well, right?  And if so, then that is incorrect.

no. since nss_override is only set if peer phymode is 160 mhz as well


Probably if you connected something like a IPQ4019 station to a 9984 
AP configured for 160Mhz,

the peer_bw_rxnss_override would be set to 2x2 instead of 1x1?
depends how the ipq4019 chipset is configured. if it itself is 
configured to 160 mhz and configured to 2x2, yes
but the peer itself can also send with 1x1, then the ap will also send 
just 1x1
but as i said. this all is just used if the peer is configured to vht160 
and if num_spatial_stream is set by peer.
of not this is all ignored and only 1<<31 is masked. this way has been 
taken from qca's propertiery code

or lets say not taken but the behaviour has been translated




-    if (arg->peer_vht_rates.rx_max_rate &&
-    (sta->vht_cap.cap & 
IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {

-    switch (arg->peer_vht_rates.rx_max_rate) {
-    case 1560:
-    /* Must be 2x2 at 160Mhz is all it can do. */
-    arg->peer_bw_rxnss_override = 2;
-    break;
-  

[PATCH] mac80211: fix kernel-doc "bad line" warning

2018-04-26 Thread Randy Dunlap
From: Randy Dunlap <rdun...@infradead.org>

Fix 88 instances of a kernel-doc warning:
  ../include/net/mac80211.h:2083: warning: bad line:  >

Signed-off-by: Randy Dunlap <rdun...@infradead.org>
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johan...@sipsolutions.net>
---
 include/net/mac80211.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20180426.orig/include/net/mac80211.h
+++ linux-next-20180426/include/net/mac80211.h
@@ -2080,7 +2080,7 @@ struct ieee80211_txq {
  * virtual interface might not be given air time for the transmission of
  * the frame, as it is not synced with the AP/P2P GO yet, and thus the
  * deauthentication frame might not be transmitted.
- >
+ *
  * @IEEE80211_HW_DOESNT_SUPPORT_QOS_NDP: The driver (or firmware) doesn't
  * support QoS NDP for AP probing - that's most likely a driver bug.
  *




[PATCH v2] staging/wilc1000: fix wilc_mac_xmit()'s return type

2018-04-26 Thread Luc Van Oostenryck
The method ndo_start_xmit() is defined as returning an 'netdev_tx_t',
which is a typedef for an enum type, but the implementation in this
driver returns an 'int'.

Fix this by returning 'netdev_tx_t' in this driver too
and accordingly change 'return 0;' by 'return NETDEV_TX_OK;'

Signed-off-by: Luc Van Oostenryck 
---
 drivers/staging/wilc1000/linux_wlan.c | 8 
 drivers/staging/wilc1000/wilc_wlan.h  | 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/wilc1000/linux_wlan.c 
b/drivers/staging/wilc1000/linux_wlan.c
index 38a83bd31..d95b9750b 100644
--- a/drivers/staging/wilc1000/linux_wlan.c
+++ b/drivers/staging/wilc1000/linux_wlan.c
@@ -941,7 +941,7 @@ static void linux_wlan_tx_complete(void *priv, int status)
kfree(pv_data);
 }
 
-int wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev)
+netdev_tx_t wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev)
 {
struct wilc_vif *vif;
struct tx_complete_data *tx_data = NULL;
@@ -956,14 +956,14 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device 
*ndev)
 
if (skb->dev != ndev) {
netdev_err(ndev, "Packet not destined to this device\n");
-   return 0;
+   return NETDEV_TX_OK;
}
 
tx_data = kmalloc(sizeof(*tx_data), GFP_ATOMIC);
if (!tx_data) {
dev_kfree_skb(skb);
netif_wake_queue(ndev);
-   return 0;
+   return NETDEV_TX_OK;
}
 
tx_data->buff = skb->data;
@@ -994,7 +994,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device 
*ndev)
netif_stop_queue(wilc->vif[1]->ndev);
}
 
-   return 0;
+   return NETDEV_TX_OK;
 }
 
 static int wilc_mac_close(struct net_device *ndev)
diff --git a/drivers/staging/wilc1000/wilc_wlan.h 
b/drivers/staging/wilc1000/wilc_wlan.h
index fa157a67b..d3b5a6b38 100644
--- a/drivers/staging/wilc1000/wilc_wlan.h
+++ b/drivers/staging/wilc1000/wilc_wlan.h
@@ -298,7 +298,7 @@ void wilc_chip_sleep_manually(struct wilc *wilc);
 
 void wilc_enable_tcp_ack_filter(bool value);
 int wilc_wlan_get_num_conn_ifcs(struct wilc *wilc);
-int wilc_mac_xmit(struct sk_buff *skb, struct net_device *dev);
+netdev_tx_t wilc_mac_xmit(struct sk_buff *skb, struct net_device *dev);
 
 void WILC_WFI_p2p_rx(struct net_device *dev, u8 *buff, u32 size);
 void host_wakeup_notify(struct wilc *wilc);
-- 
2.17.0



Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread Ben Greear

On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 +++
 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+}

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 0x%x\n",
-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+if (arg->peer_num_spatial_streams && (arg->peer_phymode == MODE_11AC_VHT160 
|| arg->peer_phymode == MODE_11AC_VHT80_80)) {
+arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+}


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. From what I 
can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if peer is 
VHT-160,
then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams here.

no? rxnss_override is only taked if peer phymode is vht160 or vht80_80. vht80 
is not considered in that code PEER phy_mode, not HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode
if a peer is 80 mhz, the code will be skipped here.


From what I can tell, this feature is supposed to configure the rate-ctrl in 
the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can send at 
higher NSS if it sends
at 80Mhz or lower.

If a 2x2 peer connects to the AP, will it have peer_num_spatial_streams set to 
2?  If so,
then your code will configure the peer_bw_rxnss_override to indicate it can 
send at 160Mhz
2x2 as well, right?  And if so, then that is incorrect.

Probably if you connected something like a IPQ4019 station to a 9984 AP 
configured for 160Mhz,
the peer_bw_rxnss_override would be set to 2x2 instead of 1x1?



-if (arg->peer_vht_rates.rx_max_rate &&
-(sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-switch (arg->peer_vht_rates.rx_max_rate) {
-case 1560:
-/* Must be 2x2 at 160Mhz is all it can do. */
-arg->peer_bw_rxnss_override = 2;
-break;
-case 780:
-/* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-arg->peer_bw_rxnss_override = 1;
-break;
-}


This old code does look wrong, the firmware is using zero-based, so override-0 
== nss-1, override-1 == nss-2.

0 = crash

and 1 and 2 is wrong.


Yes, it should be 0 and 1.  The old code | in the (1<<31) later.



+#define BW_NSS_FWCONF_MAP_ENABLE (1 << 31)
+#define BW_NSS_FWCONF_MAP_160MHZ_S   (0)
+#define BW_NSS_FWCONF_MAP_160MHZ_M   (0x0007)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_S (3)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_M (0x0038)


This is confusing enough that it deserves a comment in the code I think

the removal doesnt deserve a comment. i dont know how to explain that its 
simply wrong. it uses the wrong
bit masks and this has been written in the initial patch description


I think a comment like this would be 

Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread Sebastian Gottschall

Am 26.04.2018 um 17:30 schrieb Ben Greear:

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on 
guessing the VHT160/8080 capability by rx rate. this is wrong and may 
lead
to a non initialized peer_bw_rxnss_override parameter which is 
required since VHT160 operation mode only supports 2x2 chainmasks in 
addition the original code

initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the 
parameter by minimum nss which is suggested by QCA as temporary 
workaround according

to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 
+++

 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
 arg->peer_flags |= ar->wmi.peer_flags->bw80;

-    if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+    if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
 arg->peer_flags |= ar->wmi.peer_flags->bw160;
+    }

 /* Calculate peer NSS capability from VHT capabilities if STA
  * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct 
ath10k *ar,

 arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
 __le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 0x%x\n",

-   sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+    if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+    arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);

+    }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. From 
what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if 
peer is VHT-160,

then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or vht80_80. 
vht80 is not considered in that code PEER phy_mode, not HOST phy_mode

this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for 
peer_bw_rxnss_override in vht160 operation mode

if a peer is 80 mhz, the code will be skipped here.





-    if (arg->peer_vht_rates.rx_max_rate &&
-    (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-    switch (arg->peer_vht_rates.rx_max_rate) {
-    case 1560:
-    /* Must be 2x2 at 160Mhz is all it can do. */
-    arg->peer_bw_rxnss_override = 2;
-    break;
-    case 780:
-    /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-    arg->peer_bw_rxnss_override = 1;
-    break;
-    }


This old code does look wrong, the firmware is using zero-based, so 
override-0 == nss-1, override-1 == nss-2.

0 = crash

and 1 and 2 is wrong.

+#define BW_NSS_FWCONF_MAP_ENABLE (1 << 31)
+#define BW_NSS_FWCONF_MAP_160MHZ_S   (0)
+#define BW_NSS_FWCONF_MAP_160MHZ_M   (0x0007)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_S (3)
+#define BW_NSS_FWCONF_MAP_80_80MHZ_M (0x0038)


This is confusing enough that it deserves a comment in the code I 
think
the removal doesnt deserve a comment. i dont know how to explain that 
its simply wrong. it uses the wrong

bit masks and this has been written in the initial patch description


+    if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+    arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);

 }
+
+    /* In very exceptional  conditions it is observed  that
+ * firmware was receiving bw_rxnss_override as 0 for peer from 
host, and resulting in Target Assert.
+ * Changing the rxnss_override to minimum nss. This is a 
temporary WAR. Needs to be fixed

+ * properly.
+ */
+    if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {

+    arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+    }
+
+    ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d 
flags 

[PATCHv2] cfg80211: Call reg_notifier for self managed hints conditionally

2018-04-26 Thread Jouni Malinen
From: Amar Singhal 

Currently the regulatory core does not call the regulatory callback
reg_notifier for self managed wiphys, but regulatory_hint_user() call is
independent of wiphy and is meant for all wiphys in the system. Even a
self managed wiphy may be interested in regulatory_hint_user() to know
the country code from a trusted regulatory domain change like a cellular
base station. Therefore, for the regulatory source
NL80211_REGDOM_SET_BY_USER and the user hint type
NL80211_USER_REG_HINT_CELL_BASE, call the regulatory notifier.

No current wlan driver uses the REGULATORY_WIPHY_SELF_MANAGED flag while
also registering the reg_notifier regulatory callback, therefore there
will be no impact on existing drivers without them being explicitly
modified to take advantage of this new possibility.

Signed-off-by: Amar Singhal 
Signed-off-by: Jouni Malinen 
---
 net/wireless/reg.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)
 
v2
- merge the two patches into a single one
- instead of modifying reg_only_self_managed_wiphys() use a new helper
  function notify_self_managed_wiphys() to clean up the implementation
- update commit message and comments to describe the desired use case
  more clearly and note that this does not change behavior with existing
  drivers without an explicit driver change

diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index ecfee5f..25bce79 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2768,6 +2768,21 @@ static void reg_process_hint(struct regulatory_request 
*reg_request)
reg_free_request(reg_request);
 }
 
+static void notify_self_managed_wiphys(struct regulatory_request *request)
+{
+   struct cfg80211_registered_device *rdev;
+   struct wiphy *wiphy;
+
+   list_for_each_entry(rdev, _rdev_list, list) {
+   wiphy = >wiphy;
+   if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED &&
+   request->initiator == NL80211_REGDOM_SET_BY_USER &&
+   request->user_reg_hint_type ==
+   NL80211_USER_REG_HINT_CELL_BASE)
+   reg_call_notifier(wiphy, request);
+   }
+}
+
 static bool reg_only_self_managed_wiphys(void)
 {
struct cfg80211_registered_device *rdev;
@@ -2819,6 +2834,7 @@ static void reg_process_pending_hints(void)
 
spin_unlock(_requests_lock);
 
+   notify_self_managed_wiphys(reg_request);
if (reg_only_self_managed_wiphys()) {
reg_free_request(reg_request);
return;
@@ -3698,17 +3714,26 @@ EXPORT_SYMBOL(regulatory_set_wiphy_regd_sync_rtnl);
 
 void wiphy_regulatory_register(struct wiphy *wiphy)
 {
-   struct regulatory_request *lr;
+   struct regulatory_request *lr = get_last_request();
 
-   /* self-managed devices ignore external hints */
-   if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED)
+   /* self-managed devices ignore beacon hints and country IE */
+   if (wiphy->regulatory_flags & REGULATORY_WIPHY_SELF_MANAGED) {
wiphy->regulatory_flags |= REGULATORY_DISABLE_BEACON_HINTS |
   REGULATORY_COUNTRY_IE_IGNORE;
 
+   /*
+* The last request may have been received before this
+* registration call. Call the driver notifier if
+* initiator is USER and user type is CELL_BASE.
+*/
+   if (lr->initiator == NL80211_REGDOM_SET_BY_USER &&
+   lr->user_reg_hint_type == NL80211_USER_REG_HINT_CELL_BASE)
+   reg_call_notifier(wiphy, lr);
+   }
+
if (!reg_dev_ignore_cell_hint(wiphy))
reg_num_devs_support_basehint++;
 
-   lr = get_last_request();
wiphy_update_regulatory(wiphy, lr->initiator);
wiphy_all_share_dfs_chan_state(wiphy);
 }
-- 
2.7.4



Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread Ben Greear

On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 +++
 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;

-   if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+   }

/* Calculate peer NSS capability from VHT capabilities if STA
 * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);

-   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
-  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+   if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+   arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+   }


So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP.  From what I 
can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if peer is 
VHT-160,
then of course it can only talk at 2x2.

So, I don't think you can just look at the peer_num_spatial_streams here.



-   if (arg->peer_vht_rates.rx_max_rate &&
-   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-   switch (arg->peer_vht_rates.rx_max_rate) {
-   case 1560:
-   /* Must be 2x2 at 160Mhz is all it can do. */
-   arg->peer_bw_rxnss_override = 2;
-   break;
-   case 780:
-   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-   arg->peer_bw_rxnss_override = 1;
-   break;
-   }


This old code does look wrong, the firmware is using zero-based, so override-0 
== nss-1, override-1 == nss-2.

This is confusing enough that it deserves a comment in the code I think


+   if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+   arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);
}
+
+   /* In very exceptional  conditions it is observed  that
+* firmware was receiving bw_rxnss_override as 0 for peer from host, 
and resulting in Target Assert.
+* Changing the rxnss_override to minimum nss. This is a temporary WAR. 
Needs to be fixed
+* properly.
+*/
+   if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
+  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
 }

 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2700,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);

return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 

Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

2018-04-26 Thread Sebastian Gottschall

Am 26.04.2018 um 15:44 schrieb Ben Greear:



On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

starting with firmware 10.4.3.4.x series QCA changed the handling of 
the channel property band_center_freq1 and band_center_freq2 in 
vht160 operation mode

likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with 
official qca firmwares newer than 3.3
consider that this patch will not work with older firmwares anymore. 
to avoid undefined behaviour this we disable vht160 capability for 
outdated firmwares


We should be able to use a feature-flag or otherwise determine if the 
firmware needs the old or new

API and make the driver able to handle both.
the new firmware must be used as is and it works. the old firmware can 
be detected on the missing vht cap flag.
but thats not my task. i can only use feature flags if they are included 
within the qca firmwares. but they arent
the old pre 3.3 firmwares should be treated as obsolete. they are more 
than 2 years old and do not announce vht160 capability
even if it works with some ignorance, but on the other side the it has 
backward incompatiblies with older vht80 only clients.

this is why the new way was introduced


Thanks,
Ben


---
 drivers/net/wireless/ath/ath10k/mac.c |  7 ---
 drivers/net/wireless/ath/ath10k/wmi.c | 11 ---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c

index 5be6386ede8f..d1239d40ac19 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,13 +4449,6 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)

 vht_cap.cap |= val;
 }

-    /* Currently the firmware seems to be buggy, don't enable 80+80
- * mode until that's resolved.
- */
-    if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
-    (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) 
== 0)

-    vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
-
 mcs_map = 0;
 for (i = 0; i < 8; i++) {
 if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c

index 2c36256a441d..d78b8857a513 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1671,13 +1671,18 @@ void ath10k_wmi_put_wmi_channel(struct 
wmi_channel *ch,

 flags |= WMI_CHAN_FLAG_HT40_PLUS;
 if (arg->chan_radar)
 flags |= WMI_CHAN_FLAG_DFS;
-
+    ch->band_center_freq2 = 0;
 ch->mhz = __cpu_to_le32(arg->freq);
 ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
 if (arg->mode == MODE_11AC_VHT80_80)
 ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
-    else
-    ch->band_center_freq2 = 0;
+    if (arg->mode == MODE_11AC_VHT160)  {
+    if (arg->freq < arg->band_center_freq1)
+    ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 - 40);

+    else
+    ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 + 40);

+    ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
+    }
 ch->min_power = arg->min_power;
 ch->max_power = arg->max_power;
 ch->reg_power = arg->max_reg_power;





--
Mit freundlichen Grüssen / Regards

Sebastian Gottschall / CTO

NewMedia-NET GmbH - DD-WRT
Firmensitz:  Stubenwaldallee 21a, 64625 Bensheim
Registergericht: Amtsgericht Darmstadt, HRB 25473
Geschäftsführer: Peter Steinhäuser, Christian Scheele
http://www.dd-wrt.com
email: s.gottsch...@dd-wrt.com
Tel.: +496251-582650 / Fax: +496251-5826565



[PATCH] rsi: Uninitialized return value in rsi_reset_card()

2018-04-26 Thread Dan Carpenter
If rsi_usb_master_reg_write() fails then "ret" hasn't been initialized.

Fixes: 16d3bb7b2f37 ("rsi: disable fw watchdog timer during reset")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index b065438f51b2..6ce6b754df12 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -687,9 +687,10 @@ static int rsi_reset_card(struct rsi_hw *adapter)
 */
msleep(100);
 
-   if (rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
-RSI_FW_WDT_DISABLE_REQ,
-RSI_COMMON_REG_SIZE) < 0) {
+   ret = rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
+  RSI_FW_WDT_DISABLE_REQ,
+  RSI_COMMON_REG_SIZE);
+   if (ret < 0) {
rsi_dbg(ERR_ZONE, "Disabling firmware watchdog timer failed\n");
goto fail;
}


[PATCH] rsi_91x_mac80211: fix structurally dead code

2018-04-26 Thread Gustavo A. R. Silva
Function rsi_hal_key_config returns before reaching code at line
922 if (status), hence this code is structurally dead.

Fix this by storing the value returned by rsi_hal_load_key
into _status_ for its further evaluation and use.

Addresses-Coverity-ID: 1468409 ("Structurally dead code")
Fixes: 4fd6c4762f37 ("rsi: roaming enhancements")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/rsi/rsi_91x_mac80211.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c 
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 766d874..80e7f4f 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -911,14 +911,14 @@ static int rsi_hal_key_config(struct ieee80211_hw *hw,
}
}
 
-   return rsi_hal_load_key(adapter->priv,
-   key->key,
-   key->keylen,
-   key_type,
-   key->keyidx,
-   key->cipher,
-   sta_id,
-   vif);
+   status = rsi_hal_load_key(adapter->priv,
+ key->key,
+ key->keylen,
+ key_type,
+ key->keyidx,
+ key->cipher,
+ sta_id,
+ vif);
if (status)
return status;
 
-- 
2.7.4



Re: [PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

2018-04-26 Thread Ben Greear



On 04/26/2018 02:43 AM, s.gottsch...@dd-wrt.com wrote:

From: Sebastian Gottschall 

starting with firmware 10.4.3.4.x series QCA changed the handling of the 
channel property band_center_freq1 and band_center_freq2 in vht160 operation 
mode
likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with official qca 
firmwares newer than 3.3
consider that this patch will not work with older firmwares anymore. to avoid 
undefined behaviour this we disable vht160 capability for outdated firmwares


We should be able to use a feature-flag or otherwise determine if the firmware 
needs the old or new
API and make the driver able to handle both.

Thanks,
Ben


---
 drivers/net/wireless/ath/ath10k/mac.c |  7 ---
 drivers/net/wireless/ath/ath10k/wmi.c | 11 ---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..d1239d40ac19 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,13 +4449,6 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.cap |= val;
}

-   /* Currently the firmware seems to be buggy, don't enable 80+80
-* mode until that's resolved.
-*/
-   if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
-   (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) == 0)
-   vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
-
mcs_map = 0;
for (i = 0; i < 8; i++) {
if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..d78b8857a513 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1671,13 +1671,18 @@ void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
flags |= WMI_CHAN_FLAG_HT40_PLUS;
if (arg->chan_radar)
flags |= WMI_CHAN_FLAG_DFS;
-
+   ch->band_center_freq2 = 0;
ch->mhz = __cpu_to_le32(arg->freq);
ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
if (arg->mode == MODE_11AC_VHT80_80)
ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
-   else
-   ch->band_center_freq2 = 0;
+   if (arg->mode == MODE_11AC_VHT160)  {
+   if (arg->freq < arg->band_center_freq1)
+   ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 - 40);
+   else
+   ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 + 40);   
+   ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
+   }
ch->min_power = arg->min_power;
ch->max_power = arg->max_power;
ch->reg_power = arg->max_reg_power;



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


[PATCH] rsi_91x_usb: fix uninitialized variable

2018-04-26 Thread Gustavo A. R. Silva
There is a potential execution path in which variable ret is returned
without being properly initialized previously.

Fix this by storing the value returned by function
rsi_usb_master_reg_write into _ret_.

Addresses-Coverity-ID: 1468407 ("Uninitialized scalar variable")
Fixes: 16d3bb7b2f37 ("rsi: disable fw watchdog timer during reset")
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/net/wireless/rsi/rsi_91x_usb.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c 
b/drivers/net/wireless/rsi/rsi_91x_usb.c
index b065438..6ce6b75 100644
--- a/drivers/net/wireless/rsi/rsi_91x_usb.c
+++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
@@ -687,9 +687,10 @@ static int rsi_reset_card(struct rsi_hw *adapter)
 */
msleep(100);
 
-   if (rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
-RSI_FW_WDT_DISABLE_REQ,
-RSI_COMMON_REG_SIZE) < 0) {
+   ret = rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
+  RSI_FW_WDT_DISABLE_REQ,
+  RSI_COMMON_REG_SIZE);
+   if (ret < 0) {
rsi_dbg(ERR_ZONE, "Disabling firmware watchdog timer failed\n");
goto fail;
}
-- 
2.7.4



pull-request: iwlwifi-next 2018-04-26

2018-04-26 Thread Luca Coelho
Hi Kalle,

This is the second batch of patches intended for v4.18.  Nothing major
here, just the usual continued development, bugfixes, new FW APIs and
some new features.  More details about the contents in the tag
description.

I have sent this out before and kbuildbot reported success.

Please let me know if there are any issues.

Cheers,
Luca.


The following changes since commit 0ddcf3e76ae4d02918e609342a1020b50258fadd:

  Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
(2018-04-26 13:26:37 +0300)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git 
tags/iwlwifi-next-for-kalle-2018-04-26

for you to fetch changes up to d3a6f7fb97fc34a38e40cc56392e701598f99863:

  iwlwifi: mvm: set wakeup filters for wowlan "any" configuration (2018-04-26 
15:18:07 +0300)


Second batch of iwlwifi patches for 4.18

* Some preparations for new hardware;
* A workaround to rescan the bus for the rare situation when older
  devices become irresponsive,
* Hardening of the firmware loading code to avoid issues with
  corrupted files;
* A few clean-ups and bugfixes.


Eliad Peller (2):
  iwlwifi: pcie: allow sending pre-built A-MSDUs
  iwlwifi: mvm: set wakeup filters for wowlan "any" configuration

Golan Ben Ami (2):
  iwlwifi: allow different csr flags for different device families
  iwlwifi: support new csr addresses for hw address

Golan Ben-Ami (1):
  iwlwifi: introduce Image Loader (IML) - new firmware image

Johannes Berg (1):
  iwlwifi: mvm: move skb padding reservation earlier

Luca Coelho (5):
  iwlwifi: cfg: remove unnecessary cfg data in non-dvm devices
  iwlwifi: fw: harden page loading code
  iwlwifi: fw: combine loading of last page block into main copy loop
  iwlwifi: pcie: remove non-responsive device
  iwlwifi: make bitfield a u32 instead of u16

Sara Sharon (1):
  iwlwifi: mvm: remove check for non low latency TIDs

 drivers/net/wireless/intel/iwlwifi/cfg/1000.c|   8 +++---
 drivers/net/wireless/intel/iwlwifi/cfg/2000.c|  13 ++---
 drivers/net/wireless/intel/iwlwifi/cfg/22000.c   |  10 ---
 drivers/net/wireless/intel/iwlwifi/cfg/5000.c|   8 +++---
 drivers/net/wireless/intel/iwlwifi/cfg/6000.c|  19 +-
 drivers/net/wireless/intel/iwlwifi/cfg/7000.c|  12 -
 drivers/net/wireless/intel/iwlwifi/cfg/8000.c|  10 +++
 drivers/net/wireless/intel/iwlwifi/cfg/9000.c|   6 ++---
 drivers/net/wireless/intel/iwlwifi/fw/file.h |   3 +++
 drivers/net/wireless/intel/iwlwifi/fw/img.h  |   6 +
 drivers/net/wireless/intel/iwlwifi/fw/paging.c   |  78 
--
 drivers/net/wireless/intel/iwlwifi/iwl-config.h  |  87 
++---
 drivers/net/wireless/intel/iwlwifi/iwl-csr.h |  28 ++--
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c |  14 ++
 drivers/net/wireless/intel/iwlwifi/iwl-eeprom-read.c |   8 +++---
 drivers/net/wireless/intel/iwlwifi/iwl-modparams.h   |   2 ++
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c   |  14 +++---
 drivers/net/wireless/intel/iwlwifi/iwl-trans.h   |   5 
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c  |  15 +++
 drivers/net/wireless/intel/iwlwifi/mvm/ops.c |   3 +++
 drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c|  20 +++---
 drivers/net/wireless/intel/iwlwifi/mvm/tx.c  |   1 -
 drivers/net/wireless/intel/iwlwifi/mvm/utils.c   |   8 +++---
 drivers/net/wireless/intel/iwlwifi/pcie/internal.h   |   5 
 drivers/net/wireless/intel/iwlwifi/pcie/rx.c |   3 ++-
 drivers/net/wireless/intel/iwlwifi/pcie/trans-gen2.c |  15 +++
 drivers/net/wireless/intel/iwlwifi/pcie/trans.c  | 139 
+++--
 drivers/net/wireless/intel/iwlwifi/pcie/tx.c |  24 +++--
 28 files changed, 400 insertions(+), 164 deletions(-)

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


[PATCH] ath10k: sdio: jump to correct label in error handling path

2018-04-26 Thread Niklas Cassel
Jump to the correct label in error handling path.
At this point of execution create_singlethread_workqueue() has succeeded,
so it should be properly destroyed.

Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory
leak for probe allocations").
However, the bug was originally introduced in commit d96db25d2025
("ath10k: add initial SDIO support").

Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
Signed-off-by: Niklas Cassel 
---
 drivers/net/wireless/ath/ath10k/sdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/sdio.c 
b/drivers/net/wireless/ath/ath10k/sdio.c
index 2d04c54a4153..d612ce8c9cff 100644
--- a/drivers/net/wireless/ath/ath10k/sdio.c
+++ b/drivers/net/wireless/ath/ath10k/sdio.c
@@ -2011,7 +2011,7 @@ static int ath10k_sdio_probe(struct sdio_func *func,
ret = -ENODEV;
ath10k_err(ar, "unsupported device id %u (0x%x)\n",
   dev_id_base, id->device);
-   goto err_core_destroy;
+   goto err_free_wq;
}
 
ar->id.vendor = id->vendor;
-- 
2.14.3



Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2018-04-26 Thread Luciano Coelho
On Thu, 2018-04-26 at 13:33 +0300, Kalle Valo wrote:
> Luciano Coelho  writes:
> 
> > On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the wireless-drivers-next tree got a
> > > conflict in:
> > > 
> > >   drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> > > 
> > > between commit:
> > > 
> > >   77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if
> > > needed")
> > > 
> > > from the wireless-drivers tree and commits:
> > > 
> > >   9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common
> > > files")
> > >   4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c")
> > > 
> > > from the wireless-drivers-next tree.
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary.
> > > This
> > > is now fixed as far as linux-next is concerned, but any non
> > > trivial
> > > conflicts should be mentioned to your upstream maintainer when
> > > your
> > > tree
> > > is submitted for merging.  You may also want to consider
> > > cooperating
> > > with the maintainer of the conflicting tree to minimise any
> > > particularly
> > > complex conflicts.
> > 
> > Thanks for resolving this, Stephen!
> > 
> > I checked your resolution and it's spot on.
> 
> I now merged w-d to w-d-next to fix this, please check:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-driver
> s-next.git/commit/?id=0ddcf3e76ae4d02918e609342a1020b50258fadd
> 
> I was not sure what to do with these includes so I left them in:
> 
> #include "fw/api/commands.h"
> #include "fw/api/cmdhdr.h"
> #include "fw/img.h"

That's fine, these are all in our internal tree too.

Thanks!

--
Cheers,
Luca.



Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2018-04-26 Thread Kalle Valo
Luciano Coelho  writes:

> On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote:
>> Hi all,
>> 
>> Today's linux-next merge of the wireless-drivers-next tree got a
>> conflict in:
>> 
>>   drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
>> 
>> between commit:
>> 
>>   77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if needed")
>> 
>> from the wireless-drivers tree and commits:
>> 
>>   9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common
>> files")
>>   4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c")
>> 
>> from the wireless-drivers-next tree.
>> 
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your
>> tree
>> is submitted for merging.  You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any
>> particularly
>> complex conflicts.
>
> Thanks for resolving this, Stephen!
>
> I checked your resolution and it's spot on.

I now merged w-d to w-d-next to fix this, please check:

https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git/commit/?id=0ddcf3e76ae4d02918e609342a1020b50258fadd

I was not sure what to do with these includes so I left them in:

#include "fw/api/commands.h"
#include "fw/api/cmdhdr.h"
#include "fw/img.h"

-- 
Kalle Valo


[PATCH 0/6] brcmfmac: new pcie fw-api support and cleanup

2018-04-26 Thread Arend van Spriel
This series contains following:
  * support for PCIe rev7 firmware api.
  * include boottime stamp for bss.
  * check user-space provided P2P DEVICE mac address.

The series applies to the master branch of wireless-drivers-next repository.

Arend van Spriel (2):
  brcmfmac: check p2pdev mac address uniqueness
  brcmfmac: constify firmware mapping tables

Franky Lin (4):
  brcmfmac: reports boottime_ns while informing bss
  brcmfmac: use nl80211_band directly to get ieee80211 channel
  brcmfmac: add hostready indication
  brcmfmac: coarse support for PCIe shared structure rev7

 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 34 +--
 .../broadcom/brcm80211/brcmfmac/firmware.c |  2 +-
 .../broadcom/brcm80211/brcmfmac/firmware.h |  2 +-
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h  |  6 ++--
 .../net/wireless/broadcom/brcm80211/brcmfmac/p2p.c |  7 
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c| 39 ++
 .../wireless/broadcom/brcm80211/brcmfmac/sdio.c|  2 +-
 .../net/wireless/broadcom/brcm80211/brcmfmac/usb.c |  2 +-
 8 files changed, 64 insertions(+), 30 deletions(-)

--
1.9.1



[PATCH 2/6] brcmfmac: reports boottime_ns while informing bss

2018-04-26 Thread Arend van Spriel
From: Franky Lin 

Provides a timestamp in bss information so user space can see when the
bss info was updated. Since tsf is not available from the dongle events
boottime is reported instead.

Reported-by: Dmitry Shmidt 
Reviewed-by: Arend van Spriel 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../broadcom/brcm80211/brcmfmac/cfg80211.c | 26 +++---
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 89b8625..5d891cb 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2728,7 +2728,6 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
   struct brcmf_bss_info_le *bi)
 {
struct wiphy *wiphy = cfg_to_wiphy(cfg);
-   struct ieee80211_channel *notify_channel;
struct cfg80211_bss *bss;
struct ieee80211_supported_band *band;
struct brcmu_chan ch;
@@ -2738,7 +2737,7 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
u16 notify_interval;
u8 *notify_ie;
size_t notify_ielen;
-   s32 notify_signal;
+   struct cfg80211_inform_bss bss_data = { 0 };
 
if (le32_to_cpu(bi->length) > WL_BSS_INFO_MAX) {
brcmf_err("Bss info is larger than buffer. Discarding\n");
@@ -2758,27 +2757,28 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
band = wiphy->bands[NL80211_BAND_5GHZ];
 
freq = ieee80211_channel_to_frequency(channel, band->band);
-   notify_channel = ieee80211_get_channel(wiphy, freq);
+   bss_data.chan = ieee80211_get_channel(wiphy, freq);
+   bss_data.scan_width = NL80211_BSS_CHAN_WIDTH_20;
+   bss_data.boottime_ns = ktime_to_ns(ktime_get_boottime());
 
notify_capability = le16_to_cpu(bi->capability);
notify_interval = le16_to_cpu(bi->beacon_period);
notify_ie = (u8 *)bi + le16_to_cpu(bi->ie_offset);
notify_ielen = le32_to_cpu(bi->ie_length);
-   notify_signal = (s16)le16_to_cpu(bi->RSSI) * 100;
+   bss_data.signal = (s16)le16_to_cpu(bi->RSSI) * 100;
 
brcmf_dbg(CONN, "bssid: %pM\n", bi->BSSID);
brcmf_dbg(CONN, "Channel: %d(%d)\n", channel, freq);
brcmf_dbg(CONN, "Capability: %X\n", notify_capability);
brcmf_dbg(CONN, "Beacon interval: %d\n", notify_interval);
-   brcmf_dbg(CONN, "Signal: %d\n", notify_signal);
-
-   bss = cfg80211_inform_bss(wiphy, notify_channel,
- CFG80211_BSS_FTYPE_UNKNOWN,
- (const u8 *)bi->BSSID,
- 0, notify_capability,
- notify_interval, notify_ie,
- notify_ielen, notify_signal,
- GFP_KERNEL);
+   brcmf_dbg(CONN, "Signal: %d\n", bss_data.signal);
+
+   bss = cfg80211_inform_bss_data(wiphy, _data,
+  CFG80211_BSS_FTYPE_UNKNOWN,
+  (const u8 *)bi->BSSID,
+  0, notify_capability,
+  notify_interval, notify_ie,
+  notify_ielen, GFP_KERNEL);
 
if (!bss)
return -ENOMEM;
-- 
1.9.1



[PATCH 4/6] brcmfmac: constify firmware mapping tables

2018-04-26 Thread Arend van Spriel
The information in the firmware mapping does not need to be modified
so it can be static const.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 2 +-
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
index 9277f4c..6e47f14 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.c
@@ -630,7 +630,7 @@ int brcmf_fw_get_firmwares(struct device *dev, struct 
brcmf_fw_request *req,
 
 struct brcmf_fw_request *
 brcmf_fw_alloc_request(u32 chip, u32 chiprev,
-  struct brcmf_firmware_mapping mapping_table[],
+  const struct brcmf_firmware_mapping mapping_table[],
   u32 table_size, struct brcmf_fw_name *fwnames,
   u32 n_fwnames)
 {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
index 79a2109..2893e56 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.h
@@ -80,7 +80,7 @@ struct brcmf_fw_name {
 
 struct brcmf_fw_request *
 brcmf_fw_alloc_request(u32 chip, u32 chiprev,
-  struct brcmf_firmware_mapping mapping_table[],
+  const struct brcmf_firmware_mapping mapping_table[],
   u32 table_size, struct brcmf_fw_name *fwnames,
   u32 n_fwnames);
 
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 6e25ff9..9708647 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -59,7 +59,7 @@ enum brcmf_pcie_state {
 BRCMF_FW_DEF(4366C, "brcmfmac4366c-pcie");
 BRCMF_FW_DEF(4371, "brcmfmac4371-pcie");
 
-static struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
+static const struct brcmf_firmware_mapping brcmf_pcie_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43602_CHIP_ID, 0x, 43602),
BRCMF_FW_ENTRY(BRCM_CC_43465_CHIP_ID, 0xFFF0, 4366C),
BRCMF_FW_ENTRY(BRCM_CC_4350_CHIP_ID, 0x00FF, 4350C),
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 1037df7..412a05b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -619,7 +619,7 @@ struct sdiod_drive_str {
 BRCMF_FW_DEF(4356, "brcmfmac4356-sdio");
 BRCMF_FW_DEF(4373, "brcmfmac4373-sdio");
 
-static struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
+static const struct brcmf_firmware_mapping brcmf_sdio_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0x, 43143),
BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x001F, 43241B0),
BRCMF_FW_ENTRY(BRCM_CC_43241_CHIP_ID, 0x0020, 43241B4),
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
index a0873ad..a4308c6 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/usb.c
@@ -52,7 +52,7 @@
 BRCMF_FW_DEF(43569, "brcmfmac43569");
 BRCMF_FW_DEF(4373, "brcmfmac4373");
 
-static struct brcmf_firmware_mapping brcmf_usb_fwnames[] = {
+static const struct brcmf_firmware_mapping brcmf_usb_fwnames[] = {
BRCMF_FW_ENTRY(BRCM_CC_43143_CHIP_ID, 0x, 43143),
BRCMF_FW_ENTRY(BRCM_CC_43235_CHIP_ID, 0x0008, 43236B),
BRCMF_FW_ENTRY(BRCM_CC_43236_CHIP_ID, 0x0008, 43236B),
-- 
1.9.1



[PATCH 1/6] brcmfmac: check p2pdev mac address uniqueness

2018-04-26 Thread Arend van Spriel
The mac address for p2pdev must be different from the primary interface
due to firmware requirement. Add an explicit check for this requirement
if user-space provides a mac address.

Reviewed-by: Hante Meuleman 
Reviewed-by: Pieter-Paul Giesberts 
Reviewed-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
index bcef208..4b2149b 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/p2p.c
@@ -2073,6 +2073,13 @@ static struct wireless_dev 
*brcmf_p2p_create_p2pdev(struct brcmf_p2p_info *p2p,
}
 
pri_ifp = p2p->bss_idx[P2PAPI_BSSCFG_PRIMARY].vif->ifp;
+
+   /* firmware requires unique mac address for p2pdev interface */
+   if (addr && ether_addr_equal(addr, pri_ifp->mac_addr)) {
+   brcmf_err("discovery vif must be different from primary 
interface\n");
+   return ERR_PTR(-EINVAL);
+   }
+
brcmf_p2p_generate_bss_mac(p2p, addr);
brcmf_p2p_set_firmware(pri_ifp, p2p->dev_addr);
 
-- 
1.9.1



[PATCH 3/6] brcmfmac: use nl80211_band directly to get ieee80211 channel

2018-04-26 Thread Arend van Spriel
From: Franky Lin 

The enum nl80211_band used to retrieve wiphy->bands is the same as
wiphy->bands->band which is checked by wiphy_register(). So it can be used
directly as parameter of ieee80211_channel_to_frequency().

Reviewed-by: Arend van Spriel 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
index 5d891cb..ff6b351 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
@@ -2729,7 +2729,7 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
 {
struct wiphy *wiphy = cfg_to_wiphy(cfg);
struct cfg80211_bss *bss;
-   struct ieee80211_supported_band *band;
+   enum nl80211_band band;
struct brcmu_chan ch;
u16 channel;
u32 freq;
@@ -2752,11 +2752,11 @@ static s32 brcmf_inform_single_bss(struct 
brcmf_cfg80211_info *cfg,
channel = bi->ctl_ch;
 
if (channel <= CH_MAX_2G_CHANNEL)
-   band = wiphy->bands[NL80211_BAND_2GHZ];
+   band = NL80211_BAND_2GHZ;
else
-   band = wiphy->bands[NL80211_BAND_5GHZ];
+   band = NL80211_BAND_5GHZ;
 
-   freq = ieee80211_channel_to_frequency(channel, band->band);
+   freq = ieee80211_channel_to_frequency(channel, band);
bss_data.chan = ieee80211_get_channel(wiphy, freq);
bss_data.scan_width = NL80211_BSS_CHAN_WIDTH_20;
bss_data.boottime_ns = ktime_to_ns(ktime_get_boottime());
-- 
1.9.1



[PATCH 6/6] brcmfmac: coarse support for PCIe shared structure rev7

2018-04-26 Thread Arend van Spriel
From: Franky Lin 

Revision 7 of PCIe dongle interface increases the item size of tx and rx
complete rings to accommodate extra payload for new feature. This patch
simply bump up the size of these two rings without adding the support
for utilizing the new space. This makes brcmfmac compatible with rev7
firmware.

Reviewed-by: Arend van Spriel 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 .../wireless/broadcom/brcm80211/brcmfmac/msgbuf.h  |  6 --
 .../wireless/broadcom/brcm80211/brcmfmac/pcie.c| 23 ++
 2 files changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
index f93ba6b..692235d 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/msgbuf.h
@@ -27,8 +27,10 @@
 #define BRCMF_H2D_MSGRING_CONTROL_SUBMIT_ITEMSIZE  40
 #define BRCMF_H2D_MSGRING_RXPOST_SUBMIT_ITEMSIZE   32
 #define BRCMF_D2H_MSGRING_CONTROL_COMPLETE_ITEMSIZE24
-#define BRCMF_D2H_MSGRING_TX_COMPLETE_ITEMSIZE 16
-#define BRCMF_D2H_MSGRING_RX_COMPLETE_ITEMSIZE 32
+#define BRCMF_D2H_MSGRING_TX_COMPLETE_ITEMSIZE_PRE_V7  16
+#define BRCMF_D2H_MSGRING_TX_COMPLETE_ITEMSIZE 24
+#define BRCMF_D2H_MSGRING_RX_COMPLETE_ITEMSIZE_PRE_V7  32
+#define BRCMF_D2H_MSGRING_RX_COMPLETE_ITEMSIZE 40
 #define BRCMF_H2D_TXFLOWRING_ITEMSIZE  48
 
 struct msgbuf_buf_addr {
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 71b69af..f0797ae 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -136,8 +136,9 @@ enum brcmf_pcie_state {
 BRCMF_PCIE_MB_INT_D2H3_DB0 | \
 BRCMF_PCIE_MB_INT_D2H3_DB1)
 
+#define BRCMF_PCIE_SHARED_VERSION_77
 #define BRCMF_PCIE_MIN_SHARED_VERSION  5
-#define BRCMF_PCIE_MAX_SHARED_VERSION  6
+#define BRCMF_PCIE_MAX_SHARED_VERSION  BRCMF_PCIE_SHARED_VERSION_7
 #define BRCMF_PCIE_SHARED_VERSION_MASK 0x00FF
 #define BRCMF_PCIE_SHARED_DMA_INDEX0x1
 #define BRCMF_PCIE_SHARED_DMA_2B_IDX   0x10
@@ -318,6 +319,14 @@ struct brcmf_pcie_dhi_ringinfo {
BRCMF_D2H_MSGRING_RX_COMPLETE_MAX_ITEM
 };
 
+static const u32 brcmf_ring_itemsize_pre_v7[BRCMF_NROF_COMMON_MSGRINGS] = {
+   BRCMF_H2D_MSGRING_CONTROL_SUBMIT_ITEMSIZE,
+   BRCMF_H2D_MSGRING_RXPOST_SUBMIT_ITEMSIZE,
+   BRCMF_D2H_MSGRING_CONTROL_COMPLETE_ITEMSIZE,
+   BRCMF_D2H_MSGRING_TX_COMPLETE_ITEMSIZE_PRE_V7,
+   BRCMF_D2H_MSGRING_RX_COMPLETE_ITEMSIZE_PRE_V7
+};
+
 static const u32 brcmf_ring_itemsize[BRCMF_NROF_COMMON_MSGRINGS] = {
BRCMF_H2D_MSGRING_CONTROL_SUBMIT_ITEMSIZE,
BRCMF_H2D_MSGRING_RXPOST_SUBMIT_ITEMSIZE,
@@ -1007,8 +1016,14 @@ static int brcmf_pcie_ring_mb_update_wptr(void *ctx)
struct brcmf_pcie_ringbuf *ring;
u32 size;
u32 addr;
+   const u32 *ring_itemsize_array;
+
+   if (devinfo->shared.version < BRCMF_PCIE_SHARED_VERSION_7)
+   ring_itemsize_array = brcmf_ring_itemsize_pre_v7;
+   else
+   ring_itemsize_array = brcmf_ring_itemsize;
 
-   size = brcmf_ring_max_item[ring_id] * brcmf_ring_itemsize[ring_id];
+   size = brcmf_ring_max_item[ring_id] * ring_itemsize_array[ring_id];
dma_buf = brcmf_pcie_init_dmabuffer_for_device(devinfo, size,
tcm_ring_phys_addr + BRCMF_RING_MEM_BASE_ADDR_OFFSET,
_handle);
@@ -1018,7 +1033,7 @@ static int brcmf_pcie_ring_mb_update_wptr(void *ctx)
addr = tcm_ring_phys_addr + BRCMF_RING_MAX_ITEM_OFFSET;
brcmf_pcie_write_tcm16(devinfo, addr, brcmf_ring_max_item[ring_id]);
addr = tcm_ring_phys_addr + BRCMF_RING_LEN_ITEMS_OFFSET;
-   brcmf_pcie_write_tcm16(devinfo, addr, brcmf_ring_itemsize[ring_id]);
+   brcmf_pcie_write_tcm16(devinfo, addr, ring_itemsize_array[ring_id]);
 
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
if (!ring) {
@@ -1027,7 +1042,7 @@ static int brcmf_pcie_ring_mb_update_wptr(void *ctx)
return NULL;
}
brcmf_commonring_config(>commonring, brcmf_ring_max_item[ring_id],
-   brcmf_ring_itemsize[ring_id], dma_buf);
+   ring_itemsize_array[ring_id], dma_buf);
ring->dma_handle = dma_handle;
ring->devinfo = devinfo;
brcmf_commonring_register_cb(>commonring,
-- 
1.9.1



[PATCH 5/6] brcmfmac: add hostready indication

2018-04-26 Thread Arend van Spriel
From: Franky Lin 

A hostready signal is introduced to inform firmware through mailbox
doorbell1 when common ring initialized or D3 exited.

Reviewed-by: Arend van Spriel 
Signed-off-by: Franky Lin 
Signed-off-by: Arend van Spriel 
---
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c 
b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
index 9708647..71b69af 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c
@@ -105,7 +105,8 @@ enum brcmf_pcie_state {
 #define BRCMF_PCIE_PCIE2REG_MAILBOXMASK0x4C
 #define BRCMF_PCIE_PCIE2REG_CONFIGADDR 0x120
 #define BRCMF_PCIE_PCIE2REG_CONFIGDATA 0x124
-#define BRCMF_PCIE_PCIE2REG_H2D_MAILBOX0x140
+#define BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_0  0x140
+#define BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_1  0x144
 
 #define BRCMF_PCIE2_INTA   0x01
 #define BRCMF_PCIE2_INTB   0x02
@@ -140,6 +141,7 @@ enum brcmf_pcie_state {
 #define BRCMF_PCIE_SHARED_VERSION_MASK 0x00FF
 #define BRCMF_PCIE_SHARED_DMA_INDEX0x1
 #define BRCMF_PCIE_SHARED_DMA_2B_IDX   0x10
+#define BRCMF_PCIE_SHARED_HOSTRDY_DB1  0x1000
 
 #define BRCMF_PCIE_FLAGS_HTOD_SPLIT0x4000
 #define BRCMF_PCIE_FLAGS_DTOH_SPLIT0x8000
@@ -782,6 +784,12 @@ static void brcmf_pcie_intr_enable(struct 
brcmf_pciedev_info *devinfo)
   BRCMF_PCIE_MB_INT_FN0_1);
 }
 
+static void brcmf_pcie_hostready(struct brcmf_pciedev_info *devinfo)
+{
+   if (devinfo->shared.flags & BRCMF_PCIE_SHARED_HOSTRDY_DB1)
+   brcmf_pcie_write_reg32(devinfo,
+  BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_1, 1);
+}
 
 static irqreturn_t brcmf_pcie_quick_check_isr(int irq, void *arg)
 {
@@ -924,7 +932,7 @@ static int brcmf_pcie_ring_mb_ring_bell(void *ctx)
 
brcmf_dbg(PCIE, "RING !\n");
/* Any arbitrary value will do, lets use 1 */
-   brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_H2D_MAILBOX, 1);
+   brcmf_pcie_write_reg32(devinfo, BRCMF_PCIE_PCIE2REG_H2D_MAILBOX_0, 1);
 
return 0;
 }
@@ -1728,6 +1736,7 @@ static void brcmf_pcie_setup(struct device *dev, int ret,
init_waitqueue_head(>mbdata_resp_wait);
 
brcmf_pcie_intr_enable(devinfo);
+   brcmf_pcie_hostready(devinfo);
if (brcmf_attach(>pdev->dev, devinfo->settings) == 0)
return;
 
@@ -1950,6 +1959,7 @@ static int brcmf_pcie_pm_leave_D3(struct device *dev)
brcmf_pcie_select_core(devinfo, BCMA_CORE_PCIE2);
brcmf_bus_change_state(bus, BRCMF_BUS_UP);
brcmf_pcie_intr_enable(devinfo);
+   brcmf_pcie_hostready(devinfo);
return 0;
}
 
-- 
1.9.1



RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

2018-04-26 Thread Reizer, Eyal
> 
> >>
> >> > pm_runtime handles sdio power on and power off transitions.
> >> > An old workaround for trying to control the power explicitly from the
> >> > driver was in fact causing failures on suspend/resume as the mmc layer
> >> > already power the module on resume.
> >> >
> >> > In case of resume pm_runtime_get sync returns a positive device's
> usage
> >> > count causing the driver to try an re-initialize an already initialized
> >> > device. This was causing sdio bus failure on resume.
> >> >
> >> > Remove this manual power on/off sequence as it is in-fact not needed.
> >> >
> >> > Signed-off-by: Eyal Reizer 
> >> > Acked-by: Tony Lindgren 
> >>
> >> No changelog.
> >>
> >>
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> >> atches#changelog_missing
> >>
> >> No need to resubmit because of this, I guess you just fixed the title
> >> and added Tony's Acked-by?
> >
> > Yes, this is correct. No change in the actual patch hence there was no
> change
> > Log.
> 
> _Always_ include a change log, even if you didn't actually change
> anything. Otherwise the maintainer has no clue what has changed and why
> a new version was submitted.
> 
Understood. Thanks!

BR,
Eyal


pull-request: wireless-drivers 2018-04-26

2018-04-26 Thread Kalle Valo
Hi Dave,

here's a pull request to net tree, more info below. Please let me know
if you have any problems.

Kalle

The following changes since commit 4608f064532c28c0ea3c03fe26a3a5909852811a:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next 
(2018-04-03 14:08:58 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git 
tags/wireless-drivers-for-davem-2018-04-26

for you to fetch changes up to af8a41cccf8f469165c6debc8fe07c5fd2ca501a:

  rtlwifi: cleanup 8723be ant_sel definition (2018-04-24 13:15:08 +0300)


wireless-drivers fixes for 4.17

A few fixes for 4.17 but nothing really special. The new ETSI WMM
parameter support for iwlwifi is not technically a bugfix but
important for regulatory compliance.

iwlwifi

* use new ETSI WMM parameters from regulatory database

* fix a regression with the older firmware API 31 (eg. 31.560484.0)

brcmfmac

* fix a double free in nvmam loading fails

rtlwifi

* yet another fix for ant_sel module parameter


Arend Van Spriel (1):
  brcmfmac: fix firmware request processing if nvram load fails

Haim Dreyfuss (1):
  iwlwifi: mvm: query regdb for wmm rule if needed

Luca Coelho (1):
  iwlwifi: mvm: fix old scan version sizes

Ping-Ke Shih (1):
  rtlwifi: cleanup 8723be ant_sel definition

 .../broadcom/brcm80211/brcmfmac/firmware.c |  36 ---
 drivers/net/wireless/intel/iwlwifi/fw/api/scan.h   |  13 +--
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 111 ++---
 drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.h |   6 +-
 drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c  |   3 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   |  15 ---
 .../net/wireless/realtek/rtlwifi/rtl8723be/hw.c|  11 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h|   5 +
 8 files changed, 138 insertions(+), 62 deletions(-)


[PATCH v1] ath10k: fix band_center_freq handling for VHT160 in recent firmwares

2018-04-26 Thread s . gottschall
From: Sebastian Gottschall 

starting with firmware 10.4.3.4.x series QCA changed the handling of the 
channel property band_center_freq1 and band_center_freq2 in vht160 operation 
mode
likelly for backward compatiblity with vht80 only capable clients.
this patch adjusts the handling to get vht160 to work again with official qca 
firmwares newer than 3.3
consider that this patch will not work with older firmwares anymore. to avoid 
undefined behaviour this we disable vht160 capability for outdated firmwares
---
 drivers/net/wireless/ath/ath10k/mac.c |  7 ---
 drivers/net/wireless/ath/ath10k/wmi.c | 11 ---
 2 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..d1239d40ac19 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -4449,13 +4449,6 @@ static struct ieee80211_sta_vht_cap 
ath10k_create_vht_cap(struct ath10k *ar)
vht_cap.cap |= val;
}
 
-   /* Currently the firmware seems to be buggy, don't enable 80+80
-* mode until that's resolved.
-*/
-   if ((ar->vht_cap_info & IEEE80211_VHT_CAP_SHORT_GI_160) &&
-   (ar->vht_cap_info & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK) == 0)
-   vht_cap.cap |= IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_160MHZ;
-
mcs_map = 0;
for (i = 0; i < 8; i++) {
if ((i < ar->num_rf_chains) && (ar->cfg_tx_chainmask & BIT(i)))
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..d78b8857a513 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -1671,13 +1671,18 @@ void ath10k_wmi_put_wmi_channel(struct wmi_channel *ch,
flags |= WMI_CHAN_FLAG_HT40_PLUS;
if (arg->chan_radar)
flags |= WMI_CHAN_FLAG_DFS;
-
+   ch->band_center_freq2 = 0;
ch->mhz = __cpu_to_le32(arg->freq);
ch->band_center_freq1 = __cpu_to_le32(arg->band_center_freq1);
if (arg->mode == MODE_11AC_VHT80_80)
ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq2);
-   else
-   ch->band_center_freq2 = 0;
+   if (arg->mode == MODE_11AC_VHT160)  {
+   if (arg->freq < arg->band_center_freq1)
+   ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 - 40);
+   else
+   ch->band_center_freq1 = 
__cpu_to_le32(arg->band_center_freq1 + 40); 
+   ch->band_center_freq2 = __cpu_to_le32(arg->band_center_freq1);
+   }
ch->min_power = arg->min_power;
ch->max_power = arg->max_power;
ch->reg_power = arg->max_reg_power;
-- 
2.14.1



[PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread s . gottschall
From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 

v2: remove debug messages
---
 drivers/net/wireless/ath/ath10k/mac.c | 36 +++
 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
 3 files changed, 34 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
 
-   if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+   }
 
/* Calculate peer NSS capability from VHT capabilities if STA
 * supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
 
-   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
-  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+   if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+   arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+   }
 
-   if (arg->peer_vht_rates.rx_max_rate &&
-   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-   switch (arg->peer_vht_rates.rx_max_rate) {
-   case 1560:
-   /* Must be 2x2 at 160Mhz is all it can do. */
-   arg->peer_bw_rxnss_override = 2;
-   break;
-   case 780:
-   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-   arg->peer_bw_rxnss_override = 1;
-   break;
-   }
+   if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+   arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);
}
+
+   /* In very exceptional  conditions it is observed  that
+* firmware was receiving bw_rxnss_override as 0 for peer from host, 
and resulting in Target Assert.
+* Changing the rxnss_override to minimum nss. This is a temporary WAR. 
Needs to be fixed
+* properly.
+*/
+   if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
+  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
 }
 
 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2700,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..7d72fdc703c8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7212,9 +7212,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void 
*buf,
 
ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
if (arg->peer_bw_rxnss_override)
-   cmd->peer_bw_rxnss_override =
-   __cpu_to_le32((arg->peer_bw_rxnss_override - 1) |
- BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
+   cmd->peer_bw_rxnss_override = 

Re: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

2018-04-26 Thread Kalle Valo
"Reizer, Eyal"  writes:

>> 
>> > pm_runtime handles sdio power on and power off transitions.
>> > An old workaround for trying to control the power explicitly from the
>> > driver was in fact causing failures on suspend/resume as the mmc layer
>> > already power the module on resume.
>> >
>> > In case of resume pm_runtime_get sync returns a positive device's usage
>> > count causing the driver to try an re-initialize an already initialized
>> > device. This was causing sdio bus failure on resume.
>> >
>> > Remove this manual power on/off sequence as it is in-fact not needed.
>> >
>> > Signed-off-by: Eyal Reizer 
>> > Acked-by: Tony Lindgren 
>> 
>> No changelog.
>> 
>> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
>> atches#changelog_missing
>> 
>> No need to resubmit because of this, I guess you just fixed the title
>> and added Tony's Acked-by?
>
> Yes, this is correct. No change in the actual patch hence there was no change 
> Log.

_Always_ include a change log, even if you didn't actually change
anything. Otherwise the maintainer has no clue what has changed and why
a new version was submitted.

-- 
Kalle Valo


[PATCH v1] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread s . gottschall
From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 
---
 drivers/net/wireless/ath/ath10k/mac.c | 39 +--
 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 -
 3 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..758e1d77eed4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
 
-   if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+   }
 
/* Calculate peer NSS capability from VHT capabilities if STA
 * supports VHT.
@@ -2529,22 +2530,28 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
 
-   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
-  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+   if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+   arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+   printk(KERN_INFO "vht160, set rxnss to %X from peer %X\n", 
arg->peer_bw_rxnss_override, arg->peer_num_spatial_streams );
+   }
 
-   if (arg->peer_vht_rates.rx_max_rate &&
-   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-   switch (arg->peer_vht_rates.rx_max_rate) {
-   case 1560:
-   /* Must be 2x2 at 160Mhz is all it can do. */
-   arg->peer_bw_rxnss_override = 2;
-   break;
-   case 780:
-   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-   arg->peer_bw_rxnss_override = 1;
-   break;
-   }
+   if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+   arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);
+   printk(KERN_INFO "vht8080, set rxnss to %X from peer %X\n", 
arg->peer_bw_rxnss_override, arg->peer_num_spatial_streams );
}
+
+   /* In very exceptional  conditions it is observed  that
+* firmware was receiving bw_rxnss_override as 0 for peer from host, 
and resulting in Target Assert.
+* Changing the rxnss_override to minimum nss. This is a temporary WAR. 
Needs to be fixed
+* properly.
+*/
+   if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+   printk(KERN_INFO "vht8080, set rxnss to WAR %X\n", 
arg->peer_bw_rxnss_override);
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
+  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
 }
 
 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2703,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..7d72fdc703c8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7212,9 +7212,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void 

[PATCH][next] ath10k: fix spelling mistake: "servive" -> "service"

2018-04-26 Thread Colin King
From: Colin Ian King 

Trivial fix to spelling mistake in ath10k_warn warning message text

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/ath/ath10k/wmi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index df2e92a6c9bd..622e026ae940 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -5280,7 +5280,7 @@ void ath10k_wmi_event_service_available(struct ath10k 
*ar, struct sk_buff *skb)
 
ret = ath10k_wmi_pull_svc_avail(ar, skb, );
if (ret) {
-   ath10k_warn(ar, "failed to parse servive available event: %d\n",
+   ath10k_warn(ar, "failed to parse service available event: %d\n",
ret);
}
 
-- 
2.17.0



[PATCH v1] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter

2018-04-26 Thread s . gottschall
From: Sebastian Gottschall 

current handling of peer_bw_rxnss_override parameter is based on guessing the 
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since 
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct 
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by 
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.

Signed-off-by: Sebastian Gottschall 
---
 drivers/net/wireless/ath/ath10k/mac.c | 39 +--
 drivers/net/wireless/ath/ath10k/wmi.c |  4 +---
 drivers/net/wireless/ath/ath10k/wmi.h | 14 -
 3 files changed, 37 insertions(+), 20 deletions(-)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..758e1d77eed4 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
 
-   if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+   if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+   }
 
/* Calculate peer NSS capability from VHT capabilities if STA
 * supports VHT.
@@ -2529,22 +2530,28 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
 
-   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
-  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+   if (arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+   arg->peer_bw_rxnss_override = 
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+   printk(KERN_INFO "vht160, set rxnss to %X from peer %X\n", 
arg->peer_bw_rxnss_override, arg->peer_num_spatial_streams );
+   }
 
-   if (arg->peer_vht_rates.rx_max_rate &&
-   (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
-   switch (arg->peer_vht_rates.rx_max_rate) {
-   case 1560:
-   /* Must be 2x2 at 160Mhz is all it can do. */
-   arg->peer_bw_rxnss_override = 2;
-   break;
-   case 780:
-   /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
-   arg->peer_bw_rxnss_override = 1;
-   break;
-   }
+   if (arg->peer_num_spatial_streams && arg->peer_phymode == 
MODE_11AC_VHT80_80) {
+   arg->peer_bw_rxnss_override |= 
BW_NSS_FWCONF_80_80(arg->peer_num_spatial_streams);
+   printk(KERN_INFO "vht8080, set rxnss to %X from peer %X\n", 
arg->peer_bw_rxnss_override, arg->peer_num_spatial_streams );
}
+
+   /* In very exceptional  conditions it is observed  that
+* firmware was receiving bw_rxnss_override as 0 for peer from host, 
and resulting in Target Assert.
+* Changing the rxnss_override to minimum nss. This is a temporary WAR. 
Needs to be fixed
+* properly.
+*/
+   if (!arg->peer_num_spatial_streams && (arg->peer_phymode == 
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+   arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
+   printk(KERN_INFO "vht8080, set rxnss to WAR %X\n", 
arg->peer_bw_rxnss_override);
+   }
+
+   ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 
0x%x\n",
+  sta->addr, arg->peer_max_mpdu, arg->peer_flags);
 }
 
 static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2703,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
-   ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
 
return 0;
 }
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c 
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..7d72fdc703c8 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7212,9 +7212,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void 

Re: [PATCH v2 01/21] staging: wilc1000: replace crc7_byte() with inline macro CRC7_BYTE

2018-04-26 Thread Ajay Singh
Hi Greg,

On Thu, 26 Apr 2018 09:40:20 +0200
Greg KH  wrote:

> On Wed, Apr 25, 2018 at 10:48:06PM +0530, Ajay Singh wrote:
> > Replace the function call for crc7_byte() with macro CRC7_BYTE.
> > crc7_byte() was called in close while(), so replaced it with
> > macro to avoid extra functional call depth.
> > 
> > Signed-off-by: Ajay Singh 
> > ---
> >  drivers/staging/wilc1000/wilc_spi.c | 7 ++-
> >  1 file changed, 2 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/staging/wilc1000/wilc_spi.c
> > b/drivers/staging/wilc1000/wilc_spi.c index 2cb9f4e..3bb8fec
> > 100644 --- a/drivers/staging/wilc1000/wilc_spi.c
> > +++ b/drivers/staging/wilc1000/wilc_spi.c
> > @@ -75,15 +75,12 @@ static const u8 crc7_syndrome_table[256] = {
> > 0x46, 0x4f, 0x54, 0x5d, 0x62, 0x6b, 0x70, 0x79
> >  };
> >  
> > -static u8 crc7_byte(u8 crc, u8 data)
> > -{
> > -   return crc7_syndrome_table[(crc << 1) ^ data];
> > -}
> > +#define CRC7_BYTE(crc, data) crc7_syndrome_table[(crc << 1) ^
> > data]  
> 
> Ick, no.  That's not needed at all, a function is always much
> better.
> 
> And a good compiler will just inline this, are you _sure_ you are
> actually changing anything here?

As you mentioned, we can leave as it is for good compiler to
handle.

> 
> But most importantly, why not just use the build-in crc7
> functionality that the kernel already provides?  Don't have a
> duplicate version here.
> 
> That would be a much better cleanup, right?
> 

Thank you for your suggestion.

Yes, I agree its better to use the existing crc7 functionality.

It seems the same crc7() functions was available in kernel version
before v3.16-rc1 (in /lib/crc7.c) but later it got changed to
crc7_be() with a different crc lookup table. So i think it can not be
changed directly now.

I will check more on this and see how can we can make use of
modified version of crc7, by also considering the receiver end
changes.

> thanks,
> 
> greg k-h



Regards,
Ajay



RE: [EXTERNAL] Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

2018-04-26 Thread Reizer, Eyal
> 
> > pm_runtime handles sdio power on and power off transitions.
> > An old workaround for trying to control the power explicitly from the
> > driver was in fact causing failures on suspend/resume as the mmc layer
> > already power the module on resume.
> >
> > In case of resume pm_runtime_get sync returns a positive device's usage
> > count causing the driver to try an re-initialize an already initialized
> > device. This was causing sdio bus failure on resume.
> >
> > Remove this manual power on/off sequence as it is in-fact not needed.
> >
> > Signed-off-by: Eyal Reizer 
> > Acked-by: Tony Lindgren 
> 
> No changelog.
> 
> https://wireless.wiki.kernel.org/en/developers/documentation/submittingp
> atches#changelog_missing
> 
> No need to resubmit because of this, I guess you just fixed the title
> and added Tony's Acked-by?

Yes, this is correct. No change in the actual patch hence there was no change 
Log.

Best Regards,
Eyal


Re: [PATCH v2] wlcore: sdio: allow pm to handle sdio power

2018-04-26 Thread Kalle Valo
Eyal Reizer  writes:

> pm_runtime handles sdio power on and power off transitions.
> An old workaround for trying to control the power explicitly from the
> driver was in fact causing failures on suspend/resume as the mmc layer
> already power the module on resume.
>
> In case of resume pm_runtime_get sync returns a positive device's usage
> count causing the driver to try an re-initialize an already initialized
> device. This was causing sdio bus failure on resume.
>
> Remove this manual power on/off sequence as it is in-fact not needed.
>
> Signed-off-by: Eyal Reizer 
> Acked-by: Tony Lindgren 

No changelog. 

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

No need to resubmit because of this, I guess you just fixed the title
and added Tony's Acked-by?

-- 
Kalle Valo


Re: [PATCH] net: rfkill: gpio: fix memory leak in probe error path

2018-04-26 Thread Heikki Krogerus
On Thu, Apr 26, 2018 at 09:31:52AM +0200, Johan Hovold wrote:
> Make sure to free the rfkill device in case registration fails during
> probe.
> 
> Fixes: 5e7ca3937fbe ("net: rfkill: gpio: convert to resource managed 
> allocation")
> Cc: stable    # 3.13
> Cc: Heikki Krogerus 

Good catch. FWIW:

Reviewed-by: Heikki Krogerus 

> Signed-off-by: Johan Hovold 
> ---
>  net/rfkill/rfkill-gpio.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
> index 41bd496531d4..00192a996be0 100644
> --- a/net/rfkill/rfkill-gpio.c
> +++ b/net/rfkill/rfkill-gpio.c
> @@ -137,13 +137,18 @@ static int rfkill_gpio_probe(struct platform_device 
> *pdev)
>  
>   ret = rfkill_register(rfkill->rfkill_dev);
>   if (ret < 0)
> - return ret;
> + goto err_destroy;
>  
>   platform_set_drvdata(pdev, rfkill);
>  
>   dev_info(>dev, "%s device registered.\n", rfkill->name);
>  
>   return 0;
> +
> +err_destroy:
> + rfkill_destroy(rfkill->rfkill_dev);
> +
> + return ret;
>  }
>  
>  static int rfkill_gpio_remove(struct platform_device *pdev)
> -- 
> 2.17.0

-- 
heikki


Re: [PATCH v2 12/12] iwlwifi: pcie: remove non-responsive device

2018-04-26 Thread Luciano Coelho
Ooops, I obviously meant "PATCH v2 09/12" in the subject.

--
Luca.


On Thu, 2018-04-26 at 10:53 +0300, Luca Coelho wrote:
> From: Luca Coelho 
> 
> If we fail to to grab NIC access because the device is not responding
> (i.e. CSR_GP_CNTRL returns 0x), remove the device from the
> PCI
> bus, to avoid any further damage, and to let the user space rescan.
> 
> In order to inform the userspace that a rescan is needed, we send a
> kobject uevent with "INACCESSIBLE".
> 
> This functionality is disabled by default, but can be enabled via a
> new module parameter called "remove_when_gone".  In the future we may
> change this module parameter to include 3 modes instead: do nothing;
> auto-rescan or; send uevent.
> 
> Signed-off-by: Luca Coelho 
> Signed-off-by: Rajat Jain 
> ---
>  drivers/net/wireless/intel/iwlwifi/iwl-drv.c  |  6 ++
>  .../wireless/intel/iwlwifi/iwl-modparams.h|  2 +
>  .../wireless/intel/iwlwifi/pcie/internal.h|  5 ++
>  .../net/wireless/intel/iwlwifi/pcie/trans.c   | 74
> ++-
>  4 files changed, 84 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> index 4f451a6f20b9..c59ce4f8a5ed 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
> @@ -1850,3 +1850,9 @@ MODULE_PARM_DESC(d0i3_timeout, "Timeout to D0i3
> entry when idle (ms)");
>  
>  module_param_named(disable_11ac, iwlwifi_mod_params.disable_11ac,
> bool, 0444);
>  MODULE_PARM_DESC(disable_11ac, "Disable VHT capabilities (default:
> false)");
> +
> +module_param_named(remove_when_gone,
> +iwlwifi_mod_params.remove_when_gone, bool,
> +0444);
> +MODULE_PARM_DESC(remove_when_gone,
> +  "Remove dev from PCIe bus if it is deemed
> inaccessible (default: false)");
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
> b/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
> index a41c46e63eb1..a7dd8a8cddf9 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
> @@ -122,6 +122,7 @@ enum iwl_uapsd_disable {
>   * @lar_disable: disable LAR (regulatory), default = 0
>   * @fw_monitor: allow to use firmware monitor
>   * @disable_11ac: disable VHT capabilities, default = false.
> + * @remove_when_gone: remove an inaccessible device from the PCIe
> bus.
>   */
>  struct iwl_mod_params {
>   int swcrypto;
> @@ -143,6 +144,7 @@ struct iwl_mod_params {
>   bool lar_disable;
>   bool fw_monitor;
>   bool disable_11ac;
> + bool remove_when_gone;
>  };
>  
>  #endif /* #__iwl_modparams_h__ */
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> index cda66340d357..45ea32796cda 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
> @@ -383,6 +383,8 @@ struct iwl_self_init_dram {
>   * @hw_init_mask: initial unmasked hw causes
>   * @fh_mask: current unmasked fh causes
>   * @hw_mask: current unmasked hw causes
> + * @in_rescan: true if we have triggered a device rescan
> + * @scheduled_for_removal: true if we have scheduled a device
> removal
>   */
>  struct iwl_trans_pcie {
>   struct iwl_rxq *rxq;
> @@ -464,6 +466,9 @@ struct iwl_trans_pcie {
>   u32 fh_mask;
>   u32 hw_mask;
>   cpumask_t affinity_mask[IWL_MAX_RX_HW_QUEUES];
> + u16 tx_cmd_queue_size;
> + bool in_rescan;
> + bool scheduled_for_removal;
>  };
>  
>  static inline struct iwl_trans_pcie *
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> index 623476603cd4..6e9a9ecfb11c 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
> @@ -75,6 +75,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "iwl-drv.h"
>  #include "iwl-trans.h"
> @@ -1935,6 +1936,29 @@ static void iwl_trans_pcie_set_pmi(struct
> iwl_trans *trans, bool state)
>   clear_bit(STATUS_TPOWER_PMI, >status);
>  }
>  
> +struct iwl_trans_pcie_removal {
> + struct pci_dev *pdev;
> + struct work_struct work;
> +};
> +
> +static void iwl_trans_pcie_removal_wk(struct work_struct *wk)
> +{
> + struct iwl_trans_pcie_removal *removal =
> + container_of(wk, struct iwl_trans_pcie_removal,
> work);
> + struct pci_dev *pdev = removal->pdev;
> + char *prop[] = {"EVENT=INACCESSIBLE", NULL};
> +
> + dev_err(>dev, "Device gone - attempting removal\n");
> + kobject_uevent_env(>dev.kobj, KOBJ_CHANGE, prop);
> + pci_lock_rescan_remove();
> + pci_dev_put(pdev);
> + pci_stop_and_remove_bus_device(pdev);
> + pci_unlock_rescan_remove();
> +
> + kfree(removal);
> + 

[PATCH v2 12/12] iwlwifi: pcie: remove non-responsive device

2018-04-26 Thread Luca Coelho
From: Luca Coelho 

If we fail to to grab NIC access because the device is not responding
(i.e. CSR_GP_CNTRL returns 0x), remove the device from the PCI
bus, to avoid any further damage, and to let the user space rescan.

In order to inform the userspace that a rescan is needed, we send a
kobject uevent with "INACCESSIBLE".

This functionality is disabled by default, but can be enabled via a
new module parameter called "remove_when_gone".  In the future we may
change this module parameter to include 3 modes instead: do nothing;
auto-rescan or; send uevent.

Signed-off-by: Luca Coelho 
Signed-off-by: Rajat Jain 
---
 drivers/net/wireless/intel/iwlwifi/iwl-drv.c  |  6 ++
 .../wireless/intel/iwlwifi/iwl-modparams.h|  2 +
 .../wireless/intel/iwlwifi/pcie/internal.h|  5 ++
 .../net/wireless/intel/iwlwifi/pcie/trans.c   | 74 ++-
 4 files changed, 84 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c 
b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
index 4f451a6f20b9..c59ce4f8a5ed 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-drv.c
@@ -1850,3 +1850,9 @@ MODULE_PARM_DESC(d0i3_timeout, "Timeout to D0i3 entry 
when idle (ms)");
 
 module_param_named(disable_11ac, iwlwifi_mod_params.disable_11ac, bool, 0444);
 MODULE_PARM_DESC(disable_11ac, "Disable VHT capabilities (default: false)");
+
+module_param_named(remove_when_gone,
+  iwlwifi_mod_params.remove_when_gone, bool,
+  0444);
+MODULE_PARM_DESC(remove_when_gone,
+"Remove dev from PCIe bus if it is deemed inaccessible 
(default: false)");
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
index a41c46e63eb1..a7dd8a8cddf9 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-modparams.h
@@ -122,6 +122,7 @@ enum iwl_uapsd_disable {
  * @lar_disable: disable LAR (regulatory), default = 0
  * @fw_monitor: allow to use firmware monitor
  * @disable_11ac: disable VHT capabilities, default = false.
+ * @remove_when_gone: remove an inaccessible device from the PCIe bus.
  */
 struct iwl_mod_params {
int swcrypto;
@@ -143,6 +144,7 @@ struct iwl_mod_params {
bool lar_disable;
bool fw_monitor;
bool disable_11ac;
+   bool remove_when_gone;
 };
 
 #endif /* #__iwl_modparams_h__ */
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h 
b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
index cda66340d357..45ea32796cda 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
@@ -383,6 +383,8 @@ struct iwl_self_init_dram {
  * @hw_init_mask: initial unmasked hw causes
  * @fh_mask: current unmasked fh causes
  * @hw_mask: current unmasked hw causes
+ * @in_rescan: true if we have triggered a device rescan
+ * @scheduled_for_removal: true if we have scheduled a device removal
  */
 struct iwl_trans_pcie {
struct iwl_rxq *rxq;
@@ -464,6 +466,9 @@ struct iwl_trans_pcie {
u32 fh_mask;
u32 hw_mask;
cpumask_t affinity_mask[IWL_MAX_RX_HW_QUEUES];
+   u16 tx_cmd_queue_size;
+   bool in_rescan;
+   bool scheduled_for_removal;
 };
 
 static inline struct iwl_trans_pcie *
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c 
b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 623476603cd4..6e9a9ecfb11c 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -75,6 +75,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "iwl-drv.h"
 #include "iwl-trans.h"
@@ -1935,6 +1936,29 @@ static void iwl_trans_pcie_set_pmi(struct iwl_trans 
*trans, bool state)
clear_bit(STATUS_TPOWER_PMI, >status);
 }
 
+struct iwl_trans_pcie_removal {
+   struct pci_dev *pdev;
+   struct work_struct work;
+};
+
+static void iwl_trans_pcie_removal_wk(struct work_struct *wk)
+{
+   struct iwl_trans_pcie_removal *removal =
+   container_of(wk, struct iwl_trans_pcie_removal, work);
+   struct pci_dev *pdev = removal->pdev;
+   char *prop[] = {"EVENT=INACCESSIBLE", NULL};
+
+   dev_err(>dev, "Device gone - attempting removal\n");
+   kobject_uevent_env(>dev.kobj, KOBJ_CHANGE, prop);
+   pci_lock_rescan_remove();
+   pci_dev_put(pdev);
+   pci_stop_and_remove_bus_device(pdev);
+   pci_unlock_rescan_remove();
+
+   kfree(removal);
+   module_put(THIS_MODULE);
+}
+
 static bool iwl_trans_pcie_grab_nic_access(struct iwl_trans *trans,
   unsigned long *flags)
 {
@@ -1977,11 +2001,55 @@ static bool iwl_trans_pcie_grab_nic_access(struct 
iwl_trans *trans,
   

[PATCH v2 12/12] iwlwifi: mvm: set wakeup filters for wowlan "any" configuration

2018-04-26 Thread Luca Coelho
From: Eliad Peller 

In case of "any" wowlan trigger is configured, no valid wakeup filter
was configured.

Moreover, the fw assumes there's no connection when there are no configured
wakeup filters.
This leads to the station info not being updated on D3 command, causing
rate_n_flags to be 0 when the offloading code sends tx frame (triggering
SYSASSERT_102C due to invalid antenna param)

Note: "any" trigger is currently assumed to only be used when entering
d0i3 (which has a different flow). However, we still reach this code
when using d3_test.

Signed-off-by: Eliad Peller 
Signed-off-by: Luca Coelho 
---
 drivers/net/wireless/intel/iwlwifi/mvm/d3.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c 
b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
index 80a9a7cb83be..3fcf489f3120 100644
--- a/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
+++ b/drivers/net/wireless/intel/iwlwifi/mvm/d3.c
@@ -8,6 +8,7 @@
  * Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
  * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
  * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
+ * Copyright(c) 2018Intel Corporation
  *
  * 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
@@ -18,11 +19,6 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  * General Public License for more details.
  *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110,
- * USA
- *
  * The full GNU General Public License is included in this distribution
  * in the file called COPYING.
  *
@@ -35,6 +31,7 @@
  * Copyright(c) 2012 - 2014 Intel Corporation. All rights reserved.
  * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH
  * Copyright(c) 2016 - 2017 Intel Deutschland GmbH
+ * Copyright(c) 2018Intel Corporation
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -693,6 +690,14 @@ iwl_mvm_get_wowlan_config(struct iwl_mvm *mvm,
IWL_WOWLAN_WAKEUP_LINK_CHANGE);
}
 
+   if (wowlan->any) {
+   wowlan_config_cmd->wakeup_filter |=
+   cpu_to_le32(IWL_WOWLAN_WAKEUP_BEACON_MISS |
+   IWL_WOWLAN_WAKEUP_LINK_CHANGE |
+   IWL_WOWLAN_WAKEUP_RX_FRAME |
+   IWL_WOWLAN_WAKEUP_BCN_FILTERING);
+   }
+
return 0;
 }
 
-- 
2.17.0



Re: [PATCH 09/12] iwlwifi: pcie: remove non-responsive device

2018-04-26 Thread Luca Coelho
On Wed, 2018-04-25 at 11:01 +0300, Kalle Valo wrote:
> Luca Coelho  writes:
> 
> > On Tue, 2018-04-24 at 12:44 +0300, Kalle Valo wrote:
> > > Luca Coelho  writes:
> > > 
> > > > From: Luca Coelho 
> > > > 
> > > > If we fail to to grab NIC access because the device is not
> > > > responding
> > > > (i.e. CSR_GP_CNTRL returns 0x), remove the device from
> > > > the
> > > > PCI
> > > > bus, to avoid any further damage, and to let the user space
> > > > rescan.
> > > > 
> > > > Signed-off-by: Luca Coelho 
> > > > Signed-off-by: Rajat Jain 
> > > 
> > > The commit log doesn't mention anything about the module
> > > parameter
> > > nor
> > > about the kobject uevent.
> > 
> > Good point.  The uevent and the module parameter were added in
> > later
> > patches and I squashed them all into this one, but forgot to update
> > the
> > commit message.  I'll fix it.
> 
> Good, thanks.
> 
> > > > +static void iwl_trans_pcie_removal_wk(struct work_struct *wk)
> > > > +{
> > > > +   struct iwl_trans_pcie_removal *removal =
> > > > +   container_of(wk, struct
> > > > iwl_trans_pcie_removal,
> > > > work);
> > > > +   struct pci_dev *pdev = removal->pdev;
> > > > +   char *prop[] = {"EVENT=INACCESSIBLE", NULL};
> > > > +
> > > > +   dev_err(>dev, "Device gone - attempting
> > > > removal\n");
> > > > +   kobject_uevent_env(>dev.kobj, KOBJ_CHANGE,
> > > > prop);
> > > > +   pci_lock_rescan_remove();
> > > > +   pci_dev_put(pdev);
> > > > +   pci_stop_and_remove_bus_device(pdev);
> > > > +   pci_unlock_rescan_remove();
> > > > +
> > > > +   kfree(removal);
> > > > +   module_put(THIS_MODULE);
> > > > +}
> > > 
> > > So is the uevent some standard thing or what? At least grepping
> > > INACCESSIBLE for didn't tell me anything.
> > 
> > No, this is not standard.  We didn't find any appropriate standard
> > message for this case, so we created a new one.  Also, we didn't
> > want
> > to interfere with components that may react to standard messages.
> > 
> > This is disabled by default and the idea is to change this in the
> > future to allow the driver to remove and rescan the device
> > automatically.  So we will have 3 options in the module parameter:
> > do
> > nothing; auto-rescan or; send uevent.
> 
> Ok, I assume you will explain this in the commit log.

Yes, I'll improve the commit message.


> In my opinion the driver should not be sending custom events like
> this
> and instead pci_stop_and_remove_bus_device() should do it, but maybe
> that's just me?

pci_stop_and_remove_bus_device() will already trigger some events, like
"REMOVED" or something like that.  But the semantics is a little bit
different.  If the device was removed, you don't usually want to rescan
the bus, because the device will not be there anymore.  In our case,
the device *is* there, but got stuck and we want to rescan to get it
back.

--
Cheers,
Luca.


Re: [PATCH v2 01/21] staging: wilc1000: replace crc7_byte() with inline macro CRC7_BYTE

2018-04-26 Thread Greg KH
On Wed, Apr 25, 2018 at 10:48:06PM +0530, Ajay Singh wrote:
> Replace the function call for crc7_byte() with macro CRC7_BYTE.
> crc7_byte() was called in close while(), so replaced it with macro to
> avoid extra functional call depth.
> 
> Signed-off-by: Ajay Singh 
> ---
>  drivers/staging/wilc1000/wilc_spi.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/staging/wilc1000/wilc_spi.c 
> b/drivers/staging/wilc1000/wilc_spi.c
> index 2cb9f4e..3bb8fec 100644
> --- a/drivers/staging/wilc1000/wilc_spi.c
> +++ b/drivers/staging/wilc1000/wilc_spi.c
> @@ -75,15 +75,12 @@ static const u8 crc7_syndrome_table[256] = {
>   0x46, 0x4f, 0x54, 0x5d, 0x62, 0x6b, 0x70, 0x79
>  };
>  
> -static u8 crc7_byte(u8 crc, u8 data)
> -{
> - return crc7_syndrome_table[(crc << 1) ^ data];
> -}
> +#define CRC7_BYTE(crc, data) crc7_syndrome_table[(crc << 1) ^ data]

Ick, no.  That's not needed at all, a function is always much better.

And a good compiler will just inline this, are you _sure_ you are
actually changing anything here?

But most importantly, why not just use the build-in crc7 functionality
that the kernel already provides?  Don't have a duplicate version here.

That would be a much better cleanup, right?

thanks,

greg k-h


Re: linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

2018-04-26 Thread Luciano Coelho
On Thu, 2018-04-26 at 11:09 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the wireless-drivers-next tree got a
> conflict in:
> 
>   drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> 
> between commit:
> 
>   77e30e10ee28 ("iwlwifi: mvm: query regdb for wmm rule if needed")
> 
> from the wireless-drivers tree and commits:
> 
>   9c4f7d512740 ("iwlwifi: move all NVM parsing code to the common
> files")
>   4c625c564ba2 ("iwlwifi: get rid of fw/nvm.c")
> 
> from the wireless-drivers-next tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your
> tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any
> particularly
> complex conflicts.

Thanks for resolving this, Stephen!

I checked your resolution and it's spot on.

--
Cheers,
Luca.


[PATCH] net: rfkill: gpio: fix memory leak in probe error path

2018-04-26 Thread Johan Hovold
Make sure to free the rfkill device in case registration fails during
probe.

Fixes: 5e7ca3937fbe ("net: rfkill: gpio: convert to resource managed 
allocation")
Cc: stable  # 3.13
Cc: Heikki Krogerus 
Signed-off-by: Johan Hovold 
---
 net/rfkill/rfkill-gpio.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/net/rfkill/rfkill-gpio.c b/net/rfkill/rfkill-gpio.c
index 41bd496531d4..00192a996be0 100644
--- a/net/rfkill/rfkill-gpio.c
+++ b/net/rfkill/rfkill-gpio.c
@@ -137,13 +137,18 @@ static int rfkill_gpio_probe(struct platform_device *pdev)
 
ret = rfkill_register(rfkill->rfkill_dev);
if (ret < 0)
-   return ret;
+   goto err_destroy;
 
platform_set_drvdata(pdev, rfkill);
 
dev_info(>dev, "%s device registered.\n", rfkill->name);
 
return 0;
+
+err_destroy:
+   rfkill_destroy(rfkill->rfkill_dev);
+
+   return ret;
 }
 
 static int rfkill_gpio_remove(struct platform_device *pdev)
-- 
2.17.0



Re: [PATCH v2 00/21] staging: wilc1000: remove unused code and reorder functions

2018-04-26 Thread Ajay Singh
Hi Greg,

This series is actually V1 and not V2. Sorry, it's mistake from my
side. 
If you want me to resend this series, please let me know.

 
 On Wed, 25 Apr 2018 22:48:05 +0530
Ajay Singh  wrote:

> This patch series contains fixes to remove the unused code. It also
> has patches to reorganize the function and simplify the function
> logic.
> 
> Ajay Singh (21):
>   staging: wilc1000: replace crc7_byte() with inline macro CRC7_BYTE
>   staging: wilc1000: align the #define in wilc_spi file
>   staging: wilc1000: remove unnecessary assingment from 'if'
> conditions staging: wilc1000: remove 'cmd' variable in wilc_spi
> functions staging: wicl1000: removed the unsed variables in
> wilc_parse_network_info()
>   staging: wilc1000: remove inner {} in wilc_parse_network_info()
>   staging: wilc1000: simplified if conditions in spi_data_write()
>   staging: wilc1000: remove unused variable scan_while_connected
>   staging: wilc1000: remove unsed typedef wilc_debug_func
>   staging: wilc1000: remove used #define HIF_SDIO_GPIO_IRQ
>   staging: wilc1000: remove unused #define related to MAC status
>   staging: wilc1000: rename mac status macros and moved related
> #define together
>   staging: wilc1000: rename WILC_WFI_stats to avoid uppercase
>   staging: wilc1000: rename num_reg_frame macro to have uppercase in
> macro name
>   staging: wilc1000: rename wlan init and deinit function prefixed
> with wil1000
>   staging: wilc1000: remove unused elements in 'wilc_priv' struct
>   staging: wilc1000: remove unused enum 'stats_flags'
>   staging: wilc1000: rename P2P_LISTEN_STATE variable to use
> lowercase staging: wilc1000: remove inner block '{}' in
> handle_remain_on_chan() staging: wilc1000: change function to
> static in linux_wlan staging: wilc1000: reorder functions to avoid
> forward declaration in linux_wlan
> 
>  drivers/staging/wilc1000/coreconfigurator.c   |  84
> +++ drivers/staging/wilc1000/host_interface.c
> |  64 
> drivers/staging/wilc1000/linux_wlan.c | 122
> ++
> drivers/staging/wilc1000/wilc_sdio.c  |  12 +--
> drivers/staging/wilc1000/wilc_spi.c   |  70
> ++--- drivers/staging/wilc1000/wilc_wfi_cfgoperations.c |
> 2 +- drivers/staging/wilc1000/wilc_wfi_netdevice.h |  23 +---
> drivers/staging/wilc1000/wilc_wlan.h  |   7 --
> drivers/staging/wilc1000/wilc_wlan_if.h   |  11 +- 9 files
> changed, 158 insertions(+), 237 deletions(-)
> 



Regards,
Ajay