[PATCH 4.4 180/193] nl80211: Sanitize array index in parse_txq_params
4.4-stable review patch. If anyone has any objections, please let me know. -- From: Dan Williams (cherry picked from commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05) Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Reported-by: Christian Lamparter Reported-by: Elena Reshetova Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Acked-by: Johannes Berg Cc: linux-a...@vger.kernel.org Cc: kernel-harden...@lists.openwall.com Cc: gre...@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torva...@linux-foundation.org Cc: "David S. Miller" Cc: a...@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.st...@dwillia2-desk3.amr.corp.intel.com Signed-off-by: David Woodhouse [jwang: cherry pick to 4.4] Signed-off-by: Jack Wang Signed-off-by: Greg Kroah-Hartman --- net/wireless/nl80211.c |9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -1879,20 +1880,22 @@ static const struct nla_policy txq_param static int parse_txq_params(struct nlattr *tb[], struct ieee80211_txq_params *txq_params) { + u8 ac; + if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] || !tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] || !tb[NL80211_TXQ_ATTR_AIFS]) return -EINVAL; - txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]); + ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]); txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]); txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]); txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]); txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]); - if (txq_params->ac >= NL80211_NUM_ACS) + if (ac >= NL80211_NUM_ACS) return -EINVAL; - + txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS); return 0; }
Re: [PATCH v2] cfg80211/nl80211: add DFS offload flag
23.02.2018 14:32, Johannes Berg wrote: On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote: + * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions. + * Device or driver will do all DFS-related actions by itself, + * informing user-space about CAC progress, radar detection event, + * channel change triggered by radar detection event. + * No need to start CAC from user-space, no need to react to + * "radar detected" event. The "channel change" part bothers me a bit - isn't normally hostapd very much in control of the channel? How does it even get notified of the new channel? How can you configure the parameters like how many beacons to include the (E)CSA IE for, and whether to add ECSA or not etc? johannes hostapd will be notified with NL80211_CMD_CH_SWITCH_NOTIFY event and it already has a handler for this event and looks like it works as expected. In case of radar detection, userspace (hostapd) should receive two events (with DFS offload enabled): 1. RADAR_DETECT - and in case of DFS_OFFLOAD flag turned on don't do any CSA 2. CH_SWITCH_NOTIFY - at the moment when HW will switch channel as a reaction to radar event Currently, all CSA will be sent with default parameters. If it's crucial to tune e.g. TBTT count, then let's add it with a separate commit later, when DFS offload will be implemented in the whole SW stack (driver/kernel/userspace). DFS offload should be quite useful and should fix some issues in a repeater configuration. There are a number of issues which are hard to fix without DFS offload feature: e.g. if repeater has detected a radar and sent radar report frame to master AP, master AP will reply with CSA, but hostapd will try to change channel to different channel. Regards, Dmitry
Re: pull-request: mac80211-next 2018-02-22
From: Johannes Berg Date: Fri, 23 Feb 2018 12:29:39 +0100 > On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote: >> >> Pulled, thank you! > > Thanks. I just realized that I have a patch pending for -next that > depends another commit in net/mac80211 (or would otherwise conflict > badly while applying, and again while merging later), could I ask you > to pull net into net-next at some point now? I'll get that to happen in the next day or two. Pablo asked for this as well.
Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal
On 02/23/2018 03:18 AM, Kalle Valo wrote: Larry Finger writes: In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem correctly") a problem in rtl8821ae that caused loss of signal was fixed. That same problem has now been reported for rtl8723be. Accordingly, the ASPM L1 latency has been increased from 0 to 7 to fix the instability. Signed-off-by: Larry Finger Cc: Stable --- Kalle, This patch should be sent to 4.16. Ok, I'll queue this for 4.16. Thanks, Larry
[v8 3/8] rsi: add header file rsi_91x
From: Prameela Rani Garnepudi The common parameters used by wlan and bt modules are add to a new header file "rsi_91x.h" defined in 'include/net' Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla Signed-off-by: Amitkumar Karwar --- v8: Same as v6, v7 v6: Renamed rsi_header.h to rsi_91x.h and moved to include/net from include/linux(Kalle) v5: Same as earlier versions --- drivers/net/wireless/rsi/rsi_main.h | 12 ++-- include/net/rsi_91x.h | 34 ++ 2 files changed, 36 insertions(+), 10 deletions(-) create mode 100644 include/net/rsi_91x.h diff --git a/drivers/net/wireless/rsi/rsi_main.h b/drivers/net/wireless/rsi/rsi_main.h index ee469dc..b0f4e2c 100644 --- a/drivers/net/wireless/rsi/rsi_main.h +++ b/drivers/net/wireless/rsi/rsi_main.h @@ -20,6 +20,7 @@ #include #include #include +#include struct rsi_sta { struct ieee80211_sta *sta; @@ -85,10 +86,6 @@ extern __printf(2, 3) void rsi_dbg(u32 zone, const char *fmt, ...); #define MGMT_HW_Q 10 #define BEACON_HW_Q11 -/* Queue information */ -#define RSI_COEX_Q 0x0 -#define RSI_WIFI_MGMT_Q 0x4 -#define RSI_WIFI_DATA_Q 0x5 #define IEEE80211_MGMT_FRAME0x00 #define IEEE80211_CTL_FRAME 0x04 @@ -293,11 +290,6 @@ struct rsi_common { struct ieee80211_vif *roc_vif; }; -enum host_intf { - RSI_HOST_INTF_SDIO = 0, - RSI_HOST_INTF_USB -}; - struct eepromrw_info { u32 offset; u32 length; @@ -322,7 +314,7 @@ struct rsi_hw { struct device *device; u8 sc_nvifs; - enum host_intf rsi_host_intf; + enum rsi_host_intf rsi_host_intf; u16 block_size; enum ps_state ps_state; struct rsi_ps_info ps_info; diff --git a/include/net/rsi_91x.h b/include/net/rsi_91x.h new file mode 100644 index 000..16a447b --- /dev/null +++ b/include/net/rsi_91x.h @@ -0,0 +1,34 @@ +/** + * Copyright (c) 2017 Redpine Signals Inc. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#ifndef __RSI_HEADER_H__ +#define __RSI_HEADER_H__ + +/* HAL queue information */ +#define RSI_COEX_Q 0x0 +#define RSI_BT_Q 0x2 +#define RSI_WLAN_Q 0x3 +#define RSI_WIFI_MGMT_Q 0x4 +#define RSI_WIFI_DATA_Q 0x5 +#define RSI_BT_MGMT_Q 0x6 +#define RSI_BT_DATA_Q 0x7 + +enum rsi_host_intf { + RSI_HOST_INTF_SDIO = 0, + RSI_HOST_INTF_USB +}; + +#endif -- 2.7.4
[v8 8/8] rsi: sdio changes to support BT
From: Prameela Rani Garnepudi Queue number is correctly updated for BT traffic. Also, kzalloc instead of kmalloc is used for Rx packet allocation. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_sdio.c | 2 ++ drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c index 5722736..beb18d0 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c @@ -763,6 +763,8 @@ static int rsi_sdio_host_intf_write_pkt(struct rsi_hw *adapter, int status; queueno = ((pkt[1] >> 4) & 0xf); + if (queueno == RSI_BT_MGMT_Q || queueno == RSI_BT_DATA_Q) + queueno = RSI_BT_Q; num_blocks = len / block_size; diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c index 169c981..6e74261 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c @@ -103,7 +103,7 @@ static int rsi_process_pkt(struct rsi_common *common) rcv_pkt_len = (num_blks * 256); - common->rx_data_pkt = kmalloc(rcv_pkt_len, GFP_KERNEL); + common->rx_data_pkt = kzalloc(rcv_pkt_len, GFP_KERNEL); if (!common->rx_data_pkt) { rsi_dbg(ERR_ZONE, "%s: Failed in memory allocation\n", __func__); -- 2.7.4
[v8 6/8] rsi: handle BT traffic in driver
From: Siva Rebbagondla BT frames are passed through coex and hal modules to BUS. After firmware is loaded, based on the operating mode CARD READY frame comes for each protocol. When BT card ready is received, BT attach is called. Protocol operations are exchanged between the modules at initialization time. Build flag CONFIG_RSI_COEX is introduced to enable coex support if CONFIG_BT_RSIHCI is enabled. Coex operations are valid if coex mode is greater than 1 only. Signed-off-by: Siva Rebbagondla Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar --- v8: Same as v6, v7 v6: Removed CONFIG_BT_HCIRSI flag dependency on RSI_91x. Introduced CONFIG_RSI_COEX for coex code. (Kalle) v5: Same as v3, v4 v3: bt_ops need not be present structure g_proto_ops. It is removed. v2: WLAN module depends on BT module. Updated in Kconfig --- drivers/net/wireless/rsi/rsi_91x_coex.c | 4 +- drivers/net/wireless/rsi/rsi_91x_core.c | 20 +++--- drivers/net/wireless/rsi/rsi_91x_hal.c | 39 drivers/net/wireless/rsi/rsi_91x_main.c | 57 +++-- drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 1 + drivers/net/wireless/rsi/rsi_common.h | 1 + drivers/net/wireless/rsi/rsi_hal.h | 10 + drivers/net/wireless/rsi/rsi_main.h | 3 ++ 8 files changed, 126 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_coex.c b/drivers/net/wireless/rsi/rsi_91x_coex.c index c07e839..d055099 100644 --- a/drivers/net/wireless/rsi/rsi_91x_coex.c +++ b/drivers/net/wireless/rsi/rsi_91x_coex.c @@ -43,8 +43,10 @@ static void rsi_coex_sched_tx_pkts(struct rsi_coex_ctrl_block *coex_cb) coex_q = rsi_coex_determine_coex_q(coex_cb); rsi_dbg(INFO_ZONE, "queue = %d\n", coex_q); - if (coex_q == RSI_COEX_Q_BT) + if (coex_q == RSI_COEX_Q_BT) { skb = skb_dequeue(&coex_cb->coex_tx_qs[RSI_COEX_Q_BT]); + rsi_send_bt_pkt(coex_cb->priv, skb); + } } while (coex_q != RSI_COEX_Q_INVALID); } diff --git a/drivers/net/wireless/rsi/rsi_91x_core.c b/drivers/net/wireless/rsi/rsi_91x_core.c index d0d2201..5dafd2e 100644 --- a/drivers/net/wireless/rsi/rsi_91x_core.c +++ b/drivers/net/wireless/rsi/rsi_91x_core.c @@ -17,6 +17,7 @@ #include "rsi_mgmt.h" #include "rsi_common.h" #include "rsi_hal.h" +#include "rsi_coex.h" /** * rsi_determine_min_weight_queue() - This function determines the queue with @@ -301,14 +302,23 @@ void rsi_core_qos_processor(struct rsi_common *common) mutex_unlock(&common->tx_lock); break; } - - if (q_num == MGMT_SOFT_Q) { - status = rsi_send_mgmt_pkt(common, skb); - } else if (q_num == MGMT_BEACON_Q) { + if (q_num == MGMT_BEACON_Q) { status = rsi_send_pkt_to_bus(common, skb); dev_kfree_skb(skb); } else { - status = rsi_send_data_pkt(common, skb); +#ifdef CONFIG_RSI_COEX + if (common->coex_mode > 1) { + status = rsi_coex_send_pkt(common, skb, + RSI_WLAN_Q); + } else { +#endif + if (q_num == MGMT_SOFT_Q) + status = rsi_send_mgmt_pkt(common, skb); + else + status = rsi_send_data_pkt(common, skb); +#ifdef CONFIG_RSI_COEX + } +#endif } if (status) { diff --git a/drivers/net/wireless/rsi/rsi_91x_hal.c b/drivers/net/wireless/rsi/rsi_91x_hal.c index 151d228..de608ae 100644 --- a/drivers/net/wireless/rsi/rsi_91x_hal.c +++ b/drivers/net/wireless/rsi/rsi_91x_hal.c @@ -15,6 +15,7 @@ */ #include +#include #include "rsi_mgmt.h" #include "rsi_hal.h" #include "rsi_sdio.h" @@ -24,6 +25,7 @@ static struct ta_metadata metadata_flash_content[] = { {"flash_content", 0x0001}, {"rsi/rs9113_wlan_qspi.rps", 0x0001}, + {"rsi/rs9113_wlan_bt_dual_mode.rps", 0x0001}, }; int rsi_send_pkt_to_bus(struct rsi_common *common, struct sk_buff *skb) @@ -357,6 +359,43 @@ int rsi_send_mgmt_pkt(struct rsi_common *common, return status; } +int rsi_send_bt_pkt(struct rsi_common *common, struct sk_buff *skb) +{ + int status = -EINVAL; + u8 header_size = 0; + struct rsi_bt_desc *bt_desc; + u8 queueno = ((skb->data[1] >> 4) & 0xf); + + if (queueno == RSI_BT_MGMT_Q) { + status = rsi_send_pkt_to_bus(common, skb); + if (status) + rsi_dbg(ERR_ZONE, "%s: Failed to write bt mgmt pkt\n", + __func__); + goto out; + } +
[v8 7/8] rsi: add module parameter operating mode
From: Prameela Rani Garnepudi Operating mode determines the support for other protocols. This is made as module parameter for better usage. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla Signed-off-by: Amitkumar Karwar --- drivers/net/wireless/rsi/rsi_91x_main.c | 48 ++--- drivers/net/wireless/rsi/rsi_91x_sdio.c | 10 ++- drivers/net/wireless/rsi/rsi_91x_usb.c | 10 ++- drivers/net/wireless/rsi/rsi_common.h | 2 +- drivers/net/wireless/rsi/rsi_hal.h | 11 5 files changed, 74 insertions(+), 7 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c index b3e7d75..1485a0c 100644 --- a/drivers/net/wireless/rsi/rsi_91x_main.c +++ b/drivers/net/wireless/rsi/rsi_91x_main.c @@ -70,8 +70,24 @@ EXPORT_SYMBOL_GPL(rsi_dbg); static char *opmode_str(int oper_mode) { switch (oper_mode) { - case RSI_DEV_OPMODE_WIFI_ALONE: + case DEV_OPMODE_WIFI_ALONE: return "Wi-Fi alone"; + case DEV_OPMODE_BT_ALONE: + return "BT EDR alone"; + case DEV_OPMODE_BT_LE_ALONE: + return "BT LE alone"; + case DEV_OPMODE_BT_DUAL: + return "BT Dual"; + case DEV_OPMODE_STA_BT: + return "Wi-Fi STA + BT EDR"; + case DEV_OPMODE_STA_BT_LE: + return "Wi-Fi STA + BT LE"; + case DEV_OPMODE_STA_BT_DUAL: + return "Wi-Fi STA + BT DUAL"; + case DEV_OPMODE_AP_BT: + return "Wi-Fi AP + BT EDR"; + case DEV_OPMODE_AP_BT_DUAL: + return "Wi-Fi AP + BT DUAL"; } return "Unknown"; @@ -278,7 +294,7 @@ void rsi_set_bt_context(void *priv, void *bt_context) * * Return: Pointer to the adapter structure on success, NULL on failure . */ -struct rsi_hw *rsi_91x_init(void) +struct rsi_hw *rsi_91x_init(u16 oper_mode) { struct rsi_hw *adapter = NULL; struct rsi_common *common = NULL; @@ -321,9 +337,33 @@ struct rsi_hw *rsi_91x_init(void) timer_setup(&common->roc_timer, rsi_roc_timeout, 0); init_completion(&common->wlan_init_completion); common->init_done = true; + adapter->device_model = RSI_DEV_9113; + common->oper_mode = oper_mode; + + /* Determine coex mode */ + switch (common->oper_mode) { + case DEV_OPMODE_STA_BT_DUAL: + case DEV_OPMODE_STA_BT: + case DEV_OPMODE_STA_BT_LE: + case DEV_OPMODE_BT_ALONE: + case DEV_OPMODE_BT_LE_ALONE: + case DEV_OPMODE_BT_DUAL: + common->coex_mode = 2; + break; + case DEV_OPMODE_AP_BT_DUAL: + case DEV_OPMODE_AP_BT: + common->coex_mode = 4; + break; + case DEV_OPMODE_WIFI_ALONE: + common->coex_mode = 1; + break; + default: + common->oper_mode = 1; + common->coex_mode = 1; + } + rsi_dbg(INFO_ZONE, "%s: oper_mode = %d, coex_mode = %d\n", + __func__, common->oper_mode, common->coex_mode); - common->coex_mode = RSI_DEV_COEX_MODE_WIFI_ALONE; - common->oper_mode = RSI_DEV_OPMODE_WIFI_ALONE; adapter->device_model = RSI_DEV_9113; #ifdef CONFIG_RSI_COEX if (common->coex_mode > 1) { diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c index ba38c6d..5722736 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c @@ -21,6 +21,14 @@ #include "rsi_coex.h" #include "rsi_hal.h" +/* Default operating mode is wlan STA + BT */ +static u16 dev_oper_mode = DEV_OPMODE_STA_BT_DUAL; +module_param(dev_oper_mode, ushort, 0444); +MODULE_PARM_DESC(dev_oper_mode, +"1[Wi-Fi], 4[BT], 8[BT LE], 5[Wi-Fi STA + BT classic]\n" +"9[Wi-Fi STA + BT LE], 13[Wi-Fi STA + BT classic + BT LE]\n" +"6[AP + BT classic], 14[AP + BT classic + BT LE]"); + /** * rsi_sdio_set_cmd52_arg() - This function prepares cmd 52 read/write arg. * @rw: Read/write @@ -926,7 +934,7 @@ static int rsi_probe(struct sdio_func *pfunction, rsi_dbg(INIT_ZONE, "%s: Init function called\n", __func__); - adapter = rsi_91x_init(); + adapter = rsi_91x_init(dev_oper_mode); if (!adapter) { rsi_dbg(ERR_ZONE, "%s: Failed to init os intf ops\n", __func__); diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c index b33a05f..0a50cff 100644 --- a/drivers/net/wireless/rsi/rsi_91x_usb.c +++ b/drivers/net/wireless/rsi/rsi_91x_usb.c @@ -21,6 +21,14 @@ #include "rsi_hal.h" #include "rsi_coex.h" +/* Default operating mode is wlan STA + BT */ +static u16 dev_oper_mode = DEV_OPMODE_STA_BT_DUAL; +module_param(dev_oper_mode, ushort, 0444); +MODULE_PARM_DESC(dev_oper_mode, +"1[Wi-Fi], 4[BT], 8[BT LE], 5[Wi-Fi STA + BT classic
[v8 5/8] Bluetooth: btrsi: add new rsi bluetooth driver
From: Prameela Rani Garnepudi Redpine bluetooth driver is a thin driver which depends on 'rsi_91x' driver for transmitting and receiving packets to/from device. It creates hci interface when attach() is called from 'rsi_91x' module. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla Acked-by: Marcel Holtmann Reviewed-by: Marcel Holtmann Signed-off-by: Amitkumar Karwar --- v8: Resolve 'kbuild test robot' reported error. Used asm/unaligned.h header file instead of linux/unaligned/le_byteshift.h v7: Same as v6 v6: Renamed CONFIG_BT_RSI to CONFIG_BT_HCIRSI (Marcel) v5: Addressed review comments from Marcel. Removed reduntant switch case code from rsi_hci_recv_pkt() Changed bt_cb(skb)->pkt_type to hci_skb_pkt_type(skb) Removed reduntant '\n' from BT_ERR and redundant BT_INFO messages Changed u8 *pkt to const u8 *pkt in rsi_hci_recv_pkt() v4: Removed rsi_hci.h file. Made the functions static(Marcel) v3: Made BT_RSI module by default off(Marcel) Removed redundant exported function rsi_get_hci_ops()(Marcel) v2: Addressed review comments from Marcel Removed unnecessary 'depends on BT && BT_RFOMM' line in Kconfig Removed redundant BT_INFO messages h_adapter initialization and declaration in a single line. Removed unnecessary error checks for HCI_RUNNING and fsm_state Allocated new skb with skb_realloc_headroom() API if headroom is not sufficient Used get_unaligned_le16 helpers Moved a structure and union from header file to btrsi.c file --- drivers/bluetooth/Kconfig | 12 +++ drivers/bluetooth/Makefile | 2 + drivers/bluetooth/btrsi.c | 188 + include/net/rsi_91x.h | 4 +- 4 files changed, 205 insertions(+), 1 deletion(-) create mode 100644 drivers/bluetooth/btrsi.c diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig index 07e55cd..d8bbd66 100644 --- a/drivers/bluetooth/Kconfig +++ b/drivers/bluetooth/Kconfig @@ -392,4 +392,16 @@ config BT_QCOMSMD Say Y here to compile support for HCI over Qualcomm SMD into the kernel or say M to compile as a module. +config BT_HCIRSI + tristate "Redpine HCI support" + default n + select RSI_COEX + help + Redpine BT driver. + This driver handles BT traffic from upper layers and pass + to the RSI_91x coex module for further scheduling to device + + Say Y here to compile support for HCI over Redpine into the + kernel or say M to compile as a module. + endmenu diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile index 4e4e44d..03cfc1b 100644 --- a/drivers/bluetooth/Makefile +++ b/drivers/bluetooth/Makefile @@ -28,6 +28,8 @@ obj-$(CONFIG_BT_QCA) += btqca.o obj-$(CONFIG_BT_HCIUART_NOKIA) += hci_nokia.o +obj-$(CONFIG_BT_HCIRSI)+= btrsi.o + btmrvl-y := btmrvl_main.o btmrvl-$(CONFIG_DEBUG_FS) += btmrvl_debugfs.o diff --git a/drivers/bluetooth/btrsi.c b/drivers/bluetooth/btrsi.c new file mode 100644 index 000..5034325 --- /dev/null +++ b/drivers/bluetooth/btrsi.c @@ -0,0 +1,188 @@ +/** + * Copyright (c) 2017 Redpine Signals Inc. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ +#include +#include +#include +#include +#include +#include +#include +#include + +#define RSI_HEADROOM_FOR_BT_HAL16 +#define RSI_FRAME_DESC_SIZE16 + +struct rsi_hci_adapter { + void *priv; + struct rsi_proto_ops *proto_ops; + struct hci_dev *hdev; +}; + +static int rsi_hci_open(struct hci_dev *hdev) +{ + return 0; +} + +static int rsi_hci_close(struct hci_dev *hdev) +{ + return 0; +} + +static int rsi_hci_flush(struct hci_dev *hdev) +{ + return 0; +} + +static int rsi_hci_send_pkt(struct hci_dev *hdev, struct sk_buff *skb) +{ + struct rsi_hci_adapter *h_adapter = hci_get_drvdata(hdev); + struct sk_buff *new_skb = NULL; + + switch (hci_skb_pkt_type(skb)) { + case HCI_COMMAND_PKT: + hdev->stat.cmd_tx++; + break; + case HCI_ACLDATA_PKT: + hdev->stat.acl_tx++; + break; + case HCI_SCODATA_PKT: + hdev->stat.sco_tx++; + break; + } + + i
[v8 2/8] rsi: add bluetooth rx endpoint
From: Siva Rebbagondla USB endpoint 1 is used for WLAN which is presently in use. USB endpoint 2 is introduced for BT Rx traffic. Enumeration of Rx BT endpoint and submitting Rx BT URB are added. >From /sys/kernel/debug/usb/devices, Ad=81(I) is for WLAN EP IN and Ad=01(O) is for Wlan EP OUT. Ad=82(I) is for BT EP IN and Ad=02(O) is for BT EP OUT. T: Bus=01 Lev=01 Prnt=01 Port=09 Cnt=03 Dev#= 4 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=1618 ProdID=9113 Rev= 0.02 S: Manufacturer=Redpine Signals, Inc. S: Product=Wireless USB Network Module S: SerialNumber=0001 C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr= 2mA I:* If#= 0 Alt= 0 #EPs= 6 Cls=00(>ifc ) Sub=00 Prot=00 Driver=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Siva Rebbagondla Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Amitkumar Karwar --- v8: Same as previos revisions v2: Included '/sys/kernel/debug/usb/devices' info in patch description(Marcel) --- drivers/net/wireless/rsi/rsi_91x_usb.c | 37 -- drivers/net/wireless/rsi/rsi_usb.h | 6 +++--- 2 files changed, 25 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c index bbce809..9ab86fb 100644 --- a/drivers/net/wireless/rsi/rsi_91x_usb.c +++ b/drivers/net/wireless/rsi/rsi_91x_usb.c @@ -103,41 +103,42 @@ static int rsi_find_bulk_in_and_out_endpoints(struct usb_interface *interface, struct usb_host_interface *iface_desc; struct usb_endpoint_descriptor *endpoint; __le16 buffer_size; - int ii, bep_found = 0; + int ii, bin_found = 0, bout_found = 0; iface_desc = &(interface->altsetting[0]); for (ii = 0; ii < iface_desc->desc.bNumEndpoints; ++ii) { endpoint = &(iface_desc->endpoint[ii].desc); - if ((!(dev->bulkin_endpoint_addr)) && + if (!dev->bulkin_endpoint_addr[bin_found] && (endpoint->bEndpointAddress & USB_DIR_IN) && - ((endpoint->bmAttributes & - USB_ENDPOINT_XFERTYPE_MASK) == + ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_BULK)) { buffer_size = endpoint->wMaxPacketSize; - dev->bulkin_size = buffer_size; - dev->bulkin_endpoint_addr = + dev->bulkin_size[bin_found] = buffer_size; + dev->bulkin_endpoint_addr[bin_found] = endpoint->bEndpointAddress; + bin_found++; } - if (!dev->bulkout_endpoint_addr[bep_found] && + if (!dev->bulkout_endpoint_addr[bout_found] && !(endpoint->bEndpointAddress & USB_DIR_IN) && ((endpoint->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) == - USB_ENDPOINT_XFER_BULK)) { - dev->bulkout_endpoint_addr[bep_found] = + USB_ENDPOINT_XFER_BULK)) { + buffer_size = endpoint->wMaxPacketSize; + dev->bulkout_endpoint_addr[bout_found] = endpoint->bEndpointAddress; buffer_size = endpoint->wMaxPacketSize; - dev->bulkout_size[bep_found] = buffer_size; - bep_found++; + dev->bulkout_size[bout_found] = buffer_size; + bout_found++; } - if (bep_found >= MAX_BULK_EP) + if (bin_found >= MAX_BULK_EP || bout_found >= MAX_BULK_EP) break; } - if (!(dev->bulkin_endpoint_addr) && - (dev->bulkout_endpoint_addr[0])) + if (!(dev->bulkin_endpoint_addr[0]) && + dev->bulkout_endpoint_addr[0]) return -EINVAL; return 0; @@ -273,7 +274,7 @@ static int rsi_rx_urb_submit(struct rsi_hw *adapter, u8 ep_num) usb_fill_bulk_urb(urb, dev->usbdev, usb_rcvbulkpipe(dev->usbdev, - dev->bulkin_endpoint_addr), + dev->bulkin_endpoint_addr[ep_num - 1]), urb->transfer_buffer, 3000, rsi_rx_done_handler, @@ -745,6 +746,12 @@ static int rsi_probe(struct usb_interface *pfunction, if (status) goto err1; + if (adapter->priv->coex_mode > 1) { + status = rsi_rx_urb_submit(adapter, BT_EP); + if (status) + goto err1; +
[v8 4/8] rsi: add coex support
From: Prameela Rani Garnepudi With BT support, driver has to handle two streams of data (i.e. wlan and BT). Actual coex implementation is in firmware. Coex module just schedule the packets to firmware by taking them from the corresponding paths. Structures for module and protocol operations are introduced for this purpose. Protocol operations structure is global structure which can be shared among different modules. Move initialization of coex and operating mode values to rsi_91x_init(). Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla Signed-off-by: Amitkumar Karwar --- v8: Resolve error reported by 'kbuild test robot' by moving header file code under CONFIG_RSI_COEX flag v7: Use mutex instead of semaphore (Kalle) v6: Rename semaphore tx_bus_lock to tx_bus_sema. Modified coex scheduling loop to avoid while(1) (Kalle) v5: Same as earlier versions --- drivers/net/wireless/rsi/Kconfig| 9 ++ drivers/net/wireless/rsi/Makefile | 1 + drivers/net/wireless/rsi/rsi_91x_coex.c | 177 drivers/net/wireless/rsi/rsi_91x_hal.c | 17 +-- drivers/net/wireless/rsi/rsi_91x_main.c | 30 +- drivers/net/wireless/rsi/rsi_91x_mgmt.c | 2 +- drivers/net/wireless/rsi/rsi_91x_sdio.c | 1 + drivers/net/wireless/rsi/rsi_91x_usb.c | 2 + drivers/net/wireless/rsi/rsi_coex.h | 37 +++ drivers/net/wireless/rsi/rsi_main.h | 6 ++ drivers/net/wireless/rsi/rsi_mgmt.h | 3 + include/net/rsi_91x.h | 20 12 files changed, 295 insertions(+), 10 deletions(-) create mode 100644 drivers/net/wireless/rsi/rsi_91x_coex.c create mode 100644 drivers/net/wireless/rsi/rsi_coex.h diff --git a/drivers/net/wireless/rsi/Kconfig b/drivers/net/wireless/rsi/Kconfig index 7c5e4ca..e6135ee 100644 --- a/drivers/net/wireless/rsi/Kconfig +++ b/drivers/net/wireless/rsi/Kconfig @@ -42,4 +42,13 @@ config RSI_USB This option enables the USB bus support in rsi drivers. Select M (recommended), if you have a RSI 1x1 wireless module. +config RSI_COEX + bool "Redpine Signals WLAN BT Coexistence support" + depends on BT_HCIRSI && RSI_91X + default y + ---help--- + This option enables the WLAN BT coex support in rsi drivers. + Select M (recommended), if you have want to use this feature + and you have RS9113 module. + endif # WLAN_VENDOR_RSI diff --git a/drivers/net/wireless/rsi/Makefile b/drivers/net/wireless/rsi/Makefile index 47c4590..ff87121a 100644 --- a/drivers/net/wireless/rsi/Makefile +++ b/drivers/net/wireless/rsi/Makefile @@ -5,6 +5,7 @@ rsi_91x-y += rsi_91x_mac80211.o rsi_91x-y += rsi_91x_mgmt.o rsi_91x-y += rsi_91x_hal.o rsi_91x-y += rsi_91x_ps.o +rsi_91x-$(CONFIG_RSI_COEX) += rsi_91x_coex.o rsi_91x-$(CONFIG_RSI_DEBUGFS) += rsi_91x_debugfs.o rsi_usb-y += rsi_91x_usb.o rsi_91x_usb_ops.o diff --git a/drivers/net/wireless/rsi/rsi_91x_coex.c b/drivers/net/wireless/rsi/rsi_91x_coex.c new file mode 100644 index 000..c07e839 --- /dev/null +++ b/drivers/net/wireless/rsi/rsi_91x_coex.c @@ -0,0 +1,177 @@ +/** + * Copyright (c) 2018 Redpine Signals Inc. + * + * Permission to use, copy, modify, and/or distribute this software for any + * purpose with or without fee is hereby granted, provided that the above + * copyright notice and this permission notice appear in all copies. + * + * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES + * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR + * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF + * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. + */ + +#include "rsi_main.h" +#include "rsi_coex.h" +#include "rsi_mgmt.h" +#include "rsi_hal.h" + +static enum rsi_coex_queues rsi_coex_determine_coex_q + (struct rsi_coex_ctrl_block *coex_cb) +{ + enum rsi_coex_queues q_num = RSI_COEX_Q_INVALID; + + if (skb_queue_len(&coex_cb->coex_tx_qs[RSI_COEX_Q_COMMON]) > 0) + q_num = RSI_COEX_Q_COMMON; + if (skb_queue_len(&coex_cb->coex_tx_qs[RSI_COEX_Q_BT]) > 0) + q_num = RSI_COEX_Q_BT; + if (skb_queue_len(&coex_cb->coex_tx_qs[RSI_COEX_Q_WLAN]) > 0) + q_num = RSI_COEX_Q_WLAN; + + return q_num; +} + +static void rsi_coex_sched_tx_pkts(struct rsi_coex_ctrl_block *coex_cb) +{ + enum rsi_coex_queues coex_q = RSI_COEX_Q_INVALID; + struct sk_buff *skb; + + do { + coex_q = rsi_coex_determine_coex_q(coex_cb); + rsi_dbg(INFO_ZONE, "queue = %d\n", coex_q); + + if (coex_q ==
[v8 1/8] rsi: add rx control block to handle rx packets in USB
From: Prameela Rani Garnepudi Rx bluetooth endpoint shall be added in further patches. Rx control block is introduced here to handle Rx packets properly. Separate function is written to initialize the RX control blocks. Signed-off-by: Prameela Rani Garnepudi Signed-off-by: Siva Rebbagondla Signed-off-by: Amitkumar Karwar --- v8: Same as v6, v7 v6: Removed unnecessary GFP_DMA flag for kzalloc(Kalle) v5: Same as earlier version --- drivers/net/wireless/rsi/rsi_91x_main.c | 4 +- drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 2 +- drivers/net/wireless/rsi/rsi_91x_usb.c | 75 +++-- drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 35 +- drivers/net/wireless/rsi/rsi_common.h | 2 +- drivers/net/wireless/rsi/rsi_main.h | 2 +- drivers/net/wireless/rsi/rsi_usb.h | 10 +++- 7 files changed, 96 insertions(+), 34 deletions(-) diff --git a/drivers/net/wireless/rsi/rsi_91x_main.c b/drivers/net/wireless/rsi/rsi_91x_main.c index 0cb8e68..0413af8 100644 --- a/drivers/net/wireless/rsi/rsi_91x_main.c +++ b/drivers/net/wireless/rsi/rsi_91x_main.c @@ -137,7 +137,7 @@ static struct sk_buff *rsi_prepare_skb(struct rsi_common *common, * * Return: 0 on success, -1 on failure. */ -int rsi_read_pkt(struct rsi_common *common, s32 rcv_pkt_len) +int rsi_read_pkt(struct rsi_common *common, u8 *rx_pkt, s32 rcv_pkt_len) { u8 *frame_desc = NULL, extended_desc = 0; u32 index, length = 0, queueno = 0; @@ -146,7 +146,7 @@ int rsi_read_pkt(struct rsi_common *common, s32 rcv_pkt_len) index = 0; do { - frame_desc = &common->rx_data_pkt[index]; + frame_desc = &rx_pkt[index]; actual_length = *(u16 *)&frame_desc[0]; offset = *(u16 *)&frame_desc[2]; diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c index 8e2a95c..9fbc0ef 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio_ops.c @@ -118,7 +118,7 @@ static int rsi_process_pkt(struct rsi_common *common) goto fail; } - status = rsi_read_pkt(common, rcv_pkt_len); + status = rsi_read_pkt(common, common->rx_data_pkt, rcv_pkt_len); fail: kfree(common->rx_data_pkt); diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c b/drivers/net/wireless/rsi/rsi_91x_usb.c index 8f84438..bbce809 100644 --- a/drivers/net/wireless/rsi/rsi_91x_usb.c +++ b/drivers/net/wireless/rsi/rsi_91x_usb.c @@ -247,12 +247,13 @@ static int rsi_usb_reg_write(struct usb_device *usbdev, */ static void rsi_rx_done_handler(struct urb *urb) { - struct rsi_hw *adapter = urb->context; - struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev; + struct rx_usb_ctrl_block *rx_cb = urb->context; + struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)rx_cb->data; if (urb->status) return; + rx_cb->pend = 1; rsi_set_event(&dev->rx_thread.event); } @@ -262,10 +263,11 @@ static void rsi_rx_done_handler(struct urb *urb) * * Return: 0 on success, a negative error code on failure. */ -static int rsi_rx_urb_submit(struct rsi_hw *adapter) +static int rsi_rx_urb_submit(struct rsi_hw *adapter, u8 ep_num) { struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev; - struct urb *urb = dev->rx_usb_urb[0]; + struct rx_usb_ctrl_block *rx_cb = &dev->rx_cb[ep_num - 1]; + struct urb *urb = rx_cb->rx_urb; int status; usb_fill_bulk_urb(urb, @@ -275,7 +277,7 @@ static int rsi_rx_urb_submit(struct rsi_hw *adapter) urb->transfer_buffer, 3000, rsi_rx_done_handler, - adapter); + rx_cb); status = usb_submit_urb(urb, GFP_KERNEL); if (status) @@ -484,14 +486,54 @@ static struct rsi_host_intf_ops usb_host_intf_ops = { */ static void rsi_deinit_usb_interface(struct rsi_hw *adapter) { + u8 idx; + struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev; rsi_kill_thread(&dev->rx_thread); - usb_free_urb(dev->rx_usb_urb[0]); + + for (idx = 0; idx < MAX_RX_URBS; idx++) { + usb_free_urb(dev->rx_cb[idx].rx_urb); + kfree(dev->rx_cb[idx].rx_buffer); + } + kfree(adapter->priv->rx_data_pkt); kfree(dev->tx_buffer); } +static int rsi_usb_init_rx(struct rsi_hw *adapter) +{ + struct rsi_91x_usbdev *dev = (struct rsi_91x_usbdev *)adapter->rsi_dev; + struct rx_usb_ctrl_block *rx_cb; + u8 idx; + + for (idx = 0; idx < MAX_RX_URBS; idx++) { + rx_cb = &dev->rx_cb[idx]; + + rx_cb->rx_buffer = kzalloc(RSI_USB_BUF_SIZE * 2, + GFP_KERNEL); + if (!rx_cb->rx_buffer) +
[v8 0/8] rsi: add bluetooth and coex support
From: Amitkumar Karwar This patch series adds new bluetooth driver and coex enhancments in existing wlan driver for RSI chipsets. As per our architecture, both wlan and bluetooth drivers talk over same SDIO interface to device. Separate endpoint will be used in case of USB interface. Change in v8: 4/8, 5/8 are modified Change in v7: 4/8 is modified Changes in v6: 1/8, 3/8, 4/8, 5/8, 6/8 are modified Changes in v5: 5/8 is modified Changes in v4: 5/8 is modified Changes in v3: 4/8, 5/8 and 6/8 patches are modified Changes in v2: 2/8, 5/8 and 6/8 patches are modified Prameela Rani Garnepudi (6): rsi: add rx control block to handle rx packets in USB rsi: add header file rsi_91x rsi: add coex support Bluetooth: btrsi: add new rsi bluetooth driver rsi: add module parameter operating mode rsi: sdio changes to support BT Siva Rebbagondla (2): rsi: add bluetooth rx endpoint rsi: handle BT traffic in driver drivers/bluetooth/Kconfig | 12 ++ drivers/bluetooth/Makefile | 2 + drivers/bluetooth/btrsi.c | 188 drivers/net/wireless/rsi/Kconfig| 9 ++ drivers/net/wireless/rsi/Makefile | 1 + drivers/net/wireless/rsi/rsi_91x_coex.c | 179 ++ drivers/net/wireless/rsi/rsi_91x_core.c | 20 ++- drivers/net/wireless/rsi/rsi_91x_hal.c | 56 +++-- drivers/net/wireless/rsi/rsi_91x_main.c | 129 ++- drivers/net/wireless/rsi/rsi_91x_mgmt.c | 2 +- drivers/net/wireless/rsi/rsi_91x_sdio.c | 13 +- drivers/net/wireless/rsi/rsi_91x_sdio_ops.c | 5 +- drivers/net/wireless/rsi/rsi_91x_usb.c | 124 +- drivers/net/wireless/rsi/rsi_91x_usb_ops.c | 35 -- drivers/net/wireless/rsi/rsi_coex.h | 37 ++ drivers/net/wireless/rsi/rsi_common.h | 5 +- drivers/net/wireless/rsi/rsi_hal.h | 21 drivers/net/wireless/rsi/rsi_main.h | 21 ++-- drivers/net/wireless/rsi/rsi_mgmt.h | 3 + drivers/net/wireless/rsi/rsi_usb.h | 16 ++- include/net/rsi_91x.h | 56 + 21 files changed, 852 insertions(+), 82 deletions(-) create mode 100644 drivers/bluetooth/btrsi.c create mode 100644 drivers/net/wireless/rsi/rsi_91x_coex.c create mode 100644 drivers/net/wireless/rsi/rsi_coex.h create mode 100644 include/net/rsi_91x.h -- 2.7.4
Re: brcmfmac signal/interference issues
On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel wrote: > Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | > tail -1' you can see the firmware build target and it likely has 'ndis' in > it. 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf Yes, ndis. So no easy way to run the same firmware on the 2 OSes. > Now are you using BT as well on this device? Another suggestion I got is to > disable transmit beamforming which brcmfmac enables by default. Not sure if > this device supports it, but could you try the patch below. Thanks for the ideas. I had already tried with the bluetooth disabled - no change there. Also reproduced the problem after applying your patch. Daniel
[PATCH] brcm80211: remove duplicated bit-wise or of IEEE80211_CHAN_NO_IR
From: Colin Ian King Bit pattern IEEE80211_CHAN_NO_IR is being bit-wise or'd twice; remove the redundant 2nd IEEE80211_CHAN_NO_IR Signed-off-by: Colin Ian King --- drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c index 3a03287fa912..db783e94f929 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmsmac/channel.c @@ -652,7 +652,6 @@ static void brcms_reg_apply_radar_flags(struct wiphy *wiphy) */ if (!(ch->flags & IEEE80211_CHAN_DISABLED)) ch->flags |= IEEE80211_CHAN_RADAR | -IEEE80211_CHAN_NO_IR | IEEE80211_CHAN_NO_IR; } } -- 2.15.1
[PATCH v2] mac80211: support station 4-addr mode fast-rx
Signed-off-by: Felix Fietkau --- net/mac80211/rx.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 6e2506a84586..6944705c5258 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3747,10 +3747,6 @@ void ieee80211_check_fast_rx(struct sta_info *sta) switch (sdata->vif.type) { case NL80211_IFTYPE_STATION: - /* 4-addr is harder to deal with, later maybe */ - if (sdata->u.mgd.use_4addr) - goto clear; - if (sta->sta.tdls) { fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1); fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2); @@ -3763,6 +3759,13 @@ void ieee80211_check_fast_rx(struct sta_info *sta) cpu_to_le16(IEEE80211_FCTL_FROMDS); } + if (sdata->u.mgd.use_4addr && !sta->sta.tdls) { + fastrx.expected_ds_bits |= + cpu_to_le16(IEEE80211_FCTL_TODS); + fastrx.da_offs = offsetof(struct ieee80211_hdr, addr3); + fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4); + } + if (!sdata->u.mgd.powersave) break; -- 2.14.2
Re: [PATCH 4/4] mac80211: support station 4-addr mode fast-rx
On 2018-02-23 12:24, Johannes Berg wrote: > On Fri, 2018-02-23 at 10:06 +0100, Felix Fietkau wrote: >> Signed-off-by: Felix Fietkau >> --- >> net/mac80211/cfg.c | 2 -- >> net/mac80211/rx.c | 11 +++ >> 2 files changed, 7 insertions(+), 6 deletions(-) >> >> diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c >> index 6f9d5beec73e..72b5a2ec4e94 100644 >> --- a/net/mac80211/cfg.c >> +++ b/net/mac80211/cfg.c >> @@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy, >> if (type == NL80211_IFTYPE_AP_VLAN && >> params && params->use_4addr == 0) { >> RCU_INIT_POINTER(sdata->u.vlan.sta, NULL); >> -ieee80211_check_fast_rx_iface(sdata); >> } else if (type == NL80211_IFTYPE_STATION && >> params && params->use_4addr >= 0) { >> sdata->u.mgd.use_4addr = params->use_4addr; >> @@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy >> *wiphy, >> } >> >> rcu_assign_pointer(vlansdata->u.vlan.sta, sta); >> -__ieee80211_check_fast_rx_iface(vlansdata); >> } >> >> if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN && > > I'm not convinced this is right - don't you have to recheck to modify > the station data? Otherwise you'd just drop all the frames to the > slowpath again due to the first patch in the series, no?You're right and I > forgot to take those out before sending. Will resubmit this one. Thanks, - Felix
[PATCH] ath: fix false radar detection in JP region
From: Sriram R This fixes false radar detection (of radar type 7) in Japan region by correcting the radar pulse type to Chirp as per specification. Signed-off-by: Sriram R --- drivers/net/wireless/ath/dfs_pattern_detector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/wireless/ath/dfs_pattern_detector.c b/drivers/net/wireless/ath/dfs_pattern_detector.c index 4100ffd..448b83e 100644 --- a/drivers/net/wireless/ath/dfs_pattern_detector.c +++ b/drivers/net/wireless/ath/dfs_pattern_detector.c @@ -115,7 +115,7 @@ static const struct radar_detector_specs jp_radar_ref_types[] = { JP_PATTERN(4, 0, 5, 150, 230, 1, 23, 50, false), JP_PATTERN(5, 6, 10, 200, 500, 1, 16, 50, false), JP_PATTERN(6, 11, 20, 200, 500, 1, 12, 50, false), - JP_PATTERN(7, 50, 100, 1000, 2000, 1, 3, 50, false), + JP_PATTERN(7, 50, 100, 1000, 2000, 1, 3, 50, true), JP_PATTERN(5, 0, 1, 333, 333, 1, 9, 50, false), }; -- 2.7.4
Re: [PATCH v2] cfg80211/nl80211: add DFS offload flag
On Thu, 2018-02-22 at 12:15 +0300, Sergey Matyukevich wrote: > From: Dmitry Lebed > > Add wiphy EXT_FEATURE flag to indicate that HW or driver does > all DFS actions by itself. > User-space functionality already implemented in hostapd using > vendor-specific (QCA) OUI to advertise DFS offload support. > Need to introduce generic flag to inform about DFS offload support. > For deivces with DFS_OFFLOAD flag set user-space will no longer > need to issue CAC or do any actions in response to > "radar detected" events. HW will do everything by itself and send > events to user-space to indicate that CAC was started/finished, etc. > > + * @NL80211_EXT_FEATURE_DFS_OFFLOAD: HW/driver will offload DFS actions. > + * Device or driver will do all DFS-related actions by itself, > + * informing user-space about CAC progress, radar detection event, > + * channel change triggered by radar detection event. > + * No need to start CAC from user-space, no need to react to > + * "radar detected" event. The "channel change" part bothers me a bit - isn't normally hostapd very much in control of the channel? How does it even get notified of the new channel? How can you configure the parameters like how many beacons to include the (E)CSA IE for, and whether to add ECSA or not etc? johannes
Re: pull-request: mac80211-next 2018-02-22
On Thu, 2018-02-22 at 15:19 -0500, David Miller wrote: > > Pulled, thank you! Thanks. I just realized that I have a patch pending for -next that depends another commit in net/mac80211 (or would otherwise conflict badly while applying, and again while merging later), could I ask you to pull net into net-next at some point now? Thanks, johannes
Re: [PATCH 3/4] mac80211: support fast-rx with incompatible PS capabilities when PS is disabled
I've applied 1 to mac80211, and 2/3 to mac80211-next, so please only resend 4, unless you can convince me it's OK as is :-) johannes
Re: [PATCH 4/4] mac80211: support station 4-addr mode fast-rx
On Fri, 2018-02-23 at 10:06 +0100, Felix Fietkau wrote: > Signed-off-by: Felix Fietkau > --- > net/mac80211/cfg.c | 2 -- > net/mac80211/rx.c | 11 +++ > 2 files changed, 7 insertions(+), 6 deletions(-) > > diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c > index 6f9d5beec73e..72b5a2ec4e94 100644 > --- a/net/mac80211/cfg.c > +++ b/net/mac80211/cfg.c > @@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy, > if (type == NL80211_IFTYPE_AP_VLAN && > params && params->use_4addr == 0) { > RCU_INIT_POINTER(sdata->u.vlan.sta, NULL); > - ieee80211_check_fast_rx_iface(sdata); > } else if (type == NL80211_IFTYPE_STATION && > params && params->use_4addr >= 0) { > sdata->u.mgd.use_4addr = params->use_4addr; > @@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy *wiphy, > } > > rcu_assign_pointer(vlansdata->u.vlan.sta, sta); > - __ieee80211_check_fast_rx_iface(vlansdata); > } > > if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN && I'm not convinced this is right - don't you have to recheck to modify the station data? Otherwise you'd just drop all the frames to the slowpath again due to the first patch in the series, no? johannes
Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump
Hey, Hadn't really followed this discussion much due to other fires elsewhere :-) On Fri, 2018-02-23 at 11:39 +0100, Arend van Spriel wrote: > > > Well, that depends on the eye of the beholder I guess. From user-space > > > perspective it is asynchronous regardless. A write access to the coredump > > > sysfs file eventually results in a uevent when the devcoredump entry is > > > created, ie. after driver has made a dev_coredump API call. Whether the > > > driver does that synchronously or asynchronously is irrelevant as far as > > > user-space is concerned. > > > > Is it really? The driver infrastructure seems to guarantee that the > > entirety of a driver's ->coredump() will complete before returning from > > the write. So it might be reasonable for some user to assume (based on > > implementation details, e.g., of brcmfmac) that the devcoredump will be > > ready by the time the write() syscall returns, absent documentation that > > says otherwise. But then, that's not how mwifiex works right now, so > > they might be surprised if they switch drivers. I can see how you might want to have that kind of behaviour, but you'd have to jump through some hoops to see if the coredump you saw is actually the right one - you probably want an asynchronous coredump "collector" and then wait for it to show up (with some reasonable timeout) on the actual filesystem, not on sysfs? Otherwise you have to trawl sysfs for the right coredump I guess, which too is possible. > > > You are right. Clearly I did not reach the end my learning curve here. I > > > assumed referring to the existing dev_coredump facility was sufficient, > > > but > > > maybe it is worth a patch to be more explicit and mention the uevent > > > behavior. Also dev_coredump facility may be disabled upon which the > > > trigger > > > will have no effect in sysfs. In the kernel the data passed by the driver > > > is > > > simply freed by dev_coredump facility. > > > > Is there any other documentation for the coredump feature? I don't > > really see much. > > Any other than the code itself you mean? I am not sure. Maybe Johannes > knows. There isn't really, it originally was really simple, but then somebody (Kees perhaps?) requested a way to turn it off forever for security or privacy concerns and it became more complicated. > > static ssize_t coredump_store(struct device *dev, struct device_attribute > > *attr, > > const char *buf, size_t count) > > { > > device_lock(dev); > > if (dev->driver->coredump) > > dev->driver->coredump(dev); > > device_unlock(dev); > > > > return count; > > } > > static DEVICE_ATTR_WO(coredump); > > > > Is that a bug or a feature? > > Yeah. Let's call it a bug. Just not sure what to go for. Return the > error or change coredump callback to void return type. I'm not sure it matters all that much - the underlying devcoredump calls all have no return value (void), and given the above complexities with the ability to turn off devcoredumping entirely you cannot rely on this return value to tell you if a dump was created or not, at least not without much more infrastructure work. johannes
[stable 4.4 17/29] nl80211: Sanitize array index in parse_txq_params
From: Dan Williams (cherry picked from commit 259d8c1e984318497c84eef547bbb6b1d9f4eb05) Wireless drivers rely on parse_txq_params to validate that txq_params->ac is less than NL80211_NUM_ACS by the time the low-level driver's ->conf_tx() handler is called. Use a new helper, array_index_nospec(), to sanitize txq_params->ac with respect to speculation. I.e. ensure that any speculation into ->conf_tx() handlers is done with a value of txq_params->ac that is within the bounds of [0, NL80211_NUM_ACS). Reported-by: Christian Lamparter Reported-by: Elena Reshetova Signed-off-by: Dan Williams Signed-off-by: Thomas Gleixner Acked-by: Johannes Berg Cc: linux-a...@vger.kernel.org Cc: kernel-harden...@lists.openwall.com Cc: gre...@linuxfoundation.org Cc: linux-wireless@vger.kernel.org Cc: torva...@linux-foundation.org Cc: "David S. Miller" Cc: a...@linux.intel.com Link: https://lkml.kernel.org/r/151727419584.33451.7700736761686184303.st...@dwillia2-desk3.amr.corp.intel.com Signed-off-by: David Woodhouse Signed-off-by: Greg Kroah-Hartman [jwang: cherry pick to 4.4] Signed-off-by: Jack Wang --- net/wireless/nl80211.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index 7950506..b0b58d1 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include #include @@ -1879,20 +1880,22 @@ static const struct nla_policy txq_params_policy[NL80211_TXQ_ATTR_MAX + 1] = { static int parse_txq_params(struct nlattr *tb[], struct ieee80211_txq_params *txq_params) { + u8 ac; + if (!tb[NL80211_TXQ_ATTR_AC] || !tb[NL80211_TXQ_ATTR_TXOP] || !tb[NL80211_TXQ_ATTR_CWMIN] || !tb[NL80211_TXQ_ATTR_CWMAX] || !tb[NL80211_TXQ_ATTR_AIFS]) return -EINVAL; - txq_params->ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]); + ac = nla_get_u8(tb[NL80211_TXQ_ATTR_AC]); txq_params->txop = nla_get_u16(tb[NL80211_TXQ_ATTR_TXOP]); txq_params->cwmin = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMIN]); txq_params->cwmax = nla_get_u16(tb[NL80211_TXQ_ATTR_CWMAX]); txq_params->aifs = nla_get_u8(tb[NL80211_TXQ_ATTR_AIFS]); - if (txq_params->ac >= NL80211_NUM_ACS) + if (ac >= NL80211_NUM_ACS) return -EINVAL; - + txq_params->ac = array_index_nospec(ac, NL80211_NUM_ACS); return 0; } -- 2.7.4
Re: [PATCH 2/3] mwifiex: support sysfs initiated device coredump
+ Johannes (for devcoredump documentation question). On 2/22/2018 8:35 PM, Brian Norris wrote: Hi Arend, On Thu, Feb 22, 2018 at 01:17:56PM +0100, Arend van Spriel wrote: On 2/21/2018 11:59 PM, Brian Norris wrote: On Wed, Feb 21, 2018 at 11:50:19AM +0100, Arend van Spriel wrote: Since commit 3c47d19ff4dc ("drivers: base: add coredump driver ops") it is possible to initiate a device coredump from user-space. This patch adds support for it adding the .coredump() driver callback. As there is no longer a need to initiate it through debugfs remove that code. Signed-off-by: Arend van Spriel --- drivers/net/wireless/marvell/mwifiex/debugfs.c | 31 +- drivers/net/wireless/marvell/mwifiex/pcie.c| 19 ++-- drivers/net/wireless/marvell/mwifiex/sdio.c| 13 +++ drivers/net/wireless/marvell/mwifiex/usb.c | 14 4 files changed, 45 insertions(+), 32 deletions(-) The documentation doesn't really say [1], but is the coredump supposed to happen synchronously? Because the mwifiex implementation is asynchronous, whereas it looks like the brcmfmac one is synchronous. Well, that depends on the eye of the beholder I guess. From user-space perspective it is asynchronous regardless. A write access to the coredump sysfs file eventually results in a uevent when the devcoredump entry is created, ie. after driver has made a dev_coredump API call. Whether the driver does that synchronously or asynchronously is irrelevant as far as user-space is concerned. Is it really? The driver infrastructure seems to guarantee that the entirety of a driver's ->coredump() will complete before returning from the write. So it might be reasonable for some user to assume (based on implementation details, e.g., of brcmfmac) that the devcoredump will be ready by the time the write() syscall returns, absent documentation that says otherwise. But then, that's not how mwifiex works right now, so they might be surprised if they switch drivers. Ok. I already agreed that the uevent behavior should be documented. The error handling you are bringing up below was something I realized as well. I am not familiar with mwifiex to determine what it can say about the coredump succeeding before scheduling the work. Anyway, *I'm* already personally used to these dumps being asynchronous, and writing tooling to listen for the uevent instead. But that doesn't mean everyone will be. Also, due to the differences in async/sync, mwifiex doesn't really provide you much chance for error handling, because most errors would be asynchronous. So brcmfmac's "coredump" has more chance for user programs to error-check than mwifiex's (due to the asynchronous nature) [1]. BTW, I push on this mostly because this is migrating from a debugfs feature (that is easy to hand-wave off as not really providing a consistent/stable API, etc., etc.) to a documented sysfs feature. If it were left to rot in debugfs, I probably wouldn't be as bothered ;) I appreciate it. The documentation is not in the stable ABI folder yet so I welcome any and all improvements. Might learn a thing or two from it. Brian [1] In fact, the ABI documentation really just describes kernel internals, rather than documenting any user-facing details, from what I can tell. You are right. Clearly I did not reach the end my learning curve here. I assumed referring to the existing dev_coredump facility was sufficient, but maybe it is worth a patch to be more explicit and mention the uevent behavior. Also dev_coredump facility may be disabled upon which the trigger will have no effect in sysfs. In the kernel the data passed by the driver is simply freed by dev_coredump facility. Is there any other documentation for the coredump feature? I don't really see much. Any other than the code itself you mean? I am not sure. Maybe Johannes knows. Brian [1] Oh wait, but I see that while ->coredump() has an integer return code...the caller ignores it: static ssize_t coredump_store(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) { device_lock(dev); if (dev->driver->coredump) dev->driver->coredump(dev); device_unlock(dev); return count; } static DEVICE_ATTR_WO(coredump); Is that a bug or a feature? Yeah. Let's call it a bug. Just not sure what to go for. Return the error or change coredump callback to void return type. Regards, Arend
Re: brcmfmac signal/interference issues
On 2/23/2018 9:26 AM, Daniel Drake wrote: Hi, On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake wrote: Thanks for looking into this. Here is the brcmfmac43455-sdio.txt file we are using: https://gist.github.com/dsd/d7ee3caa6dfd77f0bcd16cf272b20298 This is identical to the 4345r6nvram.txt file from windows. I checked Windows again and it seems to be using a firmware file 4345r6rtecdc.bin alongside this nvram data. This firmware is different from the one in linux-firmware. I've uploaded it here: https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_ I was hoping to try this on Linux to see if it makes any difference to the issue seen here. However, with thisi firmware in place, I can't connect to the network at all. It associates, wpa_supplicant never sees the first WPA2 key message sent from the AP - even though wireshark on a separate monitor shows that the key message was sent, and that the STA acked it. I turned off WPA2 to make it an open network instead, and now I am unable to complete the DHCP conversation. According to the monitor station, the STA succesfully transmits DHCPDISCOVER and the AP responds with DHCPOFFER. The offer is acked, but dhclient never sees it, and eventually times out. Any ideas why this firmware may not be working at all on linux? Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | tail -1' you can see the firmware build target and it likely has 'ndis' in it. Now are you using BT as well on this device? Another suggestion I got is to disable transmit beamforming which brcmfmac enables by default. Not sure if this device supports it, but could you try the patch below. Regards, Arend diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 9be0b05..512ea57 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -363,9 +363,6 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) goto done; } - /* Enable tx beamforming, errors can be ignored (not supported) */ - (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1); - /* do bus specific preinit here */ err = brcmf_bus_preinit(ifp->drvr->bus_if); done:
Re: [PATCH] rtlwifi: rtl8723be: Fix loss of signal
Larry Finger writes: > In commit c713fb071edc ("rtlwifi: rtl8821ae: Fix connection lost problem > correctly") a problem in rtl8821ae that caused loss of signal was fixed. > That same problem has now been reported for rtl8723be. Accordingly, > the ASPM L1 latency has been increased from 0 to 7 to fix the instability. > > Signed-off-by: Larry Finger > Cc: Stable > --- > Kalle, > > This patch should be sent to 4.16. Ok, I'll queue this for 4.16. -- Kalle Valo
[PATCH 1/4] mac80211: drop frames with unexpected DS bits from fast-rx to slow path
Fixes rx for 4-addr packets in AP mode Signed-off-by: Felix Fietkau --- net/mac80211/rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 3dc162ddc3a6..1c947e005434 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3937,7 +3937,7 @@ static bool ieee80211_invoke_fast_rx(struct ieee80211_rx_data *rx, if ((hdr->frame_control & cpu_to_le16(IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS)) != fast_rx->expected_ds_bits) - goto drop; + return false; /* assign the key to drop unencrypted frames (later) * and strip the IV/MIC if necessary -- 2.14.2
[PATCH 2/4] mac80211: support AP 4-addr mode fast-rx
Signed-off-by: Felix Fietkau --- net/mac80211/rx.c | 9 + 1 file changed, 9 insertions(+) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 1c947e005434..bef83c6bf50c 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3783,6 +3783,15 @@ void ieee80211_check_fast_rx(struct sta_info *sta) !(sdata->flags & IEEE80211_SDATA_DONT_BRIDGE_PACKETS) && (sdata->vif.type != NL80211_IFTYPE_AP_VLAN || !sdata->u.vlan.sta); + + if (sdata->vif.type == NL80211_IFTYPE_AP_VLAN && + sdata->u.vlan.sta) { + fastrx.expected_ds_bits |= + cpu_to_le16(IEEE80211_FCTL_FROMDS); + fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4); + fastrx.internal_forward = 0; + } + break; default: goto clear; -- 2.14.2
[PATCH 4/4] mac80211: support station 4-addr mode fast-rx
Signed-off-by: Felix Fietkau --- net/mac80211/cfg.c | 2 -- net/mac80211/rx.c | 11 +++ 2 files changed, 7 insertions(+), 6 deletions(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 6f9d5beec73e..72b5a2ec4e94 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -160,7 +160,6 @@ static int ieee80211_change_iface(struct wiphy *wiphy, if (type == NL80211_IFTYPE_AP_VLAN && params && params->use_4addr == 0) { RCU_INIT_POINTER(sdata->u.vlan.sta, NULL); - ieee80211_check_fast_rx_iface(sdata); } else if (type == NL80211_IFTYPE_STATION && params && params->use_4addr >= 0) { sdata->u.mgd.use_4addr = params->use_4addr; @@ -1575,7 +1574,6 @@ static int ieee80211_change_station(struct wiphy *wiphy, } rcu_assign_pointer(vlansdata->u.vlan.sta, sta); - __ieee80211_check_fast_rx_iface(vlansdata); } if (sta->sdata->vif.type == NL80211_IFTYPE_AP_VLAN && diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 6e2506a84586..6944705c5258 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3747,10 +3747,6 @@ void ieee80211_check_fast_rx(struct sta_info *sta) switch (sdata->vif.type) { case NL80211_IFTYPE_STATION: - /* 4-addr is harder to deal with, later maybe */ - if (sdata->u.mgd.use_4addr) - goto clear; - if (sta->sta.tdls) { fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1); fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2); @@ -3763,6 +3759,13 @@ void ieee80211_check_fast_rx(struct sta_info *sta) cpu_to_le16(IEEE80211_FCTL_FROMDS); } + if (sdata->u.mgd.use_4addr && !sta->sta.tdls) { + fastrx.expected_ds_bits |= + cpu_to_le16(IEEE80211_FCTL_TODS); + fastrx.da_offs = offsetof(struct ieee80211_hdr, addr3); + fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr4); + } + if (!sdata->u.mgd.powersave) break; -- 2.14.2
[PATCH 3/4] mac80211: support fast-rx with incompatible PS capabilities when PS is disabled
When powersave is disabled for the interface, we can do fast-rx anyway. Signed-off-by: Felix Fietkau --- net/mac80211/cfg.c | 1 + net/mac80211/rx.c | 17 +++-- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c index 46028e12e216..6f9d5beec73e 100644 --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -2685,6 +2685,7 @@ static int ieee80211_set_power_mgmt(struct wiphy *wiphy, struct net_device *dev, ieee80211_recalc_ps(local); ieee80211_recalc_ps_vif(sdata); + ieee80211_check_fast_rx_iface(sdata); return 0; } diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index bef83c6bf50c..6e2506a84586 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -3750,12 +3750,7 @@ void ieee80211_check_fast_rx(struct sta_info *sta) /* 4-addr is harder to deal with, later maybe */ if (sdata->u.mgd.use_4addr) goto clear; - /* software powersave is a huge mess, avoid all of it */ - if (ieee80211_hw_check(&local->hw, PS_NULLFUNC_STACK)) - goto clear; - if (ieee80211_hw_check(&local->hw, SUPPORTS_PS) && - !ieee80211_hw_check(&local->hw, SUPPORTS_DYNAMIC_PS)) - goto clear; + if (sta->sta.tdls) { fastrx.da_offs = offsetof(struct ieee80211_hdr, addr1); fastrx.sa_offs = offsetof(struct ieee80211_hdr, addr2); @@ -3767,6 +3762,16 @@ void ieee80211_check_fast_rx(struct sta_info *sta) fastrx.expected_ds_bits = cpu_to_le16(IEEE80211_FCTL_FROMDS); } + + if (!sdata->u.mgd.powersave) + break; + + /* software powersave is a huge mess, avoid all of it */ + if (ieee80211_hw_check(&local->hw, PS_NULLFUNC_STACK)) + goto clear; + if (ieee80211_hw_check(&local->hw, SUPPORTS_PS) && + !ieee80211_hw_check(&local->hw, SUPPORTS_DYNAMIC_PS)) + goto clear; break; case NL80211_IFTYPE_AP_VLAN: case NL80211_IFTYPE_AP: -- 2.14.2
Re: brcmfmac signal/interference issues
Hi, On Wed, Feb 21, 2018 at 12:39 PM, Daniel Drake wrote: > Thanks for looking into this. Here is the brcmfmac43455-sdio.txt file > we are using: > https://gist.github.com/dsd/d7ee3caa6dfd77f0bcd16cf272b20298 > This is identical to the 4345r6nvram.txt file from windows. I checked Windows again and it seems to be using a firmware file 4345r6rtecdc.bin alongside this nvram data. This firmware is different from the one in linux-firmware. I've uploaded it here: https://drive.google.com/open?id=1MUsiaoozslJb8SCYOR-FNbJFuD-h4PY_ I was hoping to try this on Linux to see if it makes any difference to the issue seen here. However, with thisi firmware in place, I can't connect to the network at all. It associates, wpa_supplicant never sees the first WPA2 key message sent from the AP - even though wireshark on a separate monitor shows that the key message was sent, and that the STA acked it. I turned off WPA2 to make it an open network instead, and now I am unable to complete the DHCP conversation. According to the monitor station, the STA succesfully transmits DHCPDISCOVER and the AP responds with DHCPOFFER. The offer is acked, but dhclient never sees it, and eventually times out. Any ideas why this firmware may not be working at all on linux? Thanks, Daniel
Re: [PATCH v8] ath10k: add LED and GPIO controlling support for various chipsets
Hi Sebastian, Thank you for the patch! Yet something to improve: [auto build test ERROR on wireless-drivers-next/master] [also build test ERROR on v4.16-rc2 next-20180223] [cannot apply to ath6kl/ath-next] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/s-gottschall-dd-wrt-com/ath10k-add-LED-and-GPIO-controlling-support-for-various-chipsets/20180221-134523 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next.git master config: i386-randconfig-b0-02231423 (attached as .config) compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4 reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): drivers/net//wireless/ath/ath10k/core.c: In function 'ath10k_attach_led': >> drivers/net//wireless/ath/ath10k/core.c:2331:3: error: implicit declaration >> of function 'ath10k_add_led' [-Werror=implicit-function-declaration] ath10k_add_led(ar, &ar->gpio->wifi_led); ^ cc1: some warnings being treated as errors vim +/ath10k_add_led +2331 drivers/net//wireless/ath/ath10k/core.c 2322 2323 static void ath10k_attach_led(struct ath10k *ar) 2324 { 2325 if (!ar->gpio_attached) { 2326 ar->gpio->wifi_led.active_low = 1; 2327 ar->gpio->wifi_led.gpio = ar->hw_params.led_pin; 2328 ar->gpio->wifi_led.name = ar->gpio->label; 2329 ar->gpio->wifi_led.default_state = LEDS_GPIO_DEFSTATE_KEEP; 2330 > 2331 ath10k_add_led(ar, &ar->gpio->wifi_led); 2332 } 2333 ath10k_reset_led_pin(ar); /* initially we need to configure the led pin to output */ 2334 } 2335 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip