RE: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values
> Hi > > 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel > : > > > > > > On 01/26/2016 12:20 AM, Nikolay Martynov wrote: > >> It looks like sometimes firmware returns zero for chain noise and > >> signal during calibration period. This seems to be a known problem > >> and current implementation accounts for this by ignoring invalid data > >> when all chains return zero signal and noise. > >> > >> The problem is that sometimes firmware returns zero for only one > >> chain for some (not all) beacons used for calibration. This leads to > >> perfectly valid chains be disabled and may cause invalid gain settings. > >> For example this is calibration data taken on laptop with Intel 6300 > >> card with all three antennas attached: > >> > >> active_chains: 3 > >> chain_noise_a: 312 > >> chain_noise_b: 297 > >> chain_noise_c: 0 > >> chain_signal_a:549 > >> chain_signal_b:513 > >> chain_signal_c:0 > >> beacon_count: 16 > >> disconn_array: 0 0 1 > >> delta_gain_code: 4 0 0 > >> radio_write: 1 > >> state: 3 > >> > >> This patch changes statistics gathering to make sure that zero noise > >> results are ignored for valid rx chains. The rationale being that > >> even if anntenna is not connected we should be able to see non zero > >> noise if rx chain is present. > > > > But then the firmware will continue to send zero for signal and this > > will impact lots of flows like roaming. If the driver allows the > > firmware to use that antenna, the firmware may use this antenna for > > scanning and roaming will be broken. > > This seems to be a bug in the firmware, but there isn't much I can do > > about it. > > Sorry, I have to NACK this patch. > > Could you please elaborate on how this patch would affect roaming or other > things. As far as I can see this patch doesn't change much behavior apart > from ignoring invalid values from firmware. > Disconnected antennas still get disabled (as before) connected antennas still > work (more often than before). So I'm not sure I can see how this patch > would change what firmware does at all. I really hope you could find a > moment and explain this. > What you are saying here is that there is a bug in the firmware which makes it report wrong values for one of the antennas. But when you will have this antenna enabled (with your patch), the firmware will keep sending bad signal / noise values for it. If the driver allows the firmware to use this antenna (after your patch), the firmware will choose this antenna to receive beacons or to scan. Then, the driver will look at the beacons' rssi (which will be wrong) and it will think that an AP which is very close is in fact far away. N�r��yb�X��ǧv�^�){.n�+{��*ޕ�,�{ay�ʇڙ�,j��f���h���z��w��� ���j:+v���w�j�mzZ+�ݢj"��!�i
Need direction to understand mac80211
Hi, I am currently working on an project that aims to provide multiple 802.11ac radio support on a single node for mesh network. In this both the radios will operate in different channel and will talk to different nodes in mesh network. I need to work with kernel mac80211 driver subsystem for the same. I went through different documentation to understand the theories of 802.11s which can help during working on mac80211 driver. However I am not able to understand the source code properly. Can you please provide some guidance to understand mac80211 and related networking stack in Linux kernel. I am looking for 1) How to create bridge bridge for two Phy radios during initialization/packet forwarding? 2) Also, need some idea about how packets will be routed in mesh_hwmp. 3) How the path request and response should behave in this case? 4) Will there be any changes for mesh path table entries? Any suggestion for document/book/blog will be great help. I already went through following materials. http://kernelnewbies.org/Documents/Kernel-Docbooks?action=AttachFile&do=get&target=mac80211_2.6.29.pdf http://www.campsmur.cat/files/mac80211_intro.pdf https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf http://www.ieee802.org/802_tutorials/06-November/802.11s_Tutorial_r5.pdf Any suggestion and directions will be great help. Thanks, Sunil Shahu. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/13] staging: wilc1000: fixes variable dereferenced before check
From: Leo Kim This patch fixes the warning reported by smatch. - wilc_wlan_get_firmware() warn: variable dereferenced before check 'vif' - wilc_set_multicast_list() warn: variable dereferenced before check 'dev' Just delete them and no need add null check since they are net_device from ndo_set_rx_mode of net_device_ops and vif of netdev_priv. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 9ca33536..22a2f98 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -397,9 +397,6 @@ int wilc_wlan_get_firmware(struct net_device *dev) netdev_info(dev, "loading firmware %s\n", firmware); - if (!vif) - goto _fail_; - if (!(&vif->ndev->dev)) goto _fail_; @@ -1017,9 +1014,6 @@ static void wilc_set_multicast_list(struct net_device *dev) vif = netdev_priv(dev); hif_drv = (struct host_if_drv *)priv->hif_drv; - if (!dev) - return; - if (dev->flags & IFF_PROMISC) return; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/13] staging: wilc1000: removes void function return
From: Leo Kim This patch removes the warning reported by checkpatch.pl for void function return statements are not generally useful. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index c16cc40..5c87105 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -1047,8 +1047,6 @@ static void wilc_set_multicast_list(struct net_device *dev) } wilc_setup_multicast_filter(vif, true, (dev->mc.count)); - - return; } static void linux_wlan_tx_complete(void *priv, int status) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/13] staging: wilc1000: removes unnecessary debug logs
From: Leo Kim This patch removes unnecessary debug logs. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 154 ++ 1 file changed, 24 insertions(+), 130 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index f03daff..e8b4533 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -70,47 +70,32 @@ static int dev_state_ev_handler(struct notifier_block *this, u8 null_ip[4] = {0}; char wlan_dev_name[5] = "wlan0"; - if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev) { - PRINT_D(GENERIC_DBG, "dev_iface = NULL\n"); + if (!dev_iface || !dev_iface->ifa_dev || !dev_iface->ifa_dev->dev) return NOTIFY_DONE; - } if (memcmp(dev_iface->ifa_label, "wlan0", 5) && - memcmp(dev_iface->ifa_label, "p2p0", 4)) { - PRINT_D(GENERIC_DBG, "Interface is neither WLAN0 nor P2P0\n"); + memcmp(dev_iface->ifa_label, "p2p0", 4)) return NOTIFY_DONE; - } dev = (struct net_device *)dev_iface->ifa_dev->dev; - if (!dev->ieee80211_ptr || !dev->ieee80211_ptr->wiphy) { - PRINT_D(GENERIC_DBG, "No Wireless registerd\n"); + if (!dev->ieee80211_ptr || !dev->ieee80211_ptr->wiphy) return NOTIFY_DONE; - } + priv = wiphy_priv(dev->ieee80211_ptr->wiphy); - if (!priv) { - PRINT_D(GENERIC_DBG, "No Wireless Priv\n"); + if (!priv) return NOTIFY_DONE; - } + hif_drv = (struct host_if_drv *)priv->hif_drv; vif = netdev_priv(dev); - if (!vif || !hif_drv) { - PRINT_D(GENERIC_DBG, "No Wireless Priv\n"); + if (!vif || !hif_drv) return NOTIFY_DONE; - } - - PRINT_INFO(GENERIC_DBG, "dev_state_ev_handler +++\n"); switch (event) { case NETDEV_UP: - PRINT_D(GENERIC_DBG, "dev_state_ev_handler event=NETDEV_UP %p\n", dev); - - PRINT_INFO(GENERIC_DBG, "\n == IP Address Obtained ===\n\n"); - if (vif->iftype == STATION_MODE || vif->iftype == CLIENT_MODE) { hif_drv->IFC_UP = 1; wilc_optaining_ip = false; del_timer(&wilc_during_ip_timer); - PRINT_D(GENERIC_DBG, "IP obtained , enable scan\n"); } if (wilc_enable_ps) @@ -127,9 +112,6 @@ static int dev_state_ev_handler(struct notifier_block *this, break; case NETDEV_DOWN: - PRINT_D(GENERIC_DBG, "dev_state_ev_handler event=NETDEV_DOWN %p\n", dev); - - PRINT_INFO(GENERIC_DBG, "\n == IP Address Released ===\n\n"); if (vif->iftype == STATION_MODE || vif->iftype == CLIENT_MODE) { hif_drv->IFC_UP = 0; wilc_optaining_ip = false; @@ -152,9 +134,6 @@ static int dev_state_ev_handler(struct notifier_block *this, break; default: - PRINT_INFO(GENERIC_DBG, "dev_state_ev_handler event=default\n"); - PRINT_INFO(GENERIC_DBG, "[%s] unknown dev event: %lu\n", dev_iface->ifa_label, event); - break; } @@ -169,7 +148,6 @@ static irqreturn_t isr_uh_routine(int irq, void *user_data) vif = netdev_priv(dev); wilc = vif->wilc; - PRINT_D(INT_DBG, "Interrupt received UH\n"); if (wilc->close) { PRINT_ER("Driver is CLOSING: Can't handle UH interrupt\n"); @@ -191,7 +169,6 @@ static irqreturn_t isr_bh_routine(int irq, void *userdata) return IRQ_HANDLED; } - PRINT_D(INT_DBG, "Interrupt received BH\n"); wilc_handle_isr(wilc); return IRQ_HANDLED; @@ -255,12 +232,9 @@ int wilc_lock_timeout(struct wilc *nic, void *vp, u32 timeout) /* FIXME: replace with mutex_lock or wait_for_completion */ int error = -1; - PRINT_D(LOCK_DBG, "Locking %p\n", vp); if (vp) error = down_timeout((struct semaphore *)vp, msecs_to_jiffies(timeout)); - else - PRINT_ER("Failed, mutex is NULL\n"); return error; } @@ -358,28 +332,21 @@ static int linux_wlan_txq_task(void *vp) up(&wl->txq_thread_started); while (1) { - PRINT_D(TX_DBG, "txq_task Taking a nap :)\n"); down(&wl->txq_event); - PRINT_D(TX_DBG, "txq_task Who waked me up :$\n"); if (wl->close) { up(&wl->txq_thread_started); while (!kthread_should_stop()) schedule(); - - PRINT_D(TX_DBG, "TX thread stopped\n");
[PATCH 08/13] staging: wilc1000: remove warnings line over 80 characters
From: Leo Kim This patch removes the warnings reported by checkpatch.pl for line over 80 characters. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 4b544df..f03daff 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -25,7 +25,8 @@ #include -static int dev_state_ev_handler(struct notifier_block *this, unsigned long event, void *ptr); +static int dev_state_ev_handler(struct notifier_block *this, + unsigned long event, void *ptr); static struct notifier_block g_dev_notifier = { .notifier_call = dev_state_ev_handler @@ -57,7 +58,8 @@ static const struct net_device_ops wilc_netdev_ops = { }; -static int dev_state_ev_handler(struct notifier_block *this, unsigned long event, void *ptr) +static int dev_state_ev_handler(struct notifier_block *this, + unsigned long event, void *ptr) { struct in_ifaddr *dev_iface = (struct in_ifaddr *)ptr; struct wilc_priv *priv; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/13] staging: wilc1000: renames u8IfIdx of wilc_vif structure
From: Leo Kim This patch renames u8IfIdx variable of wilc_vif structure to idx to avoid camelcase. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/host_interface.c | 2 +- drivers/staging/wilc1000/linux_wlan.c | 8 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 2 +- drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +- 4 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index a425b09..ad54db2 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -280,7 +280,7 @@ static void *host_int_ParseJoinBssParam(tstrNetworkInfo *ptstrNetworkInfo); */ int wilc_get_vif_idx(struct wilc_vif *vif) { - return vif->u8IfIdx + 1; + return vif->idx + 1; } /* We need to minus 1 from idx which is from wilc device to get real index diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 5c87105..9ca33536 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -107,7 +107,7 @@ static int dev_state_ev_handler(struct notifier_block *this, netdev_dbg(dev, "IP add=%d:%d:%d:%d\n", ip_addr_buf[0], ip_addr_buf[1], ip_addr_buf[2], ip_addr_buf[3]); - wilc_setup_ipaddress(vif, ip_addr_buf, vif->u8IfIdx); + wilc_setup_ipaddress(vif, ip_addr_buf, vif->idx); break; @@ -129,7 +129,7 @@ static int dev_state_ev_handler(struct notifier_block *this, ip_addr_buf[0], ip_addr_buf[1], ip_addr_buf[2], ip_addr_buf[3]); - wilc_setup_ipaddress(vif, ip_addr_buf, vif->u8IfIdx); + wilc_setup_ipaddress(vif, ip_addr_buf, vif->idx); break; @@ -1104,7 +1104,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev) vif->netstats.tx_packets++; vif->netstats.tx_bytes += tx_data->size; - tx_data->bssid = wilc->vif[vif->u8IfIdx]->bssid; + tx_data->bssid = wilc->vif[vif->idx]->bssid; queue_count = wilc_wlan_txq_add_net_pkt(ndev, (void *)tx_data, tx_data->buff, tx_data->size, linux_wlan_tx_complete); @@ -1360,7 +1360,7 @@ int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type, else strcpy(ndev->name, "p2p%d"); - vif->u8IfIdx = wl->vif_num; + vif->idx = wl->vif_num; vif->wilc = *wilc; wl->vif[i] = vif; wl->vif[wl->vif_num]->ndev = ndev; diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index 6626347..ccfd26a 100644 --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -2197,7 +2197,7 @@ static int start_ap(struct wiphy *wiphy, struct net_device *dev, if (s32Error != 0) PRINT_ER("Error in setting channel\n"); - wilc_wlan_set_bssid(dev, wl->vif[vif->u8IfIdx]->src_addr, AP_MODE); + wilc_wlan_set_bssid(dev, wl->vif[vif->idx]->src_addr, AP_MODE); wilc_set_power_mgmt(vif, 0, 0); s32Error = wilc_add_beacon(vif, settings->beacon_interval, diff --git a/drivers/staging/wilc1000/wilc_wfi_netdevice.h b/drivers/staging/wilc1000/wilc_wfi_netdevice.h index 64fcb77..07a4ff1 100644 --- a/drivers/staging/wilc1000/wilc_wfi_netdevice.h +++ b/drivers/staging/wilc1000/wilc_wfi_netdevice.h @@ -148,7 +148,7 @@ typedef struct { } struct_frame_reg; struct wilc_vif { - u8 u8IfIdx; + u8 idx; u8 iftype; int monitor_flag; int mac_opened; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/13] staging: wilc1000: rename pBssid of tx_complete_data structure
From: Leo Kim This patch renames pBssid variable of tx_complete_data structure to bssid to avoid camelcase. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 2 +- drivers/staging/wilc1000/wilc_wlan.c| 2 +- drivers/staging/wilc1000/wilc_wlan_if.h | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 402f8ce..4b544df 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -1194,7 +1194,7 @@ int wilc_mac_xmit(struct sk_buff *skb, struct net_device *ndev) PRINT_D(TX_DBG, "Adding tx packet to TX Queue\n"); vif->netstats.tx_packets++; vif->netstats.tx_bytes += tx_data->size; - tx_data->pBssid = wilc->vif[vif->u8IfIdx]->bssid; + tx_data->bssid = wilc->vif[vif->u8IfIdx]->bssid; queue_count = wilc_wlan_txq_add_net_pkt(ndev, (void *)tx_data, tx_data->buff, tx_data->size, linux_wlan_tx_complete); diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c index d7238e7..703dbe0 100644 --- a/drivers/staging/wilc1000/wilc_wlan.c +++ b/drivers/staging/wilc1000/wilc_wlan.c @@ -809,7 +809,7 @@ int wilc_wlan_handle_txq(struct net_device *dev, u32 *txq_count) if (tqe->type == WILC_CFG_PKT) { buffer_offset = ETH_CONFIG_PKT_HDR_OFFSET; } else if (tqe->type == WILC_NET_PKT) { - char *bssid = ((struct tx_complete_data *)(tqe->priv))->pBssid; + char *bssid = ((struct tx_complete_data *)(tqe->priv))->bssid; buffer_offset = ETH_ETHERNET_HDR_OFFSET; memcpy(&txb[offset + 4], bssid, 6); diff --git a/drivers/staging/wilc1000/wilc_wlan_if.h b/drivers/staging/wilc1000/wilc_wlan_if.h index 455a98f..294552d 100644 --- a/drivers/staging/wilc1000/wilc_wlan_if.h +++ b/drivers/staging/wilc1000/wilc_wlan_if.h @@ -82,7 +82,7 @@ typedef struct { struct tx_complete_data { int size; void *buff; - u8 *pBssid; + u8 *bssid; struct sk_buff *skb; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/13] staging: wilc1000: fixes missing a blank line after declarations
From: Leo Kim This patch fixes the warnings reported by checkpatch.pl for Missing a blank line after declarations. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index fd405b0..402f8ce 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -853,6 +853,7 @@ static void wlan_deinitialize_threads(struct net_device *dev) { struct wilc_vif *vif; struct wilc *wl; + vif = netdev_priv(dev); wl = vif->wilc; @@ -1473,6 +1474,7 @@ int wilc_netdev_init(struct wilc **wilc, struct device *dev, int io_type, { struct wireless_dev *wdev; + wdev = wilc_create_wiphy(ndev, dev); if (dev) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/13] staging: wilc1000: rename hWILCWFIDrv of wilc_priv structure
From: Leo Kim This patch renames hWILCWFIDrv pointer variable of wilc_priv structure to hif_drv to avoid camelcase. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 8 drivers/staging/wilc1000/wilc_wfi_cfgoperations.c | 22 -- drivers/staging/wilc1000/wilc_wfi_netdevice.h | 2 +- 3 files changed, 17 insertions(+), 15 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index a3b4939..06c79dd 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -89,7 +89,7 @@ static int dev_state_ev_handler(struct notifier_block *this, unsigned long event PRINT_D(GENERIC_DBG, "No Wireless Priv\n"); return NOTIFY_DONE; } - hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv; + hif_drv = (struct host_if_drv *)priv->hif_drv; vif = netdev_priv(dev); if (!vif || !hif_drv) { PRINT_D(GENERIC_DBG, "No Wireless Priv\n"); @@ -515,7 +515,7 @@ static int linux_wlan_init_test_config(struct net_device *dev, PRINT_D(TX_DBG, "Start configuring Firmware\n"); priv = wiphy_priv(dev->ieee80211_ptr->wiphy); - hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv; + hif_drv = (struct host_if_drv *)priv->hif_drv; PRINT_D(INIT_DBG, "Host = %p\n", hif_drv); wilc_get_mac_address(vif, mac_add); @@ -1089,7 +1089,7 @@ static void wilc_set_multicast_list(struct net_device *dev) priv = wiphy_priv(dev->ieee80211_ptr->wiphy); vif = netdev_priv(dev); - hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv; + hif_drv = (struct host_if_drv *)priv->hif_drv; if (!dev) return; @@ -1228,7 +1228,7 @@ int wilc_mac_close(struct net_device *ndev) return 0; } - hif_drv = (struct host_if_drv *)priv->hWILCWFIDrv; + hif_drv = (struct host_if_drv *)priv->hif_drv; PRINT_D(GENERIC_DBG, "Mac close\n"); diff --git a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c index 6e7f5d6..6626347 100644 --- a/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c +++ b/drivers/staging/wilc1000/wilc_wfi_cfgoperations.c @@ -512,7 +512,7 @@ static void CfgConnectResult(enum conn_event enuConnDisconnEvent, dev = priv->dev; vif = netdev_priv(dev); wl = vif->wilc; - pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv; + pstrWFIDrv = (struct host_if_drv *)priv->hif_drv; if (enuConnDisconnEvent == CONN_DISCONN_EVENT_CONN_RESP) { u16 u16ConnectStatus; @@ -711,9 +711,11 @@ static int connect(struct wiphy *wiphy, struct net_device *dev, wilc_connecting = 1; priv = wiphy_priv(wiphy); vif = netdev_priv(priv->dev); - pstrWFIDrv = (struct host_if_drv *)(priv->hWILCWFIDrv); + pstrWFIDrv = (struct host_if_drv *)priv->hif_drv; - PRINT_D(CFG80211_DBG, "Connecting to SSID [%s] on netdev [%p] host if [%p]\n", sme->ssid, dev, priv->hWILCWFIDrv); + PRINT_D(CFG80211_DBG, + "Connecting to SSID [%s] on netdev [%p] host if [%p]\n", + sme->ssid, dev, priv->hif_drv); if (!(strncmp(sme->ssid, "DIRECT-", 7))) { PRINT_D(CFG80211_DBG, "Connected to Direct network,OBSS disabled\n"); pstrWFIDrv->p2p_connect = 1; @@ -928,7 +930,7 @@ static int disconnect(struct wiphy *wiphy, struct net_device *dev, u16 reason_co priv = wiphy_priv(wiphy); vif = netdev_priv(priv->dev); - pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv; + pstrWFIDrv = (struct host_if_drv *)priv->hif_drv; if (!pstrWFIDrv->p2p_connect) wlan_channel = INVALID_CHANNEL; wilc_wlan_set_bssid(priv->dev, NullBssid, STATION_MODE); @@ -1276,7 +1278,7 @@ static int del_key(struct wiphy *wiphy, struct net_device *netdev, wilc_remove_wep_key(vif, key_index); } else { PRINT_D(CFG80211_DBG, "Removing all installed keys\n"); - wilc_remove_key(priv->hWILCWFIDrv, mac_addr); + wilc_remove_key(priv->hif_drv, mac_addr); } return 0; @@ -1632,7 +1634,7 @@ void WILC_WFI_p2p_rx (struct net_device *dev, u8 *buff, u32 size) s32 s32Freq; priv = wiphy_priv(dev->ieee80211_ptr->wiphy); - pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv; + pstrWFIDrv = (struct host_if_drv *)priv->hif_drv; memcpy(&header, (buff - HOST_HDR_OFFSET), HOST_HDR_OFFSET); @@ -1844,7 +1846,7 @@ static int mgmt_tx(struct wiphy *wiphy, vif = netdev_priv(wdev->netdev); priv = wiphy_priv(wiphy); - pstrWFIDrv = (struct host_if_drv *)priv->hWILCWFIDrv; + pstrWFIDrv = (struct host_if_drv *)priv->hif_drv; *cookie = (unsigned long)buf;
[PATCH 05/13] staging: wilc1000: rename Firmware_ver variable
From: Leo Kim This patch renames Firmware_ver variable to firmware_ver to avoid camelcase. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 06c79dd..fd405b0 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -929,13 +929,14 @@ int wilc1000_wlan_init(struct net_device *dev, struct wilc_vif *vif) if (wilc_wlan_cfg_get(vif, 1, WID_FIRMWARE_VERSION, 1, 0)) { int size; - char Firmware_ver[20]; - - size = wilc_wlan_cfg_get_val( - WID_FIRMWARE_VERSION, - Firmware_ver, sizeof(Firmware_ver)); - Firmware_ver[size] = '\0'; - PRINT_D(INIT_DBG, "* Firmware Ver = %s ***\n", Firmware_ver); + char firmware_ver[20]; + + size = wilc_wlan_cfg_get_val(WID_FIRMWARE_VERSION, +firmware_ver, +sizeof(firmware_ver)); + firmware_ver[size] = '\0'; + PRINT_D(INIT_DBG, " Firmware Ver = %s \n", + firmware_ver); } ret = linux_wlan_init_test_config(dev, vif); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/13] staging: wilc1000: fixes no space is necessary after a cast
From: Leo Kim This patch fixes the check reported by checkpatch.pl for 'no space is necessary after a cast'. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index db91a21..9552469 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -1287,7 +1287,7 @@ static int mac_ioctl(struct net_device *ndev, struct ifreq *req, int cmd) switch (cmd) { case SIOCSIWPRIV: { - struct iwreq *wrq = (struct iwreq *) req; + struct iwreq *wrq = (struct iwreq *)req; size = wrq->u.data.length; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/13] staging: wilc1000: fixes add spaces required around
From: Leo Kim This patch fixes the checks reported by checkpatch.pl for spaces required around that '=' or '||' or '('. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index 9552469..a3b4939 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -993,7 +993,7 @@ int wilc_mac_open(struct net_device *ndev) vif = netdev_priv(ndev); wl = vif->wilc; - if (!wl|| !wl->dev) { + if (!wl || !wl->dev) { netdev_err(ndev, "wilc1000: SPI device not ready\n"); return -ENODEV; } @@ -1074,7 +1074,7 @@ int wilc_mac_open(struct net_device *ndev) static struct net_device_stats *mac_stats(struct net_device *dev) { - struct wilc_vif *vif= netdev_priv(dev); + struct wilc_vif *vif = netdev_priv(dev); return &vif->netstats; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] staging: wilc1000: wilc_frmw_to_linux(): fixes null check
From: Leo Kim Null checking wilc_netdev and skb->dev are already done in the begining of the function and they are just print printing error log, so delete them. Null checking wilc is needed before is used so add null ckeck before it is used. Signed-off-by: Leo Kim Signed-off-by: Glen Lee --- drivers/staging/wilc1000/linux_wlan.c | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/drivers/staging/wilc1000/linux_wlan.c b/drivers/staging/wilc1000/linux_wlan.c index ee779ee..db91a21 100644 --- a/drivers/staging/wilc1000/linux_wlan.c +++ b/drivers/staging/wilc1000/linux_wlan.c @@ -1342,6 +1342,9 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 size, u32 pkt_offset) struct net_device *wilc_netdev; struct wilc_vif *vif; + if (!wilc) + return; + wilc_netdev = get_if_handler(wilc, buff); if (!wilc_netdev) return; @@ -1358,14 +1361,8 @@ void wilc_frmw_to_linux(struct wilc *wilc, u8 *buff, u32 size, u32 pkt_offset) PRINT_ER("Low memory - packet droped\n"); return; } - - if (!wilc || !wilc_netdev) - PRINT_ER("wilc_netdev in wilc is NULL"); skb->dev = wilc_netdev; - if (!skb->dev) - PRINT_ER("skb->dev is NULL\n"); - memcpy(skb_put(skb, frame_len), buff_to_send, frame_len); skb->protocol = eth_type_trans(skb, wilc_netdev); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc
On Tue, 2016-01-26 at 15:12 -0800, Cong Wang wrote: > On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby > wrote: > > Hi Cong, > > > > On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote: > > > > A commit message would be nice. A brief rundown of how this is called > > from userspace would be nice (I'm talking a single sentence here, e.g. > > "this is allocated when submitting a nfc packet") and what issue > > __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation > > failures.) > > > > I thought it is obvious. ;) Keep in mind that $subject is one part of commit > message too, so there is a commit message although very short. > > I will add it. BTW, kzalloc() is useless here, since it is followed by if (memcpy_from_msg(msg_data, msg, len)) { Also, this file seems to have two spots with the same problem, in nfc_llcp_send_ui_frame() & nfc_llcp_send_i_frame() -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: let unused MPP table entries timeout
On Tue, Jan 19, 2016 at 09:04:32AM +0100, Henning Rogge wrote: > err = -ENXIO; > -enddel: > +enddelpath: Concur about it being better to leave this label alone, also the diff looks weird because it continues: > + mesh_paths_generation++; > + spin_unlock(&tbl->hashwlock[hash_idx]); > + read_unlock_bh(&pathtbl_resize_lock); > + return err; > +} [...] > + err = -ENXIO; > +enddelmpp: > mesh_paths_generation++; > spin_unlock(&tbl->hashwlock[hash_idx]); > read_unlock_bh(&pathtbl_resize_lock); At first I wondered why the last half of the function was changed, but then I saw that. Shouldn't the above be "mpp_paths_generation++;"? In general I'd like to merge these two into one function; the only thing different is the initial table pointer that gets dereferenced and the generation counter (and now the labels). So something like this should be doable: static int mesh_table_delete(struct ieee80211_sub_if_data *sdata, struct mesh_table *tbl, const u8 *addr) { /* basically what mesh_path_del is today */ } int mesh_path_del(...) { tbl = resize_dereference_mesh_paths(); ret = mesh_table_delete(sdata, tbl, addr); mesh_paths_generation++; return ret; } int mpp_path_del(...) { tbl = resize_dereference_mpp_paths(); ret = mesh_table_delete(sdata, tbl, addr); mpp_paths_generation++; return ret; } -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc
Hi Cong, On Wed, Jan 27, 2016 at 10:12 AM, Cong Wang wrote: > On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby > wrote: >> Hi Cong, >> >> On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote: >> >> A commit message would be nice. A brief rundown of how this is called >> from userspace would be nice (I'm talking a single sentence here, e.g. >> "this is allocated when submitting a nfc packet") and what issue >> __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation >> failures.) >> > > I thought it is obvious. ;) Keep in mind that $subject is one part of commit > message too, so there is a commit message although very short. > > I will add it. I know almost nothing about how the NFC subsystem works, and this looks like a potential security issue, so more information is better IMHO. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc
On Tue, Jan 26, 2016 at 2:55 PM, Julian Calaby wrote: > Hi Cong, > > On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote: > > A commit message would be nice. A brief rundown of how this is called > from userspace would be nice (I'm talking a single sentence here, e.g. > "this is allocated when submitting a nfc packet") and what issue > __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation > failures.) > I thought it is obvious. ;) Keep in mind that $subject is one part of commit message too, so there is a commit message although very short. I will add it. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc
Hi Cong, On Wed, Jan 27, 2016 at 4:53 AM, Cong Wang wrote: A commit message would be nice. A brief rundown of how this is called from userspace would be nice (I'm talking a single sentence here, e.g. "this is allocated when submitting a nfc packet") and what issue __GFP_NOWARN is fixing. (I'm guessing log spam due to allocation failures.) > Reported-by: Dmitry Vyukov > Cc: Lauro Ramos Venancio > Cc: Aloisio Almeida Jr > Cc: Samuel Ortiz > Signed-off-by: Cong Wang > --- > net/nfc/llcp_commands.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c > index 3621a90..5d94055 100644 > --- a/net/nfc/llcp_commands.c > +++ b/net/nfc/llcp_commands.c > @@ -729,7 +729,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 > ssap, u8 dsap, > if (local == NULL) > return -ENODEV; > > - msg_data = kzalloc(len, GFP_KERNEL); > + msg_data = kzalloc(len, GFP_USER | __GFP_NOWARN); > if (msg_data == NULL) > return -ENOMEM; Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mac80211: avoid excessive stack usage in sta_info
When CONFIG_OPTIMIZE_INLINING is set, the sta_info_insert_finish function consumes more stack than normally, exceeding the 1024 byte limit on ARM: net/mac80211/sta_info.c: In function 'sta_info_insert_finish': net/mac80211/sta_info.c:561:1: error: the frame size of 1080 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] It turns out that there are two functions that put a 'struct station_info' on the stack: __sta_info_destroy_part2 and sta_info_insert_finish, and this structure alone requires up to 792 bytes. Hoping that both are called rarely enough, this replaces the on-stack structure with a dynamic allocation, which unfortunately requires some suboptimal error handling for out-of-memory. The __sta_info_destroy_part2 function is actually affected by the stack usage twice because it calls cfg80211_del_sta_sinfo(), which has another instance of struct station_info on its stack. Signed-off-by: Arnd Bergmann Fixes: 98b6218388e3 ("mac80211/cfg80211: add station events") Fixes: 6f7a8d26e266 ("mac80211: send statistics with delete station event") --- net/mac80211/sta_info.c | 24 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c index 4402ad5b27d1..a29199ec4c3c 100644 --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -498,11 +498,17 @@ static int sta_info_insert_finish(struct sta_info *sta) __acquires(RCU) { struct ieee80211_local *local = sta->local; struct ieee80211_sub_if_data *sdata = sta->sdata; - struct station_info sinfo; + struct station_info *sinfo; int err = 0; lockdep_assert_held(&local->sta_mtx); + sinfo = kzalloc(sizeof(struct station_info), GFP_KERNEL); + if (!sinfo) { + err = -ENOMEM; + goto out_err; + } + /* check if STA exists already */ if (sta_info_get_bss(sdata, sta->sta.addr)) { err = -EEXIST; @@ -534,10 +540,9 @@ static int sta_info_insert_finish(struct sta_info *sta) __acquires(RCU) ieee80211_sta_debugfs_add(sta); rate_control_add_sta_debugfs(sta); - memset(&sinfo, 0, sizeof(sinfo)); - sinfo.filled = 0; - sinfo.generation = local->sta_generation; - cfg80211_new_sta(sdata->dev, sta->sta.addr, &sinfo, GFP_KERNEL); + sinfo->generation = local->sta_generation; + cfg80211_new_sta(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL); + kfree(sinfo); sta_dbg(sdata, "Inserted STA %pM\n", sta->sta.addr); @@ -898,7 +903,7 @@ static void __sta_info_destroy_part2(struct sta_info *sta) { struct ieee80211_local *local = sta->local; struct ieee80211_sub_if_data *sdata = sta->sdata; - struct station_info sinfo = {}; + struct station_info *sinfo; int ret; /* @@ -936,8 +941,11 @@ static void __sta_info_destroy_part2(struct sta_info *sta) sta_dbg(sdata, "Removed STA %pM\n", sta->sta.addr); - sta_set_sinfo(sta, &sinfo); - cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, &sinfo, GFP_KERNEL); + sinfo = kzalloc(sizeof(*sinfo), GFP_KERNEL); + if (sinfo) + sta_set_sinfo(sta, sinfo); + cfg80211_del_sta_sinfo(sdata->dev, sta->sta.addr, sinfo, GFP_KERNEL); + kfree(sinfo); rate_control_remove_sta_debugfs(sta); ieee80211_sta_debugfs_remove(sta); -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, Jan 26, 2016 at 10:32:23PM +0100, Johannes Berg wrote: > On Tue, 2016-01-26 at 22:31 +0100, Johannes Berg wrote: > > On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote: > > > > > > void mesh_path_flush_by_nexthop(struct sta_info *sta) > > > { > > > [...] > > > rhashtable_walk_start(&iter); > > > > It seems you need to check the return value here? > > > > Actually, maybe not. Not sure I understand the return to beginning > though. I'll RFC that patch, it doesn't work right now anyway as rhashtable_walk_init() does a GFP_KERNEL allocation and we want to call it from the RX path (maybe not a good idea, but that's what the code currently does). -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, 2016-01-26 at 22:31 +0100, Johannes Berg wrote: > On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote: > > > > void mesh_path_flush_by_nexthop(struct sta_info *sta) > > { > > [...] > > rhashtable_walk_start(&iter); > > It seems you need to check the return value here? > Actually, maybe not. Not sure I understand the return to beginning though. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, 2016-01-26 at 16:22 -0500, Bob Copeland wrote: > > void mesh_path_flush_by_nexthop(struct sta_info *sta) > { > [...] > rhashtable_walk_start(&iter); It seems you need to check the return value here? > while ((mpath = rhashtable_walk_next(&iter))) { > if (IS_ERR(mpath) && PTR_ERR(mpath) == -EAGAIN) > continue; > if (IS_ERR(mpath)) > break; > > if (rcu_access_pointer(mpath->next_hop) == sta) > __mesh_path_del(tbl, mpath); > } > rhashtable_walk_stop(&iter); > [...] > } > > ...this still relies on the rcu read lock inside _walk_start and > _walk_stop, though. At least that's kinda hidden in walk_start/stop though ;-) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, Jan 26, 2016 at 09:53:33PM +0100, Johannes Berg wrote: > Oh. Interesting. Yeah, I guess that should be OK then. > > It's not *nice*, since that's pretty much unexpected, and you then do > need the rcu_read_lock() ... hmm. Yeah, I puzzled over that a bit last week as well -- I rewrote it like this in the series I haven't posted yet: void mesh_path_flush_by_nexthop(struct sta_info *sta) { [...] rhashtable_walk_start(&iter); while ((mpath = rhashtable_walk_next(&iter))) { if (IS_ERR(mpath) && PTR_ERR(mpath) == -EAGAIN) continue; if (IS_ERR(mpath)) break; if (rcu_access_pointer(mpath->next_hop) == sta) __mesh_path_del(tbl, mpath); } rhashtable_walk_stop(&iter); [...] } ...this still relies on the rcu read lock inside _walk_start and _walk_stop, though. -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, 2016-01-26 at 13:36 -0500, Bob Copeland wrote: > On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote: > > > + mpp = node->mpath; > > > + if (ether_addr_equal(mpp->mpp, proxy)) { > > > + spin_lock(&tbl->hashwlock[i]); > > > + __mesh_path_del(tbl, node); > > > + spin_unlock(&tbl->hashwlock[i]); > > > > It also doesn't seem like for_each_mesh_entry() can deal with > > "node" > > getting deleted from underneath it? It accesses it through > > hlist_next_rcu() after the deletion, so you have a use-after-free > > here > > afaict. > > But __mesh_path_del() doesn't free it immediately: it does: > > hlist_del_rcu(&node->list); > call_rcu(&node->rcu, mesh_path_node_reclaim); > > ...so this should be ok if in an rcu read-side critical section, > right? Oh. Interesting. Yeah, I guess that should be OK then. It's not *nice*, since that's pretty much unexpected, and you then do need the rcu_read_lock() ... hmm. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: let unused MPP table entries timeout
On Tue, Jan 26, 2016 at 12:44 PM, Johannes Berg wrote: > On Tue, 2016-01-19 at 09:04 +0100, Henning Rogge wrote: > >> +++ b/net/mac80211/mesh_pathtbl.c >> @@ -929,12 +929,55 @@ int mesh_path_del(struct ieee80211_sub_if_data >> *sdata, const u8 *addr) >> if (mpath->sdata == sdata && >> ether_addr_equal(addr, mpath->dst)) { >> __mesh_path_del(tbl, node); >> - goto enddel; >> + goto enddelpath; > > C labels are scoped, why rename it? I think I had a warning with the two labels the same... might be an IDE mistake. >> } >> } >> >> err = -ENXIO; >> -enddel: >> +enddelpath: >> + mesh_paths_generation++; >> + spin_unlock(&tbl->hashwlock[hash_idx]); >> + read_unlock_bh(&pathtbl_resize_lock); >> + return err; >> +} >> + >> +/** >> + * mpp_path_del - delete a mesh proxy path from the table >> + * >> + * @addr: addr address (ETH_ALEN length) >> + * @sdata: local subif >> + * >> + * Returns: 0 if successful >> + */ >> +static int mpp_path_del(struct ieee80211_sub_if_data *sdata, const >> u8 *addr) >> +{ >> + struct mesh_table *tbl; >> + struct mesh_path *mpath; >> + struct mpath_node *node; >> + struct hlist_head *bucket; >> + int hash_idx; >> + int err = 0; >> + >> + /* flush relevant mpp entries first */ >> + mpp_flush_by_proxy(sdata, addr); >> + >> + read_lock_bh(&pathtbl_resize_lock); >> + tbl = resize_dereference_mpp_paths(); >> + hash_idx = mesh_table_hash(addr, sdata, tbl); >> + bucket = &tbl->hash_buckets[hash_idx]; >> + >> + spin_lock(&tbl->hashwlock[hash_idx]); >> + hlist_for_each_entry(node, bucket, list) { >> + mpath = node->mpath; >> + if (mpath->sdata == sdata && >> + ether_addr_equal(addr, mpath->dst)) { >> + __mesh_path_del(tbl, node); >> + goto enddelmpp; > > This has the same use-after-free, I'd say? > And another instance later in this file. > > >> + spin_lock_bh(&mppath- >> >state_lock); >> + mppath->exp_time = jiffies; > > That locking seems fairly pointless? You only write to this value here, > and it's an unsigned long, so in itself it's atomic and there's no > synchronisation against anything else needed. Most likely you are right... kernel locking is an arcane knowledge and I am still looking for a good way to get initiated into it. Henning -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] ath10k: implement push-pull tx
On 01/26/2016 02:28 AM, Michal Kazior wrote: On 22 January 2016 at 08:47, Michal Kazior wrote: On 21 January 2016 at 18:40, Peter Oh wrote: On 01/21/2016 05:46 AM, Michal Kazior wrote: [...] - /* TODO: apply configuration */ + rcu_read_unlock(); + + spin_lock_bh(&ar->htt.tx_lock); + ath10k_mac_tx_lock(ar, ATH10K_TX_PAUSE_Q_FLUSH_PENDING); + spin_unlock_bh(&ar->htt.tx_lock); + Isn't it proved it break Mesh from working? Yes, good point. I'm still working on this - I should've mentioned that in the cover letter. Nonetheless I wanted to get the review process going for this patchset. I'll address the mesh problem in v2. For the record - the problem turned out to be a bug in mac80211 mesh fwding, see: https://patchwork.kernel.org/patch/8108711/ I've verified that the patch fixed the mesh issue. Thank you Michal. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, Jan 26, 2016 at 7:36 PM, Bob Copeland wrote: > On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote: >> > + mpp = node->mpath; >> > + if (ether_addr_equal(mpp->mpp, proxy)) { >> > + spin_lock(&tbl->hashwlock[i]); >> > + __mesh_path_del(tbl, node); >> > + spin_unlock(&tbl->hashwlock[i]); >> >> It also doesn't seem like for_each_mesh_entry() can deal with "node" >> getting deleted from underneath it? It accesses it through >> hlist_next_rcu() after the deletion, so you have a use-after-free here >> afaict. > > But __mesh_path_del() doesn't free it immediately: it does: > > hlist_del_rcu(&node->list); > call_rcu(&node->rcu, mesh_path_node_reclaim); > > ...so this should be ok if in an rcu read-side critical section, right? The code is a direct copy what was going on the the cleanup path of the mpath objects... just modified to run on the mpp objects. Henning -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, Jan 26, 2016 at 12:41:25PM +0100, Johannes Berg wrote: > > + mpp = node->mpath; > > + if (ether_addr_equal(mpp->mpp, proxy)) { > > + spin_lock(&tbl->hashwlock[i]); > > + __mesh_path_del(tbl, node); > > + spin_unlock(&tbl->hashwlock[i]); > > It also doesn't seem like for_each_mesh_entry() can deal with "node" > getting deleted from underneath it? It accesses it through > hlist_next_rcu() after the deletion, so you have a use-after-free here > afaict. But __mesh_path_del() doesn't free it immediately: it does: hlist_del_rcu(&node->list); call_rcu(&node->rcu, mesh_path_node_reclaim); ...so this should be ok if in an rcu read-side critical section, right? -- Bob Copeland %% http://bobcopeland.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND net] nfc: use GFP_USER for user-controlled kmalloc
Reported-by: Dmitry Vyukov Cc: Lauro Ramos Venancio Cc: Aloisio Almeida Jr Cc: Samuel Ortiz Signed-off-by: Cong Wang --- net/nfc/llcp_commands.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c index 3621a90..5d94055 100644 --- a/net/nfc/llcp_commands.c +++ b/net/nfc/llcp_commands.c @@ -729,7 +729,7 @@ int nfc_llcp_send_ui_frame(struct nfc_llcp_sock *sock, u8 ssap, u8 dsap, if (local == NULL) return -ENODEV; - msg_data = kzalloc(len, GFP_KERNEL); + msg_data = kzalloc(len, GFP_USER | __GFP_NOWARN); if (msg_data == NULL) return -ENOMEM; -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] brcmfmac: access PMU registers using standalone PMU core if available
Hi Rafał, [auto build test ERROR on wireless-drivers/master] [also build test ERROR on v4.5-rc1 next-20160125] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Rafa-Mi-ecki/brcmfmac-support-for-new-14e43-4365-card-with-BCM4366/20160127-010149 base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git master config: x86_64-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c: In function 'brcmf_chip_get_pmu': >> drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1143:25: error: >> 'BCMA_CC_CAP_EXT_AOB_PRESENT' undeclared (first use in this function) pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) { ^ drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c:1143:25: note: each undeclared identifier is reported only once for each function it appears in vim +/BCMA_CC_CAP_EXT_AOB_PRESENT +1143 drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c 1137 { 1138 struct brcmf_core *cc = brcmf_chip_get_chipcommon(pub); 1139 struct brcmf_core *pmu; 1140 1141 /* See if there is separated PMU core available */ 1142 if (cc->rev >= 35 && > 1143 pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) { 1144 pmu = brcmf_chip_get_core(pub, BCMA_CORE_PMU); 1145 if (pmu) 1146 return pmu; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
[PATCH 3/5] brcmfmac: read extended capabilities of ChipCommon core
This is an extra bitfield with info about some present hardware. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 3 +++ drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h | 2 ++ 2 files changed, 5 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c index 55952d4..f4a4d00 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c @@ -1025,6 +1025,9 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip) /* get chipcommon capabilites */ pub->cc_caps = chip->ops->read32(chip->ctx, CORE_CC_REG(base, capabilities)); + pub->cc_caps_ext = chip->ops->read32(chip->ctx, +CORE_CC_REG(base, +capabilities_ext)); /* get pmu caps & rev */ if (pub->cc_caps & CC_CAP_PMU) { diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h index f6b5fee..cb9145f 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h @@ -27,6 +27,7 @@ * @chip: chip identifier. * @chiprev: chip revision. * @cc_caps: chipcommon core capabilities. + * @cc_caps_ext: chipcommon core extended capabilities. * @pmucaps: PMU capabilities. * @pmurev: PMU revision. * @rambase: RAM base address (only applicable for ARM CR4 chips). @@ -38,6 +39,7 @@ struct brcmf_chip { u32 chip; u32 chiprev; u32 cc_caps; + u32 cc_caps_ext; u32 pmucaps; u32 pmurev; u32 rambase; -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] brcmfmac: allow storing PMU core without wrapper address
Separated PMU core can be found in new devices and should be used for accessing PMU registers (which were routed through ChipCommon so far). This core is one of exceptions that doesn't have or need wrapper address to be still safely accessible. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c index e434e2a..55952d4 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c @@ -883,7 +883,8 @@ int brcmf_chip_dmp_erom_scan(struct brcmf_chip_priv *ci) rev = (val & DMP_COMP_REVISION) >> DMP_COMP_REVISION_S; /* need core with ports */ - if (nmw + nsw == 0) + if (nmw + nsw == 0 && + id != BCMA_CORE_PMU) continue; /* try to obtain register address info */ -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] brcmfmac: support for new 14e43:4365 card with BCM4366
I got D-Link DIR-885L with two 14e4:4365 PCI cards both using BCM4366 chipset. It seems to have newer ChipCommon and separated PMU core so I needed these patches on top of recent Broadcom's work. Please note this patchset depends on: [PATCH 2/2] bcma: support PMU present as separated bus core as I had to use BCMA_CC_CAP_EXT_AOB_PRESENT. Rafał Miłecki (5): brcmfmac: analyze descriptors of current component only brcmfmac: allow storing PMU core without wrapper address brcmfmac: read extended capabilities of ChipCommon core brcmfmac: access PMU registers using standalone PMU core if available brcmfmac: add support for 14e4:4365 PCI ID with BCM4366 chipset .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 45 ++ .../wireless/broadcom/brcm80211/brcmfmac/chip.h| 3 ++ .../wireless/broadcom/brcm80211/brcmfmac/pcie.c| 4 ++ .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 9 ++--- 4 files changed, 49 insertions(+), 12 deletions(-) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] brcmfmac: access PMU registers using standalone PMU core if available
On recent Broadcom chipsets PMU is present as separated core and it can't be accessed using ChipCommon anymore as it fails with e.g.: [ 18.198412] Unhandled fault: imprecise external abort (0x1406) at 0xb6da200f Add a new helper function that will return a proper core that should be used for accessing PMU registers. Signed-off-by: Rafał Miłecki --- .../wireless/broadcom/brcm80211/brcmfmac/chip.c| 30 ++ .../wireless/broadcom/brcm80211/brcmfmac/chip.h| 1 + .../wireless/broadcom/brcm80211/brcmfmac/sdio.c| 9 +++ 3 files changed, 30 insertions(+), 10 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c index f4a4d00..0e8f2a0 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c @@ -1014,6 +1014,7 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip) { struct brcmf_chip *pub; struct brcmf_core_priv *cc; + struct brcmf_core *pmu; u32 base; u32 val; int ret = 0; @@ -1030,9 +1031,10 @@ static int brcmf_chip_setup(struct brcmf_chip_priv *chip) capabilities_ext)); /* get pmu caps & rev */ + pmu = brcmf_chip_get_pmu(pub); /* after reading cc_caps_ext */ if (pub->cc_caps & CC_CAP_PMU) { val = chip->ops->read32(chip->ctx, - CORE_CC_REG(base, pmucapabilities)); + CORE_CC_REG(pmu->base, pmucapabilities)); pub->pmurev = val & PCAP_REV_MASK; pub->pmucaps = val; } @@ -1131,6 +1133,23 @@ struct brcmf_core *brcmf_chip_get_chipcommon(struct brcmf_chip *pub) return &cc->pub; } +struct brcmf_core *brcmf_chip_get_pmu(struct brcmf_chip *pub) +{ + struct brcmf_core *cc = brcmf_chip_get_chipcommon(pub); + struct brcmf_core *pmu; + + /* See if there is separated PMU core available */ + if (cc->rev >= 35 && + pub->cc_caps_ext & BCMA_CC_CAP_EXT_AOB_PRESENT) { + pmu = brcmf_chip_get_core(pub, BCMA_CORE_PMU); + if (pmu) + return pmu; + } + + /* Fallback to ChipCommon core for older hardware */ + return cc; +} + bool brcmf_chip_iscoreup(struct brcmf_core *pub) { struct brcmf_core_priv *core; @@ -1301,6 +1320,7 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub) { u32 base, addr, reg, pmu_cc3_mask = ~0; struct brcmf_chip_priv *chip; + struct brcmf_core *pmu = brcmf_chip_get_pmu(pub); brcmf_dbg(TRACE, "Enter\n"); @@ -1320,9 +1340,9 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub) case BRCM_CC_4335_CHIP_ID: case BRCM_CC_4339_CHIP_ID: /* read PMU chipcontrol register 3 */ - addr = CORE_CC_REG(base, chipcontrol_addr); + addr = CORE_CC_REG(pmu->base, chipcontrol_addr); chip->ops->write32(chip->ctx, addr, 3); - addr = CORE_CC_REG(base, chipcontrol_data); + addr = CORE_CC_REG(pmu->base, chipcontrol_data); reg = chip->ops->read32(chip->ctx, addr); return (reg & pmu_cc3_mask) != 0; case BRCM_CC_43430_CHIP_ID: @@ -1330,12 +1350,12 @@ bool brcmf_chip_sr_capable(struct brcmf_chip *pub) reg = chip->ops->read32(chip->ctx, addr); return reg != 0; default: - addr = CORE_CC_REG(base, pmucapabilities_ext); + addr = CORE_CC_REG(pmu->base, pmucapabilities_ext); reg = chip->ops->read32(chip->ctx, addr); if ((reg & PCAPEXT_SR_SUPPORTED_MASK) == 0) return false; - addr = CORE_CC_REG(base, retention_ctl); + addr = CORE_CC_REG(pmu->base, retention_ctl); reg = chip->ops->read32(chip->ctx, addr); return (reg & (PMU_RCTL_MACPHY_DISABLE_MASK | PMU_RCTL_LOGIC_DISABLE_MASK)) == 0; diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h index cb9145f..dd0ec3e 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.h @@ -85,6 +85,7 @@ struct brcmf_chip *brcmf_chip_attach(void *ctx, void brcmf_chip_detach(struct brcmf_chip *chip); struct brcmf_core *brcmf_chip_get_core(struct brcmf_chip *chip, u16 coreid); struct brcmf_core *brcmf_chip_get_chipcommon(struct brcmf_chip *chip); +struct brcmf_core *brcmf_chip_get_pmu(struct brcmf_chip *pub); bool brcmf_chip_iscoreup(struct brcmf_core *core); void brcmf_chip_coredisable(struct brcmf_core *core, u32 prereset, u32 reset); void brcmf_chip_resetcore(struct brcmf_core *core, u32 prereset, u32 res
[PATCH 5/5] brcmfmac: add support for 14e4:4365 PCI ID with BCM4366 chipset
On Broadcom ARM routers BCM4366 cards are available with 14e4:4365 ID. Unfortunately this ID was already used by Broadcom for cards with BCM43142, a totally different chipset requiring SoftMAC driver. To avoid a conflict between brcmfmac and bcma use more specific ID entry with subvendor and subdevice specified. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c index 0480b70..d5f9ef4 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/pcie.c @@ -1951,6 +1951,9 @@ static const struct dev_pm_ops brcmf_pciedrvr_pm = { #define BRCMF_PCIE_DEVICE(dev_id) { BRCM_PCIE_VENDOR_ID_BROADCOM, dev_id,\ PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_NETWORK_OTHER << 8, 0x00, 0 } +#define BRCMF_PCIE_DEVICE_SUB(dev_id, subvend, subdev) { \ + BRCM_PCIE_VENDOR_ID_BROADCOM, dev_id,\ + subvend, subdev, PCI_CLASS_NETWORK_OTHER << 8, 0x00, 0 } static struct pci_device_id brcmf_pcie_devid_table[] = { BRCMF_PCIE_DEVICE(BRCM_PCIE_4350_DEVICE_ID), @@ -1966,6 +1969,7 @@ static struct pci_device_id brcmf_pcie_devid_table[] = { BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_DEVICE_ID), BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_2G_DEVICE_ID), BRCMF_PCIE_DEVICE(BRCM_PCIE_4365_5G_DEVICE_ID), + BRCMF_PCIE_DEVICE_SUB(0x4365, BRCM_PCIE_VENDOR_ID_BROADCOM, 0x4365), BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_DEVICE_ID), BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_2G_DEVICE_ID), BRCMF_PCIE_DEVICE(BRCM_PCIE_4366_5G_DEVICE_ID), -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] brcmfmac: analyze descriptors of current component only
So far we were looking for address descriptors without a check for crossing current component border. In case of dealing with unsupported descriptor or descriptor missing at all the code would incorrectly get data from another component. Consider this binary-described component from BCM4366 EROM: 4bf83b01TAG==CI CID==0x83b 20080201TAG==CI PORTS==0+1 WRAPPERS==0+1 18400035TAG==ADDR SZ_SZD TYPE_SLAVE 0005 18107085TAG==ADDR SZ_4K TYPE_SWRAP Driver was assigning invalid base address to this core: brcmfmac: [6 ] core 0x83b:32 base 0x18109000 wrap 0x18107000 which came from totally different component defined in EROM: 43b36701TAG==CI CID==0x367 0201TAG==CI PORTS==0+1 WRAPPERS==0+0 18109005TAG==ADDR SZ_4K TYPE_SLAVE This change will also allow us to support components without wrapper address in the future. Signed-off-by: Rafał Miłecki --- drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c index 82e4382..e434e2a 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/chip.c @@ -803,7 +803,14 @@ static int brcmf_chip_dmp_get_regaddr(struct brcmf_chip_priv *ci, u32 *eromaddr, *eromaddr -= 4; return -EFAULT; } - } while (desc != DMP_DESC_ADDRESS); + } while (desc != DMP_DESC_ADDRESS && +desc != DMP_DESC_COMPONENT); + + /* stop if we crossed current component border */ + if (desc == DMP_DESC_COMPONENT) { + *eromaddr -= 4; + return 0; + } /* skip upper 32-bit address descriptor */ if (val & DMP_DESC_ADDRSIZE_GT32) -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 17/26] mac802154: Use skcipher
Hello. On 24/01/16 14:18, Herbert Xu wrote: This patch replaces uses of blkcipher with skcipher. Signed-off-by: Herbert Xu --- net/mac802154/llsec.c | 41 +++-- net/mac802154/llsec.h |3 +-- 2 files changed, 24 insertions(+), 20 deletions(-) diff --git a/net/mac802154/llsec.c b/net/mac802154/llsec.c index a13d02b..6a3e1c2 100644 --- a/net/mac802154/llsec.c +++ b/net/mac802154/llsec.c @@ -17,9 +17,9 @@ #include #include #include -#include #include #include +#include #include "ieee802154_i.h" #include "llsec.h" @@ -144,18 +144,18 @@ llsec_key_alloc(const struct ieee802154_llsec_key *template) goto err_tfm; } - key->tfm0 = crypto_alloc_blkcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC); + key->tfm0 = crypto_alloc_skcipher("ctr(aes)", 0, CRYPTO_ALG_ASYNC); if (IS_ERR(key->tfm0)) goto err_tfm; - if (crypto_blkcipher_setkey(key->tfm0, template->key, - IEEE802154_LLSEC_KEY_SIZE)) + if (crypto_skcipher_setkey(key->tfm0, template->key, + IEEE802154_LLSEC_KEY_SIZE)) goto err_tfm0; return key; err_tfm0: - crypto_free_blkcipher(key->tfm0); + crypto_free_skcipher(key->tfm0); err_tfm: for (i = 0; i < ARRAY_SIZE(key->tfm); i++) if (key->tfm[i]) @@ -175,7 +175,7 @@ static void llsec_key_release(struct kref *ref) for (i = 0; i < ARRAY_SIZE(key->tfm); i++) crypto_free_aead(key->tfm[i]); - crypto_free_blkcipher(key->tfm0); + crypto_free_skcipher(key->tfm0); kzfree(key); } @@ -620,15 +620,17 @@ llsec_do_encrypt_unauth(struct sk_buff *skb, const struct mac802154_llsec *sec, { u8 iv[16]; struct scatterlist src; - struct blkcipher_desc req = { - .tfm = key->tfm0, - .info = iv, - .flags = 0, - }; + SKCIPHER_REQUEST_ON_STACK(req, key->tfm0); + int err; llsec_geniv(iv, sec->params.hwaddr, &hdr->sec); sg_init_one(&src, skb->data, skb->len); - return crypto_blkcipher_encrypt_iv(&req, &src, &src, skb->len); + skcipher_request_set_tfm(req, key->tfm0); + skcipher_request_set_callback(req, 0, NULL, NULL); + skcipher_request_set_crypt(req, &src, &src, skb->len, iv); + err = crypto_skcipher_encrypt(req); + skcipher_request_zero(req); + return err; } static struct crypto_aead* @@ -830,11 +832,8 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct mac802154_llsec *sec, unsigned char *data; int datalen; struct scatterlist src; - struct blkcipher_desc req = { - .tfm = key->tfm0, - .info = iv, - .flags = 0, - }; + SKCIPHER_REQUEST_ON_STACK(req, key->tfm0); + int err; llsec_geniv(iv, dev_addr, &hdr->sec); data = skb_mac_header(skb) + skb->mac_len; @@ -842,7 +841,13 @@ llsec_do_decrypt_unauth(struct sk_buff *skb, const struct mac802154_llsec *sec, sg_init_one(&src, data, datalen); - return crypto_blkcipher_decrypt_iv(&req, &src, &src, datalen); + skcipher_request_set_tfm(req, key->tfm0); + skcipher_request_set_callback(req, 0, NULL, NULL); + skcipher_request_set_crypt(req, &src, &src, datalen, iv); + + err = crypto_skcipher_decrypt(req); + skcipher_request_zero(req); + return err; } static int diff --git a/net/mac802154/llsec.h b/net/mac802154/llsec.h index 950578e..6f3b658 100644 --- a/net/mac802154/llsec.h +++ b/net/mac802154/llsec.h @@ -19,7 +19,6 @@ #include #include -#include #include #include #include @@ -30,7 +29,7 @@ struct mac802154_llsec_key { /* one tfm for each authsize (4/8/16) */ struct crypto_aead *tfm[3]; - struct crypto_blkcipher *tfm0; + struct crypto_skcipher *tfm0; struct kref ref; }; Reviewed-by: Stefan Schmidt regards Stefan Schmidt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: Parse legacy and HT rate in injected frames
On Tuesday 26 January 2016 14:27:20 Johannes Berg wrote: > Hi, > > CALL_TXH(ieee80211_tx_h_select_key); > > - if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL)) > > + if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL) && > > + !(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)) > > CALL_TXH(ieee80211_tx_h_rate_ctrl); > > This seems a bit problematic. ieee80211_tx_h_rate_ctrl() also sets up > some protection, e.g. > > info->control.use_rts = txrc.rts; > info->control.use_cts_prot = tx->sdata->vif.bss_conf.use_cts_prot; > > and preamble settings > > info->control.short_preamble = txrc.short_preamble; > > Are you sure you want to skip that entirely? You are correct, these should be set but rate_control_get_rate should be skipped. > > > + info->control.rates[0].flags = rate_flags; > > + if (rate_retries + 1 > local->hw.max_rate_tries) > > + info->control.rates[0].count = local- > > >hw.max_rate_tries; > > + else > > + info->control.rates[0].count = rate_retries > > + 1; > > max() or max_t()? min_t - but yes, you are right. Btw. we can also change it when you prefer that by default injected frames with rates but without DATA_RETRIES should get local->hw.max_rate_tries as retries. > > > /* process and remove the injection radiotap header */ > > - if (!ieee80211_parse_tx_radiotap(skb)) > > + if (!ieee80211_parse_tx_radiotap(skb, local)) > > goto fail; > > I'd prefer adding "local" as the first argument since that's far more > commonly done in mac80211. Ok, will be changed. Kind regards, Sven signature.asc Description: This is a digitally signed message part.
[PATCH v3] mac80211: Parse legacy and HT rate in injected frames
Drivers/devices without their own rate control algorithm can get the information what rates they should use from either the radiotap header of injected frames or from the rate control algorithm. But the parsing of the legacy rate information from the radiotap header was removed in commit e6a9854b05c1 ("mac80211/drivers: rewrite the rate control API"). The removal of this feature heavily reduced the usefulness of frame injection when wanting to simulate specific transmission behavior. Having rate parsing together with MCS rates and retry support allows a fine grained selection of the tx behavior of injected frames for these kind of tests. Signed-off-by: Sven Eckelmann Cc: Simon Wunderlich --- v3: - switch order of arguments in ieee80211_parse_tx_radiotap - simplify selection of the retry counter - move IEEE80211_TX_CTRL_RATE_INJECT check inside ieee80211_tx_h_rate_ctrl to let it set use_rts, use_cts_prot, short_preamble v2: - resent RFC as v2 because first patch was not correctly marked as RFC - removed check from ieee80211_xmit_fast because this one is never called for injected frames --- Documentation/networking/mac80211-injection.txt | 17 ++ include/net/mac80211.h | 2 + net/mac80211/tx.c | 72 - 3 files changed, 89 insertions(+), 2 deletions(-) diff --git a/Documentation/networking/mac80211-injection.txt b/Documentation/networking/mac80211-injection.txt index 3a93007..ec8f934 100644 --- a/Documentation/networking/mac80211-injection.txt +++ b/Documentation/networking/mac80211-injection.txt @@ -28,6 +28,23 @@ radiotap headers and used to control injection: IEEE80211_RADIOTAP_F_TX_NOACK: frame should be sent without waiting for an ACK even if it is a unicast frame + * IEEE80211_RADIOTAP_RATE + + legacy rate for the transmission (only for devices without own rate control) + + * IEEE80211_RADIOTAP_MCS + + HT rate for the transmission (only for devices without own rate control). + Also some flags are parsed + + IEEE80211_TX_RC_SHORT_GI: use short guard interval + IEEE80211_TX_RC_40_MHZ_WIDTH: send in HT40 mode + + * IEEE80211_RADIOTAP_DATA_RETRIES + + number of retries when either IEEE80211_RADIOTAP_RATE or + IEEE80211_RADIOTAP_MCS was used + The injection code can also skip all other currently defined radiotap fields facilitating replay of captured radiotap headers directly. diff --git a/include/net/mac80211.h b/include/net/mac80211.h index 566df20..3c3c1f3 100644 --- a/include/net/mac80211.h +++ b/include/net/mac80211.h @@ -708,12 +708,14 @@ enum mac80211_tx_info_flags { * protocol frame (e.g. EAP) * @IEEE80211_TX_CTRL_PS_RESPONSE: This frame is a response to a poll * frame (PS-Poll or uAPSD). + * @IEEE80211_TX_CTRL_RATE_INJECT: This frame is injected with rate information * * These flags are used in tx_info->control.flags. */ enum mac80211_tx_control_flags { IEEE80211_TX_CTRL_PORT_CTRL_PROTO = BIT(0), IEEE80211_TX_CTRL_PS_RESPONSE = BIT(1), + IEEE80211_TX_CTRL_RATE_INJECT = BIT(2), }; /* diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c index 3311ce0..723cd7a 100644 --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -710,6 +710,10 @@ ieee80211_tx_h_rate_ctrl(struct ieee80211_tx_data *tx) info->control.short_preamble = txrc.short_preamble; + /* don't ask rate control when rate already injected via radiotap */ + if (info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT) + return TX_CONTINUE; + if (tx->sta) assoc = test_sta_flag(tx->sta, WLAN_STA_ASSOC); @@ -1665,15 +1669,24 @@ void ieee80211_xmit(struct ieee80211_sub_if_data *sdata, ieee80211_tx(sdata, sta, skb, false); } -static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb) +static bool ieee80211_parse_tx_radiotap(struct ieee80211_local *local, + struct sk_buff *skb) { struct ieee80211_radiotap_iterator iterator; struct ieee80211_radiotap_header *rthdr = (struct ieee80211_radiotap_header *) skb->data; struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb); + struct ieee80211_supported_band *sband = + local->hw.wiphy->bands[info->band]; int ret = ieee80211_radiotap_iterator_init(&iterator, rthdr, skb->len, NULL); u16 txflags; + u16 rate = 0; + bool rate_found = false; + u8 rate_retries = 0; + u16 rate_flags = 0; + u8 mcs_known, mcs_flags; + int i; info->flags |= IEEE80211_TX_INTFL_DONT_ENCRYPT | IEEE80211_TX_CTL_DONTFRAG; @@ -1724,6 +1737,35 @@ static bool ieee80211_parse_tx_radiotap(struct sk_buff *skb) info->flags |= IEEE80211_TX_CTL_NO_ACK; break; +
[PATCH] bcma: claim only 14e4:4365 PCI Dell card with SoftMAC BCM43142
It seems 14e4:4365 pattern is too generic as there are two devices: 1) 14e4:4365 1028:0016 with SoftMAC BCM43142 chipset 2) 14e4:4365 14e4:4365 with FullMAC BCM4366 chipset The later one was found in D-Link DIR-885L router and we want to let brcmfmac handle it. Signed-off-by: Rafał Miłecki --- drivers/bcma/host_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/bcma/host_pci.c b/drivers/bcma/host_pci.c index 0856189..cae5385 100644 --- a/drivers/bcma/host_pci.c +++ b/drivers/bcma/host_pci.c @@ -294,7 +294,7 @@ static const struct pci_device_id bcma_pci_bridge_tbl[] = { { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4358) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4359) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4360) }, - { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x4365) }, + { PCI_DEVICE_SUB(PCI_VENDOR_ID_BROADCOM, 0x4365, PCI_VENDOR_ID_DELL, 0x0016) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a0) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43a9) }, { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, 0x43aa) }, -- 1.8.4.5 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: fix txq queue related crashes
On 01/25/2016 10:35 PM, Michal Kazior wrote: On 25 January 2016 at 18:59, Ben Greear wrote: On 01/21/2016 05:23 AM, Michal Kazior wrote: The driver can access the queue simultanously while mac80211 tears down the interface. Without spinlock protection this could lead to corrupting sk_buff_head and subsequently to an invalid pointer dereference. Hard to know for certain, but this *appears* to fix the unexpectedly large amount of CE/AXI ath10k firmware crashes that we saw in the 4.2 kernel (4.0 previously ran much better han 4.2 for us). That's impossible. Without wake_tx_queue() txqs aren't even allocated (sdata->vif.txq is NULL). You are right. But while testing, one of my guys did find a way to reproduce the crash very quickly in 4.2. Happens fastest when I use the HTT-MGT variant of my firmware, but same firmware works good-ish in 4.0. Seems I have something to bisect now if I can get a minimal patch to apply each time to enable my htt-mgt firmware feature... The latest test case is to just to change the channel of the AP while station is connected. Station sends some null-funcs, firmware resets it's low-level stuff a bunch because it doesn't get AKCs, then CE/AXI crashes. Could be my firmware or kernel modifications of course, though similar crash scenarios have been seen forever in all sorts of firmwares and kernels. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.
On 01/26/2016 03:16 AM, Johannes Berg wrote: On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote: --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -2130,6 +2130,8 @@ enum nl80211_attrs { NL80211_ATTR_REG_INDOOR, + NL80211_ATTR_TX_ADVERT_RATEMASK, First of all, this is missing documentation. It's a FLAG as far as I can tell, but if it's set should it affect only the advertised or both? I also think you added this because I had commented that we might not want to do it unconditionally, but is there really a good reason not to do it unconditionally? I was probably more thinking out loud what would happen with P2P, but there we already say "no cck" for scanning so it shouldn't really have any effect. Turns out, I did want this flag. The reason is that I might want to advertise as a normal-ish /g station (ie, full /b/g rateset), but actually fix the TX rate as 24Mbps (or whatever). So, I do need a way to set an advertise ratemask vs a tx-rate-mask. With my current patch, and my patches to supplicant, it seems to at least mostly do what I want, but there is a user-space issue where if you set the ADVERT_RATEMASK on kernels that do not support that flag, it will just set the tx rates instead. Not the end of the world, but possibly there needs to be a feature flag that user-space could query for this feature. But given that we have NL80211_ATTR_SCAN_SUPP_RATES, where does your patch even have an effect, other than this not handling HT/VHT? I'm a bit wary that we're introducing two ways of achieving a very similar thing. Also, adding these overrides all over the code seems very complex. Perhaps we can achieve the goal of being able to pretend to have limited hardware capabilities by actually restricting hardware capabilities instead? That would also avoid having to play whack-a-mole with code paths using the device capabilities. I'd imagine an API along the lines of doing some kind of higher-layer re-register of the wiphy in mac80211 with limited capabilites. At that point you'd allocate a copy of the original capabilities (as far as the new restricted ones overwrite the data), and remove the device from the system as far as higher layers like cfg80211 are concerned. Would something like that work for you? As far as I can tell, that will not work, because I want to have multiple station devices per radio, and have each of them be able to use a different configuration. So, one station may be /g, and another /n and another /AC. Same with APs. In addition, some stations may want to use all available rates for their mode, and others may want to use a fixed rate or subset of available rates. Thanks, Ben johannes -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: Remove the p2p notice of absence info from 10.2.4 FW beacon info
Yanbo Li writes: > The p2p NOA never been supported at 10.2.4 FW, remove it to avoid SWBA > event parse error for multi beacon interval case. > > Signed-off-by: Yanbo Li Applied, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Add support for Per STA Rx duration
Mohammed Shafi Shajakhan writes: > From: Mohammed Shafi Shajakhan > > From: Mohammed Shafi Shajakhan > > *Enable parsing of rx_duration as part of peer stats support > by the new 10.2.4 firmware > *Add support to dump per STA rx_duration (usecs) > *Pre-requisite cleanups > *For calculating total rx-duration in host, enable provision to > support periodic peer stats update. > *Also enable mac80211 debugfs entry to track per STA rx duration(usecs) > > Mohammed Shafi Shajakhan (7): > ath10k: Add support for parsing per STA rx_duration for 10.2.4 > ath10k: Fix naming Peer stats rssi_changed field in 10.2.4 > ath10k: Cleanup setting pdev paramaters > ath10k: Rename few function names of firmware stats > ath10k: Provision to support periodic peer stats update > ath10k: Enable periodic peer stats update > ath10k: Add debugfs support for Per STA total rx duration Applied, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ath10k: prevent txrx running for too long
Michal Kazior writes: > On multicore systems it was possible for the txrx > tasklet to keep on running for long periods of > time on a single CPU due to tx completion > processing. Another CPU could feed the running > tasklet for an indefinite amount of time. > > The tasklet is now guaranteed to run a finite > amount of time and is limited by HTT CE Rx ring > depth. > > This improves behavior when RPS is used on target > system and might improve TCP handling as well. > > Signed-off-by: Michal Kazior Applied, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] dt: bindings: add bindings for ipq4019 wifi block
Raja Mani writes: > Add device tree binding documentation details for wifi block present > in Qualcomm IPQ4019 SoC into "qcom,ath10k.txt". > > Right now, ath10k wireless driver has support for PCI based wlan devices. > There is a plan to extend ath10k driver to support wifi devices which are > connected over AHB as well (enumeration will happen via device tree node). > For AHB based devices (ie, ipq4019), all wifi properties are supplied via > device tree (including irq, reg addr, cal data,etc). > > Signed-off-by: Raja Mani Applied, thanks. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] iwldvm: fix chain gain calibration when firmware return zero values
Hi 2016-01-26 3:28 GMT-05:00 Grumbach, Emmanuel : > > > On 01/26/2016 12:20 AM, Nikolay Martynov wrote: >> It looks like sometimes firmware returns zero for chain noise and signal >> during calibration period. This seems to be a known problem and current >> implementation accounts for this by ignoring invalid data when all chains >> return zero signal and noise. >> >> The problem is that sometimes firmware returns zero for only one chain for >> some (not all) beacons used for calibration. This leads to perfectly valid >> chains be disabled and may cause invalid gain settings. >> For example this is calibration data taken on laptop with Intel 6300 card >> with all three antennas attached: >> >> active_chains: 3 >> chain_noise_a: 312 >> chain_noise_b: 297 >> chain_noise_c: 0 >> chain_signal_a:549 >> chain_signal_b:513 >> chain_signal_c:0 >> beacon_count: 16 >> disconn_array: 0 0 1 >> delta_gain_code: 4 0 0 >> radio_write: 1 >> state: 3 >> >> This patch changes statistics gathering to make sure that zero noise >> results are ignored for valid rx chains. The rationale being that even if >> anntenna is not connected we should be able to see non zero noise if rx >> chain is present. > > But then the firmware will continue to send zero for signal and this > will impact lots > of flows like roaming. If the driver allows the firmware to use that > antenna, the > firmware may use this antenna for scanning and roaming will be broken. > This seems to be a bug in the firmware, but there isn't much I can do > about it. > Sorry, I have to NACK this patch. Could you please elaborate on how this patch would affect roaming or other things. As far as I can see this patch doesn't change much behavior apart from ignoring invalid values from firmware. Disconnected antennas still get disabled (as before) connected antennas still work (more often than before). So I'm not sure I can see how this patch would change what firmware does at all. I really hope you could find a moment and explain this. Thanks! Nikolay. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi 2016-01-26
On 01/26/2016 04:01 PM, Johannes Berg wrote: >>> There's a conflict due to 8f57e4d930d, how should I fix it? > I think we can thus drop my patch - that commit fixes the issue that > Andrew had reported as well, and that I worked around by casting the > result... now that abs() has a consistent result, using s32 in both > sides of the min() is perfectly fine. > > johannes > > I did just that in my new tag: iwlwifi-for-kalle-2016-01-26_2 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature
On Tue, 2016-01-26 at 14:06 +0100, Arend van Spriel wrote: > > +static u8 nl80211_band_to_fwil(enum nl80211_band band) > +{ > + switch (band) { > + case NL80211_BAND_2GHZ: > + return WLC_BAND_2G; > + case NL80211_BAND_5GHZ: > + return WLC_BAND_5G; > + default: > + WARN_ON(1); > This, btw, is trivially triggerable - you need to check in nl80211 that the specified band is actually supported by the driver, otherwise even non-sense like "17" can be specified. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi 2016-01-26
> > There's a conflict due to 8f57e4d930d, how should I fix it? I think we can thus drop my patch - that commit fixes the issue that Andrew had reported as well, and that I worked around by casting the result... now that abs() has a consistent result, using s32 in both sides of the min() is perfectly fine. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi 2016-01-26
Hi Kalle, On 01/26/2016 03:51 PM, Kalle Valo wrote: > "Grumbach, Emmanuel" writes: > >> This is the first round of fixes for 4.5. Most of them are really >> trivial. The TPC stats one stands out a little bit. It can fix traffic >> issues which are typically hard to debug. Please pull and let me know >> if you have issues. > There's a conflict due to 8f57e4d930d, how should I fix it? > > diff --cc drivers/net/wireless/intel/iwlwifi/dvm/calib.c > index e9cef9de9ed8,14949efc4a35.. > --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c > @@@ -900,8 -900,8 +900,13 @@@ static void iwlagn_gain_computation(str > > /* bound gain by 2 bits value max, 3rd bit is sign */ > data->delta_gain_code[i] = > ++<<< HEAD > + min(abs(delta_g), > + (s32) CHAIN_NOISE_MAX_DELTA_GAIN_CODE); > ++=== > + min_t(u8, abs(delta_g), > + CHAIN_NOISE_MAX_DELTA_GAIN_CODE); > ++>>> c3653efc57d9b3c51ee657a471578d2493b6e3f0 > > if (delta_g < 0) > /* > No, I'll rebase. thanks. >> I also have a batch of patches for -next, but >> wireless-drivers-next.git doesn't seem ready to accept new patches at >> this stage. > I'll open wireless-drivers-next once net-next is open, but AFAIK Dave > hasn't opened it yet. > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V4 1/2] nl80211: add feature for BSS selection support
On Tue, 2016-01-26 at 14:06 +0100, Arend van Spriel wrote: > > + * @behaviour: requested BSS selection behaviour. > + * @param: parameters for requestion behaviour. > + * @band_pref: preferred band for > %NL80211_BSS_SELECT_ATTR_BAND_PREF. > + * @adjust: parameters for %NL80211_BSS_SELECT_ATTR_RSSI_ADJUST. Sadly, I don't think this works with kernel-doc. You'd have to split it out into a named union to get this working properly. > +/** > + * enum nl80211_bss_select_attr - attributes for bss selection. > + * > + * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved. > + * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based BSS > selection > + * is requested. > + * @NL80211_BSS_SELECT_ATTR_BAND_PREF: attribute indicating BSS > + *> > selection should be done such that the specified band is preferred. > + *> > When there are multiple BSS-es in the preferred band, the driver > + *> > shall use RSSI-based BSS selection as a second step. The value of > + *> > this attribute is according to &enum nl80211_band (u32). > + * @NL80211_BSS_SELECT_ATTR_RSSI_ADJUST: When present the RSSI level for > + *> > BSS-es in the specified band is to be adjusted before doing > + *> > RSSI-based BSS selection. The attribute value is a packed two-byte > + *> > value. The lower byte contains the adjustment value (s8) and the > + * high byte contains the band according &enum nl80211_band. I think it might be nicer to define an explicit struct for this, then you don't have to use u8 for the band in one attribute and u32 for the band in the other attribute either. As long as there's no u64 in the struct that's pretty much safe - if u64 is needed use compat_u64 :) > + * @NL80211_BSS_SELECT_ATTR_MAX: highest bss select attribute number. > + *@__NL80211_BSS_SELECT_ATTR_AFTER_LAST: internal use. > + * > + * These attributes are found within %NL80211_ATTR_BSS_SELECT and > + * indicate the required BSS selection behaviour which the driver > + * should use. You should probably indicate that only a single one can ever be specified? > +static const struct nla_policy > +nl80211_bss_select_policy[NL80211_BSS_SELECT_ATTR_MAX + 1] = { > + [NL80211_BSS_SELECT_ATTR_RSSI] = { .type = NLA_FLAG }, > + [NL80211_BSS_SELECT_ATTR_BAND_PREF] = { .type = NLA_U32 }, > + [NL80211_BSS_SELECT_ATTR_RSSI_ADJUST] = { .type = NLA_U8 }, The RSSI_ADJUST here seems wrong in any case? Should've been NLA_U16 now? > @@ -5753,6 +5778,42 @@ static int validate_scan_freqs(struct nlattr > *freqs) > return n_channels; > } > > +static int parse_bss_select(struct nlattr *nla, > + struct cfg80211_bss_selection > *bss_select) > +{ > + struct nlattr *attr[NL80211_BSS_SELECT_ATTR_MAX + 1]; > + u16 band_delta; > + int err; This should perhaps reject specification of multiple attributes, since otherwise the order of the code here dictates which one "wins". But these are small things - looks good! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: iwlwifi 2016-01-26
"Grumbach, Emmanuel" writes: > This is the first round of fixes for 4.5. Most of them are really > trivial. The TPC stats one stands out a little bit. It can fix traffic > issues which are typically hard to debug. Please pull and let me know > if you have issues. There's a conflict due to 8f57e4d930d, how should I fix it? diff --cc drivers/net/wireless/intel/iwlwifi/dvm/calib.c index e9cef9de9ed8,14949efc4a35.. --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c @@@ -900,8 -900,8 +900,13 @@@ static void iwlagn_gain_computation(str /* bound gain by 2 bits value max, 3rd bit is sign */ data->delta_gain_code[i] = ++<<< HEAD + min(abs(delta_g), + (s32) CHAIN_NOISE_MAX_DELTA_GAIN_CODE); ++=== + min_t(u8, abs(delta_g), + CHAIN_NOISE_MAX_DELTA_GAIN_CODE); ++>>> c3653efc57d9b3c51ee657a471578d2493b6e3f0 if (delta_g < 0) /* > I also have a batch of patches for -next, but > wireless-drivers-next.git doesn't seem ready to accept new patches at > this stage. I'll open wireless-drivers-next once net-next is open, but AFAIK Dave hasn't opened it yet. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/RFT v4 2/2] mac80211: add NEED_ALIGNED4_SKBS hw flag
On Thu, 2016-01-21 at 10:30 +0100, Janusz Dziedzic wrote: > > +static inline unsigned int > +__ieee80211_hdrlen(struct ieee80211_hw *hw, __le16 fc) { coding style - should have that brace on the next line perhaps this really ought to be called ieee80211_padded_hdrlen() or so instead of just the __. > + unsigned int hdrlen; > + > + hdrlen = ieee80211_hdrlen(fc); > + if (ieee80211_hw_check(hw, NEEDS_ALIGNED4_SKBS)) > + hdrlen += hdrlen & 3; This needs a a comment, it only works because the hdrlen is guaranteed to be a multiple of 2 already. Perhaps it should be & 2 ;-) > - u8 hdr[30 + 2 + IEEE80211_FAST_XMIT_MAX_IV + > - sizeof(rfc1042_header)]; > + u8 hdr[round_up(30 + 2 + IEEE80211_FAST_XMIT_MAX_IV + > + sizeof(rfc1042_header), 4)]; I'm still not sure this is right, given the position of the padding. It probably works since MAX_IV and sizeof() are divisible by 4, but shouldn't it really be round_up(30 + 2, 4) + MAX_IV + sizeof()? > + /* Remove padding if was added */ > + if (ieee80211_hw_check(&local->hw, NEEDS_ALIGNED4_SKBS)) { > + hdrlen = ieee80211_hdrlen(hdr->frame_control); > + padsize = hdrlen & 3; same as above > + /* Check if HW require skb to be aligned */ > + if (ieee80211_hw_check(&sdata->local->hw, > NEEDS_ALIGNED4_SKBS)) > + padsize = hdrlen & 3; > ditto Perhaps also extract this if (...) padsize=... into a helper? Although then the "hdrlen += 0" would remain for !ALIGNED4 drivers. > + if (padsize) > + skb_push(skb, padsize); You should initialize the memory, imho, just in case it goes out anywhere by accident. > + /* Check if aligned skb required */ > + if (ieee80211_hw_check(&local->hw, NEEDS_ALIGNED4_SKBS)) > + build.hdr_len += build.hdr_len & 3; As above. You also need to clarify - IIRC the PN/IV fields are considered part of the MAC header even if we don't really take them into account in hdrlen(), so you should clearly document that the padding is before those. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] mac80211: Parse legacy and HT rate in injected frames
Hi, > CALL_TXH(ieee80211_tx_h_select_key); > - if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL)) > + if (!ieee80211_hw_check(&tx->local->hw, HAS_RATE_CONTROL) && > + !(info->control.flags & IEEE80211_TX_CTRL_RATE_INJECT)) > CALL_TXH(ieee80211_tx_h_rate_ctrl); This seems a bit problematic. ieee80211_tx_h_rate_ctrl() also sets up some protection, e.g. info->control.use_rts = txrc.rts; info->control.use_cts_prot = tx->sdata->vif.bss_conf.use_cts_prot; and preamble settings info->control.short_preamble = txrc.short_preamble; Are you sure you want to skip that entirely? > + info->control.rates[0].flags = rate_flags; > + if (rate_retries + 1 > local->hw.max_rate_tries) > + info->control.rates[0].count = local- > >hw.max_rate_tries; > + else > + info->control.rates[0].count = rate_retries > + 1; max() or max_t()? > /* process and remove the injection radiotap header */ > - if (!ieee80211_parse_tx_radiotap(skb)) > + if (!ieee80211_parse_tx_radiotap(skb, local)) > goto fail; I'd prefer adding "local" as the first argument since that's far more commonly done in mac80211. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Parse legacy and HT rate in injected frames
On Mon, 2016-01-25 at 13:59 +0100, Sven Eckelmann wrote: > > The flag itself has to be set when the radiotap information is > available+parsed and when the actual rate information calculation > should > happen. > > Afaik the ieee80211_tx_data is always a local variable on the stack. > Either > from ieee80211_tx_prepare_skb, ieee80211_tx, ieee80211_xmit_fast or > ieee80211_get_buffered_bc. But the parsing of the radiotap header > happens > before that in ieee80211_monitor_start_xmit. And after that it calls > ieee80211_xmit -> ieee80211_tx. So tx_data is definitely not > available when > the radiotap header is parsed. Fair enough. We could put that data elsewhere, but it's probably not worth it for a simple flag. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] mac80211: add RX_FLAG_MACTIME_PLCP_START
All three applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: fix unnecessary frame drops in mesh fwding
On Mon, 2016-01-25 at 14:43 +0100, Michal Kazior wrote: > The ieee80211_queue_stopped() expects hw queue > number but it was given raw WMM AC number instead. > > This could cause frame drops and problems with > traffic in some cases - most notably if driver > doesn't map AC numbers to queue numbers 1:1 and > uses ieee80211_stop_queues() and > ieee80211_wake_queue() only without ever calling > ieee80211_wake_queues(). > [...] Yeah, this seems right - applied. I put it into mac80211-next since you nobody complained before so it's likely not relevant without your other ath10k patches. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: fix txq queue related crashes
On Thu, 2016-01-21 at 14:23 +0100, Michal Kazior wrote: > The driver can access the queue simultanously > while mac80211 tears down the interface. Without > spinlock protection this could lead to corrupting > sk_buff_head and subsequently to an invalid > pointer dereference. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net:mac80211:mesh_plink: remove redundant sta_info check
On Thu, 2016-01-21 at 11:06 +0530, Sunil Shahu wrote: > Remove unnecessory "if" statement and club it with previos "if" > block. > Applied. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] General RFKill improvements
Hi, On Tue, 2016-01-19 at 10:42 -0500, João Paulo Rechi Vita wrote: > This series contains a few general improvements to the RFKill code, > found while > I was writing the rfkill-all / airplane mode LED trigger. All were > points where > I had to read twice or do some other kind of extra effort to fully > understand > it, so I think merging these changes will benefit someone trying to > understand > the RFKill subsystem in the future. I applied some of this. I think we need to keep the "state" sysfs interface, perhaps you want to document it more clearly. I also didn't apply the first patch since I'd fixed the suspend/pause issue, please see if any of your patches remain relevant and resend that. Thanks, johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC V4 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature
Announce support for nl80211 feature BSS_SELECT and process BSS selection behaviour provided in .connect() callback. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Lei Zhang Signed-off-by: Arend van Spriel --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 -- .../wireless/broadcom/brcm80211/brcmfmac/common.c | 38 +++-- .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 + 3 files changed, 84 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 7b01e4d..d90378e 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -238,6 +238,20 @@ struct parsed_vndr_ies { struct parsed_vndr_ie_info ie_info[VNDR_IE_PARSE_LIMIT]; }; +static u8 nl80211_band_to_fwil(enum nl80211_band band) +{ + switch (band) { + case NL80211_BAND_2GHZ: + return WLC_BAND_2G; + case NL80211_BAND_5GHZ: + return WLC_BAND_5G; + default: + WARN_ON(1); + break; + } + return 0; +} + static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf, struct cfg80211_chan_def *ch) { @@ -1737,6 +1751,43 @@ enum nl80211_auth_type brcmf_war_auth_type(struct brcmf_if *ifp, return type; } +static void brcmf_set_join_pref(struct brcmf_if *ifp, + struct cfg80211_bss_selection *bss_select) +{ + struct brcmf_join_pref_params join_pref_params[2]; + enum nl80211_band band; + int err, i = 0; + + join_pref_params[i].len = 2; + join_pref_params[i].rssi_gain = 0; + switch (bss_select->behaviour) { + case NL80211_BSS_SELECT_ATTR_BAND_PREF: + join_pref_params[i].type = BRCMF_JOIN_PREF_BAND; + band = bss_select->param.band_pref; + join_pref_params[i].band = nl80211_band_to_fwil(band); + i++; + break; + case NL80211_BSS_SELECT_ATTR_RSSI_ADJUST: + join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI_DELTA; + band = bss_select->param.adjust.band; + join_pref_params[i].band = nl80211_band_to_fwil(band); + join_pref_params[i].rssi_gain = bss_select->param.adjust.delta; + i++; + break; + case NL80211_BSS_SELECT_ATTR_RSSI: + default: + break; + } + join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI; + join_pref_params[i].len = 2; + join_pref_params[i].rssi_gain = 0; + join_pref_params[i].band = 0; + err = brcmf_fil_iovar_data_set(ifp, "join_pref", join_pref_params, + sizeof(join_pref_params)); + if (err) + brcmf_err("Set join_pref error (%d)\n", err); +} + static s32 brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev, struct cfg80211_connect_params *sme) @@ -1862,11 +1913,13 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev, ext_join_params->scan_le.scan_type = -1; ext_join_params->scan_le.home_time = cpu_to_le32(-1); - if (sme->bssid) + if (sme->bssid) { memcpy(&ext_join_params->assoc_le.bssid, sme->bssid, ETH_ALEN); - else + brcmf_c_set_joinpref_default(ifp); + } else { eth_broadcast_addr(ext_join_params->assoc_le.bssid); - + brcmf_set_join_pref(ifp, &sme->bss_select); + } if (cfg->channel) { ext_join_params->assoc_le.chanspec_num = cpu_to_le32(1); @@ -6179,6 +6232,10 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp) wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM; wiphy->cipher_suites = __wl_cipher_suites; wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites); + wiphy->bss_select_support = BIT(NL80211_BSS_SELECT_ATTR_RSSI) | + BIT(NL80211_BSS_SELECT_ATTR_BAND_PREF) | + BIT(NL80211_BSS_SELECT_ATTR_RSSI_ADJUST); + wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT | WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL; diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 4265b50..b9e81fb 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -32,7 +32,7 @@ const u8 ALLFFMAC[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; #define BRCMF_DEFAULT_SCAN_CHANNEL_TIME40 #define BRCMF_DEFAULT_SCAN_UNASSOC_TIME40 -/* boost value for RSSI_
[RFC V4 0/2] nl80211: allow configuration of BSS selection
This patch series adds support for configuration of BSS selection done by the driver and/or firmware. It allows user-space to pass selection behaviour with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space does provide this attribute and no explicit BSSID is provided it will pass the BSS selection behaviour to the driver if the driver supports it. When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with same SSID, this can be used to select a BSS. The behaviours defined are: 1. RSSI based selection. 2. Band selection, RSSI based selection. 3. RSSI adjustment in given band, RSSI based selection. V2: - incorporate comments from Johannes Berg (may have missed some). - split nl80211 patch in two separate patches. V3: - remove enum nl80211_bss_select_primitive. - reword documentation of nl80211_bss_select_attr enum values. V4: - remove documentation reference to removed primitive. Arend van Spriel (2): nl80211: add feature for BSS selection support brcmfmac: add support for nl80211 BSS_SELECT feature .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +- .../wireless/broadcom/brcm80211/brcmfmac/common.c | 38 ++- .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 + include/net/cfg80211.h | 34 ++ include/uapi/linux/nl80211.h | 42 net/wireless/core.c| 4 ++ net/wireless/nl80211.c | 76 ++ 7 files changed, 240 insertions(+), 18 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC V4 1/2] nl80211: add feature for BSS selection support
Introducing a new feature that the driver can use to indicate the driver/firmware supports configuration of BSS selection criteria upon CONNECT command. This can be useful when multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with same SSID. The criteria can then be used to offload selection of a preferred BSS. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Lei Zhang Signed-off-by: Arend van Spriel --- include/net/cfg80211.h | 34 include/uapi/linux/nl80211.h | 42 net/wireless/core.c | 4 +++ net/wireless/nl80211.c | 76 4 files changed, 156 insertions(+) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 9bcaaf7..f571f4a 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -1854,6 +1854,33 @@ struct cfg80211_ibss_params { }; /** + * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment. + * + * @band: band of BSS which should match for RSSI level adjustment. + * @delta: value of RSSI level adjustment. + */ +struct cfg80211_bss_select_adjust { + enum nl80211_band band; + s8 delta; +}; + +/** + * struct cfg80211_bss_selection - connection parameters for BSS selection. + * + * @behaviour: requested BSS selection behaviour. + * @param: parameters for requestion behaviour. + * @band_pref: preferred band for %NL80211_BSS_SELECT_ATTR_BAND_PREF. + * @adjust: parameters for %NL80211_BSS_SELECT_ATTR_RSSI_ADJUST. + */ +struct cfg80211_bss_selection { + enum nl80211_bss_select_attr behaviour; + union { + enum nl80211_band band_pref; + struct cfg80211_bss_select_adjust adjust; + } param; +}; + +/** * struct cfg80211_connect_params - Connection parameters * * This structure provides information needed to complete IEEE 802.11 @@ -1888,6 +1915,7 @@ struct cfg80211_ibss_params { * @ht_capa_mask: The bits of ht_capa which are to be used. * @vht_capa: VHT Capability overrides * @vht_capa_mask: The bits of vht_capa which are to be used. + * @bss_select: criteria to be used for BSS selection. */ struct cfg80211_connect_params { struct ieee80211_channel *channel; @@ -1910,6 +1938,7 @@ struct cfg80211_connect_params { struct ieee80211_ht_cap ht_capa_mask; struct ieee80211_vht_cap vht_capa; struct ieee80211_vht_cap vht_capa_mask; + struct cfg80211_bss_selection bss_select; }; /** @@ -3178,6 +3207,9 @@ struct wiphy_vendor_command { * low rssi when a frame is heard on different channel, then it should set * this variable to the maximal offset for which it can compensate. * This value should be set in MHz. + * @bss_select_support: bitmask indicating the BSS selection criteria supported + * by the driver in the .connect() callback. The bit position maps to the + * attribute indices defined in &enum nl80211_bss_select_attr. */ struct wiphy { /* assign these fields before you register the wiphy */ @@ -3300,6 +3332,8 @@ struct wiphy { u8 max_num_csa_counters; u8 max_adj_channel_rssi_comp; + u32 bss_select_support; + char priv[0] __aligned(NETDEV_ALIGN); }; diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 5b7b5eb..f3ece95 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -1789,6 +1789,12 @@ enum nl80211_commands { * thus it must not specify the number of iterations, only the interval * between scans. The scan plans are executed sequentially. * Each scan plan is a nested attribute of &enum nl80211_sched_scan_plan. + * @NL80211_ATTR_BSS_SELECT: nested attribute for driver supporting the + * BSS selection feature. When used with %NL80211_CMD_GET_WIPHY it contains + * NLA_FLAG type according &enum nl80211_bss_select_attr to indicate what + * BSS selection behaviours are supported. When used with %NL80211_CMD_CONNECT + * it contains the behaviour and parameters for BSS selection to be done by + * driver and/or firmware. * * @NUM_NL80211_ATTR: total number of nl80211_attrs available * @NL80211_ATTR_MAX: highest attribute number currently defined @@ -2164,6 +2170,8 @@ enum nl80211_attrs { NL80211_ATTR_MAX_SCAN_PLAN_ITERATIONS, NL80211_ATTR_SCHED_SCAN_PLANS, + NL80211_ATTR_BSS_SELECT, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, @@ -4651,4 +4659,38 @@ enum nl80211_sched_scan_plan { __NL80211_SCHED_SCAN_PLAN_AFTER_LAST - 1 }; +/** + * enum nl80211_bss_select_attr - attributes for bss selection. + * + * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved. + * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based BSS selection + * is requested. + * @NL80211_BSS_SELECT_ATTR_BAND_PREF: attribute indicati
Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers
> I don't see a point in maintaining coherency between the two counters > with regard to each other alone. Do you have a use-case that would > actually make use of that property? > > I'd like to avoid any unnecessary spinlocks. > Make sure you document the lack of consistency between the two values then, please. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: basic support for PBSS network type
> Yes, DMG devices can function as a full AP in addition to PCP. Ok. I'll try to remember :) > Certified 11ad devices must support PBSS, but in theory you can have > 11ad drivers that do not support it. 11ac devices cannot support > it and currently will just ignore this flag, so I think I will add a > feature flag (something like NL80211_EXT_FEATURE_PBSS) and return an > error if the driver does not support this feature. I'd rather return an error when the device isn't 11ad. If it's basically a requirement then I don't think we really need a feature flag, but can just have the driver reject the flag in the meantime. I do want to avoid having a situation where userspace specified PBSS and it gets ignored entirely though. > I have a patch for the wil6210 driver that uses this feature. Do you > prefer that I add the wil6210 driver changes to this patch? Great. No, I don't want bigger wil6210 changes in this patch, so I'd prefer you add a few lines to this patch that make wil6210 reject the configuration with PBSS, and then obviously in the real wil6210 patch remove that again. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers
On 26 January 2016 at 13:04, Felix Fietkau wrote: > On 2016-01-26 12:56, Michal Kazior wrote: >> On 26 January 2016 at 11:45, Felix Fietkau wrote: >>> On 2016-01-21 14:23, Michal Kazior wrote: This will allow drivers to make more educated decisions whether to defer transmission or not. Relying on wake_tx_queue() call count implicitly was not possible because it could be called without queued frame count actually changing on software tx aggregation start/stop code paths. It was also not possible to know how long byte-wise queue was without dequeueing. Signed-off-by: Michal Kazior >>> Instead of exposing these in the struct to the driver directly, please >>> make a function to get them. Since the number of frames is already >>> tracked in txqi->queue, you can avoid counter duplication that way. >> >> Hmm, so you suggest to have something like: [...] >>> Also, that way you can fix a race condition between accessing the number >>> of frames counter and the bytes counter. >> >> I don't see a point in maintaining coherency between the two counters >> with regard to each other alone. Do you have a use-case that would >> actually make use of that property? >> >> I'd like to avoid any unnecessary spinlocks. > OK. I guess we can leave them out for now. How frequently are you going > to call this function? Depends, but with new data path in ath10k[1][2] it'll be at least once for each wake_tx_queue() + once for each txq in each fetch-ind event. Michał [1]: https://patchwork.kernel.org/patch/8081301/ [2]: https://patchwork.kernel.org/patch/8081331/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC V3 0/2] nl80211: allow configuration of BSS selection
On 26-1-2016 11:01, Arend van Spriel wrote: > This patch series adds support for configuration of BSS selection done by > the driver and/or firmware. It allows user-space to pass selection criteria > with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space > does provide this attribute and no explicit BSSID is provided it will pass > the BSS selection criteria to the driver if the driver supports it. > > When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with > same SSID, the criteria can be used to select a BSS. The criteria defined are: > > 1. RSSI based selection. > 2. Band selection, RSSI based selection. > 3. RSSI adjustment in given band, RSSI based selection. > > V2: > - incorporate comments from Johannes Berg (may have missed some). > - split nl80211 patch in two separate patches. > > V3: > - remove enum nl80211_bss_select_primitive. > - reword documentation of nl80211_bss_select_attr enum values. > > Arend van Spriel (3): > nl80211: add extended feature for BSS selection support > nl80211: add bss selection attribute to CONNECT command > brcmfmac: add support for nl80211 BSS_SELECT feature Hmmm. Made a bit of a mess with this version. Let's go to V4. Regards, Arend > .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +- > .../wireless/broadcom/brcm80211/brcmfmac/common.c | 38 ++- > .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 + > include/net/cfg80211.h | 34 ++ > include/uapi/linux/nl80211.h | 42 > net/wireless/core.c| 4 ++ > net/wireless/nl80211.c | 76 > ++ > 7 files changed, 240 insertions(+), 18 deletions(-) > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: basic support for PBSS network type
On 1/26/2016 1:22 PM, Johannes Berg wrote: > On Wed, 2016-01-13 at 11:04 +0200, Lior David wrote: >> >> + * @NL80211_ATTR_PBSS: flag attribute. If set it means operate >> + * in a PBSS. Specified in %NL80211_CMD_CONNECT to request >> + * connecting to a PCP, and in %NL80211_CMD_START_AP to start >> + * a PCP instead of AP. Relevant for DMG networks only. > > I'm continually confused by this; is it possible for DMG devices to be > a "real" AP rather than a PCP? > Yes, DMG devices can function as a full AP in addition to PCP. >> @@ -3461,6 +3462,8 @@ static int nl80211_start_ap(struct sk_buff *skb, >> struct genl_info *info) >> return PTR_ERR(params.acl); >> } >> >> +params.pbss = nla_get_flag(info->attrs[NL80211_ATTR_PBSS]); >> + >> wdev_lock(wdev); >> err = rdev_start_ap(rdev, dev, ¶ms); >> if (!err) { > > This, and the corresponding code in nl80211_connect, really ought to > check that the device is a DMG device and able to do this. > > Perhaps this even needs a capability check, or do we assume that all > devices/drivers will be able to do this (or should reject it?) > Certified 11ad devices must support PBSS, but in theory you can have 11ad drivers that do not support it. 11ac devices cannot support it and currently will just ignore this flag, so I think I will add a feature flag (something like NL80211_EXT_FEATURE_PBSS) and return an error if the driver does not support this feature. > If you want to rely on drivers though you need to have (in this patch!) > a small change to the existing driver to reject the operations if > pbss==true since obviously it cannot be doing the right thing right now > without further changes. That reject would then of course be removed > again with the driver update. I have a patch for the wil6210 driver that uses this feature. Do you prefer that I add the wil6210 driver changes to this patch? Thanks, Lior -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers
On 2016-01-26 12:56, Michal Kazior wrote: > On 26 January 2016 at 11:45, Felix Fietkau wrote: >> On 2016-01-21 14:23, Michal Kazior wrote: >>> This will allow drivers to make more educated >>> decisions whether to defer transmission or not. >>> >>> Relying on wake_tx_queue() call count implicitly >>> was not possible because it could be called >>> without queued frame count actually changing on >>> software tx aggregation start/stop code paths. >>> >>> It was also not possible to know how long >>> byte-wise queue was without dequeueing. >>> >>> Signed-off-by: Michal Kazior >> Instead of exposing these in the struct to the driver directly, please >> make a function to get them. Since the number of frames is already >> tracked in txqi->queue, you can avoid counter duplication that way. > > Hmm, so you suggest to have something like: > > void > ieee80211_get_txq_depth(struct ieee80211_txq *txq, > unsigned int *frame_cnt, > unsigned int *byte_count) { >struct txq_info *txqi = txq_to_info(txq); > >if (frame_cnt) > *frame_cnt = txqi->queue.qlen; > >if (byte_count) > *byte_cnt = txqi->byte_cnt; > } > > Correct? > > Sounds reasonable. Right. >> Also, that way you can fix a race condition between accessing the number >> of frames counter and the bytes counter. > > I don't see a point in maintaining coherency between the two counters > with regard to each other alone. Do you have a use-case that would > actually make use of that property? > > I'd like to avoid any unnecessary spinlocks. OK. I guess we can leave them out for now. How frequently are you going to call this function? - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers
On 26 January 2016 at 11:45, Felix Fietkau wrote: > On 2016-01-21 14:23, Michal Kazior wrote: >> This will allow drivers to make more educated >> decisions whether to defer transmission or not. >> >> Relying on wake_tx_queue() call count implicitly >> was not possible because it could be called >> without queued frame count actually changing on >> software tx aggregation start/stop code paths. >> >> It was also not possible to know how long >> byte-wise queue was without dequeueing. >> >> Signed-off-by: Michal Kazior > Instead of exposing these in the struct to the driver directly, please > make a function to get them. Since the number of frames is already > tracked in txqi->queue, you can avoid counter duplication that way. Hmm, so you suggest to have something like: void ieee80211_get_txq_depth(struct ieee80211_txq *txq, unsigned int *frame_cnt, unsigned int *byte_count) { struct txq_info *txqi = txq_to_info(txq); if (frame_cnt) *frame_cnt = txqi->queue.qlen; if (byte_count) *byte_cnt = txqi->byte_cnt; } Correct? Sounds reasonable. > Also, that way you can fix a race condition between accessing the number > of frames counter and the bytes counter. I don't see a point in maintaining coherency between the two counters with regard to each other alone. Do you have a use-case that would actually make use of that property? I'd like to avoid any unnecessary spinlocks. Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: let unused MPP table entries timeout
On Tue, 2016-01-19 at 09:04 +0100, Henning Rogge wrote: > +++ b/net/mac80211/mesh_pathtbl.c > @@ -929,12 +929,55 @@ int mesh_path_del(struct ieee80211_sub_if_data > *sdata, const u8 *addr) > if (mpath->sdata == sdata && > ether_addr_equal(addr, mpath->dst)) { > __mesh_path_del(tbl, node); > - goto enddel; > + goto enddelpath; C labels are scoped, why rename it? > } > } > > err = -ENXIO; > -enddel: > +enddelpath: > + mesh_paths_generation++; > + spin_unlock(&tbl->hashwlock[hash_idx]); > + read_unlock_bh(&pathtbl_resize_lock); > + return err; > +} > + > +/** > + * mpp_path_del - delete a mesh proxy path from the table > + * > + * @addr: addr address (ETH_ALEN length) > + * @sdata: local subif > + * > + * Returns: 0 if successful > + */ > +static int mpp_path_del(struct ieee80211_sub_if_data *sdata, const > u8 *addr) > +{ > + struct mesh_table *tbl; > + struct mesh_path *mpath; > + struct mpath_node *node; > + struct hlist_head *bucket; > + int hash_idx; > + int err = 0; > + > + /* flush relevant mpp entries first */ > + mpp_flush_by_proxy(sdata, addr); > + > + read_lock_bh(&pathtbl_resize_lock); > + tbl = resize_dereference_mpp_paths(); > + hash_idx = mesh_table_hash(addr, sdata, tbl); > + bucket = &tbl->hash_buckets[hash_idx]; > + > + spin_lock(&tbl->hashwlock[hash_idx]); > + hlist_for_each_entry(node, bucket, list) { > + mpath = node->mpath; > + if (mpath->sdata == sdata && > + ether_addr_equal(addr, mpath->dst)) { > + __mesh_path_del(tbl, node); > + goto enddelmpp; This has the same use-after-free, I'd say? And another instance later in this file. > + spin_lock_bh(&mppath- > >state_lock); > + mppath->exp_time = jiffies; That locking seems fairly pointless? You only write to this value here, and it's an unsigned long, so in itself it's atomic and there's no synchronisation against anything else needed. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mac80211: Remove connected MPP table entries with MPath
On Tue, 2016-01-19 at 09:04 +0100, Henning Rogge wrote: > > +static void mpp_flush_by_proxy(struct ieee80211_sub_if_data *sdata, > + const u8 *proxy) > +{ > + struct mesh_table *tbl; > + struct mesh_path *mpp; > + struct mpath_node *node; > + int i; > + > + rcu_read_lock(); > + read_lock_bh(&pathtbl_resize_lock); > + tbl = resize_dereference_mpp_paths(); > + for_each_mesh_entry(tbl, node, i) { It does not seem to me that the rcu_read_lock() above is necessary or correct, though it's probably not hurting it should be removed to avoid having misleading code. > + mpp = node->mpath; > + if (ether_addr_equal(mpp->mpp, proxy)) { > + spin_lock(&tbl->hashwlock[i]); > + __mesh_path_del(tbl, node); > + spin_unlock(&tbl->hashwlock[i]); It also doesn't seem like for_each_mesh_entry() can deal with "node" getting deleted from underneath it? It accesses it through hlist_next_rcu() after the deletion, so you have a use-after-free here afaict. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/26] libceph: Use skcipher
On Tue, Jan 26, 2016 at 12:29:57PM +0100, Ilya Dryomov wrote: > > LGTM. You want to take it through crypto? That's probably the easiest route since I'd like to take the first patch through cryptodev. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/26] libceph: Use skcipher
On Tue, Jan 26, 2016 at 11:54 AM, Herbert Xu wrote: > On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote: >> >> Could you get rid of ivsize instead of assigning to it - see the >> attached diff? > > How about an incremental patch like this? Thanks! > > ---8<--- > From: Ilya Dryomov > Subject: libceph: Remove unnecessary ivsize variables > > This patch removes the unnecessary ivsize variabls as they always > have the value of AES_BLOCK_SIZE. > > Signed-off-by: Ilya Dryomov > > diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c > index fb9cb2b..db2847a 100644 > --- a/net/ceph/crypto.c > +++ b/net/ceph/crypto.c > @@ -166,8 +166,7 @@ static int ceph_aes_encrypt(const void *key, int key_len, > struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); > SKCIPHER_REQUEST_ON_STACK(req, tfm); > int ret; > - int ivsize = AES_BLOCK_SIZE; > - char iv[ivsize]; > + char iv[AES_BLOCK_SIZE]; > size_t zero_padding = (0x10 - (src_len & 0x0f)); > char pad[16]; > > @@ -186,7 +185,7 @@ static int ceph_aes_encrypt(const void *key, int key_len, > goto out_tfm; > > crypto_skcipher_setkey((void *)tfm, key, key_len); > - memcpy(iv, aes_iv, ivsize); > + memcpy(iv, aes_iv, AES_BLOCK_SIZE); > > skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); > @@ -229,8 +228,7 @@ static int ceph_aes_encrypt2(const void *key, int > key_len, void *dst, > struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); > SKCIPHER_REQUEST_ON_STACK(req, tfm); > int ret; > - int ivsize = AES_BLOCK_SIZE; > - char iv[ivsize]; > + char iv[AES_BLOCK_SIZE]; > size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f)); > char pad[16]; > > @@ -250,7 +248,7 @@ static int ceph_aes_encrypt2(const void *key, int > key_len, void *dst, > goto out_tfm; > > crypto_skcipher_setkey((void *)tfm, key, key_len); > - memcpy(iv, aes_iv, ivsize); > + memcpy(iv, aes_iv, AES_BLOCK_SIZE); > > skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); > @@ -294,8 +292,7 @@ static int ceph_aes_decrypt(const void *key, int key_len, > struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); > SKCIPHER_REQUEST_ON_STACK(req, tfm); > char pad[16]; > - int ivsize = AES_BLOCK_SIZE; > - char iv[16]; > + char iv[AES_BLOCK_SIZE]; > int ret; > int last_byte; > > @@ -310,7 +307,7 @@ static int ceph_aes_decrypt(const void *key, int key_len, > goto out_tfm; > > crypto_skcipher_setkey((void *)tfm, key, key_len); > - memcpy(iv, aes_iv, ivsize); > + memcpy(iv, aes_iv, AES_BLOCK_SIZE); > > skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); > @@ -363,8 +360,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len, > struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); > SKCIPHER_REQUEST_ON_STACK(req, tfm); > char pad[16]; > - int ivsize = AES_BLOCK_SIZE; > - char iv[ivsize]; > + char iv[AES_BLOCK_SIZE]; > int ret; > int last_byte; > > @@ -380,7 +376,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len, > goto out_tfm; > > crypto_skcipher_setkey((void *)tfm, key, key_len); > - memcpy(iv, aes_iv, ivsize); > + memcpy(iv, aes_iv, AES_BLOCK_SIZE); > > skcipher_request_set_tfm(req, tfm); > skcipher_request_set_callback(req, 0, NULL, NULL); LGTM. You want to take it through crypto? Thanks, Ilya -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: basic support for PBSS network type
On Wed, 2016-01-13 at 11:04 +0200, Lior David wrote: > > + * @NL80211_ATTR_PBSS: flag attribute. If set it means operate > + * in a PBSS. Specified in %NL80211_CMD_CONNECT to request > + * connecting to a PCP, and in %NL80211_CMD_START_AP to start > + * a PCP instead of AP. Relevant for DMG networks only. I'm continually confused by this; is it possible for DMG devices to be a "real" AP rather than a PCP? > @@ -3461,6 +3462,8 @@ static int nl80211_start_ap(struct sk_buff *skb, > struct genl_info *info) > return PTR_ERR(params.acl); > } > > + params.pbss = nla_get_flag(info->attrs[NL80211_ATTR_PBSS]); > + > wdev_lock(wdev); > err = rdev_start_ap(rdev, dev, ¶ms); > if (!err) { This, and the corresponding code in nl80211_connect, really ought to check that the device is a DMG device and able to do this. Perhaps this even needs a capability check, or do we assume that all devices/drivers will be able to do this (or should reject it?) If you want to rely on drivers though you need to have (in this patch!) a small change to the existing driver to reject the operations if pbss==true since obviously it cannot be doing the right thing right now without further changes. That reject would then of course be removed again with the driver update. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2 2/2] mac80211: ensure association req uses configured ratemask.
On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote: > From: Ben Greear > > When sending the association request, pay attention to the > legacy rates configured by the user, and do not advertise support > for any that are not configured. > > This makes the assoc request packet look more correct when > making modern hardware act like a /b mode station, for instance. > This is what I meant by "playing whack-a-mole" :) Next you'll have to fix TDLS too, etc. I feel that overall this is too complex and we need to address this at a lower level, to actually get the capabilities that all the code already looks at into the restricted state you need for this kind of testing. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2 1/2] mac80211: Take bitrates into account when building IEs.
On Tue, 2015-10-20 at 10:24 -0700, gree...@candelatech.com wrote: > --- a/include/uapi/linux/nl80211.h > +++ b/include/uapi/linux/nl80211.h > @@ -2130,6 +2130,8 @@ enum nl80211_attrs { > > NL80211_ATTR_REG_INDOOR, > > + NL80211_ATTR_TX_ADVERT_RATEMASK, First of all, this is missing documentation. It's a FLAG as far as I can tell, but if it's set should it affect only the advertised or both? I also think you added this because I had commented that we might not want to do it unconditionally, but is there really a good reason not to do it unconditionally? I was probably more thinking out loud what would happen with P2P, but there we already say "no cck" for scanning so it shouldn't really have any effect. But given that we have NL80211_ATTR_SCAN_SUPP_RATES, where does your patch even have an effect, other than this not handling HT/VHT? I'm a bit wary that we're introducing two ways of achieving a very similar thing. Also, adding these overrides all over the code seems very complex. Perhaps we can achieve the goal of being able to pretend to have limited hardware capabilities by actually restricting hardware capabilities instead? That would also avoid having to play whack-a-mole with code paths using the device capabilities. I'd imagine an API along the lines of doing some kind of higher-layer re-register of the wiphy in mac80211 with limited capabilites. At that point you'd allocate a copy of the original capabilities (as far as the new restricted ones overwrite the data), and remove the device from the system as far as higher layers like cfg80211 are concerned. Would something like that work for you? johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
UBSAN: Undefined behaviour in net/mac80211/rx.c:924:18
4.5.0-rc1 another UBSAN error: [ 4845.229441] [ 4845.229454] UBSAN: Undefined behaviour in net/mac80211/rx.c:924:18 [ 4845.229458] load of value 2 is not a valid value for type '_Bool' [ 4845.229464] CPU: 1 PID: 6266 Comm: kworker/u16:8 Not tainted 4.5.0-rc1 #252 [ 4845.229468] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015 [ 4845.229491] Workqueue: phy2 rt2x00usb_work_rxdone [ 4845.229493] 0002 8801b13c39f8 [ 4845.229496] 81b2e7d9 0007 8801b13c3a20 8801b13c3a10 [ 4845.229498] 81bcb87d 85016890 8801b13c3a60 81bcc279 [ 4845.229501] Call Trace: [ 4845.229506] [] dump_stack+0x45/0x6c [ 4845.229510] [] ubsan_epilogue+0xd/0x40 [ 4845.229513] [] __ubsan_handle_load_invalid_value+0x69/0x80 [ 4845.229517] [] ? xhci_setup_addressable_virt_dev+0xeb2/0x13b0 [ 4845.229520] [] ? pick_next_entity+0xcb/0x280 [ 4845.229524] [] ieee80211_sta_reorder_release.isra.15+0x7e3/0xad0 [ 4845.229527] [] ieee80211_prepare_and_rx_handle+0x11a7/0x2ab0 [ 4845.229530] [] ? xhci_urb_enqueue+0x394/0x1140 [ 4845.229533] [] ? usb_hcd_map_urb_for_dma+0x94f/0x1140 [ 4845.229537] [] ? skb_release_data+0x117/0x2f0 [ 4845.229539] [] __ieee80211_rx_handle_packet+0x26a/0x9a0 [ 4845.229542] [] ? __kmalloc_reserve.isra.11+0x2c/0x80 [ 4845.229545] [] ieee80211_rx_napi+0x651/0x12b0 [ 4845.229549] [] rt2x00lib_rxdone+0x402/0x1120 [ 4845.229552] [] ? dequeue_task_fair+0x97f/0x41d0 [ 4845.229554] [] rt2x00usb_work_rxdone+0xac/0x1f0 [ 4845.229558] [] ? __schedule+0x5cd/0x1770 [ 4845.229561] [] process_one_work+0x266/0xc00 [ 4845.229563] [] worker_thread+0x96/0xd40 [ 4845.229565] [] ? process_scheduled_works+0x70/0x70 [ 4845.229568] [] kthread+0x108/0x180 [ 4845.229571] [] ? kthread_create_on_node+0x210/0x210 [ 4845.229573] [] ret_from_fork+0x3f/0x70 [ 4845.229576] [] ? kthread_create_on_node+0x210/0x210 [ 4845.229577] -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
UBSAN: Undefined behaviour in net/mac80211/rc80211_minstrel.h:47:34
4.5.0-rc1 with the new UBSAN checker: [ 2624.978741] [ 2624.978749] UBSAN: Undefined behaviour in net/mac80211/rc80211_minstrel.h:47:34 [ 2624.978752] signed integer overflow: [ 2624.978754] -32768 * 100 cannot be represented in type 'int' [ 2624.978759] CPU: 1 PID: 5362 Comm: kworker/u16:2 Not tainted 4.5.0-rc1 #252 [ 2624.978762] Hardware name: Apple Inc. MacBookPro10,2/Mac-AFD8A9D944EA4843, BIOS MBP102.88Z.0106.B0A.1509130955 09/13/2015 [ 2624.978770] Workqueue: phy1 rt2800usb_work_txdone [ 2624.978773] 000f4240 8801e5d23990 [ 2624.978778] 81b2e7d9 0007 8801e5d239c0 8801e5d239a8 [ 2624.978782] 81bcb87d 850b928c 8801e5d23a30 81bcbc4d [ 2624.978785] Call Trace: [ 2624.978792] [] dump_stack+0x45/0x6c [ 2624.978797] [] ubsan_epilogue+0xd/0x40 [ 2624.978802] [] handle_overflow+0xbd/0xe0 [ 2624.978807] [] ? number+0x35f/0x600 [ 2624.978812] [] __ubsan_handle_mul_overflow+0xe/0x10 [ 2624.978819] [] minstrel_calc_rate_stats+0x58c/0x5f0 [ 2624.978823] [] minstrel_ht_update_stats.isra.4+0x148/0xdd0 [ 2624.978827] [] minstrel_ht_tx_status+0x683/0x1120 [ 2624.978832] [] ieee80211_tx_status+0xff8/0x2d10 [ 2624.978836] [] rt2x00lib_txdone+0x42c/0x11a0 [ 2624.978841] [] ? update_curr+0x15a/0x400 [ 2624.978846] [] rt2800_txdone_entry+0xc5/0x1b0 [ 2624.978850] [] rt2800usb_work_txdone+0x6ff/0xbb0 [ 2624.978854] [] process_one_work+0x266/0xc00 [ 2624.978857] [] worker_thread+0x96/0xd40 [ 2624.978861] [] ? process_scheduled_works+0x70/0x70 [ 2624.978865] [] kthread+0x108/0x180 [ 2624.978869] [] ? kthread_create_on_node+0x210/0x210 [ 2624.978874] [] ret_from_fork+0x3f/0x70 [ 2624.978878] [] ? kthread_create_on_node+0x210/0x210 [ 2624.978880] -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211: Fix some linguistics in Kconfig
Applied, thanks! johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull-request: mac80211 2016-01-26
Hi Dave, After split up the patches from the previous pull request that was lost in the process, here's a new one with fixes for the current cycle (I'll follow up with a -next one later.) I've also scripted my pull-request sending process a bit more, so hopefully the emails will no longer have any unexpected UTF-8 contents that tripped up patchwork :) Let me know if there's any problem. Thanks, johannes The following changes since commit 701a0fd5231866db08cebcd502894699f49cb960: hip04_eth: fix missing error handle for build_skb failed (2016-01-13 15:48:14 -0500) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git tags/mac80211-for-davem-2016-01-26 for you to fetch changes up to 6736fde9672ff6717ac576e9bba2fd5f3dfec822: rfkill: fix rfkill_fop_read wait_event usage (2016-01-26 11:32:05 +0100) Here's a first set of fixes for the 4.5-rc cycle: * make regulatory messages much less verbose by default * various remain-on-channel fixes * scheduled scanning fixes with hardware restart * a PS-Poll handling fix; was broken just recently * bugfix to avoid buffering non-bufferable MMPDUs * world regulatory domain data fix * a fix for scanning causing other work to get stuck * hwsim: revert an older problematic patch that caused some userspace tools to have issues - not that big a deal as it's a debug only driver though Bob Copeland (1): Revert "mac80211_hwsim: support any address in userspace" Dave Young (1): wireless: change cfg80211 regulatory domain info as debug messages Eliad Peller (3): mac80211: avoid ROC during hw restart mac80211: clear local->sched_scan_req properly on reconfig mac80211: handle sched_scan_stopped vs. hw restart race Emmanuel Grumbach (1): mac80211: fix PS-Poll handling Helmut Schaa (1): mac80211: Don't buffer non-bufferable MMPDUs Johannes Berg (4): mac80211: recalculate SW ROC only when needed mac80211: fix remain-on-channel cancellation regulatory: fix world regulatory domain data rfkill: fix rfkill_fop_read wait_event usage Sachin Kulkarni (1): mac80211: Requeue work after scan complete for all VIF types. drivers/net/wireless/mac80211_hwsim.c | 5 ++-- net/mac80211/ibss.c | 1 - net/mac80211/main.c | 6 + net/mac80211/mesh.c | 11 - net/mac80211/mesh.h | 4 net/mac80211/mlme.c | 2 -- net/mac80211/offchannel.c | 16 +++-- net/mac80211/scan.c | 20 +++- net/mac80211/sta_info.c | 2 +- net/mac80211/status.c | 5 net/mac80211/util.c | 16 ++--- net/rfkill/core.c | 16 - net/wireless/reg.c| 45 +++ 13 files changed, 85 insertions(+), 64 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 16/26] libceph: Use skcipher
On Mon, Jan 25, 2016 at 05:18:47PM +0100, Ilya Dryomov wrote: > > Could you get rid of ivsize instead of assigning to it - see the > attached diff? How about an incremental patch like this? Thanks! ---8<--- From: Ilya Dryomov Subject: libceph: Remove unnecessary ivsize variables This patch removes the unnecessary ivsize variabls as they always have the value of AES_BLOCK_SIZE. Signed-off-by: Ilya Dryomov diff --git a/net/ceph/crypto.c b/net/ceph/crypto.c index fb9cb2b..db2847a 100644 --- a/net/ceph/crypto.c +++ b/net/ceph/crypto.c @@ -166,8 +166,7 @@ static int ceph_aes_encrypt(const void *key, int key_len, struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); SKCIPHER_REQUEST_ON_STACK(req, tfm); int ret; - int ivsize = AES_BLOCK_SIZE; - char iv[ivsize]; + char iv[AES_BLOCK_SIZE]; size_t zero_padding = (0x10 - (src_len & 0x0f)); char pad[16]; @@ -186,7 +185,7 @@ static int ceph_aes_encrypt(const void *key, int key_len, goto out_tfm; crypto_skcipher_setkey((void *)tfm, key, key_len); - memcpy(iv, aes_iv, ivsize); + memcpy(iv, aes_iv, AES_BLOCK_SIZE); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL); @@ -229,8 +228,7 @@ static int ceph_aes_encrypt2(const void *key, int key_len, void *dst, struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); SKCIPHER_REQUEST_ON_STACK(req, tfm); int ret; - int ivsize = AES_BLOCK_SIZE; - char iv[ivsize]; + char iv[AES_BLOCK_SIZE]; size_t zero_padding = (0x10 - ((src1_len + src2_len) & 0x0f)); char pad[16]; @@ -250,7 +248,7 @@ static int ceph_aes_encrypt2(const void *key, int key_len, void *dst, goto out_tfm; crypto_skcipher_setkey((void *)tfm, key, key_len); - memcpy(iv, aes_iv, ivsize); + memcpy(iv, aes_iv, AES_BLOCK_SIZE); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL); @@ -294,8 +292,7 @@ static int ceph_aes_decrypt(const void *key, int key_len, struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); SKCIPHER_REQUEST_ON_STACK(req, tfm); char pad[16]; - int ivsize = AES_BLOCK_SIZE; - char iv[16]; + char iv[AES_BLOCK_SIZE]; int ret; int last_byte; @@ -310,7 +307,7 @@ static int ceph_aes_decrypt(const void *key, int key_len, goto out_tfm; crypto_skcipher_setkey((void *)tfm, key, key_len); - memcpy(iv, aes_iv, ivsize); + memcpy(iv, aes_iv, AES_BLOCK_SIZE); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL); @@ -363,8 +360,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len, struct crypto_skcipher *tfm = ceph_crypto_alloc_cipher(); SKCIPHER_REQUEST_ON_STACK(req, tfm); char pad[16]; - int ivsize = AES_BLOCK_SIZE; - char iv[ivsize]; + char iv[AES_BLOCK_SIZE]; int ret; int last_byte; @@ -380,7 +376,7 @@ static int ceph_aes_decrypt2(const void *key, int key_len, goto out_tfm; crypto_skcipher_setkey((void *)tfm, key, key_len); - memcpy(iv, aes_iv, ivsize); + memcpy(iv, aes_iv, AES_BLOCK_SIZE); skcipher_request_set_tfm(req, tfm); skcipher_request_set_callback(req, 0, NULL, NULL); -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] mac80211: expose txq queue depth and size to drivers
On 2016-01-21 14:23, Michal Kazior wrote: > This will allow drivers to make more educated > decisions whether to defer transmission or not. > > Relying on wake_tx_queue() call count implicitly > was not possible because it could be called > without queued frame count actually changing on > software tx aggregation start/stop code paths. > > It was also not possible to know how long > byte-wise queue was without dequeueing. > > Signed-off-by: Michal Kazior Instead of exposing these in the struct to the driver directly, please make a function to get them. Since the number of frames is already tracked in txqi->queue, you can avoid counter duplication that way. Also, that way you can fix a race condition between accessing the number of frames counter and the bytes counter. - Felix -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mac80211: Requeue work after scan complete for all VIF types.
On Tue, 2016-01-12 at 14:30 +0530, Sachin Kulkarni wrote: > From: Sachin Kulkarni > > During a sw scan ieee80211_iface_work ignores work items for all > vifs. > However after the scan complete work is requeued only for STA, ADHOC > and MESH iftypes. > > This occasionally results in event processing getting delayed/not > processed for iftype AP when it coexists with a STA. This can result > in data halt and eventually disconnection on the AP interface. > Applied. I added a Cc stable tag - I don't think the commit message (hw vs. sw scan) matters that much. johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rfkill: fix rfkill_fop_read wait_event usage
From: Johannes Berg The code within wait_event_interruptible() is called with !TASK_RUNNING, so mustn't call any functions that can sleep, like mutex_lock(). Since we re-check the list_empty() in a loop after the wait, it's safe to simply use list_empty() without locking. This bug has existed forever, but was only discovered now because all userspace implementations, including the default 'rfkill' tool, use poll() or select() to get a readable fd before attempting to read. Cc: sta...@vger.kernel.org Fixes: c64fb01627e24 ("rfkill: create useful userspace interface") Reported-by: Dmitry Vyukov Signed-off-by: Johannes Berg --- net/rfkill/core.c | 16 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/net/rfkill/core.c b/net/rfkill/core.c index f53bf3b6558b..cf5b69ab1829 100644 --- a/net/rfkill/core.c +++ b/net/rfkill/core.c @@ -1095,17 +1095,6 @@ static unsigned int rfkill_fop_poll(struct file *file, poll_table *wait) return res; } -static bool rfkill_readable(struct rfkill_data *data) -{ - bool r; - - mutex_lock(&data->mtx); - r = !list_empty(&data->events); - mutex_unlock(&data->mtx); - - return r; -} - static ssize_t rfkill_fop_read(struct file *file, char __user *buf, size_t count, loff_t *pos) { @@ -1122,8 +,11 @@ static ssize_t rfkill_fop_read(struct file *file, char __user *buf, goto out; } mutex_unlock(&data->mtx); + /* since we re-check and it just compares pointers, +* using !list_empty() without locking isn't a problem +*/ ret = wait_event_interruptible(data->read_wait, - rfkill_readable(data)); + !list_empty(&data->events)); mutex_lock(&data->mtx); if (ret) -- 2.6.2 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 13/13] ath10k: implement push-pull tx
On 22 January 2016 at 08:47, Michal Kazior wrote: > On 21 January 2016 at 18:40, Peter Oh wrote: >> On 01/21/2016 05:46 AM, Michal Kazior wrote: [...] >>> - /* TODO: apply configuration */ >>> + rcu_read_unlock(); >>> + >>> + spin_lock_bh(&ar->htt.tx_lock); >>> + ath10k_mac_tx_lock(ar, ATH10K_TX_PAUSE_Q_FLUSH_PENDING); >>> + spin_unlock_bh(&ar->htt.tx_lock); >>> + >> >> Isn't it proved it break Mesh from working? > > Yes, good point. I'm still working on this - I should've mentioned > that in the cover letter. > > Nonetheless I wanted to get the review process going for this patchset. > > I'll address the mesh problem in v2. For the record - the problem turned out to be a bug in mac80211 mesh fwding, see: https://patchwork.kernel.org/patch/8108711/ Michał -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] iwlwifi: dvm: calib.c: fix min() warning
From: Johannes Berg Depending on the system, kernel, architecture abs() might return long or not - just use min_t(u8, ...) to avoid any warnings. Reported-by: Andrew Morton Signed-off-by: Johannes Berg Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/intel/iwlwifi/dvm/calib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c index 07a4c64..14949ef 100644 --- a/drivers/net/wireless/intel/iwlwifi/dvm/calib.c +++ b/drivers/net/wireless/intel/iwlwifi/dvm/calib.c @@ -900,8 +900,8 @@ static void iwlagn_gain_computation(struct iwl_priv *priv, /* bound gain by 2 bits value max, 3rd bit is sign */ data->delta_gain_code[i] = - min(abs(delta_g), - (long) CHAIN_NOISE_MAX_DELTA_GAIN_CODE); + min_t(u8, abs(delta_g), + CHAIN_NOISE_MAX_DELTA_GAIN_CODE); if (delta_g < 0) /* -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/5] iwlwifi: mvm: rs: fix TPC statistics handling
From: Gregory Greenman FW behaviour changed and now updates driver about the used TPC reduction in the following cases: 1. In tx response, which is used mostly for a single frame case 2. In BA notification When tx aggregation fails with the initial rate, FW will send to the driver BA notification and will try to transmit with the next rate, but this time without tx power reduction. Thus, in case of a failure with the initial rate, driver will get two BA notifications, the first one with reduced tx power as in the LQ command and the second one with 0 power reduction. This patch adapts the TPC statistics according to the description above: 1. Use BA notifications instead of Tx response 2. For TPC only, drop the optimization which considers empty BA as one MPDU. The reason is that with TPC we want to recover very quickly from a bad power reduction and, therefore we'd like the success ratio to get an immediate hit when failing to get a BA, so we'd switch back to a lower or zero power reduction Signed-off-by: Gregory Greenman Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 6 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 74 ++ drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 5 +- 3 files changed, 56 insertions(+), 29 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h index 0036d18..ba3f0bb 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h @@ -510,6 +510,9 @@ struct iwl_mvm_tx_resp { * @scd_ssn: the index of the last contiguously sent packet * @txed: number of Txed frames in this batch * @txed_2_done: number of Acked frames in this batch + * @reduced_txp: power reduced according to TPC. This is the actual value and + * not a copy from the LQ command. Thus, if not the first rate was used + * for Tx-ing then this value will be set to 0 by FW. */ struct iwl_mvm_ba_notif { __le32 sta_addr_lo32; @@ -524,7 +527,8 @@ struct iwl_mvm_ba_notif { __le16 scd_ssn; u8 txed; u8 txed_2_done; - __le16 reserved1; + u8 reduced_txp; + u8 reserved1; } __packed; /* diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c index 7bb6fd0..94caa88 100644 --- a/drivers/net/wireless/intel/iwlwifi/mvm/rs.c +++ b/drivers/net/wireless/intel/iwlwifi/mvm/rs.c @@ -2,6 +2,7 @@ * * Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved. * Copyright(c) 2013 - 2015 Intel Mobile Communications GmbH + * Copyright(c) 2016 Intel Deutschland GmbH * * This program is free software; you can redistribute it and/or modify it * under the terms of version 2 of the GNU General Public License as @@ -724,14 +725,28 @@ static int _rs_collect_tx_data(struct iwl_mvm *mvm, return 0; } -static int rs_collect_tx_data(struct iwl_mvm *mvm, - struct iwl_lq_sta *lq_sta, - struct iwl_scale_tbl_info *tbl, - int scale_index, int attempts, int successes, - u8 reduced_txp) +static int rs_collect_tpc_data(struct iwl_mvm *mvm, + struct iwl_lq_sta *lq_sta, + struct iwl_scale_tbl_info *tbl, + int scale_index, int attempts, int successes, + u8 reduced_txp) +{ + struct iwl_rate_scale_data *window = NULL; + + if (WARN_ON_ONCE(reduced_txp > TPC_MAX_REDUCTION)) + return -EINVAL; + + window = &tbl->tpc_win[reduced_txp]; + return _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes, + window); +} + +static int rs_collect_tlc_data(struct iwl_mvm *mvm, + struct iwl_lq_sta *lq_sta, + struct iwl_scale_tbl_info *tbl, + int scale_index, int attempts, int successes) { struct iwl_rate_scale_data *window = NULL; - int ret; if (scale_index < 0 || scale_index >= IWL_RATE_COUNT) return -EINVAL; @@ -745,16 +760,6 @@ static int rs_collect_tx_data(struct iwl_mvm *mvm, /* Select window for current tx bit rate */ window = &(tbl->win[scale_index]); - - ret = _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes, - window); - if (ret) - return ret; - - if (WARN_ON_ONCE(reduced_txp > TPC_MAX_REDUCTION)) - return -EINVAL; - - window = &tbl->tpc_win[reduced_txp]; return _rs_collect_tx_data(mvm, tbl, scale_index, attempts, successes, window); } @@ -1301,17 +1306,30 @@ void iwl_mvm_rs_tx_status(struct iwl_mvm *mvm, struct ieee80211_sta *sta,
[PATCH 1/5] iwlwifi: add new 3168 series devices support
From: Oren Givon Add new sub-system PCI IDs to the 3168 series. Added 0x2010, 0x2050 and 0x2150 sub-system IDs. Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 6261a68..944e88a 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -378,7 +378,10 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x3165, 0x8110, iwl3165_2ac_cfg)}, /* 3168 Series */ + {IWL_PCI_DEVICE(0x24FB, 0x2010, iwl3168_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FB, 0x2110, iwl3168_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24FB, 0x2050, iwl3168_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24FB, 0x2150, iwl3168_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FB, 0x, iwl3168_2ac_cfg)}, /* 7265 Series */ -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] iwlwifi: update support for 3168 series firmware and NVM
From: Oren Givon Update the struct which defines the support for 3168 cards. Now it will search for a firmware of this format: iwlwifi-3168-XX.ucode Also, set the minimum version of the ucode to 20. Update the minimum NVM version and minimum NVM calibrations version of the 3168 series. Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 23 +++ 1 file changed, 19 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-7000.c b/drivers/net/wireless/intel/iwlwifi/iwl-7000.c index e60cf14..fa41a5e 100644 --- a/drivers/net/wireless/intel/iwlwifi/iwl-7000.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-7000.c @@ -74,16 +74,19 @@ #define IWL7260_UCODE_API_MAX 17 #define IWL7265_UCODE_API_MAX 17 #define IWL7265D_UCODE_API_MAX 20 +#define IWL3168_UCODE_API_MAX 20 /* Oldest version we won't warn about */ #define IWL7260_UCODE_API_OK 13 #define IWL7265_UCODE_API_OK 13 #define IWL7265D_UCODE_API_OK 13 +#define IWL3168_UCODE_API_OK 20 /* Lowest firmware API version supported */ #define IWL7260_UCODE_API_MIN 13 #define IWL7265_UCODE_API_MIN 13 #define IWL7265D_UCODE_API_MIN 13 +#define IWL3168_UCODE_API_MIN 20 /* NVM versions */ #define IWL7260_NVM_VERSION0x0a1d @@ -92,6 +95,8 @@ #define IWL3160_TX_POWER_VERSION 0x /* meaningless */ #define IWL3165_NVM_VERSION0x709 #define IWL3165_TX_POWER_VERSION 0x /* meaningless */ +#define IWL3168_NVM_VERSION0xd01 +#define IWL3168_TX_POWER_VERSION 0x /* meaningless */ #define IWL7265_NVM_VERSION0x0a1d #define IWL7265_TX_POWER_VERSION 0x /* meaningless */ #define IWL7265D_NVM_VERSION 0x0c11 @@ -109,6 +114,9 @@ #define IWL3160_FW_PRE "iwlwifi-3160-" #define IWL3160_MODULE_FIRMWARE(api) IWL3160_FW_PRE __stringify(api) ".ucode" +#define IWL3168_FW_PRE "iwlwifi-3168-" +#define IWL3168_MODULE_FIRMWARE(api) IWL3168_FW_PRE __stringify(api) ".ucode" + #define IWL7265_FW_PRE "iwlwifi-7265-" #define IWL7265_MODULE_FIRMWARE(api) IWL7265_FW_PRE __stringify(api) ".ucode" @@ -180,6 +188,12 @@ static const struct iwl_ht_params iwl7000_ht_params = { .ucode_api_ok = IWL7265_UCODE_API_OK, \ .ucode_api_min = IWL7265_UCODE_API_MIN +#define IWL_DEVICE_3008\ + IWL_DEVICE_7000_COMMON, \ + .ucode_api_max = IWL3168_UCODE_API_MAX, \ + .ucode_api_ok = IWL3168_UCODE_API_OK, \ + .ucode_api_min = IWL3168_UCODE_API_MIN + #define IWL_DEVICE_7005D \ IWL_DEVICE_7000_COMMON, \ .ucode_api_max = IWL7265D_UCODE_API_MAX,\ @@ -299,11 +313,11 @@ const struct iwl_cfg iwl3165_2ac_cfg = { const struct iwl_cfg iwl3168_2ac_cfg = { .name = "Intel(R) Dual Band Wireless AC 3168", - .fw_name_pre = IWL7265D_FW_PRE, - IWL_DEVICE_7000, + .fw_name_pre = IWL3168_FW_PRE, + IWL_DEVICE_3008, .ht_params = &iwl7000_ht_params, - .nvm_ver = IWL3165_NVM_VERSION, - .nvm_calib_ver = IWL3165_TX_POWER_VERSION, + .nvm_ver = IWL3168_NVM_VERSION, + .nvm_calib_ver = IWL3168_TX_POWER_VERSION, .pwr_tx_backoffs = iwl7265_pwr_tx_backoffs, .dccm_len = IWL7265_DCCM_LEN, }; @@ -376,5 +390,6 @@ const struct iwl_cfg iwl7265d_n_cfg = { MODULE_FIRMWARE(IWL7260_MODULE_FIRMWARE(IWL7260_UCODE_API_OK)); MODULE_FIRMWARE(IWL3160_MODULE_FIRMWARE(IWL7260_UCODE_API_OK)); +MODULE_FIRMWARE(IWL3168_MODULE_FIRMWARE(IWL3168_UCODE_API_OK)); MODULE_FIRMWARE(IWL7265_MODULE_FIRMWARE(IWL7265_UCODE_API_OK)); MODULE_FIRMWARE(IWL7265D_MODULE_FIRMWARE(IWL7265D_UCODE_API_OK)); -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] iwlwifi: add device ID for 8265
From: Oren Givon Signed-off-by: Oren Givon Signed-off-by: Emmanuel Grumbach --- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c index 944e88a..00335ea 100644 --- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c @@ -478,6 +478,7 @@ static const struct pci_device_id iwl_hw_card_ids[] = { {IWL_PCI_DEVICE(0x24F3, 0x, iwl8265_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x0010, iwl8265_2ac_cfg)}, {IWL_PCI_DEVICE(0x24FD, 0x8010, iwl8265_2ac_cfg)}, + {IWL_PCI_DEVICE(0x24FD, 0x0810, iwl8265_2ac_cfg)}, /* 9000 Series */ {IWL_PCI_DEVICE(0x9DF0, 0x2A10, iwl5165_2ac_cfg)}, -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
pull request: iwlwifi 2016-01-26
Hi Kalle, This is the first round of fixes for 4.5. Most of them are really trivial. The TPC stats one stands out a little bit. It can fix traffic issues which are typically hard to debug. Please pull and let me know if you have issues. I also have a batch of patches for -next, but wireless-drivers-next.git doesn't seem ready to accept new patches at this stage. Thanks! The following changes since commit aee3bfa3307cd0da2126bdc0ea359dabea5ee8f7: Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next (2016-01-12 18:57:02 -0800) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes.git tags/iwlwifi-for-kalle-2016-01-26 for you to fetch changes up to a0d792850af3257d9b4b1dbf4e3df57994a481e7: iwlwifi: mvm: rs: fix TPC statistics handling (2016-01-25 14:42:11 +0200) * Fix support for 3168 device + NVM version + firmware file name + device IDs * Fix a compilation warning in dvm calibration code * Fix the TPC (reduced Tx Power) code. This fixes performance issues * Device IDs for 8265 Gregory Greenman (1): iwlwifi: mvm: rs: fix TPC statistics handling Johannes Berg (1): iwlwifi: dvm: calib.c: fix min() warning Oren Givon (3): iwlwifi: add new 3168 series devices support iwlwifi: add device ID for 8265 iwlwifi: update support for 3168 series firmware and NVM drivers/net/wireless/intel/iwlwifi/dvm/calib.c | 4 ++-- drivers/net/wireless/intel/iwlwifi/iwl-7000.c | 23 +++ drivers/net/wireless/intel/iwlwifi/mvm/fw-api-tx.h | 6 +- drivers/net/wireless/intel/iwlwifi/mvm/rs.c| 74 -- drivers/net/wireless/intel/iwlwifi/mvm/tx.c| 5 +++-- drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 4 6 files changed, 81 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: net/rfkill: WARNING in rfkill_fop_read
On Tue, 2016-01-26 at 10:55 +0100, Dmitry Vyukov wrote: > Hello, > > The following program triggers WARNING message in rfkill_fop_read: > > [ cut here ] > WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663 > __might_sleep+0x138/0x1a0() > do not call blocking ops when !TASK_RUNNING; state=1 set at > [] prepare_to_wait_event+0x141/0x410 > kernel/sched/wait.c:210 > [< inline >] rfkill_readable net/rfkill/core.c:1102 Yeah, this should not acquire the mutex ... but luckily it's not a problem not to anyway, so it's easy to fix. Thanks! I'll send out a fix once I've tested it. > // autogenerated by syzkaller (http://github.com/google/syzkaller) gotta love the raw mmap etc. :) johannes -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC V3 0/2] nl80211: allow configuration of BSS selection
This patch series adds support for configuration of BSS selection done by the driver and/or firmware. It allows user-space to pass selection criteria with the NL80211_CMD_CONNECT using NL80211_ATTR_BSS_SELECT. When user-space does provide this attribute and no explicit BSSID is provided it will pass the BSS selection criteria to the driver if the driver supports it. When multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with same SSID, the criteria can be used to select a BSS. The criteria defined are: 1. RSSI based selection. 2. Band selection, RSSI based selection. 3. RSSI adjustment in given band, RSSI based selection. V2: - incorporate comments from Johannes Berg (may have missed some). - split nl80211 patch in two separate patches. V3: - remove enum nl80211_bss_select_primitive. - reword documentation of nl80211_bss_select_attr enum values. Arend van Spriel (3): nl80211: add extended feature for BSS selection support nl80211: add bss selection attribute to CONNECT command brcmfmac: add support for nl80211 BSS_SELECT feature .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 +- .../wireless/broadcom/brcm80211/brcmfmac/common.c | 38 ++- .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 + include/net/cfg80211.h | 34 ++ include/uapi/linux/nl80211.h | 42 net/wireless/core.c| 4 ++ net/wireless/nl80211.c | 76 ++ 7 files changed, 240 insertions(+), 18 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC V3 2/2] brcmfmac: add support for nl80211 BSS_SELECT feature
Announce support for nl80211 feature BSS_SELECT and process BSS selection behaviour provided in .connect() callback. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Lei Zhang Signed-off-by: Arend van Spriel --- .../broadcom/brcm80211/brcmfmac/cfg80211.c | 63 -- .../wireless/broadcom/brcm80211/brcmfmac/common.c | 38 +++-- .../wireless/broadcom/brcm80211/brcmfmac/core.h| 1 + 3 files changed, 84 insertions(+), 18 deletions(-) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c index 7b01e4d..d90378e 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c @@ -238,6 +238,20 @@ struct parsed_vndr_ies { struct parsed_vndr_ie_info ie_info[VNDR_IE_PARSE_LIMIT]; }; +static u8 nl80211_band_to_fwil(enum nl80211_band band) +{ + switch (band) { + case NL80211_BAND_2GHZ: + return WLC_BAND_2G; + case NL80211_BAND_5GHZ: + return WLC_BAND_5G; + default: + WARN_ON(1); + break; + } + return 0; +} + static u16 chandef_to_chanspec(struct brcmu_d11inf *d11inf, struct cfg80211_chan_def *ch) { @@ -1737,6 +1751,43 @@ enum nl80211_auth_type brcmf_war_auth_type(struct brcmf_if *ifp, return type; } +static void brcmf_set_join_pref(struct brcmf_if *ifp, + struct cfg80211_bss_selection *bss_select) +{ + struct brcmf_join_pref_params join_pref_params[2]; + enum nl80211_band band; + int err, i = 0; + + join_pref_params[i].len = 2; + join_pref_params[i].rssi_gain = 0; + switch (bss_select->behaviour) { + case NL80211_BSS_SELECT_ATTR_BAND_PREF: + join_pref_params[i].type = BRCMF_JOIN_PREF_BAND; + band = bss_select->param.band_pref; + join_pref_params[i].band = nl80211_band_to_fwil(band); + i++; + break; + case NL80211_BSS_SELECT_ATTR_RSSI_ADJUST: + join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI_DELTA; + band = bss_select->param.adjust.band; + join_pref_params[i].band = nl80211_band_to_fwil(band); + join_pref_params[i].rssi_gain = bss_select->param.adjust.delta; + i++; + break; + case NL80211_BSS_SELECT_ATTR_RSSI: + default: + break; + } + join_pref_params[i].type = BRCMF_JOIN_PREF_RSSI; + join_pref_params[i].len = 2; + join_pref_params[i].rssi_gain = 0; + join_pref_params[i].band = 0; + err = brcmf_fil_iovar_data_set(ifp, "join_pref", join_pref_params, + sizeof(join_pref_params)); + if (err) + brcmf_err("Set join_pref error (%d)\n", err); +} + static s32 brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev, struct cfg80211_connect_params *sme) @@ -1862,11 +1913,13 @@ brcmf_cfg80211_connect(struct wiphy *wiphy, struct net_device *ndev, ext_join_params->scan_le.scan_type = -1; ext_join_params->scan_le.home_time = cpu_to_le32(-1); - if (sme->bssid) + if (sme->bssid) { memcpy(&ext_join_params->assoc_le.bssid, sme->bssid, ETH_ALEN); - else + brcmf_c_set_joinpref_default(ifp); + } else { eth_broadcast_addr(ext_join_params->assoc_le.bssid); - + brcmf_set_join_pref(ifp, &sme->bss_select); + } if (cfg->channel) { ext_join_params->assoc_le.chanspec_num = cpu_to_le32(1); @@ -6179,6 +6232,10 @@ static int brcmf_setup_wiphy(struct wiphy *wiphy, struct brcmf_if *ifp) wiphy->signal_type = CFG80211_SIGNAL_TYPE_MBM; wiphy->cipher_suites = __wl_cipher_suites; wiphy->n_cipher_suites = ARRAY_SIZE(__wl_cipher_suites); + wiphy->bss_select_support = BIT(NL80211_BSS_SELECT_ATTR_RSSI) | + BIT(NL80211_BSS_SELECT_ATTR_BAND_PREF) | + BIT(NL80211_BSS_SELECT_ATTR_RSSI_ADJUST); + wiphy->flags |= WIPHY_FLAG_PS_ON_BY_DEFAULT | WIPHY_FLAG_OFFCHAN_TX | WIPHY_FLAG_HAS_REMAIN_ON_CHANNEL; diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 4265b50..b9e81fb 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -32,7 +32,7 @@ const u8 ALLFFMAC[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }; #define BRCMF_DEFAULT_SCAN_CHANNEL_TIME40 #define BRCMF_DEFAULT_SCAN_UNASSOC_TIME40 -/* boost value for RSSI_
[RFC V3 1/2] nl80211: add feature for BSS selection support
Introducing a new feature that the driver can use to indicate the driver/firmware supports configuration of BSS selection criteria upon CONNECT command. This can be useful when multiple BSS-es are found belonging to the same ESS, ie. Infra-BSS with same SSID. The criteria can then be used to offload selection of a preferred BSS. Reviewed-by: Hante Meuleman Reviewed-by: Franky (Zhenhui) Lin Reviewed-by: Pieter-Paul Giesberts Reviewed-by: Lei Zhang Signed-off-by: Arend van Spriel --- include/net/cfg80211.h | 34 include/uapi/linux/nl80211.h | 42 net/wireless/core.c | 4 +++ net/wireless/nl80211.c | 76 4 files changed, 156 insertions(+) diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 9bcaaf7..b4c1bf4 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -1854,6 +1854,33 @@ struct cfg80211_ibss_params { }; /** + * struct cfg80211_bss_select_adjust - BSS selection with RSSI adjustment. + * + * @band: band of BSS which should match for RSSI level adjustment. + * @delta: value of RSSI level adjustment. + */ +struct cfg80211_bss_select_adjust { + enum nl80211_band band; + s8 delta; +}; + +/** + * struct cfg80211_bss_selection - connection parameters for BSS selection. + * + * @behaviour: requested BSS selection behaviour. + * @param: parameters for given primitive. + * @band_pref: preferred band for %BSS_SELECT_BAND_PREF primitive. + * @adjust: parameters for %BSS_SELECT_ADJUST_RSSI primitive. + */ +struct cfg80211_bss_selection { + enum nl80211_bss_select_attr behaviour; + union { + enum nl80211_band band_pref; + struct cfg80211_bss_select_adjust adjust; + } param; +}; + +/** * struct cfg80211_connect_params - Connection parameters * * This structure provides information needed to complete IEEE 802.11 @@ -1888,6 +1915,7 @@ struct cfg80211_ibss_params { * @ht_capa_mask: The bits of ht_capa which are to be used. * @vht_capa: VHT Capability overrides * @vht_capa_mask: The bits of vht_capa which are to be used. + * @bss_select: criteria to be used for BSS selection. */ struct cfg80211_connect_params { struct ieee80211_channel *channel; @@ -1910,6 +1938,7 @@ struct cfg80211_connect_params { struct ieee80211_ht_cap ht_capa_mask; struct ieee80211_vht_cap vht_capa; struct ieee80211_vht_cap vht_capa_mask; + struct cfg80211_bss_selection bss_select; }; /** @@ -3178,6 +3207,9 @@ struct wiphy_vendor_command { * low rssi when a frame is heard on different channel, then it should set * this variable to the maximal offset for which it can compensate. * This value should be set in MHz. + * @bss_select_support: bitmask indicating the BSS selection criteria supported + * by the driver in the .connect() callback. The bit position maps to the + * criteria defined in &enum nl80211_bss_select_primitive. */ struct wiphy { /* assign these fields before you register the wiphy */ @@ -3300,6 +3332,8 @@ struct wiphy { u8 max_num_csa_counters; u8 max_adj_channel_rssi_comp; + u32 bss_select_support; + char priv[0] __aligned(NETDEV_ALIGN); }; diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 5b7b5eb..e9f5ae7 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -1789,6 +1789,12 @@ enum nl80211_commands { * thus it must not specify the number of iterations, only the interval * between scans. The scan plans are executed sequentially. * Each scan plan is a nested attribute of &enum nl80211_sched_scan_plan. + * @NL80211_ATTR_BSS_SELECT: nested attribute for driver supporting the + * extended feature %NL80211_EXT_FEATURE_BSS_SELECT. When used with + * %NL80211_CMD_GET_WIPHY is contains NLA_FLAG type according + * &enum nl80211_bss_select_attr to indicate what primitives are + * supported. When used with %NL80211_CMD_CONNECT is contains the behaviour + * and parameters for BSS selection to be done by driver and/or firmware. * * @NUM_NL80211_ATTR: total number of nl80211_attrs available * @NL80211_ATTR_MAX: highest attribute number currently defined @@ -2164,6 +2170,8 @@ enum nl80211_attrs { NL80211_ATTR_MAX_SCAN_PLAN_ITERATIONS, NL80211_ATTR_SCHED_SCAN_PLANS, + NL80211_ATTR_BSS_SELECT, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, @@ -4651,4 +4659,38 @@ enum nl80211_sched_scan_plan { __NL80211_SCHED_SCAN_PLAN_AFTER_LAST - 1 }; +/** + * enum nl80211_bss_select_attr - attributes for bss selection. + * + * @__NL80211_BSS_SELECT_ATTR_INVALID: reserved. + * @NL80211_BSS_SELECT_ATTR_RSSI: Flag indicating only RSSI-based BSS selection + * is requested. + * @NL80211_BSS_SELECT_ATTR_BAND_PREF: attribute indicating
net/rfkill: WARNING in rfkill_fop_read
Hello, The following program triggers WARNING message in rfkill_fop_read: [ cut here ] WARNING: CPU: 2 PID: 6975 at kernel/sched/core.c:7663 __might_sleep+0x138/0x1a0() do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait_event+0x141/0x410 kernel/sched/wait.c:210 Modules linked in: CPU: 2 PID: 6975 Comm: a.out Not tainted 4.5.0-rc1+ #283 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011 88003369f908 8299a06d 88003369f978 8800338e 864453c0 88003369f948 8134fcf9 813c9cf8 ed00066d3f2b 864453c0 1def Call Trace: [< inline >] __dump_stack lib/dump_stack.c:15 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482 [] warn_slowpath_fmt+0xa9/0xd0 kernel/panic.c:494 [] __might_sleep+0x138/0x1a0 kernel/sched/core.c:7658 [] mutex_lock_nested+0x74/0xa50 kernel/locking/mutex.c:617 [< inline >] rfkill_readable net/rfkill/core.c:1102 [] rfkill_fop_read+0x23d/0x3e0 net/rfkill/core.c:1125 [] do_loop_readv_writev+0x141/0x1e0 fs/read_write.c:719 [] do_readv_writev+0x5f8/0x6e0 fs/read_write.c:849 [] vfs_readv+0x83/0xb0 fs/read_write.c:873 [< inline >] SYSC_readv fs/read_write.c:899 [] SyS_readv+0x111/0x2b0 fs/read_write.c:891 [] entry_SYSCALL_64_fastpath+0x16/0x7a arch/x86/entry/entry_64.S:185 ---[ end trace 8fc3336c73e4219c ]--- // autogenerated by syzkaller (http://github.com/google/syzkaller) #include #include #include #include #include #include #include #include #include #include long r[8]; void* thr(void* arg) { switch ((long)arg) { case 0: r[0] = syscall(SYS_mmap, 0x2000ul, 0x5ul, 0x3ul, 0x32ul, 0xul, 0x0ul); break; case 1: r[2] = open("/dev/rfkill", O_RDWR); break; case 2: *(uint64_t*)0x20042fe0 = (uint64_t)0x20042ff9; *(uint64_t*)0x20042fe8 = (uint64_t)0x7; *(uint64_t*)0x20042ff0 = (uint64_t)0x20032fa1; *(uint64_t*)0x20042ff8 = (uint64_t)0xf4; r[7] = syscall(SYS_readv, r[2], 0x20042fe0ul, 0x2ul, 0, 0, 0); break; } return 0; } void worker() { long i; pthread_t th[3]; memset(r, -1, sizeof(r)); for (i = 0; i < 3; i++) { pthread_create(&th[i], 0, thr, (void*)i); usleep(1); } for (i = 0; i < 3; i++) { pthread_create(&th[i], 0, thr, (void*)i); if (i % 2 == 0) usleep(1); } usleep(10); } int main() { int i, status, pids[16]; for (;;) { for (i = 0; i < 16; i++) { if ((pids[i] = fork()) == 0) { worker(); exit(0); } } for (i = 0; i < 16; i++) { while (waitpid(pids[i], &status, __WALL) != pids[i]) { } } } return 0; } On commit 92e963f50fc74041b5e9e744c330dca48e04f08d (Jan 24). -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: wilc1000: fix alignment for open parenthesis
This patch fixes the check found by checkpatch.pl CHECK: Alignment should match open parenthesis Signed-off-by: Chaehyun Lim --- drivers/staging/wilc1000/host_interface.c | 90 +++ 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/drivers/staging/wilc1000/host_interface.c b/drivers/staging/wilc1000/host_interface.c index 98627a6..716f359 100644 --- a/drivers/staging/wilc1000/host_interface.c +++ b/drivers/staging/wilc1000/host_interface.c @@ -303,7 +303,7 @@ static s32 handle_set_channel(struct wilc_vif *vif, PRINT_D(HOSTINF_DBG, "Setting channel\n"); result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if (result) { PRINT_ER("Failed to set channel\n"); @@ -350,7 +350,7 @@ static s32 handle_set_operation_mode(struct wilc_vif *vif, wid.size = sizeof(u32); result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if ((hif_op_mode->mode) == IDLE_MODE) up(&hif_sema_driver); @@ -383,7 +383,7 @@ static s32 handle_set_ip_address(struct wilc_vif *vif, u8 *ip_addr, u8 idx) wid.size = IP_ALEN; result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); host_int_get_ipaddress(vif, firmware_ip_addr, idx); @@ -408,7 +408,7 @@ static s32 handle_get_ip_address(struct wilc_vif *vif, u8 idx) wid.size = IP_ALEN; result = wilc_send_config_pkt(vif->wilc, GET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); PRINT_INFO(HOSTINF_DBG, "%pI4\n", wid.val); @@ -451,7 +451,7 @@ static s32 handle_set_mac_address(struct wilc_vif *vif, PRINT_D(GENERIC_DBG, "mac addr = :%pM\n", wid.val); result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if (result) { PRINT_ER("Failed to set mac address\n"); result = -EFAULT; @@ -473,7 +473,7 @@ static s32 handle_get_mac_address(struct wilc_vif *vif, wid.size = ETH_ALEN; result = wilc_send_config_pkt(vif->wilc, GET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if (result) { PRINT_ER("Failed to get mac address\n"); @@ -939,7 +939,7 @@ static s32 Handle_ScanDone(struct wilc_vif *vif, wid.size = sizeof(char); result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if (result) { PRINT_ER("Failed to set abort running scan\n"); @@ -1356,7 +1356,7 @@ static s32 Handle_ConnectTimeout(struct wilc_vif *vif) PRINT_D(HOSTINF_DBG, "Sending disconnect request\n"); result = wilc_send_config_pkt(vif->wilc, SET_CFG, &wid, 1, -wilc_get_vif_idx(vif)); + wilc_get_vif_idx(vif)); if (result) PRINT_ER("Failed to send dissconect config packet\n"); @@ -1750,8 +1750,8 @@ static int Handle_Key(struct wilc_vif *vif, strWIDList[3].val = (s8 *)pu8keybuf; result = wilc_send_config_pkt(vif->wilc, SET_CFG, - strWIDList, 4, - wilc_get_vif_idx(vif)); + strWIDList, 4, + wilc_get_vif_idx(vif)); kfree(pu8keybuf); } else if (pstrHostIFkeyAttr->action & ADDKEY) { PRINT_D(HOSTINF_DBG, "Handling WEP key\n"); @@ -1772,8 +1772,8 @@ static int Handle_Key(struct wilc_vif *vif, wid.size = pstrHostIFkeyAttr->attr.wep.key_len + 2; result = wilc_send_config_pkt(vif->wilc, SET_CFG, - &wid, 1, - wilc_get_vif_idx(vif)); + &wid, 1, + wilc_get_vif_idx(vif)); kfree(pu8keybuf); } else if (pstrHostIFkeyAttr->action & REMOVEKEY) { PRINT_D(HOSTINF_DBG, "Removing key\n"); @@ -1785,8 +1785,8 @@ sta