Re: [PATCH 8/8] Makefile: drop -D__CHECK_ENDIAN__ from cflags
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
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
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
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
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
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
__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
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:
On Wed, Dec 14, 2016 at 01:35:03PM -0500, Geoff Lansberry wrote: > On Wed, Dec 14, 2016 at 12:10 PM, Mark Greerwrote: > > 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
On 12/14/2016 02:46 PM, Valo, Kalle wrote: > Erik Stromdahlwrites: > >> 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
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
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
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
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
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
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
From: Thomas HuehnMakes 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
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
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
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
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 HuehnSigned-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
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
From: Ben GreearThis 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
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:
On Wed, Dec 14, 2016 at 12:10 PM, Mark Greerwrote: > 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
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:
On Wed, Dec 14, 2016 at 11:17:33AM -0500, Geoff Lansberry wrote: > On Wed, Dec 14, 2016 at 10:57 AM, Mark Greerwrote: > > > > 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
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
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:
On Wed, Dec 14, 2016 at 10:57 AM, Mark Greerwrote: > > 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:
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
From: Xinming Huadapter 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
From: Xinming HuCommit 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
From: Xinming HuThis 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
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
From: Xinming HuThis 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
Michal Kaziorwrites: >> 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
Erik Stromdahlwrites: > 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
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
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