Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-14 Thread Marcel Holtmann
Hi Michael,

> That's the default now, no need for makefiles to set it.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---
> drivers/bluetooth/Makefile| 2 --
> drivers/net/can/Makefile  | 1 -
> drivers/net/ethernet/altera/Makefile  | 1 -
> drivers/net/ethernet/atheros/alx/Makefile | 1 -
> drivers/net/ethernet/freescale/Makefile   | 2 --
> drivers/net/wireless/ath/Makefile | 2 --
> drivers/net/wireless/ath/wil6210/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
> drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
> drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
> drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
> drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
> drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
> drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
> drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
> drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
> drivers/net/wireless/ti/wl1251/Makefile   | 2 --
> drivers/net/wireless/ti/wlcore/Makefile   | 2 --
> drivers/staging/rtl8188eu/Makefile| 2 +-
> drivers/staging/rtl8192e/Makefile | 2 --
> drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
> net/bluetooth/Makefile| 2 --
> net/ieee802154/Makefile   | 2 --
> net/mac80211/Makefile | 2 +-
> net/mac802154/Makefile| 2 --
> net/wireless/Makefile | 2 --
> 38 files changed, 5 insertions(+), 68 deletions(-)

for drivers/bluetooth, net/bluetooth, net/ieee802154 and net/mac802154

Acked-by: Marcel Holtmann 

Regards

Marcel



[RFC 3/3] mac80211: Add receive path for ethernet frame format

2016-12-14 Thread Vasanthakumar Thiagarajan
Implement rx path which does fewer processing on the
received data frame which has already gone through
802.11 header decapsulation and other functionalities
which require 802.11 header in the low level driver
or hardware. Currently this rx path is restricted
to AP and STA mode, but can be extended for Adhoc
mode as well.

This rx path only checks if the driver has advertised
it's support of 802.11 header encap/decap offload for
data frames. It is upto the low level driver to make
sure if the frame that it passes is in ethernet format
and the sta pointer is valid.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/mac80211.h |  19 +
 net/mac80211/rx.c  | 189 -
 2 files changed, 206 insertions(+), 2 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 225abaa..75c55e2 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1088,6 +1088,9 @@ ieee80211_tx_info_clear_status(struct ieee80211_tx_info 
*info)
  * @RX_FLAG_ALLOW_SAME_PN: Allow the same PN as same packet before.
  * This is used for AMSDU subframes which can have the same PN as
  * the first subframe.
+ * @RX_FLAG_MCAST: If the receiver address (addr1) in the frame is multicast.
+ * This is used with the data frames by the drivers supporting 802.11 hdr
+ * decap offload.
  */
 enum mac80211_rx_flags {
RX_FLAG_MMIC_ERROR  = BIT(0),
@@ -1123,6 +1126,7 @@ enum mac80211_rx_flags {
RX_FLAG_RADIOTAP_VENDOR_DATA= BIT(31),
RX_FLAG_MIC_STRIPPED= BIT_ULL(32),
RX_FLAG_ALLOW_SAME_PN   = BIT_ULL(33),
+   RX_FLAG_MCAST   = BIT_ULL(34),
 };
 
 #define RX_FLAG_STBC_SHIFT 26
@@ -3989,6 +3993,21 @@ static inline void ieee80211_rx_ni(struct ieee80211_hw 
*hw,
 }
 
 /**
+ * ieee80211_rx_decap_offl - Receive frames in 802.11 decapsulated format
+ *
+ * Low level driver capable of 802.11 header decap uses this function. The 
frame
+ * will be in ethernet format.
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware this frame came in on
+ * @sta : the station the frame was received from, must not be %NULL
+ * @skb: the buffer to receive, owned by mac80211 after this call
+ */
+void ieee80211_rx_decap_offl(struct ieee80211_hw *hw, struct ieee80211_sta 
*sta,
+struct sk_buff *skb);
+
+/**
  * ieee80211_sta_ps_transition - PS transition for connected sta
  *
  * When operating in AP mode with the %IEEE80211_HW_AP_LINK_PS
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index 2e8a902..3cb8d6e 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -2103,13 +2103,14 @@ __ieee80211_data_to_8023(struct ieee80211_rx_data *rx, 
bool *port_control)
return 0;
 }
 
+static const u8 pae_group_addr[ETH_ALEN] __aligned(2)
+   = { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x03 };
+
 /*
  * requires that rx->skb is a frame with ethernet header
  */
 static bool ieee80211_frame_allowed(struct ieee80211_rx_data *rx, __le16 fc)
 {
-   static const u8 pae_group_addr[ETH_ALEN] __aligned(2)
-   = { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x03 };
struct ethhdr *ehdr = (struct ethhdr *) rx->skb->data;
 
/*
@@ -4180,3 +4181,187 @@ void ieee80211_rx_irqsafe(struct ieee80211_hw *hw, 
struct sk_buff *skb)
tasklet_schedule(>tasklet);
 }
 EXPORT_SYMBOL(ieee80211_rx_irqsafe);
+
+/* Receive path for decap offloaded data frames */
+
+static void
+ieee80211_rx_handle_decap_offl(struct ieee80211_sub_if_data *sdata,
+struct sta_info *sta, struct sk_buff *skb)
+{
+   struct ieee80211_local *local = sdata->local;
+   struct ieee80211_vif *vif = >vif;
+   struct net_device *dev = sdata->dev;
+   struct ieee80211_rx_status *status;
+   struct ieee80211_key *key = NULL;
+   struct ieee80211_rx_data rx;
+   int i;
+   struct ethhdr *ehdr;
+
+   ehdr = (struct ethhdr *)skb->data;
+   status = IEEE80211_SKB_RXCB(skb);
+
+   /* TODO: Extend ieee80211_rx_decap_offl() with bssid so that Ethernet
+* encap/decap can be supported in Adhoc interface type as well.
+* Adhoc interface depends on bssid to udpate last_rx.
+*/
+   if (vif->type != NL80211_IFTYPE_STATION &&
+   vif->type != NL80211_IFTYPE_AP_VLAN &&
+   vif->type != NL80211_IFTYPE_AP)
+   goto drop;
+
+   I802_DEBUG_INC(local->dot11ReceivedFragmentCount);
+
+   if (!(status->flag & RX_FLAG_MCAST)) {
+   sta->rx_stats.last_rx = jiffies;
+   sta->rx_stats.last_rate = sta_stats_encode_rate(status);
+   }
+
+   if (sdata->vif.type == NL80211_IFTYPE_STATION &&
+   !is_multicast_ether_addr(ehdr->h_dest))
+   ieee80211_sta_reset_conn_monitor(sdata);
+
+  

[RFC 2/3] mac80211: Implement data xmit for 802.11 encap offload

2016-12-14 Thread Vasanthakumar Thiagarajan
Driver (or hw) supporting 802.11 encapsulation offload
for data frames can make use of this new xmit path.

This patch defines new ndo_ops, all these callbacks are same as
ieee80211_dataif_ops other than ndo_start_xmit() which does
minimal processing leaving 802.11 encap related to driver.
This patch makes netdev_ops registration dynamic based on the
interface type, at any time the netdev_ops of netdev will be
assigned to either the ndo_ops defined to do 802.11 encap or
the ones defined for 802.11 encap offload. There is a new hw
config notification, IEEE80211_CONF_CHANGE_80211_HDR_OFFL, to make
the driver aware of any configuration change in 802.11 encap/decap
offload.

There is a field, no_80211_encap, added to ieee80211_tx_info:control
to mark if the 802.11 encapsulation is offloaded to driver.
There is also a new callback for tx completion status indication
to handle data frames using 802.11 encap offload. Currently ath10k
fw is capable of doing 802.11 encapsulation/decapsulationi offload.
With the corresponding driver changes, using 802.11 encap/decap offload
might improve performance.

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/mac80211.h |  33 ++-
 net/mac80211/cfg.c |   8 ++
 net/mac80211/ieee80211_i.h |  12 +++
 net/mac80211/iface.c   | 147 +
 net/mac80211/key.c |  16 +++-
 net/mac80211/main.c|   3 +
 net/mac80211/status.c  |  83 -
 net/mac80211/tx.c  | 225 -
 8 files changed, 519 insertions(+), 8 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 1e3c8b5..225abaa 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -910,7 +910,12 @@ struct ieee80211_tx_info {
};
struct ieee80211_key_conf *hw_key;
u32 flags;
-   /* 4 bytes free */
+   /* XXX: This frame is not encaptulated with 802.11
+* header. Should this be added to %IEEE80211_TX_CTRL_*
+* flags?.
+*/
+   bool no_80211_encap;
+   /* 3 bytes free */
} control;
struct {
u64 cookie;
@@ -1269,6 +1274,8 @@ enum ieee80211_conf_flags {
  * @IEEE80211_CONF_CHANGE_SMPS: Spatial multiplexing powersave mode changed
  * Note that this is only valid if channel contexts are not used,
  * otherwise each channel context has the number of chains listed.
+ * @IEEE80211_CONF_CHANGE_80211_HDR_OFFL: Offload configuration
+ * implementing 802.11 encap/decap for data frames changed.
  */
 enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_SMPS  = BIT(1),
@@ -1279,6 +1286,7 @@ enum ieee80211_conf_changed {
IEEE80211_CONF_CHANGE_CHANNEL   = BIT(6),
IEEE80211_CONF_CHANGE_RETRY_LIMITS  = BIT(7),
IEEE80211_CONF_CHANGE_IDLE  = BIT(8),
+   IEEE80211_CONF_CHANGE_80211_HDR_OFFL= BIT(9),
 };
 
 /**
@@ -1333,6 +1341,9 @@ enum ieee80211_smps_mode {
  * configured for an HT channel.
  * Note that this is only valid if channel contexts are not used,
  * otherwise each channel context has the number of chains listed.
+ *
+ * @encap_decap_80211_offloaded: Whether 802.11 header encap/decap offload
+ * is enabled
  */
 struct ieee80211_conf {
u32 flags;
@@ -1346,6 +1357,7 @@ struct ieee80211_conf {
struct cfg80211_chan_def chandef;
bool radar_enabled;
enum ieee80211_smps_mode smps_mode;
+   bool encap_decap_80211_offloaded;
 };
 
 /**
@@ -4178,6 +4190,25 @@ void ieee80211_tx_status_irqsafe(struct ieee80211_hw *hw,
 struct sk_buff *skb);
 
 /**
+ * ieee80211_tx_status_8023 - transmit status callback for 802.3 frame format
+ *
+ * Call this function for all transmitted data frames after their transmit
+ * completion. This callback should only be called for data frames which
+ * are are using driver's (or hardware's) offload capability of encap/decap
+ * 802.11 frames.
+ *
+ * This function may not be called in IRQ context. Calls to this function
+ * for a single hardware must be synchronized against each other.
+ *
+ * @hw: the hardware the frame was transmitted by
+ * @vif: the interface for which the frame was transmitted
+ * @skb: the frame that was transmitted, owned by mac80211 after this call
+ */
+void ieee80211_tx_status_8023(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ struct sk_buff *skb);
+
+/**
  * ieee80211_report_low_ack - report non-responding station
  *
  * When operating in AP-mode, call this function to report a non-responding
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index 47e99ab8..0e53873 100644
--- a/net/mac80211/cfg.c
+++ 

[RFC 1/3] mac80211: Add provision for 802.11 encap/decap offload

2016-12-14 Thread Vasanthakumar Thiagarajan
Drivers can have the capability to offload 802.11 encap/decap
to firmware or hardware for data frames. This patch adds a new
hw_flag for driver to advertise the offload support. Drivers
advertising the support have also to implement new ieee80211_ops
callback, get_vif_80211_hdr_offload(), to notify if the 802.11 encap/decap
offload is supported for a particular vif type. Transmit and receive
path offloading 802.11 header (including cipher headers) encap/decap
for data frames will be implemented in separate patches.

Drivers advertising this capability should also implement other
functionalities which deal with 802.11 frame format like below

- Hardware encryption/Decryption
- ADDBA/DELBA offload
- Aggregation and deaggregation of A-MSDU offload
- Fragmentation and defragmentation offload
- Rx reordering of A-MPDU subframe offload
- PN/TSC check offload
- Rx duplication check offload
- Hardware rate control
- Powersave offload

Signed-off-by: Vasanthakumar Thiagarajan 
---
 include/net/mac80211.h| 16 
 net/mac80211/debugfs.c|  1 +
 net/mac80211/driver-ops.h | 21 +
 net/mac80211/main.c   |  4 
 net/mac80211/trace.h  | 33 +
 5 files changed, 75 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index b4faadb..1e3c8b5 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2014,6 +2014,11 @@ struct ieee80211_txq {
  * @IEEE80211_HW_TX_FRAG_LIST: Hardware (or driver) supports sending frag_list
  * skbs, needed for zero-copy software A-MSDU.
  *
+ * @IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP: Hardware/driver supports 802.11
+ * encap/decap for data frames. Supporting driver have to implement
+ * get_vif_80211_encap_decap_offload() to pass if 802.11 encap/decap
+ * offload is supported for the vif.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2054,6 +2059,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_USES_RSS,
IEEE80211_HW_TX_AMSDU,
IEEE80211_HW_TX_FRAG_LIST,
+   IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP,
 
/* keep last, obviously */
NUM_IEEE80211_HW_FLAGS
@@ -3401,6 +3407,12 @@ enum ieee80211_reconfig_type {
  * synchronization which is needed in case driver has in its RSS queues
  * pending frames that were received prior to the control path action
  * currently taken (e.g. disassociation) but are not processed yet.
+ *
+ * @get_vif_80211_hdr_offload: Called to check if driver or hardware
+ * supports 802.11 encap/decap offload for data frames for the vif.
+ * Drivers implementing this callback should advertise the support
+ * through hw_flags (%IEEE80211_HW_SUPPORTS_80211_ENCAP_DECAP).
+ * This callback can sleep.
  */
 struct ieee80211_ops {
void (*tx)(struct ieee80211_hw *hw,
@@ -3639,6 +3651,10 @@ struct ieee80211_ops {
void (*wake_tx_queue)(struct ieee80211_hw *hw,
  struct ieee80211_txq *txq);
void (*sync_rx_queues)(struct ieee80211_hw *hw);
+
+   int (*get_vif_80211_hdr_offload)(struct ieee80211_hw *hw,
+struct ieee80211_vif *vif,
+bool is_4addr, bool *supported);
 };
 
 /**
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 2906c10..f49fea5 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -302,6 +302,7 @@ static const char *hw_flag_names[] = {
FLAG(USES_RSS),
FLAG(TX_AMSDU),
FLAG(TX_FRAG_LIST),
+   FLAG(SUPPORTS_80211_ENCAP_DECAP),
 #undef FLAG
 };
 
diff --git a/net/mac80211/driver-ops.h b/net/mac80211/driver-ops.h
index 184473c..22847d2 100644
--- a/net/mac80211/driver-ops.h
+++ b/net/mac80211/driver-ops.h
@@ -1179,4 +1179,25 @@ static inline void drv_wake_tx_queue(struct 
ieee80211_local *local,
local->ops->wake_tx_queue(>hw, >txq);
 }
 
+static inline int
+drv_get_vif_80211_hdr_offload(struct ieee80211_local *local,
+ struct ieee80211_sub_if_data *sdata,
+ bool use_4addr, bool *supported)
+{
+   int ret = -EOPNOTSUPP;
+
+   might_sleep();
+
+   if (local->ops->get_vif_80211_hdr_offload)
+   ret = local->ops->get_vif_80211_hdr_offload(>hw,
+   >vif,
+   use_4addr,
+   supported);
+
+   trace_drv_get_vif_80211_hdr_offload(local, sdata, use_4addr,
+   *supported, ret);
+
+   return ret;
+}
+
 #endif /* __MAC80211_DRIVER_OPS */
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index d00ea9b..2095d7c 100644
--- a/net/mac80211/main.c

[RFC 0/3] Add new data path for ethernet frame format

2016-12-14 Thread Vasanthakumar Thiagarajan
This patch set adds a new data path to offload 802.11 header
encap/decap to driver or hardware. Drivers having support
for ieee80211 header encap/decap and other offload functionalities
which can't be done before encap or after decap can make use of
this new data path. Currently it is implemented for STA and AP
interface type, this can be extend other interface types like
adhoc.  

With ath10k driver changes using this new Tx/Rx path, 10 - 15%
CPU usage and upto ~20Mbps TCP performance improvements are
observed with this ethernet data path. This patch set is
prepared on a older mac80211 code base on top of
commit 7d27a0ba7adc ("cfg80211: Add mesh peer AID setting API").
Sorry, I could not get a chance to rework it on top of latest
mac80211 code base.

TODO (from initial review):

- Consider ieee8011 header and cipher header size also while updating 
tx/rx stats for
  ethernet frame format.
- Any optimization to reduce the amount of code change.
- Improve commit log and doc

Vasanthakumar Thiagarajan (3):
  mac80211: Add provision for 802.11 encap/decap offload
  mac80211: Implement data xmit for 802.11 encap offload
  mac80211: Add receive path for ethernet frame format

 include/net/mac80211.h |  68 +-
 net/mac80211/cfg.c |   8 ++
 net/mac80211/debugfs.c |   1 +
 net/mac80211/driver-ops.h  |  21 +
 net/mac80211/ieee80211_i.h |  12 +++
 net/mac80211/iface.c   | 147 +
 net/mac80211/key.c |  16 +++-
 net/mac80211/main.c|   7 ++
 net/mac80211/rx.c  | 189 -
 net/mac80211/status.c  |  83 -
 net/mac80211/trace.h   |  33 +++
 net/mac80211/tx.c  | 225 -
 12 files changed, 800 insertions(+), 10 deletions(-)

-- 
1.9.1



[PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags

2016-12-14 Thread Michael S. Tsirkin
That's the default now, no need for makefiles to set it.

Signed-off-by: Michael S. Tsirkin 
---
 drivers/bluetooth/Makefile| 2 --
 drivers/net/can/Makefile  | 1 -
 drivers/net/ethernet/altera/Makefile  | 1 -
 drivers/net/ethernet/atheros/alx/Makefile | 1 -
 drivers/net/ethernet/freescale/Makefile   | 2 --
 drivers/net/wireless/ath/Makefile | 2 --
 drivers/net/wireless/ath/wil6210/Makefile | 2 --
 drivers/net/wireless/broadcom/brcm80211/brcmfmac/Makefile | 2 --
 drivers/net/wireless/broadcom/brcm80211/brcmsmac/Makefile | 1 -
 drivers/net/wireless/intel/iwlegacy/Makefile  | 2 --
 drivers/net/wireless/intel/iwlwifi/Makefile   | 2 +-
 drivers/net/wireless/intel/iwlwifi/dvm/Makefile   | 2 +-
 drivers/net/wireless/intel/iwlwifi/mvm/Makefile   | 2 +-
 drivers/net/wireless/intersil/orinoco/Makefile| 3 ---
 drivers/net/wireless/mediatek/mt7601u/Makefile| 2 --
 drivers/net/wireless/realtek/rtlwifi/Makefile | 2 --
 drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192c/Makefile| 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ce/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192cu/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192de/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8192se/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/Makefile   | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8723com/Makefile  | 2 --
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/Makefile   | 2 --
 drivers/net/wireless/ti/wl1251/Makefile   | 2 --
 drivers/net/wireless/ti/wlcore/Makefile   | 2 --
 drivers/staging/rtl8188eu/Makefile| 2 +-
 drivers/staging/rtl8192e/Makefile | 2 --
 drivers/staging/rtl8192e/rtl8192e/Makefile| 2 --
 net/bluetooth/Makefile| 2 --
 net/ieee802154/Makefile   | 2 --
 net/mac80211/Makefile | 2 +-
 net/mac802154/Makefile| 2 --
 net/wireless/Makefile | 2 --
 38 files changed, 5 insertions(+), 68 deletions(-)

diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index b1fc29a..8062718 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -40,5 +40,3 @@ hci_uart-$(CONFIG_BT_HCIUART_QCA) += hci_qca.o
 hci_uart-$(CONFIG_BT_HCIUART_AG6XX)+= hci_ag6xx.o
 hci_uart-$(CONFIG_BT_HCIUART_MRVL) += hci_mrvl.o
 hci_uart-objs  := $(hci_uart-y)
-
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index 26ba4b7..7a85495 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -31,5 +31,4 @@ obj-$(CONFIG_CAN_TI_HECC) += ti_hecc.o
 obj-$(CONFIG_CAN_XILINXCAN)+= xilinx_can.o
 obj-$(CONFIG_PCH_CAN)  += pch_can.o
 
-subdir-ccflags-y += -D__CHECK_ENDIAN__
 subdir-ccflags-$(CONFIG_CAN_DEBUG_DEVICES) += -DDEBUG
diff --git a/drivers/net/ethernet/altera/Makefile 
b/drivers/net/ethernet/altera/Makefile
index 3eff2fd..d4a187e 100644
--- a/drivers/net/ethernet/altera/Makefile
+++ b/drivers/net/ethernet/altera/Makefile
@@ -5,4 +5,3 @@
 obj-$(CONFIG_ALTERA_TSE) += altera_tse.o
 altera_tse-objs := altera_tse_main.o altera_tse_ethtool.o \
 altera_msgdma.o altera_sgdma.o altera_utils.o
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/ethernet/atheros/alx/Makefile 
b/drivers/net/ethernet/atheros/alx/Makefile
index 5901fa4..ed4a605 100644
--- a/drivers/net/ethernet/atheros/alx/Makefile
+++ b/drivers/net/ethernet/atheros/alx/Makefile
@@ -1,3 +1,2 @@
 obj-$(CONFIG_ALX) += alx.o
 alx-objs := main.o ethtool.o hw.o
-ccflags-y += -D__CHECK_ENDIAN__
diff --git a/drivers/net/ethernet/freescale/Makefile 
b/drivers/net/ethernet/freescale/Makefile
index 4a13115..c46df5c 100644
--- a/drivers/net/ethernet/freescale/Makefile
+++ b/drivers/net/ethernet/freescale/Makefile
@@ -4,8 +4,6 @@
 
 obj-$(CONFIG_FEC) += fec.o
 fec-objs :=fec_main.o fec_ptp.o
-CFLAGS_fec_main.o := -D__CHECK_ENDIAN__
-CFLAGS_fec_ptp.o := -D__CHECK_ENDIAN__
 
 obj-$(CONFIG_FEC_MPC52xx) += fec_mpc52xx.o
 ifeq ($(CONFIG_FEC_MPC52xx_MDIO),y)
diff --git a/drivers/net/wireless/ath/Makefile 
b/drivers/net/wireless/ath/Makefile
index 89f8d59..4cdebc7 100644
--- a/drivers/net/wireless/ath/Makefile
+++ b/drivers/net/wireless/ath/Makefile
@@ -19,6 +19,4 @@ ath-objs :=   main.o \
 ath-$(CONFIG_ATH_DEBUG) += debug.o
 

[PATCH 5/8] linux: drop __bitwise__ everywhere

2016-12-14 Thread Michael S. Tsirkin
__bitwise__ used to mean "yes, please enable sparse checks
unconditionally", but now that we dropped __CHECK_ENDIAN__
__bitwise is exactly the same.
There aren't many users, replace it by __bitwise everywhere.

Signed-off-by: Michael S. Tsirkin 
---
 arch/arm/plat-samsung/include/plat/gpio-cfg.h| 2 +-
 drivers/md/dm-cache-block-types.h| 6 +++---
 drivers/net/ethernet/sun/sunhme.h| 2 +-
 drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h | 4 ++--
 include/linux/mmzone.h   | 2 +-
 include/linux/serial_core.h  | 4 ++--
 include/linux/types.h| 4 ++--
 include/scsi/iscsi_proto.h   | 2 +-
 include/target/target_core_base.h| 2 +-
 include/uapi/linux/virtio_types.h| 6 +++---
 net/ieee802154/6lowpan/6lowpan_i.h   | 2 +-
 net/mac80211/ieee80211_i.h   | 4 ++--
 12 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/arch/arm/plat-samsung/include/plat/gpio-cfg.h 
b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
index 21391fa..e55d1f5 100644
--- a/arch/arm/plat-samsung/include/plat/gpio-cfg.h
+++ b/arch/arm/plat-samsung/include/plat/gpio-cfg.h
@@ -26,7 +26,7 @@
 
 #include 
 
-typedef unsigned int __bitwise__ samsung_gpio_pull_t;
+typedef unsigned int __bitwise samsung_gpio_pull_t;
 
 /* forward declaration if gpio-core.h hasn't been included */
 struct samsung_gpio_chip;
diff --git a/drivers/md/dm-cache-block-types.h 
b/drivers/md/dm-cache-block-types.h
index bed4ad4..389c9e8 100644
--- a/drivers/md/dm-cache-block-types.h
+++ b/drivers/md/dm-cache-block-types.h
@@ -17,9 +17,9 @@
  * discard bitset.
  */
 
-typedef dm_block_t __bitwise__ dm_oblock_t;
-typedef uint32_t __bitwise__ dm_cblock_t;
-typedef dm_block_t __bitwise__ dm_dblock_t;
+typedef dm_block_t __bitwise dm_oblock_t;
+typedef uint32_t __bitwise dm_cblock_t;
+typedef dm_block_t __bitwise dm_dblock_t;
 
 static inline dm_oblock_t to_oblock(dm_block_t b)
 {
diff --git a/drivers/net/ethernet/sun/sunhme.h 
b/drivers/net/ethernet/sun/sunhme.h
index f430765..4a8d5b1 100644
--- a/drivers/net/ethernet/sun/sunhme.h
+++ b/drivers/net/ethernet/sun/sunhme.h
@@ -302,7 +302,7 @@
  * Always write the address first before setting the ownership
  * bits to avoid races with the hardware scanning the ring.
  */
-typedef u32 __bitwise__ hme32;
+typedef u32 __bitwise hme32;
 
 struct happy_meal_rxd {
hme32 rx_flags;
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h 
b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
index 1ad0ec1..84813b5 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-fw-file.h
@@ -228,7 +228,7 @@ enum iwl_ucode_tlv_flag {
IWL_UCODE_TLV_FLAGS_BCAST_FILTERING = BIT(29),
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_api_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_api_t;
 
 /**
  * enum iwl_ucode_tlv_api - ucode api
@@ -258,7 +258,7 @@ enum iwl_ucode_tlv_api {
 #endif
 };
 
-typedef unsigned int __bitwise__ iwl_ucode_tlv_capa_t;
+typedef unsigned int __bitwise iwl_ucode_tlv_capa_t;
 
 /**
  * enum iwl_ucode_tlv_capa - ucode capabilities
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 0f088f3..36d9896 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -246,7 +246,7 @@ struct lruvec {
 #define ISOLATE_UNEVICTABLE((__force isolate_mode_t)0x8)
 
 /* LRU Isolation modes. */
-typedef unsigned __bitwise__ isolate_mode_t;
+typedef unsigned __bitwise isolate_mode_t;
 
 enum zone_watermarks {
WMARK_MIN,
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 5d49488..5def8e8 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -111,8 +111,8 @@ struct uart_icount {
__u32   buf_overrun;
 };
 
-typedef unsigned int __bitwise__ upf_t;
-typedef unsigned int __bitwise__ upstat_t;
+typedef unsigned int __bitwise upf_t;
+typedef unsigned int __bitwise upstat_t;
 
 struct uart_port {
spinlock_t  lock;   /* port lock */
diff --git a/include/linux/types.h b/include/linux/types.h
index baf7183..d501ad3 100644
--- a/include/linux/types.h
+++ b/include/linux/types.h
@@ -154,8 +154,8 @@ typedef u64 dma_addr_t;
 typedef u32 dma_addr_t;
 #endif
 
-typedef unsigned __bitwise__ gfp_t;
-typedef unsigned __bitwise__ fmode_t;
+typedef unsigned __bitwise gfp_t;
+typedef unsigned __bitwise fmode_t;
 
 #ifdef CONFIG_PHYS_ADDR_T_64BIT
 typedef u64 phys_addr_t;
diff --git a/include/scsi/iscsi_proto.h b/include/scsi/iscsi_proto.h
index c1260d8..df156f1 100644
--- a/include/scsi/iscsi_proto.h
+++ b/include/scsi/iscsi_proto.h
@@ -74,7 +74,7 @@ static inline int iscsi_sna_gte(u32 n1, u32 n2)
 #define zero_data(p) {p[0]=0;p[1]=0;p[2]=0;}
 
 /* initiator tags; opaque for target */
-typedef uint32_t __bitwise__ itt_t;
+typedef uint32_t __bitwise itt_t;
 /* 

Re: Problems getting mwifiex with sd8887 to work

2016-12-14 Thread Federico Pietro Briata
Hi All,

I'm also using sd8887 and I'm trying to make it work in adhoc mode and
encrypt the channel with wpa-none, but I got some trouble.

If I make the same specific test with from the driver from marvel
intranet, is working (maybe because the firmware is more recent ?) but
anyway the general stability with the driver is poor, I get frequent
kernel crash, I see at [1] that this driver is based on android and
I've personally to admit that mwifiex driver solved the stability side
but unfortunately introduce a regression on wpa-none.

With mwifiex backport driver of Linux 4.1  is not working, I mean the
link seems to be established always even when the password is wrong.

I saw on older thread on linux wireless with similar issue but more
related to fix ibss-rns, but with my test ibss-rns never worked with
mwifiex as with intranet one, so I think will be more important fix
the regression with wpa-none.


[1] 
https://www.u-blox.com/sites/default/files/EVK-EMMY-W1_UserGuide_%28UBX-15012713%29.pdf

Thanks and Regards,
Federico


Re: [Patch] NFC: trf7970a:

2016-12-14 Thread Mark Greer
On Wed, Dec 14, 2016 at 01:35:03PM -0500, Geoff Lansberry wrote:
> On Wed, Dec 14, 2016 at 12:10 PM, Mark Greer  wrote:
> > On Wed, Dec 14, 2016 at 11:17:33AM -0500, Geoff Lansberry wrote:
> >> On Wed, Dec 14, 2016 at 10:57 AM, Mark Greer  
> >> wrote:
> >> >
> >> > On Tue, Dec 13, 2016 at 08:50:04PM -0500, Geoff Lansberry wrote:
> >> > > Hi Mark -  Thanks for getting back to me.   It's funny that you ask,
> >> > > because we are currently chasing a segfault that is happening in 
> >> > > neard, but
> >> > > may end up back in the trf7970a driver.   Have you ever heard on anyone
> >> > > having segfault problems related to the trf7970a hardware drivers?
> >> >
> >> > No.  Mind sharing more info on that segfault?
> >> >
> >> > > I'll get you an update later tonight or tomorrow.
> >> >
> >> > Okay, thanks.
> >> >
> >> > Mark
> >> > --
> >>
> >> Mark - The segfault issue is only happening on writing, The work on
> >> the segfault is being done by a consultant, but here is his statement
> >> on how to recreate it on our build:
> >>
> >> I am able to reliably force neard to segfault by flooding it with
> >> write requests. I have attached a python script called flood.py that
> >> can be used to do this. The script uses utilities that ship with
> >> neard.
> >>
> >> The segfault does not appear deterministic. It usually happens within
> >> 1000 writes, but the time can varying greatly. The logs output from
> >> neard are inconsistent between crashes, which suggests this may be a
> >> timing or race condition related issue.
> >>
> >> I have been running neard manually to obtain the log information and a
> >> core file for debugging (attached). I run neard as,
> >>
> >>   $ /usr/lib/neard/nfc/neard -d -n
> >>
> >> In a separate terminal I run,
> >>
> >>   $ python flood.py
> >>
> >> And the resulting core file provides the following backtrace,
> >>
> >> (gdb) bt
> >> #0  0xb6caed64 in ?? ()
> >> #1  0x0001ed7c in data_recv (resp=0x5bd90 "", length=17, data=0x58348)
> >> at plugins/nfctype2.c:156
> >> #2  0x00024ecc in execute_recv_cb (user_data=0x5bd88) at src/adapter.c:979
> >> #3  0xb6e70d60 in ?? ()
> >> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> >> (gdb)
> >>
> >> The line at nfctype2.c:156 contains a memcpy operation.
> >
> > Thanks Geoff.
> >
> > What are the values of the arguments to memcpy()?
> >
> > I will look at it later today/tomorrow but if you have another NFC device
> > to test with, it would help isolate whether it is neard or the trf7970a
> > driver.  The driver shouldn't be able to make neard crash like this but
> > who knows.
> >
> > You could also try testing older versions of neard to see if they also
> > fail and if not, start bisecting from there.  Maybe test a different
> > tag type too.
> >
> > Mark
> > --
> Mark - We can't seem to get gdb to run on our board, so we can't see
> the exact arguments.

:(

> Here is what our consultant has to say about
> your question:
> 
> 
> The backtrace seems to indicate that the error is occurring in neard,
> not the driver.

Yep.

> Since the driver is built as a module, your kernel won't crash if
> there is a problem in it,

Not true.  A driver driver can happily crash the kernel even when it
is dynamically loaded/linked.  I expect the fact that it is dynamicaly
loaded to be irrelevant to this issue.

> but you should be told that the error is
> originating in the module.
>
> It is also possible that the NFC driver does have a non-fatal problem
> in it (such as returning unexpected data) that is propagating to neard
> and causing the error there.

I agree, it is possible that the driver is returning bad data but that
still shouldn't crash neard.  So there is almost certainly one neard
issue and potentially more.  There could also be driver issues too,
of course.

> Of course, it is also worth noting:
> 
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> 
> and the same address appearing twice -- what I would assume to be your
> memcpy address, since that is the last call made on a given source
> line. If the stack is corrupt, then the error could very well
> originate in the driver and not neard.

Lots of things are possible but that doesn't make them so.  Let's be
methodical and follow where the data takes us.  I'll start on this
tonight but won't likely get far until tomorrow.  In the meantime,
if you and/or your contractor make progress, please share.

Thanks,

Mark
--


Re: [RFC v2 05/11] ath10k: htc: refactorization

2016-12-14 Thread Erik Stromdahl


On 12/14/2016 02:46 PM, Valo, Kalle wrote:
> Erik Stromdahl  writes:
> 
>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath master.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
> 
> Good, this makes it easier to follow the development. So what's the
> current status with this branch? What works and what doesn't?
> 
Well, everything in there has been tested (limited though, as you
yourself experienced), but it is not complete. I still have some other
patches that need some more refurbishing before I can push them.

I will push those patches that I consider "good enough" for publish to
this repo. Most likely I will rewrite/squash etc. some of it before
submitting a new RFC series.

So, there are still some additional stuff that needs to be added. In my
case I have a series of patches related to OCB (Outside the Context of a
BSS) mode of operation (since the chipset I am using is intended for
this purpose). These patches are still not complete.

Other SDIO 11ac chipsets might just need an item in the struct
ath10k_hw_params array together with some firmware files.

> Especially I'm interested about the state of the HTT high latency
> support. How much work is to add that? It would also make it easier to
> add USB support to ath10k.
> 

I actually have some patches regarding this, but they have not been
tested at all since I have not yet managed to fully configure my SDIO
chip properly so far. I must finish the OCB code I mentioned earlier and
fix another really annoying issue with a missing HTT version response
(sometimes target won't respond to the HTT version request).

Then, hopefully, I can make some TX and RX tests.

I think the HTT TX part is fairly straight forward. But the RX part is a
little bit more tricky since I am not really sure about how to interface
mac80211 in the RX path.

My work flow goes like this:

As soon as there is a new tag on the ath.git master, I rebase my stuff
on top of it and push a new branch to my repo.

I will continuously push updates to the latest branch (the branch based
on the latest ath tag).

Older branches will not be maintained.

/Erik


Re: [PATCH v2] ath9k: do not return early to fix rcu unlocking

2016-12-14 Thread Felix Fietkau
On 2016-12-13 18:08, Tobias Klausmann wrote:
> Starting with commit d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb
> where possible") the driver uses rcu_read_lock() && rcu_read_unlock(), yet on
> returning early in ath_tx_edma_tasklet() the unlock is missing leading to 
> stalls
> and suspicious RCU usage:
> 
>  ===
>  [ INFO: suspicious RCU usage. ]
>  4.9.0-rc8 #11 Not tainted
>  ---
>  kernel/rcu/tree.c:705 Illegal idle entry in RCU read-side critical section.!
> 
>  other info that might help us debug this:
> 
>  RCU used illegally from idle CPU!
>  rcu_scheduler_active = 1, debug_locks = 0
>  RCU used illegally from extended quiescent state!
>  1 lock held by swapper/7/0:
>  #0:
>   (
>  rcu_read_lock
>  ){..}
>  , at:
>  [] ath_tx_edma_tasklet+0x0/0x450 [ath9k]
> 
>  stack backtrace:
>  CPU: 7 PID: 0 Comm: swapper/7 Not tainted 4.9.0-rc8 #11
>  Hardware name: Acer Aspire V3-571G/VA50_HC_CR, BIOS V2.21 12/16/2013
>   88025efc3f38 8132b1e5 88017ede4540 0001
>   88025efc3f68 810a25f7 88025efcee60 88017edebdd8
>   88025eeb5400 0091 88025efc3f88 810c3cd4
>  Call Trace:
>   
>   [] dump_stack+0x68/0x93
>   [] lockdep_rcu_suspicious+0xd7/0x110
>   [] rcu_eqs_enter_common.constprop.85+0x154/0x200
>   [] rcu_irq_exit+0x44/0xa0
>   [] irq_exit+0x61/0xd0
>   [] do_IRQ+0x65/0x110
>   [] common_interrupt+0x89/0x89
>   
>   [] ? cpuidle_enter_state+0x151/0x200
>   [] cpuidle_enter+0x12/0x20
>   [] call_cpuidle+0x1e/0x40
>   [] cpu_startup_entry+0x146/0x220
>   [] start_secondary+0x148/0x170
> 
> Signed-off-by: Tobias Klausmann 
> Fixes: d94a461d7a7d ("ath9k: use ieee80211_tx_status_noskb where possible")
> Cc:  # v4.9
Acked-by: Felix Fietkau 



Re: ath10k firmware sends probes on DFS channels without radar detection

2016-12-14 Thread Jouni Malinen
On Tue, Dec 06, 2016 at 06:02:52PM +0100, Jean-Pierre Tosoni wrote:
> This follows on the previous discussion
>   "Client station sends probes on DFS channels"
> 
> Problem:
> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> wpa_supplicant do not comply with the norm ETSI/EN 301-893
> section 4.7; because they can send probes for 600s when no
> AP is around.
> 
> Analysis:
> The problem seems to lie in the firmware, which regards the presence
> of *any* beacon as a proof that the channel is radar-clean for 600s.

I don't think this is really firmware, but cfg80211 regulatory code and
how it interacts with ath10k..

> - there is no obvious fix working in ath10k.
> - the issue does not show up with other mac80211 devices like ath9k.
> - wpa_supplicant considers this is a kernel issue [2]

There seems to be a difference between ath9k (mac80211-based Probe
Request frame sending) and ath10k (firmware) in this area for active
scanning. mac80211 uses IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_RADAR
while ath10k uses IEEE80211_CHAN_NO_IR. I'd assume this difference
results in ath10k using cfg80211 beacon hints (etc.) to update the NO_IR
flag and that might be behind the difference you see.

Could you check whether the following change gets you the behavior you
want to see here? I have not had a chance to test this yet, but based on
code review, it looks like something that brings the same behavior to
ath10k that ath9k has for this through mac80211.


diff --git a/drivers/net/wireless/ath/ath10k/mac.c 
b/drivers/net/wireless/ath/ath10k/mac.c
index aa545a1..758dbbd 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2973,7 +2973,8 @@ static int ath10k_update_channel_list(struct ath10k *ar)
ch->chan_radar =
!!(channel->flags & IEEE80211_CHAN_RADAR);
 
-   passive = channel->flags & IEEE80211_CHAN_NO_IR;
+   passive = channel->flags & (IEEE80211_CHAN_NO_IR |
+   IEEE80211_CHAN_RADAR);
ch->passive = passive;
 
ch->freq = channel->center_freq;

-- 
Jouni MalinenPGP id EFC895FA


[PATCH 01/10] mac80211: minstrel_ht: move supported bitrate mask out of group data

2016-12-14 Thread Felix Fietkau
Improves dcache footprint by ensuring that fewer cache lines need to be
touched.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel_ht.c | 30 +++---
 net/mac80211/rc80211_minstrel_ht.h |  6 +++---
 net/mac80211/rc80211_minstrel_ht_debugfs.c |  8 
 3 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel_ht.c 
b/net/mac80211/rc80211_minstrel_ht.c
index 30fbabf..ed8a34d 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -301,7 +301,7 @@ minstrel_ht_get_stats(struct minstrel_priv *mp, struct 
minstrel_ht_sta *mi,
break;
 
/* short preamble */
-   if (!(mi->groups[group].supported & BIT(idx)))
+   if (!(mi->supported[group] & BIT(idx)))
idx += 4;
}
return >groups[group].rates[idx];
@@ -486,7 +486,7 @@ minstrel_ht_prob_rate_reduce_streams(struct minstrel_ht_sta 
*mi)
  MCS_GROUP_RATES].streams;
for (group = 0; group < ARRAY_SIZE(minstrel_mcs_groups); group++) {
mg = >groups[group];
-   if (!mg->supported || group == MINSTREL_CCK_GROUP)
+   if (!mi->supported[group] || group == MINSTREL_CCK_GROUP)
continue;
 
tmp_idx = mg->max_group_prob_rate % MCS_GROUP_RATES;
@@ -540,7 +540,7 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, struct 
minstrel_ht_sta *mi)
for (group = 0; group < ARRAY_SIZE(minstrel_mcs_groups); group++) {
 
mg = >groups[group];
-   if (!mg->supported)
+   if (!mi->supported[group])
continue;
 
mi->sample_count++;
@@ -550,7 +550,7 @@ minstrel_ht_update_stats(struct minstrel_priv *mp, struct 
minstrel_ht_sta *mi)
tmp_group_tp_rate[j] = group;
 
for (i = 0; i < MCS_GROUP_RATES; i++) {
-   if (!(mg->supported & BIT(i)))
+   if (!(mi->supported[group] & BIT(i)))
continue;
 
index = MCS_GROUP_RATES * group + i;
@@ -636,7 +636,7 @@ minstrel_set_next_sample_idx(struct minstrel_ht_sta *mi)
mi->sample_group %= ARRAY_SIZE(minstrel_mcs_groups);
mg = >groups[mi->sample_group];
 
-   if (!mg->supported)
+   if (!mi->supported[mi->sample_group])
continue;
 
if (++mg->index >= MCS_GROUP_RATES) {
@@ -657,7 +657,7 @@ minstrel_downgrade_rate(struct minstrel_ht_sta *mi, u16 
*idx, bool primary)
while (group > 0) {
group--;
 
-   if (!mi->groups[group].supported)
+   if (!mi->supported[group])
continue;
 
if (minstrel_mcs_groups[group].streams >
@@ -994,7 +994,7 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, struct 
minstrel_ht_sta *mi)
sample_idx = sample_table[mg->column][mg->index];
minstrel_set_next_sample_idx(mi);
 
-   if (!(mg->supported & BIT(sample_idx)))
+   if (!(mi->supported[sample_group] & BIT(sample_idx)))
return -1;
 
mrs = >rates[sample_idx];
@@ -1052,7 +1052,7 @@ static void
 minstrel_ht_check_cck_shortpreamble(struct minstrel_priv *mp,
struct minstrel_ht_sta *mi, bool val)
 {
-   u8 supported = mi->groups[MINSTREL_CCK_GROUP].supported;
+   u8 supported = mi->supported[MINSTREL_CCK_GROUP];
 
if (!supported || !mi->cck_supported_short)
return;
@@ -1061,7 +1061,7 @@ minstrel_ht_check_cck_shortpreamble(struct minstrel_priv 
*mp,
return;
 
supported ^= mi->cck_supported_short | (mi->cck_supported_short << 4);
-   mi->groups[MINSTREL_CCK_GROUP].supported = supported;
+   mi->supported[MINSTREL_CCK_GROUP] = supported;
 }
 
 static void
@@ -1154,7 +1154,7 @@ minstrel_ht_update_cck(struct minstrel_priv *mp, struct 
minstrel_ht_sta *mi,
mi->cck_supported_short |= BIT(i);
}
 
-   mi->groups[MINSTREL_CCK_GROUP].supported = mi->cck_supported;
+   mi->supported[MINSTREL_CCK_GROUP] = mi->cck_supported;
 }
 
 static void
@@ -1224,7 +1224,7 @@ minstrel_ht_update_caps(void *priv, struct 
ieee80211_supported_band *sband,
u32 gflags = minstrel_mcs_groups[i].flags;
int bw, nss;
 
-   mi->groups[i].supported = 0;
+   mi->supported[i] = 0;
if (i == MINSTREL_CCK_GROUP) {
minstrel_ht_update_cck(mp, mi, sband, sta);
continue;
@@ -1256,8 +1256,8 @@ minstrel_ht_update_caps(void *priv, struct 
ieee80211_supported_band *sband,
if (use_vht && minstrel_vht_only)
continue;
 #endif
-  

[PATCH 02/10] mac80211: minstrel_ht: move short preamble check out of get_rate

2016-12-14 Thread Felix Fietkau
Test short preamble support in minstrel_ht_update_caps instead of
looking at the per-packet flag. Makes the code more efficient.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel_ht.c | 22 +-
 1 file changed, 5 insertions(+), 17 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel_ht.c 
b/net/mac80211/rc80211_minstrel_ht.c
index ed8a34d..ae45dcb 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include "rate.h"
+#include "sta_info.h"
 #include "rc80211_minstrel.h"
 #include "rc80211_minstrel_ht.h"
 
@@ -1049,22 +1050,6 @@ minstrel_get_sample_rate(struct minstrel_priv *mp, 
struct minstrel_ht_sta *mi)
 }
 
 static void
-minstrel_ht_check_cck_shortpreamble(struct minstrel_priv *mp,
-   struct minstrel_ht_sta *mi, bool val)
-{
-   u8 supported = mi->supported[MINSTREL_CCK_GROUP];
-
-   if (!supported || !mi->cck_supported_short)
-   return;
-
-   if (supported & (mi->cck_supported_short << (val * 4)))
-   return;
-
-   supported ^= mi->cck_supported_short | (mi->cck_supported_short << 4);
-   mi->supported[MINSTREL_CCK_GROUP] = supported;
-}
-
-static void
 minstrel_ht_get_rate(void *priv, struct ieee80211_sta *sta, void *priv_sta,
  struct ieee80211_tx_rate_control *txrc)
 {
@@ -1087,7 +1072,6 @@ minstrel_ht_get_rate(void *priv, struct ieee80211_sta 
*sta, void *priv_sta,
minstrel_aggr_check(sta, txrc->skb);
 
info->flags |= mi->tx_flags;
-   minstrel_ht_check_cck_shortpreamble(mp, mi, txrc->short_preamble);
 
 #ifdef CONFIG_MAC80211_DEBUGFS
if (mp->fixed_rate_idx != -1)
@@ -1168,6 +1152,7 @@ minstrel_ht_update_caps(void *priv, struct 
ieee80211_supported_band *sband,
struct ieee80211_mcs_info *mcs = >ht_cap.mcs;
u16 sta_cap = sta->ht_cap.cap;
struct ieee80211_sta_vht_cap *vht_cap = >vht_cap;
+   struct sta_info *sinfo = container_of(sta, struct sta_info, sta);
int use_vht;
int n_supported = 0;
int ack_dur;
@@ -1293,6 +1278,9 @@ minstrel_ht_update_caps(void *priv, struct 
ieee80211_supported_band *sband,
if (!n_supported)
goto use_legacy;
 
+   if (test_sta_flag(sinfo, WLAN_STA_SHORT_PREAMBLE))
+   mi->cck_supported_short |= mi->cck_supported_short << 4;
+
/* create an initial rate table with the lowest supported rates */
minstrel_ht_update_stats(mp, mi);
minstrel_ht_update_rates(mp, mi);
-- 
2.10.1



[PATCH 03/10] mac80211: minstrel_ht: make att_hist and succ_hist u32 instead of u64

2016-12-14 Thread Felix Fietkau
They are only used for debugging purposes and take a very long time to
overflow. Visibly reduces the size of the per-sta rate control data.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index c230bbe..209961c 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -59,7 +59,7 @@ struct minstrel_rate_stats {
u16 success, last_success;
 
/* total attempts/success counters */
-   u64 att_hist, succ_hist;
+   u32 att_hist, succ_hist;
 
/* statistis of packet delivery probability
 *  cur_prob  - current prob within last update intervall
-- 
2.10.1



[PATCH 08/10] mac80211: minstrel: make prob_ewma u16 instead of u32

2016-12-14 Thread Felix Fietkau
Saves about 1.2 KiB memory per station

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index ea86e67..be6c3f3 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -59,7 +59,7 @@ struct minstrel_rate_stats {
/* statistis of packet delivery probability
 *  prob_ewma - exponential weighted moving average of prob
 *  prob_ewmsd - exp. weighted moving standard deviation of prob */
-   unsigned int prob_ewma;
+   u16 prob_ewma;
u16 prob_ewmv;
 
/* maximum retry counts */
-- 
2.10.1



[PATCH 10/10] mac80211: minstrel: avoid port control frames for sampling

2016-12-14 Thread Felix Fietkau
From: Thomas Huehn 

Makes connections more reliable

Signed-off-by: Thomas Huehn 
Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index 11a4cc3..3ebe440 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -367,6 +367,11 @@ minstrel_get_rate(void *priv, struct ieee80211_sta *sta,
return;
 #endif
 
+   /* Don't use EAPOL frames for sampling on non-mrr hw */
+   if (mp->hw->max_rates == 1 &&
+   (info->control.flags & IEEE80211_TX_CTRL_PORT_CTRL_PROTO))
+   return;
+
delta = (mi->total_packets * sampling_ratio / 100) -
(mi->sample_packets + mi->sample_deferred / 2);
 
-- 
2.10.1



[PATCH 06/10] mac80211: minstrel: reduce MINSTREL_SCALE

2016-12-14 Thread Felix Fietkau
The loss of a bit of extra precision does not hurt the calculation, 12
bits is still enough to calculate probabilities well. Reducing the scale
makes it easier to avoid overflows

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index 94b89b1..03716fd 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -14,7 +14,7 @@
 #define SAMPLE_COLUMNS 10  /* number of columns in sample table */
 
 /* scaled fraction values */
-#define MINSTREL_SCALE  16
+#define MINSTREL_SCALE  12
 #define MINSTREL_FRAC(val, div) (((val) << MINSTREL_SCALE) / div)
 #define MINSTREL_TRUNC(val) ((val) >> MINSTREL_SCALE)
 
-- 
2.10.1



[PATCH 04/10] mac80211: check for MCS in ieee80211_duration before fetching chanctx

2016-12-14 Thread Felix Fietkau
Makes the code a bit more efficient

Signed-off-by: Felix Fietkau 
---
 net/mac80211/tx.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 058652d..4dea18b 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -64,6 +64,10 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data 
*tx,
struct ieee80211_chanctx_conf *chanctx_conf;
u32 rate_flags = 0;
 
+   /* assume HW handles this */
+   if (tx->rate.flags & (IEEE80211_TX_RC_MCS | IEEE80211_TX_RC_VHT_MCS))
+   return 0;
+
rcu_read_lock();
chanctx_conf = rcu_dereference(tx->sdata->vif.chanctx_conf);
if (chanctx_conf) {
@@ -72,10 +76,6 @@ static __le16 ieee80211_duration(struct ieee80211_tx_data 
*tx,
}
rcu_read_unlock();
 
-   /* assume HW handles this */
-   if (tx->rate.flags & (IEEE80211_TX_RC_MCS | IEEE80211_TX_RC_VHT_MCS))
-   return 0;
-
/* uh huh? */
if (WARN_ON_ONCE(tx->rate.idx < 0))
return 0;
-- 
2.10.1



[PATCH 05/10] mac80211: minstrel: remove cur_prob from debugfs

2016-12-14 Thread Felix Fietkau
This field is redundant, because it is simply last success divided by
last attempt count. Removing it from the rate stats struct saves about
1.2 KiB per HT station.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.c| 10 ++
 net/mac80211/rc80211_minstrel.h|  2 --
 net/mac80211/rc80211_minstrel_debugfs.c| 16 ++--
 net/mac80211/rc80211_minstrel_ht_debugfs.c | 16 ++--
 4 files changed, 18 insertions(+), 26 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index 14c5ba3..a284ea0 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -159,21 +159,23 @@ minstrel_update_rates(struct minstrel_priv *mp, struct 
minstrel_sta_info *mi)
 void
 minstrel_calc_rate_stats(struct minstrel_rate_stats *mrs)
 {
+   unsigned int cur_prob;
+
if (unlikely(mrs->attempts > 0)) {
mrs->sample_skipped = 0;
-   mrs->cur_prob = MINSTREL_FRAC(mrs->success, mrs->attempts);
+   cur_prob = MINSTREL_FRAC(mrs->success, mrs->attempts);
if (unlikely(!mrs->att_hist)) {
-   mrs->prob_ewma = mrs->cur_prob;
+   mrs->prob_ewma = cur_prob;
} else {
/* update exponential weighted moving variance */
mrs->prob_ewmsd = minstrel_ewmsd(mrs->prob_ewmsd,
-mrs->cur_prob,
+cur_prob,
 mrs->prob_ewma,
 EWMA_LEVEL);
 
/*update exponential weighted moving avarage */
mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
-  mrs->cur_prob,
+  cur_prob,
   EWMA_LEVEL);
}
mrs->att_hist += mrs->attempts;
diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index 209961c..94b89b1 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -62,10 +62,8 @@ struct minstrel_rate_stats {
u32 att_hist, succ_hist;
 
/* statistis of packet delivery probability
-*  cur_prob  - current prob within last update intervall
 *  prob_ewma - exponential weighted moving average of prob
 *  prob_ewmsd - exp. weighted moving standard deviation of prob */
-   unsigned int cur_prob;
unsigned int prob_ewma;
u16 prob_ewmsd;
 
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c 
b/net/mac80211/rc80211_minstrel_debugfs.c
index 820b0ab..ca0bafd 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -75,7 +75,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
 {
struct minstrel_sta_info *mi = inode->i_private;
struct minstrel_debugfs_info *ms;
-   unsigned int i, tp_max, tp_avg, prob, eprob;
+   unsigned int i, tp_max, tp_avg, eprob;
char *p;
 
ms = kmalloc(2048, GFP_KERNEL);
@@ -86,9 +86,9 @@ minstrel_stats_open(struct inode *inode, struct file *file)
p = ms->buf;
p += sprintf(p, "\n");
p += sprintf(p,
-"best   __rate_
statisticslast_____sum-of\n");
+"best   __rate_
statisticslast___sum-of\n");
p += sprintf(p,
-"rate  [name idx airtime max_tp]  [avg(tp) avg(prob) 
sd(prob)]  [prob.|retry|suc|att]  [#success | #attempts]\n");
+"rate  [name idx airtime max_tp]  [avg(tp) avg(prob) 
sd(prob)]  [retry|suc|att]  [#success | #attempts]\n");
 
for (i = 0; i < mi->n_rates; i++) {
struct minstrel_rate *mr = >r[i];
@@ -107,17 +107,15 @@ minstrel_stats_open(struct inode *inode, struct file 
*file)
 
tp_max = minstrel_get_tp_avg(mr, MINSTREL_FRAC(100,100));
tp_avg = minstrel_get_tp_avg(mr, mrs->prob_ewma);
-   prob = MINSTREL_TRUNC(mrs->cur_prob * 1000);
eprob = MINSTREL_TRUNC(mrs->prob_ewma * 1000);
 
p += sprintf(p, "%4u.%1u%4u.%1u %3u.%1u%3u.%1u"
-   " %3u.%1u %3u   %3u %-3u   "
+   " %3u   %3u %-3u   "
"%9llu   %-9llu\n",
tp_max / 10, tp_max % 10,
tp_avg / 10, tp_avg % 10,
eprob / 10, eprob % 10,
mrs->prob_ewmsd / 10, mrs->prob_ewmsd % 10,
-   

[PATCH 07/10] mac80211: minstrel: store probability variance instead of standard deviation

2016-12-14 Thread Felix Fietkau
This avoids the costly int_sqrt calls in the statistics update and moves
it to the debugfs code instead.
This also fixes an overflow in the previous standard deviation
calculation.

Signed-off-by: Thomas Huehn 
Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel.c|  8 
 net/mac80211/rc80211_minstrel.h| 25 ++---
 net/mac80211/rc80211_minstrel_debugfs.c|  8 ++--
 net/mac80211/rc80211_minstrel_ht_debugfs.c |  8 ++--
 4 files changed, 30 insertions(+), 19 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel.c b/net/mac80211/rc80211_minstrel.c
index a284ea0..11a4cc3 100644
--- a/net/mac80211/rc80211_minstrel.c
+++ b/net/mac80211/rc80211_minstrel.c
@@ -168,10 +168,10 @@ minstrel_calc_rate_stats(struct minstrel_rate_stats *mrs)
mrs->prob_ewma = cur_prob;
} else {
/* update exponential weighted moving variance */
-   mrs->prob_ewmsd = minstrel_ewmsd(mrs->prob_ewmsd,
-cur_prob,
-mrs->prob_ewma,
-EWMA_LEVEL);
+   mrs->prob_ewmv = minstrel_ewmv(mrs->prob_ewmv,
+   cur_prob,
+   mrs->prob_ewma,
+   EWMA_LEVEL);
 
/*update exponential weighted moving avarage */
mrs->prob_ewma = minstrel_ewma(mrs->prob_ewma,
diff --git a/net/mac80211/rc80211_minstrel.h b/net/mac80211/rc80211_minstrel.h
index 03716fd..ea86e67 100644
--- a/net/mac80211/rc80211_minstrel.h
+++ b/net/mac80211/rc80211_minstrel.h
@@ -36,21 +36,16 @@ minstrel_ewma(int old, int new, int weight)
 }
 
 /*
- * Perform EWMSD (Exponentially Weighted Moving Standard Deviation) calculation
+ * Perform EWMV (Exponentially Weighted Moving Variance) calculation
  */
 static inline int
-minstrel_ewmsd(int old_ewmsd, int cur_prob, int prob_ewma, int weight)
+minstrel_ewmv(int old_ewmv, int cur_prob, int prob_ewma, int weight)
 {
-   int diff, incr, tmp_var;
+   int diff, incr;
 
-   /* calculate exponential weighted moving variance */
-   diff = MINSTREL_TRUNC((cur_prob - prob_ewma) * 100);
+   diff = cur_prob - prob_ewma;
incr = (EWMA_DIV - weight) * diff / EWMA_DIV;
-   tmp_var = old_ewmsd * old_ewmsd;
-   tmp_var = weight * (tmp_var + diff * incr / 100) / EWMA_DIV;
-
-   /* return standard deviation */
-   return (u16) int_sqrt(tmp_var);
+   return weight * (old_ewmv + MINSTREL_TRUNC(diff * incr)) / EWMA_DIV;
 }
 
 struct minstrel_rate_stats {
@@ -65,7 +60,7 @@ struct minstrel_rate_stats {
 *  prob_ewma - exponential weighted moving average of prob
 *  prob_ewmsd - exp. weighted moving standard deviation of prob */
unsigned int prob_ewma;
-   u16 prob_ewmsd;
+   u16 prob_ewmv;
 
/* maximum retry counts */
u8 retry_count;
@@ -151,6 +146,14 @@ struct minstrel_debugfs_info {
char buf[];
 };
 
+/* Get EWMSD (Exponentially Weighted Moving Standard Deviation) * 10 */
+static inline int
+minstrel_get_ewmsd10(struct minstrel_rate_stats *mrs)
+{
+   unsigned int ewmv = mrs->prob_ewmv;
+   return int_sqrt(MINSTREL_TRUNC(ewmv * 1000 * 1000));
+}
+
 extern const struct rate_control_ops mac80211_minstrel;
 void minstrel_add_sta_debugfs(void *priv, void *priv_sta, struct dentry *dir);
 void minstrel_remove_sta_debugfs(void *priv, void *priv_sta);
diff --git a/net/mac80211/rc80211_minstrel_debugfs.c 
b/net/mac80211/rc80211_minstrel_debugfs.c
index ca0bafd..36fc971 100644
--- a/net/mac80211/rc80211_minstrel_debugfs.c
+++ b/net/mac80211/rc80211_minstrel_debugfs.c
@@ -93,6 +93,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
for (i = 0; i < mi->n_rates; i++) {
struct minstrel_rate *mr = >r[i];
struct minstrel_rate_stats *mrs = >r[i].stats;
+   unsigned int prob_ewmsd;
 
*(p++) = (i == mi->max_tp_rate[0]) ? 'A' : ' ';
*(p++) = (i == mi->max_tp_rate[1]) ? 'B' : ' ';
@@ -108,6 +109,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
tp_max = minstrel_get_tp_avg(mr, MINSTREL_FRAC(100,100));
tp_avg = minstrel_get_tp_avg(mr, mrs->prob_ewma);
eprob = MINSTREL_TRUNC(mrs->prob_ewma * 1000);
+   prob_ewmsd = minstrel_get_ewmsd10(mrs);
 
p += sprintf(p, "%4u.%1u%4u.%1u %3u.%1u%3u.%1u"
" %3u   %3u %-3u   "
@@ -115,7 +117,7 @@ minstrel_stats_open(struct inode *inode, struct file *file)
tp_max / 10, tp_max % 10,

[PATCH 09/10] mac80211: minstrel_ht: remove obsolete #if for >= 3 streams

2016-12-14 Thread Felix Fietkau
This was added during early development when 3x3 hardware was not very
common yet. This is completely unnecessary now.

Signed-off-by: Felix Fietkau 
---
 net/mac80211/rc80211_minstrel_ht.c | 20 
 1 file changed, 20 deletions(-)

diff --git a/net/mac80211/rc80211_minstrel_ht.c 
b/net/mac80211/rc80211_minstrel_ht.c
index ae45dcb..8e783e1 100644
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -155,67 +155,47 @@ MODULE_PARM_DESC(minstrel_vht_only,
 const struct mcs_group minstrel_mcs_groups[] = {
MCS_GROUP(1, 0, BW_20),
MCS_GROUP(2, 0, BW_20),
-#if MINSTREL_MAX_STREAMS >= 3
MCS_GROUP(3, 0, BW_20),
-#endif
 
MCS_GROUP(1, 1, BW_20),
MCS_GROUP(2, 1, BW_20),
-#if MINSTREL_MAX_STREAMS >= 3
MCS_GROUP(3, 1, BW_20),
-#endif
 
MCS_GROUP(1, 0, BW_40),
MCS_GROUP(2, 0, BW_40),
-#if MINSTREL_MAX_STREAMS >= 3
MCS_GROUP(3, 0, BW_40),
-#endif
 
MCS_GROUP(1, 1, BW_40),
MCS_GROUP(2, 1, BW_40),
-#if MINSTREL_MAX_STREAMS >= 3
MCS_GROUP(3, 1, BW_40),
-#endif
 
CCK_GROUP,
 
 #ifdef CONFIG_MAC80211_RC_MINSTREL_VHT
VHT_GROUP(1, 0, BW_20),
VHT_GROUP(2, 0, BW_20),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 0, BW_20),
-#endif
 
VHT_GROUP(1, 1, BW_20),
VHT_GROUP(2, 1, BW_20),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 1, BW_20),
-#endif
 
VHT_GROUP(1, 0, BW_40),
VHT_GROUP(2, 0, BW_40),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 0, BW_40),
-#endif
 
VHT_GROUP(1, 1, BW_40),
VHT_GROUP(2, 1, BW_40),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 1, BW_40),
-#endif
 
VHT_GROUP(1, 0, BW_80),
VHT_GROUP(2, 0, BW_80),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 0, BW_80),
-#endif
 
VHT_GROUP(1, 1, BW_80),
VHT_GROUP(2, 1, BW_80),
-#if MINSTREL_MAX_STREAMS >= 3
VHT_GROUP(3, 1, BW_80),
 #endif
-#endif
 };
 
 static u8 sample_table[SAMPLE_COLUMNS][MCS_GROUP_RATES] __read_mostly;
-- 
2.10.1



[PATCH v2] mac80211: fix legacy and invalid rx-rate rpt

2016-12-14 Thread greearb
From: Ben Greear 

This fixes obtaining the rate info via sta_set_sinfo
when the rx rate is invalid (for instance, on IBSS
interface that has received no frames from one of its
peers).

This also fixes a more general issue with rinfo->flags
not being properly initialized for legacy rates.

Signed-off-by: Ben Greear 
---

Patch is against 4.7

 net/mac80211/sta_info.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 01868f9..6d27813e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2057,6 +2057,7 @@ static void sta_stats_decode_rate(struct ieee80211_local 
*local, u16 rate,
u16 brate;
unsigned int shift;
 
+   rinfo->flags = 0;
sband = local->hw.wiphy->bands[(rate >> 4) & 0xf];
brate = sband->bitrates[rate & 0xf].bitrate;
if (rinfo->bw == RATE_INFO_BW_5)
@@ -2072,14 +2073,15 @@ static void sta_stats_decode_rate(struct 
ieee80211_local *local, u16 rate,
rinfo->flags |= RATE_INFO_FLAGS_SHORT_GI;
 }
 
-static void sta_set_rate_info_rx(struct sta_info *sta, struct rate_info *rinfo)
+static int sta_set_rate_info_rx(struct sta_info *sta, struct rate_info *rinfo)
 {
u16 rate = ACCESS_ONCE(sta_get_last_rx_stats(sta)->last_rate);
-
-   if (rate == STA_STATS_RATE_INVALID)
-   rinfo->flags = 0;
-   else
+   if (rate == STA_STATS_RATE_INVALID) {
+   return -EINVAL;
+   } else {
sta_stats_decode_rate(sta->local, rate, rinfo);
+   return 0;
+   }
 }
 
 static void sta_set_tidstats(struct sta_info *sta,
@@ -2284,8 +2286,8 @@ void sta_set_sinfo(struct sta_info *sta, struct 
station_info *sinfo)
}
 
if (!(sinfo->filled & BIT(NL80211_STA_INFO_RX_BITRATE))) {
-   sta_set_rate_info_rx(sta, >rxrate);
-   sinfo->filled |= BIT(NL80211_STA_INFO_RX_BITRATE);
+   if (sta_set_rate_info_rx(sta, >rxrate) == 0)
+   sinfo->filled |= BIT(NL80211_STA_INFO_RX_BITRATE);
}
 
sinfo->filled |= BIT(NL80211_STA_INFO_TID_STATS);
-- 
2.4.11



RE: ath10k firmware sends probes on DFS channels without radar detection

2016-12-14 Thread Jean-Pierre Tosoni
On 12/06/15 08:36 PM, Ben Greear wrote: 
> On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
> > This follows on the previous discussion
> > "Client station sends probes on DFS channels"
> >
> > Problem:
> > The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> > wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
> > 4.7; because they can send probes for 600s when no AP is around.
> >
> > Analysis:
> > The problem seems to lie in the firmware, which regards the presence
> > of *any* beacon as a proof that the channel is radar-clean for 600s.
> >
> > This is a wrong hypothesis, since a rogue AP sending fraudulent
> > beacons should not induce a scrupulous STA in sending illegal probes.
> >
> > Moreover, the norm (table D.1) sets a time limit of 10s to shutdown
> > when no AP positively allows the STA to transmit on the DFS channel.
> >
> > Status:
> > - there is no known plan at QCA to fix the issue.
> > - ath10k firmware is not publicly available for fixes.
> > - there is no obvious fix working in ath10k.
> > - the issue does not show up with other mac80211 devices like ath9k.
> > - wpa_supplicant considers this is a kernel issue [2]
> 
> Have you confirmed that there are no probe requests being sent by ath10k
> driver?

I have put a printk in the ath10k_tx function (in the path for management
frames) and it does not show up.
On another hand I cannot find any other function preparing / sending probes.
There is only the wmi command that starts scans.

> 
> You could also try disabling the station keep-alive and roaming logic in
> the firmware by tweaking the wmi initial setup logic.  I disable that in
> my firmware, for instance, because mac80211 can do a better job and then I
> can save resources in the firmware.

Do you mean the values set in wmi.c:: ath10k_wmi_start_scan_init() ?

Should I replace all the scan offload by a mac80211-controlled scan like
in ath9k? The problem then is to switch channels; channel switching
seems very different from ath9k.

Thanks,
JP

> Finally, if that doesn't work, then I could probably fix that in CT
> firmware in case that is of interest.
> 
> Thanks,
> Ben
> 
> >
> > Jean-Pierre Tosoni
> >
> >
> >
> >> -Message d'origine-
> >> De : ath10k [mailto:ath10k-boun...@lists.infradead.org] De la part de
> >> Jean-Pierre Tosoni Envoyé : mercredi 30 novembre 2016 19:04 À :
> >> ath...@lists.infradead.org Objet : Client station sends probes on DFS
> >> channels
> >>
> >> Hello list,
> >>
> >> There is a case where I can see probes on a DFS channel, from a non-
> >> associated station using ath10k. (note that the problem does not
> >> arise when using ath9k).
> >>
> >> *The setup*
> >>
> >> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
> >> Card firmware is   ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
> >>fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
> >>cal otp max-sta 128 features no-p2p
> >>ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
> >>
> >> I am using channel 116, regdom US or FR, where I see no traffic at
> >> all using wireshark+Airpcap.
> >> I set wpa_supplicant to scan this channel only for a specific SSID
> >> "ssid1".
> >>
> >> At initial startup of the client device, no probes are going out,
> >> which is OK.
> >>
> >> Then, on another device, I start a hostapd set to channel 116, with a
> >> different SSID "otherssid" so that the supplicant will not associate.
> >>
> >> Shortly (1-2s) after the beacons appear in the air, the client begins
> >> to Send probe request in the air, which is unexpected, but acceptable
> >> since the client can infer absence of radars from the presence of
> beacons.
> >>
> >> *The problem*
> >>
> >> If I power down the AP, the client continues to send probes for
> >> around
> >> 10 minutes, which is unacceptable since it cannot handle radar
> >> detection, as it is a slave device in the meaning of ETSI/EN 301-
> 893[1].
> >>
> >>
> >> Some tests I made:
> >> - I tried to investigate the "beacon hint" mechanism but it appears
> >>   that it is not used on DFS channels.
> >>
> >> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
> >>   is set.
> >>
> >> - When I reload the reg. domain using "iw reg set", the probes cease,
> >>   but will reappear if I cycle my AP again On then Off.
> >>
> >> - When I let the client associate, then disassociate and stop the AP,
> >>   the same problem arises. It disappears if I add a call to
> >>   ath10k_regd_update() in mac.c after a disconnection (This is not a
> >>   fix, since in my case the client never associates).
> >>
> >> - Since at startup, the client does not send probes, I infer that the
> >>   problem is *not* caused by a hidden AP that the card could see but
> >>   not airpcap.
> >>
> >> - I tried with channels 52 and 100, with regdom FR or US: same problem.
> >>
> >> Any ideas?
> >>
> >>
> >> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
> >> 

Re: [Patch] NFC: trf7970a:

2016-12-14 Thread Geoff Lansberry
On Wed, Dec 14, 2016 at 12:10 PM, Mark Greer  wrote:
> On Wed, Dec 14, 2016 at 11:17:33AM -0500, Geoff Lansberry wrote:
>> On Wed, Dec 14, 2016 at 10:57 AM, Mark Greer  wrote:
>> >
>> > On Tue, Dec 13, 2016 at 08:50:04PM -0500, Geoff Lansberry wrote:
>> > > Hi Mark -  Thanks for getting back to me.   It's funny that you ask,
>> > > because we are currently chasing a segfault that is happening in neard, 
>> > > but
>> > > may end up back in the trf7970a driver.   Have you ever heard on anyone
>> > > having segfault problems related to the trf7970a hardware drivers?
>> >
>> > No.  Mind sharing more info on that segfault?
>> >
>> > > I'll get you an update later tonight or tomorrow.
>> >
>> > Okay, thanks.
>> >
>> > Mark
>> > --
>>
>> Mark - The segfault issue is only happening on writing, The work on
>> the segfault is being done by a consultant, but here is his statement
>> on how to recreate it on our build:
>>
>> I am able to reliably force neard to segfault by flooding it with
>> write requests. I have attached a python script called flood.py that
>> can be used to do this. The script uses utilities that ship with
>> neard.
>>
>> The segfault does not appear deterministic. It usually happens within
>> 1000 writes, but the time can varying greatly. The logs output from
>> neard are inconsistent between crashes, which suggests this may be a
>> timing or race condition related issue.
>>
>> I have been running neard manually to obtain the log information and a
>> core file for debugging (attached). I run neard as,
>>
>>   $ /usr/lib/neard/nfc/neard -d -n
>>
>> In a separate terminal I run,
>>
>>   $ python flood.py
>>
>> And the resulting core file provides the following backtrace,
>>
>> (gdb) bt
>> #0  0xb6caed64 in ?? ()
>> #1  0x0001ed7c in data_recv (resp=0x5bd90 "", length=17, data=0x58348)
>> at plugins/nfctype2.c:156
>> #2  0x00024ecc in execute_recv_cb (user_data=0x5bd88) at src/adapter.c:979
>> #3  0xb6e70d60 in ?? ()
>> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>> (gdb)
>>
>> The line at nfctype2.c:156 contains a memcpy operation.
>
> Thanks Geoff.
>
> What are the values of the arguments to memcpy()?
>
> I will look at it later today/tomorrow but if you have another NFC device
> to test with, it would help isolate whether it is neard or the trf7970a
> driver.  The driver shouldn't be able to make neard crash like this but
> who knows.
>
> You could also try testing older versions of neard to see if they also
> fail and if not, start bisecting from there.  Maybe test a different
> tag type too.
>
> Mark
> --
Mark - We can't seem to get gdb to run on our board, so we can't see
the exact arguments.  Here is what our consultant has to say about
your question:


The backtrace seems to indicate that the error is occurring in neard,
not the driver.

Since the driver is built as a module, your kernel won't crash if
there is a problem in it, but you should be told that the error is
originating in the module.

It is also possible that the NFC driver does have a non-fatal problem
in it (such as returning unexpected data) that is propagating to neard
and causing the error there.


Of course, it is also worth noting:

Backtrace stopped: previous frame identical to this frame (corrupt stack?)

and the same address appearing twice -- what I would assume to be your
memcpy address, since that is the last call made on a given source
line. If the stack is corrupt, then the error could very well
originate in the driver and not neard.


Re: ath10k firmware sends probes on DFS channels without radar detection

2016-12-14 Thread Ben Greear

On 12/14/2016 10:14 AM, Jean-Pierre Tosoni wrote:

On 12/06/15 08:36 PM, Ben Greear wrote:

On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:

This follows on the previous discussion
"Client station sends probes on DFS channels"

Problem:
The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
wpa_supplicant do not comply with the norm ETSI/EN 301-893 section
4.7; because they can send probes for 600s when no AP is around.

Analysis:
The problem seems to lie in the firmware, which regards the presence
of *any* beacon as a proof that the channel is radar-clean for 600s.

This is a wrong hypothesis, since a rogue AP sending fraudulent
beacons should not induce a scrupulous STA in sending illegal probes.

Moreover, the norm (table D.1) sets a time limit of 10s to shutdown
when no AP positively allows the STA to transmit on the DFS channel.

Status:
- there is no known plan at QCA to fix the issue.
- ath10k firmware is not publicly available for fixes.
- there is no obvious fix working in ath10k.
- the issue does not show up with other mac80211 devices like ath9k.
- wpa_supplicant considers this is a kernel issue [2]


Have you confirmed that there are no probe requests being sent by ath10k
driver?


I have put a printk in the ath10k_tx function (in the path for management
frames) and it does not show up.
On another hand I cannot find any other function preparing / sending probes.
There is only the wmi command that starts scans.


That wmi command causes probes, so make sure it is not being called.



You could also try disabling the station keep-alive and roaming logic in
the firmware by tweaking the wmi initial setup logic.  I disable that in
my firmware, for instance, because mac80211 can do a better job and then I
can save resources in the firmware.


Do you mean the values set in wmi.c:: ath10k_wmi_start_scan_init() ?

Should I replace all the scan offload by a mac80211-controlled scan like
in ath9k? The problem then is to switch channels; channel switching
seems very different from ath9k.


You might try one or more of these settings in the ath10k_wmi_10_1_op_gen_init
method (or 10.2 if that is the FW you are using):

config.roam_offload_max_vdev = 0; /* disable roaming */
config.roam_offload_max_ap_profiles = 0; /* disable roaming */
config.bmiss_offload_max_vdev = 0;

I have only tested this using my CT firmware, and I have some additional
patches in my driver to enable mac80211 keep-alive logic when using my
CT firmware.

Thanks,
Ben



Thanks,
JP


Finally, if that doesn't work, then I could probably fix that in CT
firmware in case that is of interest.

Thanks,
Ben



Jean-Pierre Tosoni




-Message d'origine-
De : ath10k [mailto:ath10k-boun...@lists.infradead.org] De la part de
Jean-Pierre Tosoni Envoyé : mercredi 30 novembre 2016 19:04 À :
ath...@lists.infradead.org Objet : Client station sends probes on DFS
channels

Hello list,

There is a case where I can see probes on a DFS channel, from a non-
associated station using ath10k. (note that the problem does not
arise when using ath9k).

*The setup*

I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
Card firmware isath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
cal otp max-sta 128 features no-p2p
ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1

I am using channel 116, regdom US or FR, where I see no traffic at
all using wireshark+Airpcap.
I set wpa_supplicant to scan this channel only for a specific SSID
"ssid1".

At initial startup of the client device, no probes are going out,
which is OK.

Then, on another device, I start a hostapd set to channel 116, with a
different SSID "otherssid" so that the supplicant will not associate.

Shortly (1-2s) after the beacons appear in the air, the client begins
to Send probe request in the air, which is unexpected, but acceptable
since the client can infer absence of radars from the presence of

beacons.


*The problem*

If I power down the AP, the client continues to send probes for
around
10 minutes, which is unacceptable since it cannot handle radar
detection, as it is a slave device in the meaning of ETSI/EN 301-

893[1].



Some tests I made:
- I tried to investigate the "beacon hint" mechanism but it appears
  that it is not used on DFS channels.

- I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
  is set.

- When I reload the reg. domain using "iw reg set", the probes cease,
  but will reappear if I cycle my AP again On then Off.

- When I let the client associate, then disassociate and stop the AP,
  the same problem arises. It disappears if I add a call to
  ath10k_regd_update() in mac.c after a disconnection (This is not a
  fix, since in my case the client never associates).

- Since at startup, the client does not send probes, I infer that the
  problem is *not* caused by a hidden AP that the card could see 

Re: [Patch] NFC: trf7970a:

2016-12-14 Thread Mark Greer
On Wed, Dec 14, 2016 at 11:17:33AM -0500, Geoff Lansberry wrote:
> On Wed, Dec 14, 2016 at 10:57 AM, Mark Greer  wrote:
> >
> > On Tue, Dec 13, 2016 at 08:50:04PM -0500, Geoff Lansberry wrote:
> > > Hi Mark -  Thanks for getting back to me.   It's funny that you ask,
> > > because we are currently chasing a segfault that is happening in neard, 
> > > but
> > > may end up back in the trf7970a driver.   Have you ever heard on anyone
> > > having segfault problems related to the trf7970a hardware drivers?
> >
> > No.  Mind sharing more info on that segfault?
> >
> > > I'll get you an update later tonight or tomorrow.
> >
> > Okay, thanks.
> >
> > Mark
> > --
> 
> Mark - The segfault issue is only happening on writing, The work on
> the segfault is being done by a consultant, but here is his statement
> on how to recreate it on our build:
> 
> I am able to reliably force neard to segfault by flooding it with
> write requests. I have attached a python script called flood.py that
> can be used to do this. The script uses utilities that ship with
> neard.
> 
> The segfault does not appear deterministic. It usually happens within
> 1000 writes, but the time can varying greatly. The logs output from
> neard are inconsistent between crashes, which suggests this may be a
> timing or race condition related issue.
> 
> I have been running neard manually to obtain the log information and a
> core file for debugging (attached). I run neard as,
> 
>   $ /usr/lib/neard/nfc/neard -d -n
> 
> In a separate terminal I run,
> 
>   $ python flood.py
> 
> And the resulting core file provides the following backtrace,
> 
> (gdb) bt
> #0  0xb6caed64 in ?? ()
> #1  0x0001ed7c in data_recv (resp=0x5bd90 "", length=17, data=0x58348)
> at plugins/nfctype2.c:156
> #2  0x00024ecc in execute_recv_cb (user_data=0x5bd88) at src/adapter.c:979
> #3  0xb6e70d60 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb)
> 
> The line at nfctype2.c:156 contains a memcpy operation.

Thanks Geoff.

What are the values of the arguments to memcpy()?

I will look at it later today/tomorrow but if you have another NFC device
to test with, it would help isolate whether it is neard or the trf7970a
driver.  The driver shouldn't be able to make neard crash like this but
who knows.

You could also try testing older versions of neard to see if they also
fail and if not, start bisecting from there.  Maybe test a different
tag type too.

Mark
--


Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics

2016-12-14 Thread Christian Lamparter
On Wednesday, December 14, 2016 1:03:38 PM CET Mohammed Shafi Shajakhan wrote:
> > On Wednesday, December 7, 2016 11:58:24 AM CET Mohammed Shafi Shajakhan 
> > wrote:
> > > On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> > > > @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k 
> > > > *ar, struct sk_buff *skb)
> > > > goto free;
> > > > }
> > > >  
> > > > +   if (!list_empty())
> > > 
> > > [shafi] sorry please correct me if i am wrong, for 'extended peer stats' 
> > > we are checking
> > > for normal 'peer stats' ? Is this the fix intended, i had started a build 
> > > to
> > > check your change and we will keep you posted, does this fix displaying
> > > 'rx_duration' in ath10k fw_stats.
> > The idea is not to queue any "extended peer stats" when there where no 
> > "peer stats" to
> > begin with. Because otherwise, the function is still vulnerable to OOM 
> > since the 
> > extended peers stats will be queued unchecked (not that this is currently a 
> > problem).
> 
> [shafi] list_splice_tail_init should still check for non-empty 'peers_extd' 
> list
> and append if required ? please let me know if i am still missing something
Well, you can also count the entries in peers_extd and delete the old entries
if they start to overflow. If you want to do it differently, please go ahead.

Regards,
Christian


[PATCH] mac80211: only alloc mem if a station doesnt exist yet

2016-12-14 Thread Koen Vandeputte
This speeds up the function in case a station already exists by avoiding
calling an expensive kzalloc just to free it again after the next check.

Signed-off-by: Koen Vandeputte 
---
 net/mac80211/sta_info.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 1711bae..0a42e6e 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -513,23 +513,23 @@ static int sta_info_insert_finish(struct sta_info *sta) 
__acquires(RCU)
 {
struct ieee80211_local *local = sta->local;
struct ieee80211_sub_if_data *sdata = sta->sdata;
-   struct station_info *sinfo;
+   struct station_info *sinfo = NULL;
int err = 0;
 
lockdep_assert_held(>sta_mtx);
 
-   sinfo = kzalloc(sizeof(struct station_info), GFP_KERNEL);
-   if (!sinfo) {
-   err = -ENOMEM;
-   goto out_err;
-   }
-
/* check if STA exists already */
if (sta_info_get_bss(sdata, sta->sta.addr)) {
err = -EEXIST;
goto out_err;
}
 
+   sinfo = kzalloc(sizeof(struct station_info), GFP_KERNEL);
+   if (!sinfo) {
+   err = -ENOMEM;
+   goto out_err;
+   }
+
local->num_sta++;
local->sta_generation++;
smp_mb();
-- 
2.7.4



Re: [Patch] NFC: trf7970a:

2016-12-14 Thread Geoff Lansberry
On Wed, Dec 14, 2016 at 10:57 AM, Mark Greer  wrote:
>
> On Tue, Dec 13, 2016 at 08:50:04PM -0500, Geoff Lansberry wrote:
> > Hi Mark -  Thanks for getting back to me.   It's funny that you ask,
> > because we are currently chasing a segfault that is happening in neard, but
> > may end up back in the trf7970a driver.   Have you ever heard on anyone
> > having segfault problems related to the trf7970a hardware drivers?
>
> No.  Mind sharing more info on that segfault?
>
> > I'll get you an update later tonight or tomorrow.
>
> Okay, thanks.
>
> Mark
> --

Mark - The segfault issue is only happening on writing, The work on
the segfault is being done by a consultant, but here is his statement
on how to recreate it on our build:

I am able to reliably force neard to segfault by flooding it with
write requests. I have attached a python script called flood.py that
can be used to do this. The script uses utilities that ship with
neard.

The segfault does not appear deterministic. It usually happens within
1000 writes, but the time can varying greatly. The logs output from
neard are inconsistent between crashes, which suggests this may be a
timing or race condition related issue.

I have been running neard manually to obtain the log information and a
core file for debugging (attached). I run neard as,

  $ /usr/lib/neard/nfc/neard -d -n

In a separate terminal I run,

  $ python flood.py

And the resulting core file provides the following backtrace,

(gdb) bt
#0  0xb6caed64 in ?? ()
#1  0x0001ed7c in data_recv (resp=0x5bd90 "", length=17, data=0x58348)
at plugins/nfctype2.c:156
#2  0x00024ecc in execute_recv_cb (user_data=0x5bd88) at src/adapter.c:979
#3  0xb6e70d60 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

The line at nfctype2.c:156 contains a memcpy operation.


Below is the flood.py script:
#!/usr/bin/python

import neardutils
import dbus
import time

bus = dbus.SystemBus()
DURATION = 0.05


def write():
# Get an adapter interface
objects = neardutils.get_managed_objects()
for path, interfaces in objects.iteritems():
if "org.neard.Adapter" in interfaces:
break

else:
raise Exception("Unable to find adapter")

print("adapter object path: " + path)
adapter = dbus.Interface(bus.get_object("org.neard", path),
"org.freedesktop.DBus.Properties")

# power cycle
try:
adapter.Set("org.neard.Adapter", "Powered", dbus.Boolean(0))
time.sleep(DURATION)
except:
pass

try:
adapter.Set("org.neard.Adapter", "Powered", dbus.Boolean(1))
time.sleep(DURATION)
except:
pass

# Set polling
adapter = dbus.Interface(bus.get_object("org.neard", path),
"org.neard.Adapter")
adapter.StartPollLoop("Initiator")

time.sleep(DURATION)

# write tag
objects = neardutils.get_managed_objects()
for path, interfaces in objects.iteritems():
if "org.neard.Tag" in interfaces:
break
else:
raise Exception("Unable to find tag")

print("tag object path: " + path)

time.sleep(DURATION)

tag = dbus.Interface(bus.get_object("org.neard", path), "org.neard.Tag")
tag.Write(({
"Type": "Text",
"Encoding": "UTF-8",
"Language": "en",
"Representation": "omen_red_2014",
}))

time.sleep(DURATION)

objects = neardutils.get_managed_objects()
for path, interfaces in objects.iteritems():
if "org.neard.Record" in interfaces:
break
else:
raise Exception("Unable to read record")

print("record object path: " + path)

time.sleep(DURATION)

record = dbus.Interface(bus.get_object("org.neard", path),
"org.freedesktop.DBus.Properties")
print("representation: " + record.Get("org.neard.Record", "Representation"))


def main():
for iteration in range(1000):
try:
print("==")
print("iteration: " + str(iteration))
write()
print("SUCCESS")

except Exception,e:
print(str(e))
print("FAILURE")


if __name__ == "__main__":
main()
-

If we find the source of the problem, we will share it upstream.   If
you have any thoughts on where to look, please share.

Geoff Lansberry


Re: [Patch] NFC: trf7970a:

2016-12-14 Thread Mark Greer
On Tue, Dec 13, 2016 at 08:50:04PM -0500, Geoff Lansberry wrote:
> Hi Mark -  Thanks for getting back to me.   It's funny that you ask,
> because we are currently chasing a segfault that is happening in neard, but
> may end up back in the trf7970a driver.   Have you ever heard on anyone
> having segfault problems related to the trf7970a hardware drivers?

No.  Mind sharing more info on that segfault?

> I'll get you an update later tonight or tomorrow.

Okay, thanks.

Mark
--


[PATCH 2/5] mwifiex: cleanup in PCIe flr code path

2016-12-14 Thread Amitkumar Karwar
From: Xinming Hu 

adapter and card variables don't get freed during PCIe function level
reset. "adapter->ext_scan" variable need not be re-initialized.
fw_name and tx_buf_size initialization is moved to pcie specific code
so that mwifiex_reinit_sw() can be used by SDIO.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/main.c |  9 -
 drivers/net/wireless/marvell/mwifiex/pcie.c | 12 +++-
 2 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index 3fc6221..9d80180 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1425,9 +1425,6 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
 int
 mwifiex_reinit_sw(struct mwifiex_adapter *adapter)
 {
-   char fw_name[32];
-   struct pcie_service_card *card = adapter->card;
-
mwifiex_init_lock_list(adapter);
if (adapter->if_ops.up_dev)
adapter->if_ops.up_dev(adapter);
@@ -1468,18 +1465,12 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
 * mwifiex_register_dev()
 */
mwifiex_dbg(adapter, INFO, "%s, mwifiex_init_hw_fw()...\n", __func__);
-   strcpy(fw_name, adapter->fw_name);
-   strcpy(adapter->fw_name, PCIE8997_DEFAULT_WIFIFW_NAME);
 
-   adapter->tx_buf_size = card->pcie.tx_buf_size;
-   adapter->ext_scan = card->pcie.can_ext_scan;
if (mwifiex_init_hw_fw(adapter, false)) {
-   strcpy(adapter->fw_name, fw_name);
mwifiex_dbg(adapter, ERROR,
"%s: firmware init failed\n", __func__);
goto err_init_fw;
}
-   strcpy(adapter->fw_name, fw_name);
mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
 
complete_all(adapter->fw_done);
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 02f6db0..66226c6 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -3082,6 +3082,17 @@ static void mwifiex_pcie_up_dev(struct mwifiex_adapter 
*adapter)
struct pci_dev *pdev = card->dev;
const struct mwifiex_pcie_card_reg *reg = card->pcie.reg;
 
+   /* Bluetooth is not on pcie interface. Download Wifi only firmware
+* during pcie FLR, so that bluetooth part of firmware which is
+* already running doesn't get affected.
+*/
+   strcpy(adapter->fw_name, PCIE8997_DEFAULT_WIFIFW_NAME);
+
+   /* tx_buf_size might be changed to 3584 by firmware during
+* data transfer, we should reset it to default size.
+*/
+   adapter->tx_buf_size = card->pcie.tx_buf_size;
+
card->cmdrsp_buf = NULL;
ret = mwifiex_pcie_create_txbd_ring(adapter);
if (ret) {
@@ -3143,7 +3154,6 @@ static void mwifiex_pcie_down_dev(struct mwifiex_adapter 
*adapter)
mwifiex_dbg(adapter, ERROR, "Failed to write driver not-ready 
signature\n");
 
adapter->seq_num = 0;
-   adapter->tx_buf_size = MWIFIEX_TX_DATA_BUF_SIZE_4K;
 
if (reg->sleep_cookie)
mwifiex_pcie_delete_sleep_cookie_buf(adapter);
-- 
1.9.1



[PATCH 3/5] mwifiex: sdio card reset enhancement

2016-12-14 Thread Amitkumar Karwar
From: Xinming Hu 

Commit b4336a282db8 ("mwifiex: sdio: reset adapter using mmc_hw_reset")
introduces a simple sdio card reset solution based on card remove and
re-probe. This solution has proved to be vulnerable, as card and
adapter structures are not protected, concurrent access will result in
kernel panic issues.

Let's reuse PCIe FLR's functions for SDIO reset to avoid freeing and
reallocating adapter and card structures.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 73 +
 drivers/net/wireless/marvell/mwifiex/sdio.h |  3 --
 2 files changed, 33 insertions(+), 43 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 44eb65a..b3aca10 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -104,7 +104,6 @@ static int mwifiex_sdio_probe_of(struct device *dev)
init_completion(>fw_done);
 
card->func = func;
-   card->device_id = id;
 
func->card->quirks |= MMC_QUIRK_BLKSZ_FOR_BYTE_MODE;
 
@@ -2196,33 +2195,13 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter 
*adapter)
port, card->mp_data_port_mask);
 }
 
-static void mwifiex_recreate_adapter(struct sdio_mmc_card *card)
+static struct mwifiex_adapter *save_adapter;
+static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
 {
+   struct sdio_mmc_card *card = adapter->card;
struct sdio_func *func = card->func;
-   const struct sdio_device_id *device_id = card->device_id;
-
-   /* TODO mmc_hw_reset does not require destroying and re-probing the
-* whole adapter. Hence there was no need to for this rube-goldberg
-* design to reload the fw from an external workqueue. If we don't
-* destroy the adapter we could reload the fw from
-* mwifiex_main_work_queue directly.
-* The real difficulty with fw reset is to restore all the user
-* settings applied through ioctl. By destroying and recreating the
-* adapter, we take the easy way out, since we rely on user space to
-* restore them. We assume that user space will treat the new
-* incarnation of the adapter(interfaces) as if they had been just
-* discovered and initializes them from scratch.
-*/
 
-   __mwifiex_sdio_remove(func);
-
-   /*
-* Normally, we would let the driver core take care of releasing these.
-* But we're not letting the driver core handle this one. See above
-* TODO.
-*/
-   sdio_set_drvdata(func, NULL);
-   devm_kfree(>dev, card);
+   mwifiex_shutdown_sw(adapter);
 
/* power cycle the adapter */
sdio_claim_host(func);
@@ -2235,21 +2214,7 @@ static void mwifiex_recreate_adapter(struct 
sdio_mmc_card *card)
clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, _work_flags);
clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, _work_flags);
 
-   mwifiex_sdio_probe(func, device_id);
-}
-
-static struct mwifiex_adapter *save_adapter;
-static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
-{
-   struct sdio_mmc_card *card = adapter->card;
-
-   /* TODO card pointer is unprotected. If the adapter is removed
-* physically, sdio core might trigger mwifiex_sdio_remove, before this
-* workqueue is run, which will destroy the adapter struct. When this
-* workqueue eventually exceutes it will dereference an invalid adapter
-* pointer
-*/
-   mwifiex_recreate_adapter(card);
+   mwifiex_reinit_sw(adapter);
 }
 
 /* This function read/write firmware */
@@ -2677,6 +2642,33 @@ static void mwifiex_sdio_device_dump(struct 
mwifiex_adapter *adapter)
return p - drv_buf;
 }
 
+/* sdio device/function initialization, code is extracted
+ * from init_if handler and register_dev handler.
+ */
+static void mwifiex_sdio_up_dev(struct mwifiex_adapter *adapter)
+{
+   struct sdio_mmc_card *card = adapter->card;
+   u8 sdio_ireg;
+
+   sdio_claim_host(card->func);
+   sdio_enable_func(card->func);
+   sdio_set_block_size(card->func, MWIFIEX_SDIO_BLOCK_SIZE);
+   sdio_release_host(card->func);
+
+   /* tx_buf_size might be changed to 3584 by firmware during
+* data transfer, we will reset to default size.
+*/
+   adapter->tx_buf_size = card->tx_buf_size;
+
+   /* Read the host_int_status_reg for ACK the first interrupt got
+* from the bootloader. If we don't do this we get a interrupt
+* as soon as we register the irq.
+*/
+   mwifiex_read_reg(adapter, card->reg->host_int_status_reg, _ireg);
+
+   mwifiex_init_sdio_ioport(adapter);
+}
+
 static struct mwifiex_if_ops sdio_ops = {
.init_if = mwifiex_init_sdio,
.cleanup_if = 

[PATCH 5/5] mwifiex: get rid of global save_adapter and sdio_work

2016-12-14 Thread Amitkumar Karwar
From: Xinming Hu 

This patch moves sdio_work to card structure, in this way we can get
adapter structure in the work, so save_adapter won't be needed.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/sdio.c | 39 -
 drivers/net/wireless/marvell/mwifiex/sdio.h |  3 +++
 2 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index 0fda87a..a4b356d 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -32,10 +32,8 @@
 #define SDIO_VERSION   "1.0"
 
 static void mwifiex_sdio_work(struct work_struct *work);
-static DECLARE_WORK(sdio_work, mwifiex_sdio_work);
 
 static struct mwifiex_if_ops sdio_ops;
-static unsigned long iface_work_flags;
 
 static struct memory_type_mapping generic_mem_type_map[] = {
{"DUMP", NULL, 0, 0xDD},
@@ -123,6 +121,7 @@ static int mwifiex_sdio_probe_of(struct device *dev)
card->fw_dump_enh = data->fw_dump_enh;
card->can_auto_tdls = data->can_auto_tdls;
card->can_ext_scan = data->can_ext_scan;
+   INIT_WORK(>work, mwifiex_sdio_work);
}
 
sdio_claim_host(func);
@@ -388,7 +387,7 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
 
-   cancel_work_sync(_work);
+   cancel_work_sync(>work);
 
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
 
@@ -2190,7 +2189,6 @@ static void mwifiex_cleanup_sdio(struct mwifiex_adapter 
*adapter)
port, card->mp_data_port_mask);
 }
 
-static struct mwifiex_adapter *save_adapter;
 static void mwifiex_sdio_card_reset_work(struct mwifiex_adapter *adapter)
 {
struct sdio_mmc_card *card = adapter->card;
@@ -2206,8 +2204,8 @@ static void mwifiex_sdio_card_reset_work(struct 
mwifiex_adapter *adapter)
/* Previous save_adapter won't be valid after this. We will cancel
 * pending work requests.
 */
-   clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, _work_flags);
-   clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, _work_flags);
+   clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, >work_flags);
+   clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET, >work_flags);
 
mwifiex_reinit_sw(adapter);
 }
@@ -2513,35 +2511,40 @@ static void mwifiex_sdio_device_dump_work(struct 
mwifiex_adapter *adapter)
 
 static void mwifiex_sdio_work(struct work_struct *work)
 {
+   struct sdio_mmc_card *card =
+   container_of(work, struct sdio_mmc_card, work);
+
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP,
-  _work_flags))
-   mwifiex_sdio_device_dump_work(save_adapter);
+  >work_flags))
+   mwifiex_sdio_device_dump_work(card->adapter);
if (test_and_clear_bit(MWIFIEX_IFACE_WORK_CARD_RESET,
-  _work_flags))
-   mwifiex_sdio_card_reset_work(save_adapter);
+  >work_flags))
+   mwifiex_sdio_card_reset_work(card->adapter);
 }
 
 /* This function resets the card */
 static void mwifiex_sdio_card_reset(struct mwifiex_adapter *adapter)
 {
-   save_adapter = adapter;
-   if (test_bit(MWIFIEX_IFACE_WORK_CARD_RESET, _work_flags))
+   struct sdio_mmc_card *card = adapter->card;
+
+   if (test_bit(MWIFIEX_IFACE_WORK_CARD_RESET, >work_flags))
return;
 
-   set_bit(MWIFIEX_IFACE_WORK_CARD_RESET, _work_flags);
+   set_bit(MWIFIEX_IFACE_WORK_CARD_RESET, >work_flags);
 
-   schedule_work(_work);
+   schedule_work(>work);
 }
 
 /* This function dumps FW information */
 static void mwifiex_sdio_device_dump(struct mwifiex_adapter *adapter)
 {
-   save_adapter = adapter;
-   if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, _work_flags))
+   struct sdio_mmc_card *card = adapter->card;
+
+   if (test_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, >work_flags))
return;
 
-   set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, _work_flags);
-   schedule_work(_work);
+   set_bit(MWIFIEX_IFACE_WORK_DEVICE_DUMP, >work_flags);
+   schedule_work(>work);
 }
 
 /* Function to dump SDIO function registers and SDIO scratch registers in case
diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.h 
b/drivers/net/wireless/marvell/mwifiex/sdio.h
index afa10d5..dccf7fd 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.h
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.h
@@ -267,6 +267,9 @@ struct sdio_mmc_card {
 
struct mwifiex_sdio_mpa_tx mpa_tx;
struct mwifiex_sdio_mpa_rx mpa_rx;
+
+   struct work_struct work;
+   unsigned long work_flags;
 };
 
 struct mwifiex_sdio_device {
-- 
1.9.1



[PATCH 4/5] mwifiex: get rid of __mwifiex_sdio_remove helper

2016-12-14 Thread Amitkumar Karwar
From: Xinming Hu 

__mwifiex_sdio_remove helper is not needed after
our enhancements in SDIO card reset.

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

diff --git a/drivers/net/wireless/marvell/mwifiex/sdio.c 
b/drivers/net/wireless/marvell/mwifiex/sdio.c
index b3aca10..0fda87a 100644
--- a/drivers/net/wireless/marvell/mwifiex/sdio.c
+++ b/drivers/net/wireless/marvell/mwifiex/sdio.c
@@ -370,7 +370,7 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
  * This function removes the interface and frees up the card structure.
  */
 static void
-__mwifiex_sdio_remove(struct sdio_func *func)
+mwifiex_sdio_remove(struct sdio_func *func)
 {
struct sdio_mmc_card *card;
struct mwifiex_adapter *adapter;
@@ -388,6 +388,8 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
if (!adapter || !adapter->priv_num)
return;
 
+   cancel_work_sync(_work);
+
mwifiex_dbg(adapter, INFO, "info: SDIO func num=%d\n", func->num);
 
ret = mwifiex_sdio_read_fw_status(adapter, _stat);
@@ -402,13 +404,6 @@ static int mwifiex_check_winner_status(struct 
mwifiex_adapter *adapter)
mwifiex_remove_card(adapter);
 }
 
-static void
-mwifiex_sdio_remove(struct sdio_func *func)
-{
-   cancel_work_sync(_work);
-   __mwifiex_sdio_remove(func);
-}
-
 /*
  * SDIO suspend.
  *
-- 
1.9.1



[PATCH 1/5] mwifiex: get rid of mwifiex_do_flr wrapper

2016-12-14 Thread Amitkumar Karwar
From: Xinming Hu 

This patch gets rid of mwifiex_do_flr. We will call
mwifiex_shutdown_sw() and mwifiex_reinit_sw() directly.
These two general purpose functions will be useful for
sdio card reset handler.

Signed-off-by: Xinming Hu 
Signed-off-by: Amitkumar Karwar 
---
 drivers/net/wireless/marvell/mwifiex/main.c | 31 +
 drivers/net/wireless/marvell/mwifiex/main.h |  3 ++-
 drivers/net/wireless/marvell/mwifiex/pcie.c |  4 ++--
 3 files changed, 9 insertions(+), 29 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/main.c 
b/drivers/net/wireless/marvell/mwifiex/main.c
index c1821aa..3fc6221 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.c
+++ b/drivers/net/wireless/marvell/mwifiex/main.c
@@ -1348,7 +1348,7 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
  * This function gets called during PCIe function level reset. Required
  * code is extracted from mwifiex_remove_card()
  */
-static int
+int
 mwifiex_shutdown_sw(struct mwifiex_adapter *adapter)
 {
struct mwifiex_private *priv;
@@ -1417,13 +1417,13 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
 exit_return:
return 0;
 }
+EXPORT_SYMBOL_GPL(mwifiex_shutdown_sw);
 
 /* This function gets called during PCIe function level reset. Required
  * code is extracted from mwifiex_add_card()
  */
-static int
-mwifiex_reinit_sw(struct mwifiex_adapter *adapter, struct completion *fw_done,
- struct mwifiex_if_ops *if_ops, u8 iface_type)
+int
+mwifiex_reinit_sw(struct mwifiex_adapter *adapter)
 {
char fw_name[32];
struct pcie_service_card *card = adapter->card;
@@ -1432,9 +1432,6 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
if (adapter->if_ops.up_dev)
adapter->if_ops.up_dev(adapter);
 
-   adapter->iface_type = iface_type;
-   adapter->fw_done = fw_done;
-
adapter->hw_status = MWIFIEX_HW_STATUS_INITIALIZING;
adapter->surprise_removed = false;
init_waitqueue_head(>init_wait_q);
@@ -1507,25 +1504,7 @@ static void mwifiex_main_work_queue(struct work_struct 
*work)
 
return -1;
 }
-
-/* This function processes pre and post PCIe function level resets.
- * It performs software cleanup without touching PCIe specific code.
- * Also, during initialization PCIe stuff is skipped.
- */
-void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare)
-{
-   struct mwifiex_if_ops if_ops;
-
-   if (!prepare) {
-   mwifiex_reinit_sw(adapter, adapter->fw_done, _ops,
- adapter->iface_type);
-   } else {
-   memcpy(_ops, >if_ops,
-  sizeof(struct mwifiex_if_ops));
-   mwifiex_shutdown_sw(adapter);
-   }
-}
-EXPORT_SYMBOL_GPL(mwifiex_do_flr);
+EXPORT_SYMBOL_GPL(mwifiex_reinit_sw);
 
 static irqreturn_t mwifiex_irq_wakeup_handler(int irq, void *priv)
 {
diff --git a/drivers/net/wireless/marvell/mwifiex/main.h 
b/drivers/net/wireless/marvell/mwifiex/main.h
index d501d03..5f7a010 100644
--- a/drivers/net/wireless/marvell/mwifiex/main.h
+++ b/drivers/net/wireless/marvell/mwifiex/main.h
@@ -1666,5 +1666,6 @@ void mwifiex_process_multi_chan_event(struct 
mwifiex_private *priv,
 void mwifiex_dev_debugfs_init(struct mwifiex_private *priv);
 void mwifiex_dev_debugfs_remove(struct mwifiex_private *priv);
 #endif
-void mwifiex_do_flr(struct mwifiex_adapter *adapter, bool prepare);
+int mwifiex_reinit_sw(struct mwifiex_adapter *adapter);
+int mwifiex_shutdown_sw(struct mwifiex_adapter *adapter);
 #endif /* !_MWIFIEX_MAIN_H_ */
diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c 
b/drivers/net/wireless/marvell/mwifiex/pcie.c
index 55c79e3..02f6db0 100644
--- a/drivers/net/wireless/marvell/mwifiex/pcie.c
+++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
@@ -375,7 +375,7 @@ static void mwifiex_pcie_reset_notify(struct pci_dev *pdev, 
bool prepare)
 * Cleanup all software without cleaning anything related to
 * PCIe and HW.
 */
-   mwifiex_do_flr(adapter, prepare);
+   mwifiex_shutdown_sw(adapter);
adapter->surprise_removed = true;
} else {
/* Kernel stores and restores PCIe function context before and
@@ -383,7 +383,7 @@ static void mwifiex_pcie_reset_notify(struct pci_dev *pdev, 
bool prepare)
 * and firmware including firmware redownload
 */
adapter->surprise_removed = false;
-   mwifiex_do_flr(adapter, prepare);
+   mwifiex_reinit_sw(adapter);
}
mwifiex_dbg(adapter, INFO, "%s, successful\n", __func__);
 }
-- 
1.9.1



Re: [RFC v2 05/11] ath10k: htc: refactorization

2016-12-14 Thread Valo, Kalle
Michal Kazior  writes:

>> I have made a few updates since I submitted the original RFC and created
>> a repo on github:
>>
>> https://github.com/erstrom/linux-ath
>>
>> I have a bunch of branches that are all based on the tags on the ath master.
>>
>> As of this moment the latest version is:
>>
>> ath-201612131156-ath10k-sdio
>>
>> This branch contains the original RFC patches plus some addons/fixes.
>>
>> In the above mentioned branch there are a few commits related to this
>> race condition. Perhaps you can have a look at them?
>>
>> The commits are:
>> 821672913328cf737c9616786dc28d2e4e8a4a90
>
> I would avoid if(bus==xx) checks.

Very much agreed. For example to enable HTT high latency support you
could add an enum to ath10k_core_create() with values for both high and
low latency. This way sdio.c and pci.c can enable the correct mode
during initialisation.

-- 
Kalle Valo

Re: [RFC v2 05/11] ath10k: htc: refactorization

2016-12-14 Thread Valo, Kalle
Erik Stromdahl  writes:

> I have made a few updates since I submitted the original RFC and created
> a repo on github:
>
> https://github.com/erstrom/linux-ath
>
> I have a bunch of branches that are all based on the tags on the ath master.
>
> As of this moment the latest version is:
>
> ath-201612131156-ath10k-sdio
>
> This branch contains the original RFC patches plus some addons/fixes.

Good, this makes it easier to follow the development. So what's the
current status with this branch? What works and what doesn't?

Especially I'm interested about the state of the HTT high latency
support. How much work is to add that? It would also make it easier to
add USB support to ath10k.

-- 
Kalle Valo

Re: [RFC V3 04/11] nl80211: add driver api for gscan notifications

2016-12-14 Thread Arend Van Spriel
On 13-12-2016 17:20, Johannes Berg wrote:
> On Mon, 2016-12-12 at 11:59 +, Arend van Spriel wrote:
>> The driver can indicate gscan results are available or gscan
>> operation has stopped.
> 
> This patch is renumbering the previous patches' nl80211 API, which is
> best avoided, even if I do realize it doesn't matter now. :)

Indeed. Will be more careful in upcoming revision(s).

> Even here it's not clear how things are reported though. Somehow I
> thought that gscan was reporting only partial information through the
> buckets, or is that not true?

Not sure what is meant by "through the buckets". Referring to your
remark/question in the "Unversal scan proposal" thread:

"""
I'm much more worried about the "bucket reporting" since that doesn't
fit into the current full BSS reporting model at all. What's your
suggestion for this?
"""

So this is exactly the dilemma I considered so I decided to stick with
the full BSS reporting model for gscan as well merely to get it
discussed so glad you brought it up ;-). The problem here is that
gscan is a vehicle that serves a number of use-cases. So ignoring
hotlists, ePNO, etc. the gscan configuration still hold several
notification types:

- report after completing M scans capturing N best APs or a
  percentage of (M * N).
- report after completing a scan include a specific bucket.
- report full scan results.

The first two notification trigger retrieval of gscan results which are
historic, ie. partial scan results for max M scans.

As said earlier the universal scan proposal has some similarities to
gscan. Guess you share that as you are using the term "bucket reporting"
in that discussion ;-). The historic results are needed for location (if
I am not mistaken) so the full BSS reporting model does not fit that.
Question is what particular attribute in the historic results is needed
for location (suspecting only rssi and possibly the timestamp, but would
like to see that confirmed). I was thinking about have historic storage
in cfg80211 so we do not need a per-driver solution.

Regards,
Arend


Re: [RFC V3 03/11] nl80211: add support for gscan

2016-12-14 Thread Arend Van Spriel


On 13-12-2016 23:29, Johannes Berg wrote:
> On Tue, 2016-12-13 at 21:09 +0100, Arend Van Spriel wrote:
>>  
>>> There's a bit of a weird hard-coded restriction to 16 channels too,
>>> that's due to the bucket map?
>>
>> Uhm. Is there? I will check, but if you can give me a pointer where
>> to look it is appreciated.
> 
> Just look for "< 16" or "<= 16" or so in the patch. I do think that's
> because the channel map is a u16 though, not sure we'd want to change
> that.

Had to look for "> 16" ;-)

> + /* ignore channels if band is specified */
> + if (band_select)
> + return 0;
> +
> +nla_for_each_nested(chan,
tb[NL80211_GSCAN_BUCKET_ATTR_CHANNELS], rem) {
> +num_chans++;
> +}

Here an instance of the tab vs. space issue you mentioned. Will go over
the patch and fix that.

> + if (num_chans > 16)
> + return -EINVAL;

I suspect this is the restriction you were referring to. There is no
reason for this although the android wifi hal has max 16 channels in a
bucket so I might have picked that up. So could a driver have a similar
limit and should we add such to the gscan capabilities? For instance our
firmware api has a nasty restriction of 64 channels for all buckets
together, eg. can do 4 buckets of 16 channels each.

Regards,
Arend